Monitoring routerów Teltonika w LibreNMS bez lawiny fałszywych alarmów

Routery brzegowe Teltonika w sieciach rozproszonych generują dziesiątki alertów dziennie, gdy prosty ping ICMP kończy się niepowodzeniem. Taki monitoring nie pokazuje przyczyny problemu – czy to chwilowy spadek sygnału LTE, restart stacji bazowej operatora, czy rzeczywista awaria interfejsu. W efekcie administratorzy tracą czas na weryfikację nieistotnych zdarzeń, zamiast skupić się na krytycznych incydentach.

Jakie sygnały z routera Teltonika mają wartość diagnostyczną?

Zamiast polegać na samym pingu, warto sięgnąć po bardziej szczegółowe dane. Kluczowe jest monitorowanie statusu operacyjnego interfejsu (ifOperStatus), który jednoznacznie wskazuje, czy port jest aktywny (wartość 1), czy nie (wartość 2). Równie ważne są metryki transferu danych, takie jak ifInOctets i ifOutOctets. Ich analiza pozwala wykryć nagły spadek ruchu poniżej ustalonego progu, który może sygnalizować problem z łączem nawet gdy interfejs pozostaje aktywny. W przypadku tuneli VPN należy śledzić ich status, by wiedzieć, czy połączenie jest stabilne. Dla łącz komórkowych najważniejsza jest jednak jakość sygnału, opisywana przez wskaźniki RSSI, RSRP oraz SINR, dostępne w TELTONIKA-MIB (np. OID 1.3.6.1.4.1.48690.2.4).

Te metryki pomagają odróżnić problemy zewnętrzne od wewnętrznych. Na przykład RSSI poniżej -100 dBm wskazuje na słaby zasięg, ale jeśli router nie zmienia operatora, prawdopodobną przyczyną jest restart stacji bazowej, a nie awaria karty SIM.

Jak ograniczyć fałszywe alarmy w LibreNMS?

System LibreNMS domyślnie odpytuje urządzenia co 5 minut. W przypadku routerów LTE warto wydłużyć ten interwał do 10 minut, by uniknąć alarmów wywołanych chwilowymi wahaniami sygnału. Kluczowe jest też inteligentne ustawienie progów w regułach. Zamiast reagować na pojedynczy odczyt, można zdefiniować alert dla sygnału RSRP poniżej -95 dBm utrzymującego się przez trzy kolejne cykle odpytywania, z dodatkowym 15-minutowym opóźnieniem notyfikacji. Warunki logiczne pozwalają łączyć metryki: alarm jest wysyłany tylko wtedy, gdy jednocześnie ifOperStatus=down, ruch spadnie poniżej 5% średniej, a sygnał spadnie poniżej -100 dBm.

Aby zachować porządek w systemie, warto nadać monitorowanym metrykom czytelne nazwy. Przykładowo, dla routerów teltonika OID 1.3.6.1.4.1.48690.2.4 można opisać jako „Poziom sygnału LTE”. Pozwoli to na przypisanie zdarzeń do zrozumiałych kategorii, takich jak „Słaby sygnał” (alert informacyjny, zapisywany w historii) czy „Awaria interfejsu” (alert krytyczny, wymagający eskalacji).

W scenariuszach z łączem zapasowym, jak w firmach z wieloma oddziałami, priorytetem jest monitorowanie przełączenia. Alert powinien być wyzwalany tylko wtedy, gdy oba łącza są nieaktywne lub główne łącze ma słaby sygnał przez dłuższy czas bez uruchomienia zapasu. Zdarzenia takie jak restart stacji bazowej operatora można natomiast zapisywać tylko w historii zdarzeń.

Prawidłowo skonfigurowany monitoring routera pozwala odróżnić chwilowe zakłócenia od rzeczywistych awarii, co minimalizuje liczbę fałszywych alarmów i wspiera administratora w podejmowaniu trafnych decyzji. Zamiast polegać na prostym pingu, kluczowe jest skupienie się na metrykach jakości sygnału i ruchu sieciowego. Dzięki temu można reagować tylko na zdarzenia, które naprawdę tego wymagają.