2 SNMP agent

Przegląd

Możesz chcieć używać monitorowania SNMP na urządzeniach takich jak drukarki, przełączniki sieciowe, routery czy UPS-y, które zwykle mają włączoną obsługę SNMP i na których próba skonfigurowania kompletnych systemów operacyjnych oraz agentów Zabbix byłaby niepraktyczna.

Aby można było pobierać dane udostępniane przez agenty SNMP na tych urządzeniach, serwer Zabbix musi być wstępnie skonfigurowany z obsługą SNMP przez podanie flagi --with-net-snmp. Zaleca się również zainstalowanie plików MIB, aby mieć pewność, że wartości pozycji są wyświetlane w prawidłowym formacie. Bez plików MIB mogą występować problemy z formatowaniem, takie jak wyświetlanie wartości w formacie HEX zamiast UTF-8 lub odwrotnie.

Kontrole SNMP są wykonywane wyłącznie przez protokół UDP.

Demony serwera Zabbix i proxy zapisują w logach wiersze podobne do poniższego, jeśli otrzymają nieprawidłową odpowiedź SNMP:

SNMP response from host "gateway" does not contain all of the requested variable bindings

Chociaż nie obejmują one wszystkich problematycznych przypadków, są przydatne do identyfikowania poszczególnych urządzeń SNMP, dla których należy wyłączyć żądania łączone.

Serwer/proxy Zabbix ponowi próbę maksymalnie 5 razy dla pozycji SNMP walk i get. Mechanizm ponawiania nie ma zastosowania do błędów rozwiązywania DNS.

W przypadku starszych kontroli SNMP (pojedynczy numer OID lub ciąg znaków) serwer/proxy Zabbix ponowi próbę co najmniej jeden raz po nieudanej próbie zapytania: albo za pomocą mechanizmu ponawiania biblioteki SNMP, albo za pomocą wewnętrznego mechanizmu przetwarzania łączonego.

Jeśli monitorujesz urządzenia SNMPv3, upewnij się, że msgAuthoritativeEngineID (znane również jako snmpEngineID lub "Engine ID") nigdy nie jest współdzielone przez dwa urządzenia. Zgodnie z RFC 2571 (sekcja 3.1.1.1) musi być unikalne dla każdego urządzenia.

RFC3414 wymaga, aby urządzenia SNMPv3 zachowywały swoje engineBoots. Niektóre urządzenia tego nie robią, co powoduje, że ich komunikaty SNMP są odrzucane jako nieaktualne po ponownym uruchomieniu. W takiej sytuacji pamięć podręczna SNMP musi zostać ręcznie wyczyszczona na serwerze/proxy (za pomocą -R snmp_cache_reload) albo serwer/proxy musi zostać ponownie uruchomiony.

Zabbix buforuje mapowania SNMPv3 EngineID → IP i ponownie wykorzystuje zapisane w pamięci podręcznej EngineID przy kolejnych kontrolach zamiast każdorazowo wysyłać zapytanie sondujące, co zmniejsza ruch sieciowy. Jeśli EngineID nie może zostać użyte ponownie, zostanie wykoniona ponowna próba z zapytaniem sondującym w celu wykrycia nowego EngineID.

Konfigurowanie monitorowania SNMP

Aby rozpocząć monitorowanie urządzenia za pomocą SNMP, należy wykonać następujące kroki:

Krok 1

Ustal ciąg SNMP (lub OID) pozycji, którą chcesz monitorować.

Aby uzyskać listę ciągów SNMP, użyj polecenia snmpwalk (części oprogramowania net-snmp, które powinno być zainstalowane w ramach instalacji Zabbix) lub równoważnego narzędzia:

snmpwalk -v 2c -c public <host IP> .

Ponieważ '2c' oznacza tutaj wersję SNMP, możesz również zastąpić ją wartością '1', aby wskazać SNMP Version 1 na urządzeniu.

Powinno to zwrócić listę ciągów SNMP i ich ostatnią wartość. Jeśli tak się nie stanie, możliwe jest, że SNMP 'community' różni się od standardowego 'public'; w takim przypadku trzeba ustalić, jaka ona jest.

Następnie możesz przejrzeć listę, aż znajdziesz ciąg, który chcesz monitorować, np. jeśli chcesz monitorować bajty przychodzące do przełącznika na porcie 3, użyj ciągu IF-MIB::ifHCInOctets.3 z tego wiersza:

IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

Możesz teraz użyć polecenia snmpget, aby ustalić numeryczny OID dla 'IF-MIB::ifHCInOctets.3':

snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

Zwróć uwagę, że ostatnia liczba w ciągu to numer portu, który chcesz monitorować. Zobacz także: Indeksy dynamiczne.

Powinno to zwrócić coś podobnego do poniższego:

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

Ponownie, ostatnia liczba w OID to numer portu.

Niektóre z najczęściej używanych OID-ów SNMP są automatycznie tłumaczone na reprezentację numeryczną przez Zabbix.

W ostatnim przykładzie powyżej typ wartości to "Counter64", co wewnętrznie odpowiada typowi ASN_COUNTER64. 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 oraz ASN_OBJECT_ID. Typy te w przybliżeniu odpowiadają wartościom "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" w danych wyjściowych snmpget, ale mogą być również wyświetlane jako "STRING", "Hex-STRING", "OID" i inne, w zależności od obecności wskazówki wyświetlania.

Krok 2

Utwórz host odpowiadający urządzeniu.

Dodaj interfejs SNMP dla hosta:

  • Wprowadź adres IP/nazwę DNS oraz numer portu.
  • Wybierz wersję SNMP z listy rozwijanej.
  • Dodaj poświadczenia interfejsu zależnie od wybranej wersji SNMP:
    • SNMPv1, v2 wymagają tylko community (zwykle 'public').
    • SNMPv3 wymaga bardziej szczegółowych opcji (patrz poniżej).
  • Określ wartość maksymalnej liczby powtórzeń (domyślnie: 10) dla natywnych zbiorczych żądań SNMP (GetBulkRequest-PDUs); tylko dla pozycji discovery[] i walk[] w SNMPv2 i v3. Pamiętaj, że ustawienie zbyt wysokiej wartości może spowodować przekroczenie limitu czasu sprawdzania agent SNMP.
  • Zaznacz pole wyboru Użyj żądań łączonych, aby zezwolić na przetwarzanie łączone żądań SNMP (niezwiązane z natywnymi zbiorczymi żądaniami SNMP „walk” i „get”).
Parametr SNMPv3 Opis
Nazwa kontekstu Wprowadź nazwę kontekstu, aby zidentyfikować pozycja w podsieci SNMP.
Makra użytkownika są rozwijane w tym polu.
Nazwa bezpieczeństwa Wprowadź nazwę bezpieczeństwa.
Makra użytkownika są rozwijane w tym polu.
Poziom bezpieczeństwa Wybierz poziom bezpieczeństwa:
noAuthNoPriv — nie są używane ani protokoły uwierzytelniania, ani prywatności
AuthNoPriv — używany jest protokół uwierzytelniania, protokół prywatności nie jest używany
AuthPriv — używane są zarówno protokoły uwierzytelniania, jak i prywatności
Protokół uwierzytelniania Wybierz protokół uwierzytelniania — MD5, SHA1; w net-snmp 5.8 i nowszych także SHA224, SHA256, SHA384 lub SHA512.
Hasło uwierzytelniania Wprowadź hasło uwierzytelniania.
Makra użytkownika są rozwijane w tym polu.
Protokół prywatności Wybierz protokół prywatności — DES, AES128, AES192, AES256, AES192C (Cisco) lub AES256C (Cisco).
Zobacz uwagi dotyczące obsługi protokołu prywatności
Hasło prywatności Wprowadź hasło prywatności.
Makra użytkownika są rozwijane w tym polu.

W przypadku nieprawidłowych poświadczeń SNMPv3 (nazwa bezpieczeństwa, protokół/hasło uwierzytelniania, protokół prywatności):

  • Zabbix otrzymuje błąd ERROR z net-snmp, z wyjątkiem nieprawidłowego Hasła prywatności, w którym to przypadku Zabbix otrzymuje błąd TIMEOUT z net-snmp.
  • Dostępność interfejsu SNMP zmieni się na czerwoną (niedostępny).

Zmiany w Protokole uwierzytelniania, Haśle uwierzytelniania, Protokole prywatności lub Haśle prywatności, wprowadzone bez zmiany Nazwy bezpieczeństwa, są zwykle stosowane automatycznie po zaktualizowaniu odpowiedniego interfejsu SNMPv3 w Zabbix. W przypadkach, gdy Nazwa bezpieczeństwa również zostanie zmieniona, wszystkie parametry zostaną zaktualizowane natychmiast.

Możesz użyć jednego z dostarczonych szablonów SNMP, który automatycznie doda zestaw pozycji. Przed użyciem szablonu sprawdź, czy jest on zgodny z hostem.

Kliknij Dodaj, aby zapisać host.

Obsługa protokołów prywatności

W zależności od systemu operacyjnego i konfiguracji net-snmp niektóre protokoły prywatności mogą nie być dostępne:

  • W niektórych nowszych systemach operacyjnych (na przykład RHEL9) obsługa DES została usunięta z pakietu net-snmp.

  • Protokoły szyfrowania AES192 i silniejsze nie są obsługiwane od razu po instalacji w systemach operacyjnych starszych niż RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.

Aby sprawdzić, czy biblioteka net-snmp obsługuje AES192+, użyj jednej z poniższych opcji:

  1. net-snmp-config:
net-snmp-config --configure-options

Jeśli dane wyjściowe zawierają --enable-blumenthal-aes, AES192+ jest obsługiwane.

Pamiętaj, że net-snmp-config jest częścią pakietu deweloperskiego dla SNMP (libsnmp-dev dla Debian/Ubuntu, net-snmp-devel dla CentOS/RHEL/OL/SUSE) i może nie być domyślnie zainstalowany.

  1. snmpget:
snmpget -v 3 -x AES-256

Jeśli dane wyjściowe zawierają Invalid privacy protocol specified after -3x flag: AES-256, AES192+ nie jest obsługiwane. Jeśli dane wyjściowe zawierają No hostname specified., AES192+ nie jest obsługiwane.

Jeśli biblioteka net-snmp nie obsługuje protokołów AES192 i wyższych, skompiluj ponownie net-snmp z opcją --enable-blumenthal-aes, a następnie skompiluj ponownie serwer Zabbix, podając opcję --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.

Krok 3

Utwórz pozycję do monitorowania.

Teraz wróć do Zabbix i kliknij Pozycje dla hosta SNMP, którego utworzyłeś wcześniej. W zależności od tego, czy podczas tworzenia hosta użyto szablonu, czy nie, zobaczysz albo listę pozycji SNMP powiązanych z hostem, albo po prostu pustą listę. Założymy, że zamierzasz samodzielnie utworzyć pozycję, korzystając z informacji, które właśnie zebrałeś za pomocą snmpwalk i snmpget, więc kliknij Utwórz pozycję.

Wypełnij wymagane parametry w formularzu nowej pozycji:

Parametr Opis
Nazwa Wprowadź nazwę pozycji.
Typ Wybierz tutaj agent SNMP.
Klucz Wprowadź klucz o sensownej nazwie.
Interfejs hosta Upewnij się, że wybrano interfejs SNMP, np. przełącznika/routera.
SNMP OID Użyj jednego z obsługiwanych formatów, aby wprowadzić wartość(-ci) OID:

walk[OID1,OID2,...] - pobiera poddrzewo wartości.
Na przykład: walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].
Ta opcja wykorzystuje natywne żądania zbiorcze SNMP (GetBulkRequest-PDUs) asynchronicznie.
Ustawienia limitu czasu dla tej pozycji można skonfigurować w formularzu konfiguracji pozycji. Rozważ ustawienie niskiej wartości limitu czasu, aby uniknąć długich opóźnień, jeśli urządzenie jest nieosiągalne, ponieważ zostanie wykonanych do 5 ponowień, jeśli wcześniejsze próby przekroczą limit czasu lub zakończą się niepowodzeniem (np. 3-sekundowy limit czasu może skutkować 15-sekundowym czasem oczekiwania).
Możesz użyć tej pozycji jako pozycji nadrzędnej, a pozycje zależne mogą wyodrębniać dane z pozycji nadrzędnej za pomocą przetwarzania wstępnego.
Możliwe jest określenie wielu OID w jednym przebiegu snmp walk, na przykład walk[OID1,OID2,...], aby asynchronicznie przetwarzać po jednym OID naraz.
Jeśli żądanie zbiorcze nie zwróci wyników, podejmowana jest próba pobrania pojedynczego rekordu bez użycia żądania zbiorczego.
Nazwy MIB są obsługiwane jako parametry; dlatego walk[1.3.6.1.2.1.2.2.1.2] i walk[ifDescr] zwrócą ten sam wynik.
Jeśli określono kilka OID/MIB, tj. walk[ifDescr,ifType,ifPhysAddress], wynik będzie listą połączoną.
Żądania GetBulk są używane z interfejsami SNMPv2 i v3, a GetNext z interfejsami SNMPv1; parametr maksymalnej liczby powtórzeń dla żądań zbiorczych jest konfigurowany na poziomie interfejsu.
Parametr maksymalnej liczby powtórzeń wpływa na żądania zbiorcze, określając maksymalną liczbę OID zwracanych w jednej odpowiedzi zbiorczej.
Wyższa wartość skutkuje większymi odpowiedziami zbiorczymi, zmniejszając liczbę wymaganych transmisji. Jednak nie wszystkie urządzenia mogą obsługiwać bardzo wysokie wartości, co może powodować problemy.
Ta pozycja zwraca dane wyjściowe narzędzia snmpwalk z parametrami -Oe -Ot -On.
Możesz użyć tej pozycji jako pozycji nadrzędnej w wykrywaniu SNMP.

get[OID] - pobiera pojedynczą wartość asynchronicznie.
Na przykład: get[1.3.6.1.2.1.31.1.1.1.6.3]
Ustawienia limitu czasu dla tej pozycji można skonfigurować w formularzu konfiguracji pozycji. Rozważ ustawienie niskiej wartości limitu czasu, aby uniknąć długich opóźnień, jeśli urządzenie jest nieosiągalne, ponieważ zostanie wykonanych do 5 ponowień, jeśli wcześniejsze próby przekroczą limit czasu lub zakończą się niepowodzeniem (np. 3-sekundowy limit czasu może skutkować 15-sekundowym czasem oczekiwania).

OID - (starszy sposób) wprowadź pojedynczy tekstowy lub numeryczny OID, aby synchronicznie pobrać pojedynczą wartość, opcjonalnie połączoną z innymi wartościami.
Na przykład: 1.3.6.1.2.1.31.1.1.1.6.3.
Dla tej opcji limit czasu sprawdzania pozycji będzie równy wartości ustawionej w pliku konfiguracyjnym serwera.

Zaleca się używanie pozycji walk[OID] i get[OID] dla lepszej wydajności. Wszystkie pozycje walk[OID] i get[OID] są wykonywane asynchronicznie — nie jest wymagane otrzymanie odpowiedzi na jedno żądanie przed rozpoczęciem innych kontroli. Rozwiązywanie DNS również odbywa się asynchronicznie.
Maksymalna współbieżność kontroli asynchronicznych wynosi 1000 (określona przez MaxConcurrentChecksPerPoller). Liczba asynchronicznych odpytywaczy SNMP jest określana przez parametr StartSNMPPollers.

Zwróć uwagę, że dla statystyk ruchu sieciowego zwracanych przez dowolną z metod należy dodać krok Zmiana na sekundę na karcie Przetwarzanie wstępne; w przeciwnym razie otrzymasz wartość skumulowaną z urządzenia SNMP zamiast ostatniej zmiany.

Wszystkie obowiązkowe pola wejściowe są oznaczone czerwoną gwiazdką.

Teraz zapisz pozycję i przejdź do Monitorowanie > Najnowsze dane, aby zobaczyć dane SNMP.

Przykład 1

Ogólny przykład:

Parametr Opis
OID 1.2.3.45.6.7.8.0 (lub .1.2.3.45.6.7.8.0)
Key <Unikalny ciąg znaków używany jako odniesienie do wyzwalaczy>
Na przykład „my_param”.

Zwróć uwagę, że OID może być podany zarówno w postaci numerycznej, jak i tekstowej. Jednak w niektórych przypadkach tekstowy OID musi zostać przekonwertowany do postaci numerycznej. W tym celu można użyć narzędzia snmpget:

snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

Przykład 2

Monitorowanie czasu działania:

Parametr Opis
OID MIB::sysUpTime.0
Key router.uptime
Typ wartości Float
Jednostki uptime
Krok przetwarzania wstępnego: Mnożnik niestandardowy 0.01

Natywne żądania zbiorcze SNMP

Pozycja walk[OID1,OID2,...] umożliwia użycie natywnej funkcjonalności SNMP do żądań zbiorczych (GetBulkRequest-PDUs), dostępnej w wersjach SNMP 2/3.

Żądanie GetBulk w SNMP wykonuje wiele żądań GetNext i zwraca wynik w jednej odpowiedzi. Może to być używane zarówno dla zwykłych pozycji SNMP, jak i dla wykrywania SNMP, aby zminimalizować liczbę wymian z siecią.

Pozycja SNMP walk[OID1,OID2,...] może być używana jako pozycja nadrzędna, która zbiera dane w jednym żądaniu, wraz z pozycjami zależnymi, które analizują odpowiedź w razie potrzeby przy użyciu preprocessing.

Należy pamiętać, że użycie natywnych żądań zbiorczych SNMP nie jest związane z opcją łączenia żądań SNMP, która jest własnym sposobem Zabbix na łączenie wielu żądań SNMP (zobacz następną sekcję).

Dla zbiorczych pozycji SNMP zostanie wykonanych maksymalnie pięć ponowień, aby uniknąć niepowodzenia, jeśli jeden z pakietów zostanie utracony. Limit czasu dla pozycji SNMP z get i walk (ustawiany w formularzu konfiguracji pozycji) jest ustawiany dla całej sesji. Limit czasu jest stosowany niezależnie od tego, czy dane zostały pobrane w całości; jeśli dane zostaną odebrane częściowo (na przykład dane zostaną pomyślnie zebrane tylko dla jednego z wielu OID), pozycja stanie się nieobsługiwana z komunikatem „Only partial data received”. Jeśli limit czasu zostanie osiągnięty, nastąpi ponowienie, limit czasu zostanie zresetowany, a ostatnie żądanie zostanie wysłane ponownie, co pozwoli kontynuować sesję od ostatniego żądania, jeśli pojedynczy pakiet został utracony lub dotarł zbyt późno. Rozważ ustawienie niskiej wartości limitu czasu, aby uniknąć długich opóźnień, jeśli urządzenie jest nieosiągalne, ponieważ zostanie wykonanych do 5 ponowień, jeśli wcześniejsze przekroczą limit czasu lub zakończą się niepowodzeniem (np. 3-sekundowy limit czasu może skutkować 15-sekundowym czasem oczekiwania).

Wewnętrzne działanie przetwarzania łączonego

serwer Zabbix i proxy mogą odpytywać urządzenia SNMP o wiele wartości w jednym żądaniu. Wpływa to na kilka typów pozycji SNMP:

Wszystkie pozycje SNMP na pojedynczym interfejsie o identycznych parametrach są planowane do odpytywania w tym samym czasie. Pierwsze dwa typy pozycji są pobierane przez pollery partiami po maksymalnie 128 pozycji, natomiast reguły niskopoziomowego wykrywania są przetwarzane pojedynczo, tak jak wcześniej.

Na niższym poziomie wykonywane są dwa rodzaje operacji służących do odpytywania wartości: pobieranie wielu określonych obiektów oraz przechodzenie drzewa OID.

Do „pobierania” używane jest GetRequest-PDU z maksymalnie 128 powiązaniami zmiennych. Do „przechodzenia” używane jest GetNextRequest-PDU dla SNMPv1, a dla SNMPv2 i SNMPv3 używane jest GetBulkRequest z polem „max-repetitions” o wartości maksymalnie 128.

W związku z tym korzyści z przetwarzania łączonego dla każdego typu pozycji SNMP przedstawiają się następująco:

  • zwykłe pozycje SNMP korzystają z usprawnień „pobierania”;
  • pozycje SNMP z dynamicznymi indeksami korzystają zarówno z usprawnień „pobierania”, jak i „przechodzenia”: „pobieranie” jest używane do weryfikacji indeksów, a „przechodzenie” do budowania pamięci podręcznej;
  • reguły niskopoziomowego wykrywania SNMP korzystają z usprawnień „przechodzenia”.

Istnieje jednak problem techniczny polegający na tym, że nie wszystkie urządzenia są w stanie zwrócić 128 wartości na żądanie. Niektóre zawsze zwracają prawidłową odpowiedź, ale inne albo odpowiadają błędem „tooBig(1)”, albo nie odpowiadają wcale, gdy potencjalna odpowiedź przekracza pewien limit.

Aby znaleźć optymalną liczbę obiektów do odpytywania dla danego urządzenia, Zabbix stosuje następującą strategię. Zaczyna ostrożnie od odpytywania 1 wartości w żądaniu. Jeśli to się powiedzie, odpytywane są 2 wartości w żądaniu. Jeśli to ponownie się powiedzie, odpytywane są 3 wartości w żądaniu, a następnie proces jest kontynuowany w podobny sposób przez mnożenie liczby odpytywanych obiektów przez 1,5, co daje następującą sekwencję rozmiarów żądań: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Jednak gdy urządzenie odmówi zwrócenia prawidłowej odpowiedzi (na przykład dla 42 zmiennych), Zabbix robi dwie rzeczy.

Po pierwsze, dla bieżącej partii pozycji zmniejsza o połowę liczbę obiektów w pojedynczym żądaniu i odpytuje 21 zmiennych. Jeśli urządzenie działa, to zapytanie powinno zadziałać w zdecydowanej większości przypadków, ponieważ wiadomo, że 28 zmiennych działało, a 21 to znacznie mniej. Jeśli jednak to również się nie powiedzie, Zabbix wraca do odpytywania wartości pojedynczo. Jeśli nadal się nie powiedzie, oznacza to, że urządzenie zdecydowanie nie odpowiada i rozmiar żądania nie jest problemem.

Drugą rzeczą, jaką Zabbix robi dla kolejnych partii pozycji, jest rozpoczęcie od ostatniej pomyślnej liczby zmiennych (28 w naszym przykładzie) i dalsze zwiększanie rozmiaru żądań o 1 aż do osiągnięcia limitu. Na przykład, zakładając, że największy rozmiar odpowiedzi to 32 zmienne, kolejne żądania będą miały rozmiary 29, 30, 31, 32 i 33. Ostatnie żądanie zakończy się niepowodzeniem i Zabbix nigdy więcej nie wyśle żądania o rozmiarze 33. Od tego momentu Zabbix będzie odpytywać to urządzenie o maksymalnie 32 zmienne.

Jeśli duże zapytania zawodzą przy tej liczbie zmiennych, może to oznaczać jedną z dwóch rzeczy. Nie da się dokładnie określić kryteriów, których urządzenie używa do ograniczania rozmiaru odpowiedzi, ale staramy się to przybliżyć za pomocą liczby zmiennych. Pierwsza możliwość jest taka, że ta liczba zmiennych znajduje się blisko rzeczywistego limitu rozmiaru odpowiedzi urządzenia w ogólnym przypadku: czasami odpowiedź jest mniejsza od limitu, a czasami go przekracza. Druga możliwość jest taka, że pakiet UDP w jednym z kierunków po prostu został utracony. Z tych powodów, jeśli Zabbix otrzyma nieudane zapytanie, zmniejsza maksymalną liczbę zmiennych, aby spróbować wejść głębiej w bezpieczny zakres pracy urządzenia, ale robi to najwyżej dwa razy.

W powyższym przykładzie, jeśli zapytanie z 32 zmiennymi akurat się nie powiedzie, Zabbix zmniejszy tę liczbę do 31. Jeśli to również się nie powiedzie, Zabbix zmniejszy tę liczbę do 30. Jednak Zabbix nie zmniejszy tej liczby poniżej 30, ponieważ założy, że dalsze niepowodzenia wynikają z utraty pakietów UDP, a nie z limitu urządzenia.

Jeśli jednak urządzenie nie potrafi poprawnie obsługiwać żądań łączonych z innych powodów i opisana powyżej heurystyka nie działa, dla każdego interfejsu dostępne jest ustawienie „Use combined requests”, które pozwala wyłączyć żądania łączone dla tego urządzenia.

Jeśli żądania łączone powodują częściowe lub nieprawidłowo sformowane odpowiedzi, które skutkują błędnymi obliczeniami wartości na sekundę (delta) (na przykład pozornymi skokami liczników interfejsu), wyłącz opcję Use combined requests dla danego interfejsu, aby wymusić osobne zapytania dla każdej pozycji; często zapobiega to fałszywym skokom. Alternatywnie rozważ użycie asynchronicznych pozycji get[] lub walk[], które są wykonywane asynchronicznie i nie podlegają grupowaniu według interfejsu przez opcję Use combined requests — mogą być używane zamiast starszych synchronicznych kontroli OID, aby uniknąć problemów związanych z żądaniami łączonymi. Szukaj wpisów w logach serwera/proxy podobnych do pokazanego w sekcji Przegląd, aby pomóc w identyfikacji urządzeń, których dotyczy problem.

Dodatkowo, jeśli interfejs często staje się niedostępny, może być konieczne zwiększenie parametru UnavailableDelay w plikach konfiguracyjnych serwera Zabbix lub proxy Zabbix, aby zmniejszyć częstotliwość żądań. Pozycje mogą stać się nieobsługiwane, jeśli podczas wykrywania lub przejść OID zostaną odebrane częściowe dane.