Documentation
Table of Contents
2 Agent SNMP
Przegląd
Z monitorowania SNMP można skorzystać przy urządzeniach takich jak drukarki, przełączniki sieciowe, routery czy UPS-y, które zazwyczaj mają włączoną obsługę SNMP a w których niepraktyczne jest instalowanie kompletnego systemu operacyjnego i agentów Zabbix.
Żeby mieć możliwość odczytania danych udostępnianych przez agentów SNMP na tych urządzeniach, serwer Zabbix musi być wstępnie skompilowany z obsługą SNMP.
Testy SNMP wykonywane są tylko z wykorzystaniem protokołu UDP.
Jeżeli monitorujemy urządzenia SNMPv3, należy się upewnić, że msgAuthoritativeEngineID (znany również jako snmpEngineID lub "Engine ID") nie jest współdzielony przez dwa urządzenia. Zgodnie z RFC 2571 (rozdział 3.1.1.1) musi być unikalny dla każdego urządzenia.
O ile poprzednio dla uwierzytelniania i prywatności SNMPv3 obsługiwane były jedynie protokoły MD5 i DES, to począwszy od Zabbix 2.2 obsługiwane są protokół uwierzytelniania SHA i protokół prywatności AES.
Począwszy od wersji 2.2 demony serwera i proxy Zabbix poprawnie używają parametru konfiguracji Timeout podczas wykonywania testów SNMP. Dodatkowo demony nie będą wykonywały powtórek po pojedynczym nieprawidłowym (opóźnienie/złe uprawnienia) zapytaniu SNMP. Poprzednio używane były bieżące opóźnienie i ilość powtórzeń z biblioteki SNMP (1 sekunda i 5 powtórzeń).
Począwszy od wersji 2.2.8 demony serwera i proxy Zabbix zawsze powtórzą przynajmniej jeden raz: albo poprzez mechanizm powtarzania biblioteki SNMP albo poprzez wewnętrzny mechanizm przetwarzania zbiorczego.
Począwszy od wersji 2.2.3 demony serwera i proxy Zabbix pytają urządzenia SNMP o wiele wartości w jednym zapytaniu. Działa to dla wielu rodzajów pozycji SNMP (zwykłe pozycje SNMP, pozycje SNMP z dynamicznymi indeksami oraz niskopoziomowe wykrywanie SNMP) a przetwarzanie SNMP powinno być znacznie wydajniejsze. Jak to działa można zobaczyć poniżej w rozdziale o szczegółach technicznych.
Począwszy od wersji 2.2.7 demony serwera i proxy Zabbix, w przypadku odebrania błędnej odpowiedzi SNMP, będą w następujący sposób logować linie:SNMP response from host "gateway" does not contain all of the requested variable bindingsMimo, że nie rozwiązuje to wszystkich problemów, jest to wystarczający sygnał do tego, by ustawić parametr konfiguracji EnableSNMPBulkRequests na 0, żeby wyłączyć globalnie zapytania zbiorcze SNMP.
Konfiguracja monitorowania SNMP
Żeby rozpocząć monitorowanie urządzeń poprzez SNMP, należy wykonać następujące kroki:
Krok 1
Utworzyć host dla urządzenia z interfejsem SNMP.
Wprowadzić adres IP. Ustawić stan hosta na NIE MONITOROWANY. Można użyć jednego z dostarczonych szablonów SNMP (Template SNMP Device lub innych), które automatycznie dodadzą zestaw pozycji. Jednakże, szablon może być niekompatybilny z hostem.
Testy SNMP nie korzystają z portu Agenta, jest on ignorowany.
Krok 2
Znaleźć ciąg SNMP (lub OID) pozycji, które chcemy monitorować.
Żeby otrzymać listę ciągów SNMP, należy użyć komendy snmpwalk (część oprogramowania net-snmp, która powinna być zainstalowana jako część instalacji Zabbix) lub podobnego narzędzia:
W tym przypadku '2c' oznacza wersję SNMP, można zamiast tego podać '1', żeby wskazać, że urządzenie obsługuje SNMP w wersji 1.
Powinno to dać listę ciągów SNMP oraz ich ostatnie wartości. Jeżeli nie daje, możliwe jest, że hasło SNMP (community) jest inne od standardowego 'public', w takim przypadku należy odszukać właściwe.
Następnie przeglądamy listę i szukamy ciągu, który chcemy monitorować, np.: jeżeli chcemy monitorować ilość bajtów przychodzących na przełączniku na porcie 3, należy użyć ciągu IF-MIB::ifInOctets.3 z tej linii:
Teraz można wykorzystać komendę snmpget, żeby pobrać liczbowy OID dla 'IF-MIB::ifInOctets.3':
Należy zauważyć, że ostatnia liczba w ciągu to numer portu, który chcemy monitorować. Zobacz również: Dynamiczne indeksy.
Powinno to dać coś takiego jak:
I znowu, ostatni numer w OID to numer portu.
Wygląda na to, że 3COM dodaje do portu setkę, np.: port 1 = port 101, port 3 = port 103, ale Cisco używa zwykłych liczb, np.: port 3 = 3.
Niektóre z częściej używanych OID-ów SNMP są przez Zabbix automatycznie tłumaczone na reprezentację liczbową.
W ostatnim przykładzie powyżej typem wartości jest "Counter32", który wewnętrznie odpowiada typowi ASN_COUNTER. Pełna lista obsługiwanych typów to: ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR i ASN_OBJECT_ID (począwszy od 2.2.8). Typy te odpowiadają typom: "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" na wyjściu snmpget, ale również mogą być pokazywane jako "STRING", "Hex-STRING", "OID" i inne, zależnie od tego czy jest wyświetlana podpowiedź.
Krok 3
Utworzenie pozycji do monitorowania.
Zatem, wracamy do Zabbix i klikamy na pozycjach, wybranego hosta SNMP utworzonego wcześniej. W zależności od tego, czy użyto lub nie szablonu podczas tworzenia hosta, otrzymamy albo listę związanych z nim pozycji SNMP albo tylko nowe okno pozycji. Zakładamy, że chcesz utworzyć pozycję samodzielnie, przy użyciu informacji zebranych z pomocą snmpwalk i snmpget, zatem w oknie nowej pozycji w polu 'Opis' należałoby wprowadzić oryginalny Angielski opis. Należy się upewnić, że w polu 'Typ' jest "Agent SNMPv*". Należy wprowadzić hasło SNMP (zwykle public) a w polu 'OID SNMP' tekstowy lub numeryczny OID otrzymany wcześniej, na przykład: .1.3.6.1.2.1.2.2.1.10.3
W 'Port' wpisać 161 a w 'Klucz' coś znaczącego, np. SNMP-InOctets-Bps. Można wybrać Mnożnik oraz wprowadzić 'Interwał' i 'Okres przechowywania historii', jeżeli chcemy je ustawić na inne niż domyślne. Pozycję należy włączyć, 'Typ informacji' ustawić na Liczba (zmiennoprzecinkowa) a 'Zachowaj wartość' na ZMIANA (ważne, ponieważ w przeciwnym przypadku dostaniemy z urządzenia SNMP skumulowaną wartość zamiast ostatniej zmiany).
Teraz należy zapisać pozycję i wrócić do hostów Zabbix. Tutaj należy zmienić stan urządzenia SNMP na 'Monitorowany' i można sprawdzić dane SNMP w Ostatnich danych!
Przykład 1
Przykład ogólny:
| Parametr | Opis |
|---|---|
| Hasło | public |
| OID | 1.2.3.45.6.7.8.0 (lub .1.2.3.45.6.7.8.0) |
| Klucz | <Unikalny ciąg do użycia w wyzwalaczach> Na przykład, "moj_parametr". |
Należy zauważyć, że OID może być podane zarówno w postaci numerycznej jak i ciągu znaków. Jednakże w niektórych przypadkach, OID znakowy musi być zastąpiony na reprezentację numeryczną. W tym celu można użyć narzędzia snmpget:
Monitorowanie parametrów SNMP możliwe jest, gdy podczas konfiguracji źródeł Zabbix użyto przełącznika --with-net-snmp.
Przykład 2
Monitorowanie czasu pracy:
| Parametr | Opis |
|---|---|
| Hasło | public |
| OID | MIB::sysUpTime.0 |
| Klucz | router.uptime |
| Typ wartości | Liczba zmiennoprzecinkowa |
| Jednostki | uptime |
| Mnożnik | 0.01 |
Wewnętrzna obsługa przetwarzania zbiorczego
Począwszy od wersji 2.2.3 serwer i proxy Zabbix pytają urządzenie SNMP o wiele wartości w jednym zapytaniu. Dotyczy to kilku typów pozycji SNMP:
- zwykłe pozycje SNMP;
- pozycje SNMP z dynamicznymi indeksami;
- niskopoziomowe reguły wykrywania SNMP.
Wszystkie pozycje SNMP z pojedynczego interfejsu, posiadające identyczne parametry są ustawiane w harmonogramie do wykonania w tym samym momencie. Pierwsze dwa typy pozycji są przechwytywane przez procesy wysyłające, które grupują po maksymalnie 128 pozycji, natomiast niskopoziomowe reguły wykrywania przetwarzane są indywidualnie, jak do tej pory.
Na niższym poziomie wykonywane są dwa typy operacji dla wartości: pobranie wielu określonych obiektów i przechodzenie po drzewie OID.
Przy "pobieraniu", używane jest GetRequest-PDU z maksymalnie 128 zmiennymi. Przy "przechodzeniu", używane jest GetNextRequest-PDU dl SNMPv1 oraz GetBulkRequest z polem "max-repetitions" ustawionym najwyżej na 128 dla SNMPv2 i SNMPv3.
Podsumowanie korzyści z przetwarzania zbiorczego dla każdego typu pozycji SNMP:
- zwykłe pozycje SNMP korzystają z udoskonalonego "pobierania";
- pozycje SNMP z dynamicznymi indeksami korzystają zarówno z udoskonalonego "pobierania" jak i z "przechodzenia": "pobieranie" używane jest przy weryfikacji indeksów a "przechodzenie" przy budowie pamięci podręcznej cache;
- niskopoziomowe reguły wykrywania SNMP korzystają z udoskonalonego "przechodzenia".
Jednakże istnieją techniczne problemy związane z tym, że nie wszystkie urządzenia są w stanie zwrócić 128 wartości w zapytaniu. Niektóre zawsze zwracają prawidłową odpowiedź, a inne albo odpowiadają błędem "tooBig(1)" nie odpowiadają w ogóle, gdyż potencjalna odpowiedź przekracza jakiś limit.
Żeby znaleźć właściwą liczbę obiektów w zapytaniu dla danego urządzenia, Zabbix stosuje następującą strategię. Rozpoczyna od zapytania z jedną wartością w zapytaniu. Jeżeli się powiedzie, pyta o 2 wartości w zapytaniu. Jeżeli się ponownie powiedzie, pyta o 3 wartości i kontynuuje powielając liczbę obiektów w zapytaniu o 1.5, co daje w rezultacie następującą sekwencję ilości: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
Jednakże, gdy urządzenie odmówi udzielenia prawidłowej odpowiedzi (na przykład, dla 42 zmiennych), Zabbix zrobi dwie rzeczy.
Po pierwsze, dla aktualnej paczki pozycji podzieli ilość obiektów na dwa i zapyta 0 21 zmiennych w zapytaniu. Jeżeli urządzenie działa, to zapytanie powinno zadziałać w większości przypadków, ponieważ wiadomo, że 28 zmiennych zadziałało, a 21 jest znacznie mniej niż ta liczba. Jednakże, gdyby to nie zadziałało, Zabbix powróci do zadawania pytań pojedynczo wartość po wartości. Gdyby dalej nic nie działało, to znaczy, że urządzenie definitywnie nie odpowiada i rozmiar zapytania nie jest przyczyną takiego stanu.
Drugą rzeczą jaką zrobi Zabbix, to przy kolejnych paczkach pozycji rozpocznie z ostatnią znaną dobrą ilością zmiennych (w naszym przykładzie 28) i będzie ją zwiększał o 1 w kolejnych krokach. Na przykład, zakładając że największym możliwym rozmiarem zapytania jest 32 zmiennych, kolejne zapytania będą miały rozmiar 29, 30, 31, 32 i 33. Ostatnie zapytanie nie uda się a Zabbix nigdy więcej nie ustawi rozmiaru na 33. Od tego momentu, Zabbix będzie pytał to urządzenie maksymalnie z 32 zmiennymi.
Jeżeli większe zapytania z taką liczbą zmiennych się nie powiodą, może to oznaczać dwie rzeczy. Nie można określić dokładnych kryteriów, jakich używa to urządzenie do ograniczenia rozmiaru odpowiedzi, ale można spróbować aproksymować używając liczby zmiennych. Tak więc pierwsza możliwość jest taka, że ta liczba zmiennych jest bliska ogólnemu limitowi rozmiaru odpowiedzi: czasami odpowiedź jest mniejsza od limitu, czasami jest od niego większa. Druga możliwość jest taka, że po prostu utracono jakiś pakiet UDP. Z tych powodów, jeżeli Zabbix natrafi na błąd zapytania, zredukuje maksymalną liczbę zmiennych, by spróbować trafić w bardziej komfortowy zakres dla danego urządzenia, ale (począwszy od 2.2.8) maksymalnie dwa razy.
W przykładzie powyżej, jeżeli zapytanie z 32 zmiennymi nie powiedzie się, Zabbix zredukuje licznik do 31. Jeżeli zdarzy się to ponownie, Zabbix zredukuje licznik do 30. Jednakże, Zabbix nie zredukuje licznika poniżej 30, ponieważ zakładamy, że kolejne błędy mogą być spowodowane raczej utratą pakietów UDP, a nie limitem urządzenia.