Agent SNMP

Omówienie

Możesz chcieć używać monitorowania SNMP na urządzeniach takich jak drukarki, przełączniki sieciowe, routery lub UPS, które zwykle obsługują SNMP i na których próba skonfigurowania pełnych systemów operacyjnych oraz agentów Zabbix byłaby niepraktyczna.

Aby możliwe było pobieranie danych dostarczanych przez agentów SNMP na tych urządzeniach, serwer Zabbix musi zostać początkowo skonfigurowany z obsługą SNMP przez podanie flagi --with-net-snmp. Zaleca się również zainstalowanie plików MIB, aby zapewnić wyświetlanie wartości pozycji w prawidłowym formacie. Bez plików MIB mogą wystąpić problemy z formatowaniem, takie jak wyświetlanie wartości w HEX zamiast UTF-8 lub odwrotnie.

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

Demon 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ą wszystkich problematycznych przypadków, są przydatne do identyfikowania pojedynczych urządzeń SNMP, dla których należy wyłączyć łączone żądania.

Serwer/proxy Zabbix ponowi próbę do 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) serwer/proxy Zabbix ponowi próbę co najmniej jeden raz po nieudanej próbie zapytania: albo za pośrednictwem mechanizmu ponawiania biblioteki SNMP, albo poprzez wewnętrzny mechanizm łączonego przetwarzania.

Jeśli monitorujesz urządzenia SNMPv3, upewnij się, że msgAuthoritativeEngineID (znany również jako snmpEngineID lub "Engine ID") nigdy nie jest współdzielony przez dwa urządzenia. Zgodnie z RFC 2571 (sekcja 3.1.1.1) musi on być unikalny 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 wiadomości 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 dla kolejnych kontroli zamiast wysyłać za każdym razem sondę, co zmniejsza ruch sieciowy. Jeśli EngineID nie może zostać ponownie użyty, zostanie wykonana ponowna próba z sondą 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ęść oprogramowania net-snmp, które powinno być zainstalowane jako element 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ć na urządzeniu SNMP Version 1.

Powinno to zwrócić listę ciągów SNMP wraz z ich ostatnią wartością. Jeśli tak się nie stanie, możliwe, że społeczność SNMP ('community') różni się od standardowej wartości public; w takim przypadku trzeba będzie ją ustalić.

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żyjesz ciągu IF-MIB::ifHCInOctets.3 z tej linii:

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 też: Dynamic indexes.

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 SNMP są automatycznie tłumaczone na reprezentację numeryczną przez Zabbix.

W ostatnim przykładzie typ wartości to "Counter64", który 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ą "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" w wyniku snmpget, ale mogą być też 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:

  1. Wprowadź adres IP/nazwę DNS oraz numer portu.
  2. Wybierz wersję SNMP z listy rozwijanej.
  3. Dodaj dane uwierzytelniające interfejsu w zależności od wybranej wersji SNMP:
    • SNMPv1, v2 wymagają tylko community (zwykle 'public').
    • SNMPv3 wymaga bardziej szczegółowych opcji; zobacz SNMPv3.
  4. Określ maksymalną wartość powtórzeń (domyślnie: 10) dla natywnych żądań zbiorczych SNMP (GetBulkRequest-PDUs); tylko dla pozycji discovery[] i walk[] w SNMPv2 i v3. Pamiętaj, że ustawienie tej wartości zbyt wysoko może spowodować przekroczenie limitu czasu sprawdzania agent SNMP.
  5. Zaznacz pole wyboru Use combined requests, aby zezwolić na łączone przetwarzanie żądań SNMP (nie dotyczy natywnych zbiorczych żądań SNMP "walk" i "get").

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 Add, aby zapisać host.

SNMPv3

Następujące parametry są wymagane dla SNMPv3:

  • Context name - Wprowadź nazwę kontekstu, aby zidentyfikować pozycja w podsieci SNMP.
    Makra użytkownika są rozwijane w tym polu.
  • Security name - Wprowadź nazwę zabezpieczeń.
    Makra użytkownika są rozwijane w tym polu.
  • Security level - Wybierz poziom zabezpieczeń:
    • noAuthNoPriv - nie są używane 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 protokół uwierzytelniania, jak i protokół prywatności.
  • Authentication protocol - Wybierz protokół uwierzytelniania: MD5, SHA1; w net-snmp 5.8 i nowszych także SHA224, SHA256, SHA384 lub SHA512.
  • Authentication passphrase - Wprowadź frazę hasła uwierzytelniania.
    Makra użytkownika są rozwijane w tym polu.
  • Privacy protocol - Wybierz protokół prywatności: DES, AES128, AES192, AES256, AES192C (Cisco) lub AES256C (Cisco).
    Zobacz uwagi dotyczące obsługi protokołu prywatności.
  • Privacy passphrase - Wprowadź frazę hasła prywatności.
    Makra użytkownika są rozwijane w tym polu.

W przypadku nieprawidłowych poświadczeń SNMPv3 (security name, authentication protocol/passphrase, privacy protocol):

  • Zabbix otrzymuje błąd ERROR z net-snmp, z wyjątkiem nieprawidłowej Privacy passphrase, w którym to przypadku Zabbix otrzymuje błąd TIMEOUT z net-snmp.
  • Dostępność interfejsu SNMP zostanie przełączona na czerwony (niedostępny).

Zmiany w Authentication protocol, Authentication passphrase, Privacy protocol lub Privacy passphrase, wprowadzone bez zmiany Security name, są zwykle stosowane automatycznie po zaktualizowaniu odpowiedniego interfejsu SNMPv3 w Zabbix. W przypadkach, gdy zmieniany jest również Security name, wszystkie parametry zostaną zaktualizowane natychmiast.

Obsługa protokołów prywatności

W zależności od systemu operacyjnego i konfiguracji net-snmp, niektóre protokoły prywatności mogą być niedostę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 na systemach 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 wynik zawiera --enable-blumenthal-aes, AES192+ jest obsługiwane.

Należy pamiętać, ż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ć zainstalowany domyślnie.

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

Jeśli wynik zawiera Invalid privacy protocol specified after -3x flag: AES-256, AES192+ nie jest obsługiwane. Jeśli wynik zawiera No hostname specified., AES192+ nie jest obsługiwane.

Jeśli Twoja 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.

Wróć teraz do Zabbix i kliknij Pozycje dla utworzonego wcześniej hosta SNMP. W zależności od tego, czy podczas tworzenia hosta użyto szablonu, będzie dostępna lista pozycji SNMP powiązanych z hostem albo tylko pusta lista. Załóżmy, że utworzysz pozycję samodzielnie, korzystając z informacji zebranych przed chwilą za pomocą snmpwalk i snmpget, dlatego kliknij Utwórz pozycję.

Wypełnij wymagane parametry w formularzu nowej pozycji:

Parametr Opis
Nazwa Wprowadź nazwę pozycji.
Typ Wybierz tutaj SNMP agent.
Klucz Wprowadź odpowiednio opisowy klucz.
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ść lub 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 korzysta asynchronicznie z natywnych żądań zbiorczych SNMP (GetBulkRequest-PDU).
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 niedostępne, ponieważ zostanie wykonanych do 5 ponownych prób, jeśli wcześniejsze próby przekroczą limit czasu lub zakończą się niepowodzeniem (np. limit czasu wynoszący 3 sekundy może skutkować oczekiwaniem trwającym 15 sekund).
Możesz użyć tej pozycji jako pozycji nadrzędnej, z pozycjami zależnymi, które wyodrębniają dane z pozycji nadrzędnej za pomocą przetwarzania wstępnego.
W jednym snmp walk można określić wiele OID, np. 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 żądania zbiorczego.
Jako parametry można podawać nazwy MIB, 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, np. walk[ifDescr,ifType,ifPhysAddress], wynik będzie połączoną listą.
Żądania GetBulk są używane z interfejsami SNMPv2 i v3, a GetNext z interfejsami SNMPv1; maksymalna liczba powtórzeń dla żądań zbiorczych jest konfigurowana na poziomie interfejsu.
Parametr maksymalnej liczby powtórzeń wpływa na żądania zbiorcze, określając maksymalną liczbę OID zwracanych w pojedynczej 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 wynik narzędzia snmpwalk z parametrami -Oe -Ot -On.
Możesz użyć tej pozycji jako pozycji nadrzędnej w wykrywaniu SNMP.

get[OID] - asynchronicznie pobiera pojedynczą wartość.
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 niedostępne, ponieważ zostanie wykonanych do 5 ponownych prób, jeśli wcześniejsze próby przekroczą limit czasu lub zakończą się niepowodzeniem (np. limit czasu wynoszący 3 sekundy może skutkować oczekiwaniem trwającym 15 sekund).

OID - (starsza opcja) wprowadź pojedynczy tekstowy lub numeryczny OID, aby synchronicznie pobrać pojedynczą wartość, opcjonalnie w połączeniu z innymi wartościami.
Na przykład: 1.3.6.1.2.1.31.1.1.1.6.3.
W przypadku 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] w celu uzyskania lepszej wydajności. Wszystkie pozycje walk[OID] i get[OID] są wykonywane asynchronicznie - nie trzeba otrzymać odpowiedzi na jedno żądanie przed rozpoczęciem innych sprawdzeń. Rozpoznawanie DNS również odbywa się asynchronicznie.
Maksymalna współbieżność sprawdzeń asynchronicznych wynosi 1000 (określana przez parametr MaxConcurrentChecksPerPoller). Liczbę asynchronicznych pollerów SNMP określa parametr StartSNMPPollers.

Pamiętaj, że w przypadku statystyk ruchu sieciowego zwracanych przez dowolną z metod należy dodać krok Zmiana na sekundę na karcie Przetwarzanie wstępne; w przeciwnym razie z urządzenia SNMP zostanie pobrana wartość skumulowana zamiast ostatniej zmiany.

Wszystkie wymagane pola wejściowe są oznaczone czerwoną gwiazdką.

Zapisz teraz pozycję i przejdź do Monitorowanie > Najnowsze dane, aby wyświetlić 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 łącznego przetwarzania

serwer Zabbix i proxy mogą odpytywać urządzenia SNMP o wiele wartości w ramach jednego żądania. Dotyczy to kilku typów pozycji SNMP:

Wszystkie pozycje SNMP na jednym interfejsie, z identycznymi parametrami, są planowane do odpytywania w tym samym czasie. Dwa pierwsze typy pozycji są pobierane przez pollery w partiach obejmujących maksymalnie 128 pozycji, natomiast reguły wykrywania niskopoziomowego są przetwarzane pojedynczo, tak jak wcześniej.

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

W przypadku „pobierania” używany jest GetRequest-PDU zawierający maksymalnie 128 powiązań zmiennych. W przypadku „przechodzenia” dla SNMPv1 używany jest GetNextRequest-PDU, a dla SNMPv2 i SNMPv3 — GetBulkRequest z polem „max-repetitions” o wartości maksymalnie 128.

Korzyści z łącznego przetwarzania dla poszczególnych typów pozycji SNMP przedstawiono poniżej:

  • 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 indeksu, a „przechodzenie” do budowania pamięci podręcznej;
  • reguły wykrywania niskopoziomowego SNMP korzystają z usprawnień „przechodzenia”.

Istnieje jednak problem techniczny: nie wszystkie urządzenia mogą zwracać 128 wartości w jednym żądaniu. Niektóre zawsze zwracają prawidłową odpowiedź, ale inne zwracają błąd „tooBig(1)” albo w ogóle nie odpowiadają, gdy potencjalna odpowiedź przekroczy określony limit.

Aby znaleźć optymalną liczbę obiektów, o które należy odpytać dane urządzenie, Zabbix stosuje następującą strategię. Rozpoczyna ostrożnie od odpytywania 1 wartości w jednym żądaniu. Jeśli operacja zakończy się powodzeniem, odpytywane są 2 wartości w jednym żądaniu. Jeśli ponownie zakończy się powodzeniem, odpytywane są 3 wartości, 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.

Jeśli jednak urządzenie odmówi zwrócenia prawidłowej odpowiedzi (na przykład dla 42 zmiennych), Zabbix wykonuje dwie czynności.

Po pierwsze, dla bieżącej partii pozycji zmniejsza o połowę liczbę obiektów w jednym żądaniu i odpyta 21 zmiennych. Jeśli urządzenie działa, 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 przechodzi do odpytywania wartości pojedynczo. Jeśli na tym etapie nadal wystąpi błąd, urządzenie z pewnością nie odpowiada, a rozmiar żądania nie ma znaczenia.

Po drugie, dla kolejnych partii pozycji Zabbix rozpoczyna od ostatniej pomyślnie obsłużonej liczby zmiennych (w naszym przykładzie 28) i zwiększa rozmiar żądania o 1 aż do osiągnięcia limitu. Zakładając na przykład, że największy rozmiar odpowiedzi wynosi 32 zmienne, kolejne żądania będą miały rozmiary 29, 30, 31, 32 i 33. Ostatnie żądanie zakończy się niepowodzeniem, a 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 zakończą się niepowodzeniem przy tej liczbie zmiennych, może to oznaczać jedną z dwóch rzeczy. Nie można znać dokładnych kryteriów używanych przez urządzenie do ograniczania rozmiaru odpowiedzi, ale próbujemy je przybliżyć za pomocą liczby zmiennych. Pierwsza możliwość jest taka, że liczba zmiennych jest zbliżona do rzeczywistego limitu rozmiaru odpowiedzi urządzenia w typowych warunkach: 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 nieudaną odpowiedź na zapytanie, zmniejsza maksymalną liczbę zmiennych, aby wejść głębiej w komfortowy zakres urządzenia, ale robi to maksymalnie dwa razy.

W powyższym przykładzie, jeśli zapytanie zawierające 32 zmienne przypadkowo zakończy się niepowodzeniem, Zabbix zmniejszy ich liczbę do 31. Jeśli to zapytanie również zakończy się niepowodzeniem, Zabbix zmniejszy liczbę do 30. Zabbix nie zmniejszy jednak liczby poniżej 30, ponieważ założy, że kolejne niepowodzenia wynikają z utraty pakietów UDP, a nie z ograniczenia urządzenia.

Jeśli jednak urządzenie nie może prawidłowo obsługiwać łącznych żądań z innych powodów, a opisana powyżej heurystyka nie działa, dla każdego interfejsu dostępne jest ustawienie „Use combined requests”, które umożliwia wyłączenie łącznych żądań dla tego urządzenia.

Jeśli łączne żądania powodują częściowe lub zniekształcone odpowiedzi prowadzące do nieprawidłowych obliczeń na sekundę (delta) (na przykład pozornych skoków liczników interfejsu), wyłącz opcję Use combined requests dla danego interfejsu, aby wymusić oddzielne zapytania dla poszczególnych 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 Use combined requests na poziomie interfejsu — można ich używać zamiast starszych synchronicznych kontroli OID, aby uniknąć problemów związanych z łącznymi żądaniami. Aby zidentyfikować urządzenia, których dotyczy problem, sprawdź wpisy w dzienniku serwera/proxy podobne do przedstawionego w sekcji Przegląd.

Ponadto, 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 przechodzenia OID zostaną odebrane częściowe dane.