3 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 uzstādīt pilnvērtīgas 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 norādītā, 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 kombinētie pieprasījumi būtu jāatspējo.
Zabbix serveris/starpniekserveris atkārtos mēģinājumu līdz 5 reizēm (kopš Zabbix 7.0.14) 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 kombinētā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 noraidīti 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ē.
SNMP uzraudzības konfigurēšana
Lai sāktu ierīces uzraudzību, izmantojot SNMP, ir jāveic šādas darbības:
1. darbība
Noskaidrojiet tā vienuma SNMP virkni (vai OID), kuru vēlaties uzraudzīt.
Lai iegūtu SNMP virkņu sarakstu, izmantojiet komandu snmpwalk (daļu no net-snmp programmatūras, kurai jābūt instalētai kā daļai no Zabbix instalācijas) vai līdzvērtīgu rīku:
snmpwalk -v 2c -c public <host IP> .Tā kā šeit '2c' apzīmē SNMP versiju, varat to aizstāt arī ar '1', lai norādītu, ka ierīcē tiek izmantota SNMP 1. versija.
Tam vajadzētu atgriezt SNMP virkņu sarakstu un to pēdējo vērtību. Ja tā 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, kuru vēlaties uzraudzīt, piemēram,
ja vēlaties uzraudzīt baitus, kas ienāk jūsu komutatorā 3. portā, jums jāizmanto virkne IF-MIB::ifHCInOctets.3 no šīs rindas:
IF-MIB::ifHCInOctets.3 = Counter64: 3409739121Tagad varat izmantot komandu snmpget, lai noskaidrotu 'IF-MIB::ifHCInOctets.3' skaitlisko OID:
snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3Ņemiet vērā, ka pēdējais skaitlis virknē ir porta numurs, kuru 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: 3472126941Atkal, pēdējais skaitlis OID ir porta numurs.
Daži no visbiežāk izmantotajiem SNMP OID tiek automātiski pārveidoti skaitliskā attēlojumā Zabbix sistēmā.
Iepriekšējā pēdējā piemērā vērtības tips ir "Counter64", kas iekšēji atbilst tipam ASN_COUNTER64. 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 izvadē, taču atkarībā no attēlošanas norādes tie var tikt parādīti arī kā "STRING", "Hex-STRING", "OID" un citi.
2. solis
Izveidojiet hostu, kas atbilst ierīcei.
Pievienojiet hostam SNMP interfeisu:
- Ievadiet IP adresi/DNS nosaukumu un porta numuru.
- Nolaižamajā sarakstā atlasiet SNMP versiju.
- Pievienojiet interfeisa 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 tālāk).
- Norādiet maksimālo atkārtojumu vērtību (noklusējums: 10) vietējām SNMP bulk pieprasījumu (GetBulkRequest-PDU) apstrādēm; 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ģents pārbaudes noildzi. - Atzīmējiet izvēles rūtiņu Use combined requests, lai atļautu SNMP pieprasījumu apvienotu apstrādi (nav saistīta ar vietējiem SNMP bulk pieprasījumiem "walk" un "get").
| SNMPv3 parametrs | Apraksts |
|---|---|
| Context name | Ievadiet konteksta nosaukumu, lai identificētu vienumu SNMP apakštīklā. Šajā laukā tiek aizvietoti lietotāja makrosi. |
| Security name | Ievadiet drošības nosaukumu. Šajā laukā tiek aizvietoti lietotāja makrosi. |
| Security level | Atlasiet 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 | Atlasiet autentifikācijas protokolu - MD5, SHA1; ar net-snmp 5.8 un jaunāku versiju - SHA224, SHA256, SHA384 vai SHA512. |
| Authentication passphrase | Ievadiet autentifikācijas ieejas frāzi. Šajā laukā tiek aizvietoti lietotāja makrosi. |
| Privacy protocol | Atlasiet 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 ieejas frāzi. Šajā laukā tiek aizvietoti lietotāja makrosi. |
Nepareizu SNMPv3 akreditācijas datu gadījumā (drošības nosaukums, autentifikācijas protokols/ieejas frāze, privātuma protokols):
- Zabbix saņem ERROR no net-snmp, izņemot gadījumu ar nepareizu Privacy passphrase, kad Zabbix saņem TIMEOUT kļūdu no net-snmp.
- SNMP interfeisa pieejamība tiks mainīta uz sarkanu (nav pieejams).
Izmaiņas Authentication protocol, Authentication passphrase, Privacy protocol vai Privacy passphrase, kas veiktas, nemainot Security name, parasti tiek automātiski piemērotas, kad attiecīgais SNMPv3 interfeiss tiek atjaunināts Zabbix.
Gadījumos, kad tiek mainīts arī Security name, visi parametri tiks atjaunināti nekavējoties.
Varat izmantot kādu no pieejamajā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.
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 net-snmp pakotnē ir noņemts.
-
Šifrēšanas protokoli AES192 un spēcīgāki pēc noklusējuma netiek atbalstīti operētājsistēmās, kas ir vecākas par 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+ nav atbalstīts.
Ja izvade satur No hostname specified., AES192+ nav 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 serveris, norādot opciju --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.
3. solis
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 vai ne, jums būs vai nu ar hostu saistītu SNMP vienumu saraksts, vai arī tikai tukšs saraksts. Mēs pieņemsim, ka vienumu veidosiet pats, izmantojot informāciju, ko tikko ieguvāt ar snmpwalk un snmpget, tāpēc noklikšķiniet uz Create item.
Jaunā vienuma formā aizpildiet nepieciešamos parametrus:
| Parameter | Description |
|---|---|
| Name | Ievadiet vienuma nosaukumu. |
| Type | Šeit izvēlieties SNMP agent. |
| Key | Ievadiet atslēgu ar jēgpilnu nosaukumu. |
| Host interface | Pārliecinieties, ka ir izvēlēta SNMP saskarne, piemēram, jūsu komutatora/maršrutētāja saskarne. |
| SNMP OID | Lai ievadītu OID vērtību(-as), izmantojiet vienu 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 izmanto native SNMP bulk requests (GetBulkRequest-PDUs) asinhroni. Šī vienuma taimauta iestatījumus var norādīt vienuma konfigurācijas formā. Apsveriet iespēju iestatīt mazu taimauta vērtību, lai izvairītos no ilgas gaidīšanas, ja ierīce nav sasniedzama, jo tiks veikti līdz pat 5 atkārtoti mēģinājumi (kopš Zabbix 7.0.14), ja iepriekšējie beigsies ar taimautu vai kļūdu (piem., 3 sekunžu taimauts var radīt 15 sekunžu gaidīšanas laiku). Varat izmantot šo kā galveno vienumu ar atkarīgajiem vienumiem, kas, izmantojot pirmapstrādi, izgūst datus no galvenā vienuma. Vienā snmp walk ir iespējams norādīt vairākus OID, piemēram, walk[OID1,OID2,...], lai asinhroni apstrādātu vienu OID vienlaikus.Ja bulk pieprasījums neatgriež rezultātus, tiek mēģināts izgūt vienu ierakstu bez bulk pieprasījuma. Kā parametri tiek atbalstīti MIB nosaukumi; 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, t. i., 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; bulk pieprasījumu maksimālais atkārtojumu skaits tiek konfigurēts saskarnes līmenī. Parametrs max repetitions ietekmē bulk pieprasījumus, nosakot maksimālo OID skaitu, kas tiek atgriezts vienā bulk atbildē. Lielāka vērtība rada lielākas bulk atbildes, samazinot nepieciešamo pārraides reiž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. Varat izmantot šo vienumu kā galveno vienumu SNMP discovery. get[OID] - izgūst vienu vērtību asinhroni. Piemēram: get[1.3.6.1.2.1.31.1.1.1.6.3]Šī vienuma taimauta iestatījumus var norādīt vienuma konfigurācijas formā. Apsveriet iespēju iestatīt mazu taimauta vērtību, lai izvairītos no ilgas gaidīšanas, ja ierīce nav sasniedzama, jo tiks veikti līdz pat 5 atkārtoti mēģinājumi (kopš Zabbix 7.0.14), ja iepriekšējie beigsies ar taimautu vai kļūdu (piem., 3 sekunžu taimauts var radīt 15 sekunžu gaidīšanas laiku). OID - (mantots) ievadiet vienu teksta vai skaitlisku OID, lai sinhroni izgūtu vienu vērtību, pēc izvēles kombinējot 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ā. Labākas veiktspējas dēļ ir ieteicams izmantot vienumus walk[OID] un get[OID]. Visi walk[OID] un get[OID] vienumi tiek izpildīti asinhroni - nav nepieciešams saņemt vienas pieprasījuma atbildi, pirms tiek sākta citu pārbaužu izpilde. Arī DNS atrisināšana ir asinhrona.Asinhrono pārbaužu maksimālā paralēlā izpilde ir 1000 (definēts ar MaxConcurrentChecksPerPoller). Asinhrono SNMP polleru skaitu nosaka parametrs StartSNMPPollers. Ņemiet vērā, ka tīkla trafika statistikai, ko atgriež jebkura no metodēm, cilnē Preprocessing jāpievieno solis Change per second; pretējā gadījumā jūs saņemsiet kumulatīvo vērtību no SNMP ierīces, nevis pēdējo izmaiņu. |
Visi obligātie ievades lauki ir atzīmēti ar sarkanu zvaigznīti.
Tagad saglabājiet vienumu un dodieties uz Monitoring > Latest data saviem SNMP datiem.
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 |
Native SNMP bulk requests
Vienums walk[OID1,OID2,...] ļauj izmantot SNMP vietējo funkcionalitāti masveida pieprasījumiem (GetBulkRequest-PDU), kas ir pieejama SNMP 2/3 versijās.
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 walk[OID1,OID2,...] vienumu var izmantot kā galveno vienumu, kas vienā pieprasījumā apkopo datus, bet atkarīgie vienumi, izmantojot priekšapstrādi, pēc vajadzības parsē atbildi.
Ņemiet vērā, ka vietējo SNMP masveida pieprasījumu izmantošana nav saistīta ar SNMP pieprasījumu apvienošanas opciju, kas ir Zabbix paša metode vairāku SNMP pieprasījumu apvienošanai (skatiet nākamo sadaļu).
SNMP masveida vienumiem tiks veikti līdz pieciem atkārtotiem mēģinājumiem (kopš Zabbix 7.0.14), lai izvairītos no kļūmes, ja tiek pazaudēta viena no paketēm.
SNMP vienumu ar get un walk taimauts (iestatīts vienuma konfigurācijas formā) tiek noteikts visai sesijai.
Taimauts tiek piemērots neatkarīgi no tā, vai dati ir saņemti pilnībā; ja dati tiek saņemti daļēji (piemēram, veiksmīgi tiek savākti dati tikai vienam no vairākiem OID), tad vienums kļūst neatbalstīts ar ziņojumu "Only partial data received".
Ja taimauts tiek sasniegts, tiks veikts atkārtots mēģinājums, taimauts tiks atiestatīts un pēdējais pieprasījums tiks nosūtīts vēlreiz, ļaujot turpināt sesiju no pēdējā pieprasījuma, ja viena pakete ir pazaudēta vai saņemta pārāk vēlu.
Apsveriet iespēju iestatīt zemu taimauta vērtību, lai izvairītos no ilgām aiztures reizēm, ja ierīce nav sasniedzama, jo tiks veikti līdz 5 atkārtotiem mēģinājumiem, ja iepriekšējie beigsies ar taimautu vai kļūdu (piem., 3 sekunžu taimauts var radīt 15 sekunžu gaidīšanas laiku).
Kombinētās apstrādes iekšējā darbība
Zabbix serveris un starpniekserveris var vaicāt SNMP ierīcēm vairākas vērtības vienā pieprasījumā. Tas ietekmē vairākus SNMP vienumu veidus:
- parastie SNMP vienumi
- SNMP vienumi ar dinamiskajiem indeksiem
- SNMP zemlīmeņa atklāšanas noteikumi
Visi SNMP vienumi vienā saskarnē ar identiskiem parametriem tiek ieplānoti vaicāšanai vienā un tajā pašā laikā. Pirmie divi vienumu veidi tiek apstrādāti ar aptaujātājiem partijās, kurās ir ne vairāk kā 128 vienumi, savukārt zemlīmeņa atklāšanas noteikumi tiek apstrādāti individuāli, kā iepriekš.
Zemākā līmenī vērtību vaicāšanai tiek veikti divu veidu darbības: vairāku norādītu objektu iegūšana un OID koka pārlūkošana.
"Iegūšanai" tiek izmantots GetRequest-PDU ar ne vairāk kā 128 mainīgo piesaistēm. "Pārlūkošanai" SNMPv1 tiek izmantots GetNextRequest-PDU, bet SNMPv2 un SNMPv3 tiek izmantots GetBulkRequest ar lauku "max-repetitions" ne vairāk kā 128.
Tādējādi kombinētās apstrādes ieguvumi katram SNMP vienumu veidam ir šādi:
- parastie SNMP vienumi gūst labumu no "iegūšanas" uzlabojumiem;
- SNMP vienumi ar dinamiskajiem indeksiem gūst labumu gan no "iegūšanas", gan no "pārlūkošanas" uzlabojumiem: "iegūšana" tiek izmantota indeksa pārbaudei, bet "pārlūkošana" - kešatmiņas izveidei;
- SNMP zemlīmeņa atklāšanas noteikumi gūst labumu no "pārlūkošanas" uzlabojumiem.
Tomēr pastāv tehniska problēma: ne visas ierīces spēj atgriezt 128 vērtības vienā pieprasījumā. Dažas vienmēr atgriež korektu atbildi, bet citas vai nu atbild ar "tooBig(1)" kļūdu, vai arī vispār neatbild, tiklīdz iespējamās atbildes apjoms pārsniedz noteiktu robežu.
Lai noteiktu optimālo vaicājamo objektu skaitu konkrētai ierīcei, Zabbix izmanto šādu stratēģiju. Tas sāk piesardzīgi, vienā pieprasījumā vaicājot 1 vērtību. Ja tas izdodas, vienā pieprasījumā tiek vaicātas 2 vērtības. Ja tas atkal izdodas, vienā pieprasījumā tiek vaicātas 3 vērtības, un turpmāk skaits tiek palielināts, reizinot vaicāto objektu skaitu ar 1.5, iegūstot šādu pieprasījumu izmēru secību: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
Tomēr, tiklīdz ierīce atsakās sniegt korektu atbildi (piemēram, pie 42 mainīgajiem), Zabbix veic divas darbības.
Pirmkārt, pašreizējai vienumu partijai tas uz pusi samazina objektu skaitu vienā pieprasījumā un vaicā 21 mainīgo. Ja ierīce ir aktīva, vaicājumam vairumā gadījumu vajadzētu darboties, jo 28 mainīgie iepriekš jau darbojās, un 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ī tas joprojām neizdodas, tad ierīce noteikti neatbild, un pieprasījuma izmērs nav problēma.
Otrkārt, turpmākajā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ījuma izmēru par 1, līdz tiek sasniegta robeža. Piemēram, pieņemot, ka lielākais atbildes izmērs ir 32 mainīgie, nākamie pieprasījumi būs ar izmēriem 29, 30, 31, 32 un 33. Pēdējais pieprasījums neizdosies, un Zabbix vairs nekad neizsūtīs pieprasījumu ar izmēru 33. No tā brīža Zabbix šai ierīcei vaicās ne vairāk kā 32 mainīgos.
Ja lielie pieprasījumi ar šo mainīgo skaitu neizdodas, tas var nozīmēt vienu no divām lietām. Precīzus kritērijus, ko ierīce izmanto atbildes izmēra ierobežošanai, nevar zināt, taču mēs cenšamies tos aptuveni noteikt, izmantojot mainīgo skaitu. Tātad pirmā iespēja ir tāda, ka šis mainīgo skaits vispārējā gadījumā ir aptuveni ierīces faktiskās atbildes izmēra robežas tuvumā: dažkārt atbilde ir mazāka par robežu, dažkārt lielāka. Otrā iespēja ir tāda, ka UDP pakete vienā no virzieniem vienkārši ir pazudusi. Šo iemeslu dēļ, ja Zabbix saņem neveiksmīgu pieprasījumu, tas samazina maksimālo mēģināmo mainīgo skaitu, lai mēģinātu tikt dziļāk ierīces komforta diapazonā, taču ne vairāk kā divas reizes.
Iepriekš minētajā piemērā, ja pieprasījums ar 32 mainīgajiem nejauši neizdodas, Zabbix samazinās skaitu līdz 31. Ja arī tas neizdodas, Zabbix samazinās skaitu līdz 30. Tomēr Zabbix nesamazinās skaitu zem 30, jo pieņems, ka turpmākās kļūmes ir saistītas ar UDP pakešu zudumu, nevis ar ierīces robežu.
Tomēr, 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 iestatījums "Use combined requests", kas ļauj šai ierīcei kombinētos pieprasījumus atspējot.
Ja kombinētie pieprasījumi izraisa daļējas vai bojātas atbildes, kas noved pie nepareiziem sekundes (delta) aprēķiniem (piemēram, šķietamiem lēcieniem saskarnes skaitītājos), atspējojiet Use combined requests ietekmētajai saskarnei, lai piespiestu atsevišķus vaicājumus katram vienumam; tas bieži novērš viltus lēcienus.
Alternatīvi apsveriet asinhrono get[] vai walk[] vienumu izmantošanu, kas tiek izpildīti asinhroni un nav pakļauti uz saskarni balstītai Use combined requests partiju veidošanai — tos var izmantot mantoto sinhrono OID pārbaužu vietā, lai izvairītos no problēmām, kas saistītas ar kombinētajiem pieprasījumiem.
Meklējiet servera/starpniekservera žurnāla ierakstus, kas līdzīgi tiem, kas parādīti sadaļā Pārskats, lai palīdzētu identificēt ietekmētās ierīces.
Papildus tam, ja saskarne bieži kļūst nepieejama, var būt nepieciešams palielināt parametru UnavailableDelay 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 pārlūkošanas laikā tiek saņemti daļēji dati.