SNMP aģents
Pārskats
Jūs varat vēlēties izmantot SNMP uzraudzību tādās ierīcēs kā printeri, tīkla komutatori, maršrutētāji vai UPS, kas parasti atbalsta SNMP un kurās būtu nepraktiski mēģināt iestatīt pilnas operētājsistēmas un Zabbix aģentus.
Lai varētu izgūt datus, ko SNMP aģenti sniedz šajās ierīcēs, Zabbix serverim sākotnēji jābūt konfigurētam ar SNMP atbalstu, norādot --with-net-snmp karogu.
Ieteicams arī instalēt MIB failus, lai nodrošinātu, ka vienumu vērtības tiek attēlotas pareizajā formātā.
Bez MIB failiem var rasties formatēšanas problēmas, piemēram, vērtību attēlošana HEX formātā UTF-8 vietā vai otrādi.
SNMP pārbaudes tiek veiktas tikai, izmantojot UDP protokolu.
Zabbix servera un starpniekservera dēmoni reģistrē līdzīgas rindas kā tālāk redzamā, ja tie saņem nepareizu SNMP atbildi:
SNMP response from host "gateway" does not contain all of the requested variable bindingsLai gan tās neaptver visus problemātiskos gadījumus, tās ir noderīgas atsevišķu SNMP ierīču identificēšanai, kurām jāatspējo apvienotie pieprasījumi.
Zabbix serveris/starpniekserveris atkārtos mēģinājumu līdz 5 reizēm SNMP walk un get vienumiem.
Atkārtošanas mehānisms neattiecas uz DNS atrisināšanas kļūmēm.
Mantotajām SNMP pārbaudēm (viens OID numurs vai virkne) Zabbix serveris/starpniekserveris pēc neveiksmīga vaicājuma mēģinājuma atkārtos vismaz vienu reizi: vai nu izmantojot SNMP bibliotēkas atkārtošanas mehānismu, vai iekšējo apvienotās apstrādes mehānismu.
Ja uzraugāt SNMPv3 ierīces, pārliecinieties, ka msgAuthoritativeEngineID (pazīstams arī kā snmpEngineID vai "Engine ID") nekad netiek koplietots starp divām ierīcēm. Saskaņā ar RFC 2571 (3.1.1.1. sadaļa) tam jābūt unikālam katrai ierīcei.
RFC3414 pieprasa, lai SNMPv3 ierīces saglabātu savus engineBoots. Dažas ierīces to nedara, kā rezultātā pēc restartēšanas to SNMP ziņojumi tiek atmesti kā novecojuši. Šādā situācijā SNMP kešatmiņa serverī/starpniekserverī ir jānotīra manuāli (izmantojot -R snmp_cache_reload) vai arī serveris/starpniekserveris ir jārestartē.
Zabbix kešo SNMPv3 EngineID → IP kartējumus un atkārtotām pārbaudēm izmanto kešotos EngineID, nevis katru reizi sūta probe, tādējādi samazinot tīkla trafiku. Ja EngineID nevar atkārtoti izmantot, tiks veikts atkārtots mēģinājums ar probe, lai atklātu jauno EngineID.
SNMP uzraudzības konfigurēšana
Lai sāktu ierīces uzraudzību, izmantojot SNMP, ir jāveic šādas darbības:
1. solis
Noskaidrojiet SNMP virkni (vai OID) vienumam, ko vēlaties uzraudzīt.
Lai iegūtu SNMP virkņu sarakstu, izmantojiet komandu snmpwalk (net-snmp programmatūras daļa, kurai vajadzētu būt instalētai kā Zabbix instalācijas sastāvdaļai) vai līdzīgu rīku:
snmpwalk -v 2c -c public <host IP> .Tā kā 2c šeit apzīmē SNMP versiju, to var aizstāt arī ar 1, lai norādītu ierīcē SNMP 1. versiju.
Tam vajadzētu atgriezt SNMP virkņu sarakstu un to pēdējo vērtību. Ja tas nenotiek, iespējams, ka SNMP "community" atšķiras no standarta "public", un tādā gadījumā jums būs jānoskaidro, kāda tā ir.
Pēc tam varat pārskatīt sarakstu, līdz atrodat virkni, ko vēlaties uzraudzīt, piemēram,
ja vēlaties uzraudzīt ienākošos baitus savā komutatorā 3. portā, izmantosiet virkni IF-MIB::ifHCInOctets.3 no šīs rindas:
IF-MIB::ifHCInOctets.3 = Counter64: 3409739121Tagad varat izmantot komandu snmpget, lai noskaidrotu skaitlisko OID priekš IF-MIB::ifHCInOctets.3:
snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3Ņemiet vērā, ka pēdējais skaitlis virknē ir porta numurs, ko vēlaties uzraudzīt. Skatiet arī: Dinamiskie indeksi.
Tam vajadzētu atgriezt kaut ko līdzīgu šim:
.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941Arī šeit OID pēdējais skaitlis ir porta numurs.
Daži no visbiežāk izmantotajiem SNMP OID tiek automātiski pārtulkoti skaitliskā attēlojumā ar Zabbix.
Iepriekšējā piemērā vērtības tips ir "Counter64", kas iekšēji atbilst ASN_COUNTER64 tipam. Pilns atbalstīto tipu saraksts ir 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 un ASN_OBJECT_ID. Šie tipi aptuveni atbilst "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" snmpget izvades formātā, taču atkarībā no attēlošanas norādes klātbūtnes tie var tikt rādīti arī kā "STRING", "Hex-STRING", "OID" un citi.
2. solis
Izveidojiet hostu, kas atbilst ierīcei.
Pievienojiet hostam SNMP saskarni:
- Ievadiet IP adresi/DNS nosaukumu un porta numuru.
- Nolaižamajā sarakstā atlasiet SNMP versiju.
- Pievienojiet saskarnes akreditācijas datus atkarībā no atlasītās SNMP versijas:
- SNMPv1, v2 nepieciešams tikai community (parasti 'public').
- SNMPv3 nepieciešamas specifiskākas opcijas; skatiet SNMPv3.
- Norādiet maksimālo atkārtojumu vērtību (noklusējums: 10) native SNMP bulk requests (GetBulkRequest-PDU); tikai
discovery[]unwalk[]vienumiem SNMPv2 un v3. Ņemiet vērā, ka pārāk augstas šīs vērtības iestatīšana var izraisīt SNMP aģenta pārbaudes noildzi. - Atzīmējiet izvēles rūtiņu Use combined requests, lai atļautu SNMP pieprasījumu combined processing (nav saistīts ar native SNMP bulk requests "walk" un "get").
Varat izmantot kādu no piedāvātajām SNMP veidnēm, kas automātiski pievienos vienumu kopu. Pirms veidnes izmantošanas pārliecinieties, ka tā ir saderīga ar hostu.
Noklikšķiniet uz Add, lai saglabātu hostu.
SNMPv3
SNMPv3 ir nepieciešami šādi parametri:
- Context name - ievadiet konteksta nosaukumu, lai identificētu vienums SNMP apakštīklā.
Šajā laukā tiek aizstāti lietotāja makrosi. - Security name - ievadiet drošības nosaukumu.
Šajā laukā tiek aizstāti lietotāja makrosi. - Security level - izvēlieties drošības līmeni:
- noAuthNoPriv - netiek izmantoti ne autentifikācijas, ne privātuma protokoli;
- AuthNoPriv - tiek izmantots autentifikācijas protokols, privātuma protokols netiek izmantots;
- AuthPriv - tiek izmantoti gan autentifikācijas, gan privātuma protokoli.
- Authentication protocol - izvēlieties autentifikācijas protokolu: MD5, SHA1; ar net-snmp 5.8 un jaunāku versiju - SHA224, SHA256, SHA384 vai SHA512.
- Authentication passphrase - ievadiet autentifikācijas paroli.
Šajā laukā tiek aizstāti lietotāja makrosi. - Privacy protocol - izvēlieties privātuma protokolu: DES, AES128, AES192, AES256, AES192C (Cisco) vai AES256C (Cisco).
Skatiet piezīmes par privātuma protokola atbalstu. - Privacy passphrase - ievadiet privātuma paroli.
Šajā laukā tiek aizstāti lietotāja makrosi.
Ja SNMPv3 akreditācijas dati ir nepareizi (drošības nosaukums, autentifikācijas protokols/parole, privātuma protokols):
- Zabbix no net-snmp saņem ERROR, izņemot gadījumu, kad ir nepareiza Privacy passphrase; šādā gadījumā Zabbix no net-snmp saņem TIMEOUT kļūdu.
- SNMP saskarnes pieejamība tiks pārslēgta uz sarkanu (nav pieejama).
Izmaiņas Authentication protocol, Authentication passphrase, Privacy protocol vai Privacy passphrase, kas veiktas, nemainot Security name, parasti tiek automātiski piemērotas, kad attiecīgā SNMPv3 saskarne tiek atjaunināta Zabbix.
Gadījumos, kad tiek mainīts arī Security name, visi parametri tiks atjaunināti nekavējoties.
Privātuma protokolu atbalsts
Atkarībā no jūsu operētājsistēmas un net-snmp konfigurācijas daži privātuma protokoli var nebūt pieejami:
-
Dažās jaunākās operētājsistēmās (piemēram, RHEL9) DES atbalsts pakotnei
net-snmpir noņemts. -
Šifrēšanas protokoli AES192 un spēcīgāki pēc noklusējuma netiek atbalstīti vecākās operētājsistēmās nekā RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.
Lai pārbaudītu, vai net-snmp bibliotēka atbalsta AES192+, izmantojiet vienu no šīm iespējām:
net-snmp-config:
net-snmp-config --configure-optionsJa izvade satur --enable-blumenthal-aes, AES192+ ir atbalstīts.
Ņemiet vērā, ka net-snmp-config ir daļa no SNMP izstrādes pakotnes (libsnmp-dev Debian/Ubuntu, net-snmp-devel CentOS/RHEL/OL/SUSE) un pēc noklusējuma var nebūt instalēts.
snmpget:
snmpget -v 3 -x AES-256Ja izvade satur Invalid privacy protocol specified after -3x flag: AES-256, AES192+ netiek atbalstīts.
Ja izvade satur No hostname specified., AES192+ netiek atbalstīts.
Ja jūsu net-snmp bibliotēka neatbalsta AES192 un augstākus protokolus, pārkompilējiet net-snmp ar --enable-blumenthal-aes opciju, pēc tam pārkompilējiet Zabbix serveri, norādot opciju --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.
3. darbība
Izveidojiet vienumu uzraudzībai.
Tagad atgriezieties Zabbix un noklikšķiniet uz Items iepriekš izveidotajam SNMP hostam. Atkarībā no tā, vai, veidojot hostu, izmantojāt veidni, jums būs vai nu ar hostu saistīto SNMP vienumu saraksts, vai arī tukšs saraksts. Pieņemsim, ka vienumu izveidosiet pats, izmantojot informāciju, ko tikko ieguvāt ar snmpwalk un snmpget, tāpēc noklikšķiniet uz Create item.
Jaunā vienuma veidlapā aizpildiet obligātos parametrus:
| Parameter | Description |
|---|---|
| Name | Ievadiet vienuma nosaukumu. |
| Type | Šeit atlasiet SNMP agent. |
| Key | Ievadiet jēgpilnu atslēgu. |
| Host interface | Noteikti atlasiet SNMP saskarni, piemēram, savai komutatora vai maršrutētāja ierīcei. |
| SNMP OID | OID vērtības ievadīšanai izmantojiet kādu no atbalstītajiem formātiem: walk[OID1,OID2,...] - izgūst vērtību apakškoku. Piemēram: walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].Šī opcija asinhroni izmanto vietējos SNMP lielapjoma pieprasījumus (GetBulkRequest-PDU). Šī vienuma taimauta iestatījumus var konfigurēt vienuma konfigurācijas veidlapā. Apsveriet iespēju iestatīt nelielu taimauta vērtību, lai izvairītos no ilgām aizturēm, ja ierīce nav sasniedzama, jo tiks veikti līdz 5 atkārtoti mēģinājumi, ja iepriekšējie mēģinājumi beidzas ar taimautu vai neizdodas (piemēram, 3 sekunžu taimauts var izraisīt 15 sekunžu gaidīšanu). Varat izmantot šo vienumu kā galveno vienumu un izveidot atkarīgos vienumus, kas, izmantojot priekšapstrādi, izgūst datus no galvenā vienuma. Vienā snmp walk var norādīt vairākus OID, piemēram, walk[OID1,OID2,...], lai asinhroni apstrādātu pa vienam OID.Ja lielapjoma pieprasījums neatgriež rezultātus, tiek mēģināts izgūt vienu ierakstu bez lielapjoma pieprasījuma. MIB nosaukumus var izmantot kā parametrus; tādējādi walk[1.3.6.1.2.1.2.2.1.2] un walk[ifDescr] atgriezīs vienādu izvadi.Ja ir norādīti vairāki OID/MIB, piemēram, walk[ifDescr,ifType,ifPhysAddress], izvade būs apvienots saraksts.GetBulk pieprasījumi tiek izmantoti ar SNMPv2 un v3 saskarnēm, bet GetNext - ar SNMPv1 saskarnēm; maksimālais atkārtojumu skaits lielapjoma pieprasījumiem tiek konfigurēts saskarnes līmenī. Maksimālais atkārtojumu skaita parametrs ietekmē lielapjoma pieprasījumus, nosakot maksimālo vienā lielapjoma atbildē atgriežamo OID skaitu. Lielāka vērtība rada lielākas lielapjoma atbildes, samazinot nepieciešamo pārraižu skaitu. Tomēr ne visas ierīces var atbalstīt ļoti lielas vērtības, kas var radīt problēmas. Šis vienums atgriež snmpwalk utilītas izvadi ar parametriem -Oe -Ot -On. Šo vienumu varat izmantot kā galveno vienumu SNMP atklāšanā. get[OID] - asinhroni izgūst vienu vērtību. Piemēram: get[1.3.6.1.2.1.31.1.1.1.6.3]Šī vienuma taimauta iestatījumus var konfigurēt vienuma konfigurācijas veidlapā. Apsveriet iespēju iestatīt nelielu taimauta vērtību, lai izvairītos no ilgām aizturēm, ja ierīce nav sasniedzama, jo tiks veikti līdz 5 atkārtoti mēģinājumi, ja iepriekšējie mēģinājumi beidzas ar taimautu vai neizdodas (piemēram, 3 sekunžu taimauts var izraisīt 15 sekunžu gaidīšanu). OID - (mantots) ievadiet vienu teksta vai skaitlisku OID, lai sinhroni izgūtu vienu vērtību, pēc izvēles apvienojot to ar citām vērtībām. Piemēram: 1.3.6.1.2.1.31.1.1.1.6.3.Šai opcijai vienuma pārbaudes taimauts būs vienāds ar vērtību, kas iestatīta servera konfigurācijas failā. Ieteicams izmantot walk[OID] un get[OID] vienumus labākai veiktspējai. Visi walk[OID] un get[OID] vienumi tiek izpildīti asinhroni - nav nepieciešams saņemt atbildi uz vienu pieprasījumu, pirms tiek sākta cita pārbaude. Arī DNS atrisināšana notiek asinhroni.Asinhrono pārbaužu maksimālā vienlaicība ir 1000 (to nosaka MaxConcurrentChecksPerPoller). Asinhrono SNMP aptauju skaitu nosaka parametrs StartSNMPPollers. Ņemiet vērā, ka tīkla datplūsmas statistikai, ko atgriež jebkura no metodēm, cilnē Preprocessing jāpievieno darbība Change per second; pretējā gadījumā no SNMP ierīces saņemsiet kumulatīvo vērtību, nevis jaunākās izmaiņas. |
Visi obligātie ievades lauki ir atzīmēti ar sarkanu zvaigznīti.
Tagad saglabājiet vienumu un dodieties uz Monitoring > Latest data, lai skatītu savus SNMP datus.
Piemērs 1
Vispārīgs piemērs:
| Parametrs | Apraksts |
|---|---|
| OID | 1.2.3.45.6.7.8.0 (vai .1.2.3.45.6.7.8.0) |
| Atslēga | <Unikāla virkne, kas tiks izmantota kā atsauce uz trigeriem> Piemēram, "my_param". |
Ņemiet vērā, ka OID var norādīt gan skaitliskā, gan virknes formā. Tomēr dažos gadījumos virknes OID ir jāpārveido skaitliskā attēlojumā. Šim nolūkam var izmantot utilītu snmpget:
snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0Piemērs 2
Darbspējas laika uzraudzība:
| Parametrs | Apraksts |
|---|---|
| OID | MIB::sysUpTime.0 |
| Atslēga | router.uptime |
| Vērtības tips | Peldošā komata skaitlis |
| Mērvienības | darbspējas laiks |
| Pirmsapstrādes solis: Pielāgots reizinātājs | 0.01 |
Vietējie SNMP lielapjoma pieprasījumi
Vienums walk[OID1,OID2,...] ļauj izmantot vietējo SNMP funkcionalitāti lielapjoma pieprasījumiem (GetBulkRequest-PDU), kas ir pieejami SNMP 2. un 3. versijā.
GetBulk pieprasījums SNMP izpilda vairākus GetNext pieprasījumus un atgriež rezultātu vienā atbildē.
To var izmantot gan parastiem SNMP vienumiem, gan SNMP atklāšanai, lai samazinātu tīkla turp-atpakaļ pieprasījumu skaitu.
SNMP vienumu walk[OID1,OID2,...] var izmantot kā galveno vienumu, kas vienā pieprasījumā apkopo datus, savukārt atkarīgie vienumi pēc vajadzības analizē atbildi, izmantojot priekšapstrādi.
Ņemiet vērā, ka vietējo SNMP lielapjoma pieprasījumu izmantošana nav saistīta ar SNMP pieprasījumu apvienošanas opciju, kas ir Zabbix veids, kā apvienot vairākus SNMP pieprasījumus (skatiet nākamo sadaļu).
SNMP lielapjoma vienumiem tiks veikti līdz pieciem atkārtotiem mēģinājumiem, lai izvairītos no kļūmes, ja kāda no paketēm tiek pazaudēta.
SNMP vienumu ar get un walk taimauts (iestatīts vienuma konfigurācijas veidlapā) tiek piemērots visai sesijai. Taimauts tiek piemērots neatkarīgi no tā, vai dati ir izgūti pilnībā; ja dati tiek saņemti daļēji (piemēram, dati ir veiksmīgi apkopoti tikai vienam no vairākiem OID), vienums kļūst neatbalstīts ar ziņojumu "Only partial data received".
Ja tiek sasniegts taimauts, tiks veikts atkārtots mēģinājums, taimauts tiks atiestatīts un pēdējais pieprasījums tiks nosūtīts atkārtoti, ļaujot sesijai turpināties no pēdējā pieprasījuma, ja viena pakete tiek pazaudēta vai pienāk pārāk vēlu.
Apsveriet iespēju iestatīt zemu taimauta vērtību, lai izvairītos no ilgstošas aizkaves, ja ierīce nav sasniedzama, jo tiks veikti līdz 5 atkārtotiem mēģinājumiem, ja iepriekšējie mēģinājumi beidzas ar taimautu vai neizdodas (piemēram, 3 sekunžu taimauts var izraisīt 15 sekunžu gaidīšanas laiku).
Kombinētās apstrādes iekšējā darbība
Zabbix serveris un starpniekserveris vienā pieprasījumā var vaicāt SNMP ierīcēm vairākas vērtības. Tas ietekmē vairākus SNMP vienumu veidus:
- parastie SNMP vienumi
- SNMP vienumi ar dinamiskiem indeksiem
- SNMP zema līmeņa atklāšanas noteikumi
Visi SNMP vienumi vienā saskarnē ar identiskiem parametriem tiek ieplānoti vaicāšanai vienlaikus. Pirmo divu veidu vienumus polleri paņem partijās, kurās ir ne vairāk kā 128 vienumi, savukārt zema līmeņa atklāšanas noteikumi, tāpat kā iepriekš, tiek apstrādāti atsevišķi.
Zemākā līmenī vērtību vaicāšanai tiek veiktas divu veidu darbības: vairāku norādītu objektu iegūšana un OID koka apstaigāšana.
"Iegūšanai" tiek izmantots GetRequest-PDU ar ne vairāk kā 128 mainīgo piesaistēm. "Apstaigāšanai" SNMPv1 tiek izmantots GetNextRequest-PDU, bet SNMPv2 un SNMPv3 tiek izmantots GetBulkRequest ar lauku "max-repetitions", kura vērtība nepārsniedz 128.
Tādējādi kombinētās apstrādes priekšrocības katram SNMP vienumu veidam ir šādas:
- parastie SNMP vienumi izmanto "iegūšanas" uzlabojumus;
- SNMP vienumi ar dinamiskiem indeksiem izmanto gan "iegūšanas", gan "apstaigāšanas" uzlabojumus: "iegūšana" tiek izmantota indeksa pārbaudei, bet "apstaigāšana" - kešatmiņas izveidei;
- SNMP zema līmeņa atklāšanas noteikumi izmanto "apstaigāšanas" uzlabojumus.
Tomēr pastāv tehniska problēma: ne visas ierīces spēj vienā pieprasījumā atgriezt 128 vērtības. Dažas ierīces vienmēr atgriež pareizu atbildi, bet citas vai nu atbild ar kļūdu "tooBig(1)", vai arī vispār neatbild, tiklīdz iespējamās atbildes apjoms pārsniedz noteiktu ierobežojumu.
Lai atrastu konkrētai ierīcei optimālo vaicājamo objektu skaitu, Zabbix izmanto šādu stratēģiju. Sākumā tas piesardzīgi pieprasa 1 vērtību vienā pieprasījumā. Ja tas izdodas, tiek pieprasītas 2 vērtības vienā pieprasījumā. Ja arī tas izdodas, tiek pieprasītas 3 vērtības vienā pieprasījumā, un pēc tam process turpinās līdzīgi, reizinot vaicājamo objektu skaitu ar 1,5. Tādējādi tiek iegūta šāda pieprasījumu izmēru secība: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
Tomēr, tiklīdz ierīce atsakās sniegt pareizu atbildi, piemēram, 42 mainīgajiem, Zabbix veic divas darbības.
Pirmkārt, pašreizējai vienumu partijai tas samazina objektu skaitu vienā pieprasījumā uz pusi un pieprasa 21 mainīgo. Ja ierīce darbojas, vaicājumam vajadzētu izdoties lielākajā daļā gadījumu, jo ir zināms, ka 28 mainīgie darbojās, bet 21 ir ievērojami mazāk. Tomēr, ja arī tas neizdodas, Zabbix pāriet uz vērtību vaicāšanu pa vienai. Ja arī šajā brīdī vaicājums neizdodas, ierīce noteikti neatbild un pieprasījuma izmērs nav problēmas cēlonis.
Otrkārt, nākamajām vienumu partijām Zabbix sāk ar pēdējo veiksmīgo mainīgo skaitu (mūsu piemērā - 28) un turpina palielināt pieprasījumu izmēru par 1, līdz tiek sasniegts ierobežojums. Piemēram, pieņemot, ka lielākais atbildes izmērs ir 32 mainīgie, nākamo pieprasījumu izmēri būs 29, 30, 31, 32 un 33. Pēdējais pieprasījums neizdosies, un Zabbix vairs nekad neizsniegs pieprasījumu ar 33 mainīgajiem. No šī brīža Zabbix šai ierīcei vaicās ne vairāk kā 32 mainīgos.
Ja lieli vaicājumi ar šādu mainīgo skaitu neizdodas, tam var būt viens no diviem iemesliem. Precīzus kritērijus, ko ierīce izmanto atbildes izmēra ierobežošanai, nav iespējams zināt, taču mēs mēģinām tos aptuveni noteikt, izmantojot mainīgo skaitu. Pirmā iespēja ir tāda, ka šis mainīgo skaits vispārīgā gadījumā ir aptuveni vienāds ar ierīces faktisko atbildes izmēra ierobežojumu: dažreiz atbilde ir mazāka par ierobežojumu, bet dažreiz - lielāka. Otrā iespēja ir tāda, ka UDP pakete vienā no virzieniem vienkārši tika pazaudēta. Šo iemeslu dēļ, ja Zabbix saņem neveiksmīgu atbildi uz vaicājumu, tas samazina maksimālo mēģināmo mainīgo skaitu, lai nonāktu dziļāk ierīces komforta diapazonā, taču ne vairāk kā divas reizes.
Iepriekš minētajā piemērā, ja vaicājums ar 32 mainīgajiem nejauši neizdodas, Zabbix samazina skaitu līdz 31. Ja arī tas neizdodas, Zabbix samazina skaitu līdz 30. Tomēr Zabbix nesamazinās skaitu zem 30, jo pieņems, ka turpmākās kļūmes izraisa pazaudētas UDP paketes, nevis ierīces ierobežojums.
Ja ierīce citu iemeslu dēļ nespēj pareizi apstrādāt kombinētos pieprasījumus un iepriekš aprakstītā heiristika nedarbojas, katrai saskarnei ir pieejams iestatījums "Use combined requests", kas ļauj atspējot kombinētos pieprasījumus šai ierīcei.
Ja kombinētie pieprasījumi izraisa daļējas vai nepareizi formatētas atbildes, kuru rezultātā tiek veikti nepareizi aprēķini sekundē (delta), piemēram, šķietami lieli saskarnes skaitītāju lēcieni, atspējojiet Use combined requests ietekmētajai saskarnei, lai piespiestu veikt atsevišķus vaicājumus katram vienumam; tas bieži novērš kļūdainus lēcienus.
Varat arī apsvērt asinhrono get[] vai walk[] vienumu izmantošanu. Tie tiek izpildīti asinhroni un uz tiem neattiecas katras saskarnes Use combined requests pakešu apstrāde - tos var izmantot mantoto sinhrono OID pārbaužu vietā, lai izvairītos no ar kombinētajiem pieprasījumiem saistītām problēmām.
Lai identificētu ietekmētās ierīces, skatiet servera/starpniekservera žurnāla ierakstus, kas līdzīgi sadaļā Pārskats parādītajam ierakstam.
Turklāt, ja saskarne bieži kļūst nepieejama, var būt nepieciešams palielināt parametra UnavailableDelay vērtību Zabbix servera vai Zabbix starpniekservera konfigurācijas failos, lai samazinātu pieprasījumu biežumu.
Vienumi var kļūt neatbalstīti, ja atklāšanas vai OID koku apstaigāšanas laikā tiek saņemti daļēji dati.