3 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 poprzez podanie flagi --with-net-snmp. Zaleca się również zainstalowanie plików MIB, aby zapewnić wyświetlanie wartości pozycji w poprawnym formacie. Bez plików MIB mogą występować 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.

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 (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 komunikaty SNMP są odrzucane jako nieaktualne po ich 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ć ponownie użyty, 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 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 (patrz poniżej).
  • Określ maksymalną wartość powtórzeń (domyślnie: 10) dla natywnych zbiorczych żądań SNMP (GetBulkRequest-PDU); 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.
  • Zaznacz pole wyboru Use combined requests, aby umożliwić łączone przetwarzanie żądań SNMP (nie dotyczy natywnych zbiorczych żądań SNMP "walk" i "get").
SNMPv3 parameter Description
Context name Wprowadź nazwę kontekstu, aby zidentyfikować pozycja w podsieci SNMP.
Makra użytkownika są w tym polu rozwijane.
Security name Wprowadź nazwę bezpieczeństwa.
Makra użytkownika są w tym polu rozwijane.
Security level Wybierz poziom bezpieczeństwa:
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 SHA224, SHA256, SHA384 lub SHA512.
Authentication passphrase Wprowadź hasło uwierzytelniania.
Makra użytkownika są w tym polu rozwijane.
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ź hasło prywatności.
Makra użytkownika są w tym polu rozwijane.

W przypadku nieprawidłowych danych uwierzytelniających SNMPv3 (security name, authentication protocol/passphrase, privacy protocol):

  • Zabbix otrzymuje błąd ERROR z net-snmp, z wyjątkiem nieprawidłowego Privacy passphrase, w którym przypadku Zabbix otrzymuje błąd TIMEOUT z net-snmp.
  • Dostępność interfejsu SNMP zostanie zmieniona na czerwoną (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 zmieniana jest również Security name, wszystkie parametry zostaną zaktualizowane natychmiast.

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

Kliknij Add, 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 pozycja do monitorowania.

Wróć teraz do Zabbix i kliknij Items dla hosta SNMP, który utworzyłeś wcześniej. W zależności od tego, czy podczas tworzenia hosta użyłeś szablonu, będziesz mieć albo listę pozycji SNMP powiązanych z hostem, albo po prostu pustą listę. Założymy, że pozycję utworzysz samodzielnie, korzystając z informacji zebranych wcześniej za pomocą snmpwalk i snmpget, więc kliknij Create item.

Wypełnij wymagane parametry w nowym formularzu pozycji:

Parameter Description
Name Wprowadź nazwę pozycji.
Type Wybierz tutaj SNMP agent.
Key Wprowadź klucz w sposób opisowy.
Host interface Upewnij się, że wybierasz 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 z natywnych zbiorczych żądań SNMP (GetBulkRequest-PDU) 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 niedostępne, ponieważ zostanie wykonanych do 5 ponowień, jeśli wcześniejsze zakończą się przekroczeniem limitu czasu lub niepowodzeniem (np. limit czasu 3 sekundy może skutkować czasem oczekiwania 15 sekund).
Możesz użyć tego jako pozycji nadrzędnej, z pozycjami zależnymi, które wyodrębniają dane z pozycji nadrzędnej za pomocą przetwarzania wstępnego.
Możliwe jest określenie wielu OID w jednym 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 żądania zbiorczego.
Obsługiwane są nazwy MIB jako parametry; zatem 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 połączoną listą.
Żądania GetBulk są używane z interfejsami SNMPv2 i v3, a GetNext dla interfejsów 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 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 wynik narzędzia snmpwalk z parametrami -Oe -Ot -On.
Możesz użyć tej pozycji jako pozycji nadrzędnej w SNMP discovery.

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 niedostępne, ponieważ zostanie wykonanych do 5 ponowień, jeśli wcześniejsze zakończą się przekroczeniem limitu czasu lub niepowodzeniem (np. limit czasu 3 sekundy może skutkować czasem oczekiwania 15 sekund).

OID - (starsza metoda) wprowadź pojedynczy tekstowy lub numeryczny OID, aby pobrać pojedynczą wartość synchronicznie, 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 czas oczekiwania na sprawdzenie 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, zanim rozpoczną się inne sprawdzenia. Rozwiązywanie DNS również odbywa się asynchronicznie.
Maksymalna współbieżność asynchronicznych sprawdzeń wynosi 1000 (zdefiniowana przez MaxConcurrentChecksPerPoller). Liczba asynchronicznych pollerów SNMP jest określona przez parametr StartSNMPPollers.

Zwróć uwagę, że dla statystyk ruchu sieciowego zwracanych dowolną z metod należy dodać krok Change per second w zakładce Preprocessing; w przeciwnym razie otrzymasz wartość skumulowaną z urządzenia SNMP zamiast najnowszej zmiany.

Wszystkie obowiązkowe pola są oznaczone czerwoną gwiazdką.

Teraz zapisz pozycję i przejdź do Monitoring > Latest data dla danych 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 łączonego przetwarzania

Serwer Zabbix i proxy mogą odpytywać urządzenia SNMP o wiele wartości w jednym żądaniu. Dotyczy to kilku typów pozycji SNMP:

  • zwykłe pozycje SNMP
  • pozycje SNMP z dynamicznymi indeksami
  • reguły [odkrywania niskiego poziomu] SNMP(/manual/discovery/low_level_discovery/examples/snmp_oids_walk)

Wszystkie pozycje SNMP na jednym interfejsie z identycznymi parametrami są planowane do odpytywania w tym samym czasie. Pierwsze dwa typy pozycji są pobierane przez pollery w partiach liczących maksymalnie 128 pozycji, natomiast reguły odkrywania niskiego poziomu są przetwarzane indywidualnie, tak jak wcześniej.

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

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

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

  • 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 odkrywania niskiego poziomu SNMP korzystają z usprawnień „przechodzenia”.

Istnieje jednak techniczny problem polegający na tym, że nie wszystkie urządzenia są w stanie zwrócić 128 wartości w jednym żądaniu. Niektóre zawsze zwracają poprawną odpowiedź, ale inne odpowiadają błędem „tooBig(1)” albo w ogóle nie odpowiadają, gdy potencjalna odpowiedź przekroczy określony 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 jednym żądaniu. Jeśli się powiedzie, odpytywane są 2 wartości w jednym żądaniu. Jeśli to również się powiedzie, odpytywane są 3 wartości w jednym żądaniu i dalej podobnie, mnożąc liczbę odpytywanych obiektów przez 1,5, co daje następujący ciąg rozmiarów żądań: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Jednak gdy tylko urządzenie odmówi zwrócenia poprawnej 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ż 28 zmiennych było znane jako działające, a 21 jest od tego znacząco mniejsze. Jeśli jednak to nadal się nie powiedzie, Zabbix przechodzi do odpytywania wartości pojedynczo. Jeśli na tym etapie również wystąpi niepowodzenie, oznacza to, że urządzenie na pewno nie odpowiada i rozmiar żądania nie stanowi problemu.

Drugą rzeczą, jaką Zabbix robi dla kolejnych partii pozycji, jest rozpoczęcie od ostatniej udanej liczby zmiennych (w naszym przykładzie 28) i dalsze zwiększanie rozmiaru żądania o 1 aż do osiągnięcia limitu. Na przykład, zakładając, że największy obsługiwany 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 takiej liczbie zmiennych, może to oznaczać jedną z dwóch rzeczy. Dokładne kryteria, według których urządzenie ogranicza rozmiar odpowiedzi, nie są znane, ale próbujemy to przybliżyć za pomocą liczby zmiennych. Pierwsza możliwość jest taka, że liczba tych zmiennych jest mniej więcej zbliżona do rzeczywistego limitu rozmiaru odpowiedzi urządzenia w typowym przypadku: czasami odpowiedź jest mniejsza od limitu, a czasami większa. Druga możliwość jest taka, że pakiet UDP w jedną lub drugą stronę 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 komfortowy zakres urządzenia, ale tylko maksymalnie dwa razy.

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

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

Jeśli łączone żądania powodują częściowe lub nieprawidłowo sformatowane odpowiedzi, które skutkują błędnymi obliczeniami przyrostów na sekundę (delta) (na przykład pozornymi skokami liczników interfejsu), wyłącz 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 per interfejs przez Use combined requests — można ich używać zamiast starszych synchronicznych sprawdzeń OID, aby uniknąć problemów związanych z łączonymi żądaniami. Szukaj wpisów w logach serwera/proxy podobnych do tego pokazanego w sekcji Przegląd, aby pomóc zidentyfikować dotknięte urządzenia.

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 odkrywania lub przechodzenia po OID zostaną odebrane częściowe dane.