2 SNMP aģents
Pārskats
Iespējams, vēlēsieties izmantot SNMP uzraudzību tādās ierīcēs kā printeri, tīkla komutatori, maršrutētāji vai UPS, kurām parasti ir iespējots SNMP un kurās būtu nepraktiski mēģināt iestatīt pilnvērtīgas operētājsistēmas un Zabbix aģentus.
Lai varētu iegūt datus, ko šajās ierīcēs nodrošina SNMP aģenti, Zabbix serverim sākotnēji jābūt konfigurētam ar SNMP atbalstu, norādot karodziņu --with-net-snmp.
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ē šādām līdzīgas žurnāla rindas, 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, lai identificētu atsevišķas SNMP ierīces, kurām būtu jāatspējo kombinētie pieprasījumi.
Zabbix serveris/starpniekserveris SNMP walk un get vienumiem veiks atkārtotu mēģinājumu līdz 5 reizēm. Atkārtotu mēģinājumu 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 veiks vismaz vienu atkārtotu mēģinājumu: vai nu izmantojot SNMP bibliotēkas atkārtošanas mehānismu, vai arī izmantojot iekšējo kombinēto apstrādi.
Ja uzraugāt SNMPv3 ierīces, pārliecinieties, ka msgAuthoritativeEngineID (zināms 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 savu engineBoots vērtību. Dažas ierīces to nedara, kā rezultātā to SNMP ziņojumi pēc restartēšanas tiek noraidīti kā novecojuši. Šādā situācijā SNMP kešatmiņa serverī/starpniekserverī ir manuāli jānotīra (izmantojot -R snmp_cache_reload) vai arī serveris/starpniekserveris ir jāpārstartē.
Zabbix kešo SNMPv3 EngineID → IP atbilstības un atkārtoti izmanto kešotos EngineID turpmākajām pārbaudēm, nevis katru reizi sūta zondēšanas pieprasījumu, tādējādi samazinot tīkla datplūsmu. Ja EngineID nevar izmantot atkārtoti, tiks veikts atkārtots mēģinājums ar zondēšanu, lai noteiktu jauno EngineID.
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 saskarni:
- Ievadiet IP adresi/DNS nosaukumu un porta numuru.
- Nolaižamajā sarakstā atlasiet SNMP version.
- Pievienojiet saskarnes akreditācijas datus atkarībā no atlasītās SNMP versijas:
- SNMPv1, v2 nepieciešama tikai kopiena (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ējiem SNMP lielapjoma pieprasījumiem (GetBulkRequest-PDUs); 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 kombinēto apstrādi (nav saistīta ar vietējiem SNMP lielapjoma pieprasījumiem "walk" un "get").
| SNMPv3 parametrs | Apraksts |
|---|---|
| Context name | Ievadiet konteksta nosaukumu, lai identificētu vienumu SNMP apakštīklā. Lietotāja makrosi tiek atrisināti šajā laukā. |
| Security name | Ievadiet drošības nosaukumu. Lietotāja makrosi tiek atrisināti šajā laukā. |
| 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 arī SHA224, SHA256, SHA384 vai SHA512. |
| Authentication passphrase | Ievadiet autentifikācijas paroli. Lietotāja makrosi tiek atrisināti šajā laukā. |
| 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 paroli. Lietotāja makrosi tiek atrisināti šajā laukā. |
Nepareizu SNMPv3 akreditācijas datu gadījumā (drošības nosaukums, autentifikācijas protokols/parole, privātuma protokols):
- Zabbix saņem ERROR no net-snmp, izņemot nepareizu Privacy passphrase gadījumu, kad Zabbix saņem TIMEOUT kļūdu no net-snmp.
- SNMP saskarnes pieejamība pārslēgsies uz sarkanu (nav pieejama).
Izmaiņas Authentication protocol, Authentication passphrase, Privacy protocol vai Privacy passphrase, kas veiktas, nemainot Security name, parasti tiek piemērotas automātiski, kad atbilstošā SNMPv3 saskarne tiek atjaunināta 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 pakotnei ir noņemts.
-
Šifrēšanas protokoli AES192 un spēcīgāki netiek atbalstīti pēc noklusējuma 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+ tiek 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ēta.
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 opciju --enable-blumenthal-aes, 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 SNMP hostam, ko izveidojāt iepriekš. Atkarībā no tā, vai hosta izveides laikā izmantojāt veidni vai ne, jums būs vai nu ar jūsu hostu saistītu SNMP vienumu saraksts, vai vienkārši tukšs saraksts. Mēs pieņemsim, ka jūs izveidosiet vienumu pats, izmantojot informāciju, ko tikko ieguvāt ar snmpwalk un snmpget, tāpēc noklikšķiniet uz Create item.
Aizpildiet obligātos parametrus jaunā vienuma formā:
| Parametrs | Apraksts |
|---|---|
| Name | Ievadiet vienuma nosaukumu. |
| Type | Šeit atlasiet SNMP aģents. |
| Key | Ievadiet atslēgu ar jēgpilnu nosaukumu. |
| Host interface | Pārliecinieties, ka ir atlasīta SNMP saskarne, piemēram, jūsu komutatora/maršrutētāja saskarne. |
| SNMP OID | Izmantojiet vienu no atbalstītajiem formātiem, lai ievadītu OID vērtību(-as): walk[OID1,OID2,...] — iegūt 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 bulk pieprasījumus (GetBulkRequest-PDUs). Šī vienuma noildzes iestatījumus var norādīt vienuma konfigurācijas formā. Apsveriet iespēju iestatīt zemu noildzes vērtību, lai izvairītos no ilgām aizturēm, ja ierīce nav sasniedzama, jo tiks veikti līdz 5 atkārtotiem mēģinājumiem, ja iepriekšējie beidzas ar noildi vai neizdodas (piemēram, 3 sekunžu noilde var radīt 15 sekunžu gaidīšanas laiku). Varat to izmantot kā galveno vienumu ar atkarīgajiem vienumiem, kas iegūst datus no galvenā vienuma, izmantojot priekšapstrādi. Vienā snmp walk ir iespējams norādīt vairākus OID, piemēram, walk[OID1,OID2,...], lai asinhroni apstrādātu pa vienam OID vienlaikus.Ja bulk pieprasījums neatgriež rezultātus, tiek mēģināts iegū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, piemēram, walk[ifDescr,ifType,ifPhysAddress], tad 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 bulk pieprasījumiem tiek konfigurēts saskarnes līmenī. Maksimālo atkārtojumu parametrs 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ārraižu skaitu. Tomēr ne visas ierīces var atbalstīt ļoti lielas vērtības, un tas 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 atklāšanā. get[OID] — asinhroni iegūt vienu vērtību. Piemēram: get[1.3.6.1.2.1.31.1.1.1.6.3]Šī vienuma noildzes iestatījumus var norādīt vienuma konfigurācijas formā. Apsveriet iespēju iestatīt zemu noildzes vērtību, lai izvairītos no ilgām aizturēm, ja ierīce nav sasniedzama, jo tiks veikti līdz 5 atkārtotiem mēģinājumiem, ja iepriekšējie beidzas ar noildi vai neizdodas (piemēram, 3 sekunžu noilde var radīt 15 sekunžu gaidīšanas laiku). OID — (mantotais variants) ievadiet vienu teksta vai skaitlisku OID, lai sinhroni iegū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 noilde būs vienāda ar vērtību, kas iestatīta servera konfigurācijas failā. Labākai veiktspējai ieteicams izmantot walk[OID] un get[OID] vienumus. Visi walk[OID] un get[OID] vienumi tiek izpildīti asinhroni — nav nepieciešams saņemt atbildi uz vienu pieprasījumu, pirms tiek sāktas citas pārbaudes. Arī DNS atrisināšana notiek asinhroni.Asinhrono pārbaužu maksimālā vienlaicība ir 1000 (noteikta ar MaxConcurrentChecksPerPoller). Asinhrono SNMP aptaujātāju skaitu nosaka parametrs StartSNMPPollers. Ņemiet vērā, ka tīkla datplūsmas statistikai, kas tiek atgriezta ar jebkuru no metodēm, cilnē Preprocessing ir jāpievieno solis Change per second; pretējā gadījumā jūs saņemsiet kumulatīvo vērtību no SNMP ierīces, 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
walk[OID1,OID2,...] vienums ļauj izmantot SNMP vietējo lielapjoma pieprasījumu funkcionalitāti (GetBulkRequest-PDUs), kas ir pieejama SNMP 2./3. versijā.
GetBulk pieprasījums SNMP vidē izpilda vairākus GetNext pieprasījumus un atgriež rezultātu vienā atbildē. To var izmantot gan parastajiem SNMP vienumiem, gan SNMP atklāšanai, lai samazinātu tīkla apmaiņas reižu skaitu.
SNMP walk[OID1,OID2,...] vienumu var izmantot kā galveno vienumu, kas vienā pieprasījumā savāc datus, kopā ar atkarīgajiem vienumiem, kuri pēc vajadzības parsē atbildi, izmantojot priekšapstrādi.
Ņemiet vērā, ka SNMP vietējo lielapjoma pieprasījumu izmantošana nav saistīta ar SNMP pieprasījumu apvienošanas opciju, kas ir Zabbix paša 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 noildze (iestatīta vienuma konfigurācijas formā) tiek noteikta visai sesijai.
Noildze tiek piemērota neatkarīgi no tā, vai dati ir iegūti pilnībā; ja dati tiek saņemti tikai daļēji (piemēram, dati tiek veiksmīgi savākti tikai vienam no vairākiem OID), tad vienums kļūst neatbalstīts ar ziņojumu "Only partial data received".
Ja tiek sasniegta noildze, notiks atkārtots mēģinājums, noildze tiks atiestatīta, 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 pienākusi pārāk vēlu.
Apsveriet iespēju iestatīt zemu noildzes 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 beigsies ar noildi vai kļūmi (piemēram, 3 sekunžu noildze 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 tipus:
- parastos SNMP vienumus
- SNMP vienumus ar dinamiskiem indeksiem
- SNMP zemā līmeņa atklāšanas noteikumus
Visi SNMP vienumi vienā saskarnē ar identiskiem parametriem tiek ieplānoti vaicāšanai vienlaikus. Pirmos divus vienumu tipus aptaujātāji apstrādā paketēs, kurās ir ne vairāk kā 128 vienumi, savukārt zemā 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 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 gadījumā tiek izmantots GetNextRequest-PDU, bet SNMPv2 un SNMPv3 gadījumā 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 vienuma tipam ir šādas:
- parastie SNMP vienumi gūst labumu no "iegūšanas" uzlabojumiem;
- SNMP vienumi ar dinamiskiem indeksiem gūst labumu gan no "iegūšanas", gan "pārlūkošanas" uzlabojumiem: "iegūšana" tiek izmantota indeksu pārbaudei, bet "pārlūkošana" — kešatmiņas veidošanai;
- SNMP zemā lī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 kļūdu "tooBig(1)", vai arī neatbild vispār, tiklīdz iespējamā atbilde pārsniedz noteiktu robežu.
Lai noteiktu optimālo vaicājamo objektu skaitu konkrētai ierīcei, Zabbix izmanto šādu stratēģiju. Tas piesardzīgi sāk ar 1 vērtības vaicāšanu vienā pieprasījumā. Ja tas izdodas, tas vaicā 2 vērtības vienā pieprasījumā. Ja arī tas izdodas, tas vaicā 3 vērtības vienā pieprasījumā un turpina līdzīgi, reizinot vaicājamo 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, 42 mainīgajiem), Zabbix veic divas darbības.
Pirmkārt, pašreizējai vienumu paketei tas uz pusi samazina objektu skaitu vienā pieprasījumā un vaicā 21 mainīgo. Ja ierīce ir pieejama, tad vaicājumam vajadzētu darboties 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ī tas neizdodas, tad ierīce noteikti neatbild un pieprasījuma izmērs nav problēma.
Otrkārt, nākamajām vienumu paketē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 neizsniegs pieprasījumu ar izmēru 33. No šī brīža Zabbix šai ierīcei vaicās ne vairāk kā 32 mainīgos.
Ja lieli vaicājumi neizdodas ar šādu mainīgo skaitu, 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, nav iespējams zināt, taču mēs cenšamies to aptuveni noteikt, izmantojot mainīgo skaitu. Tātad pirmā iespēja ir tāda, ka šis mainīgo skaits vispārīgā gadījumā ir tuvu ierīces faktiskajai atbildes izmēra robežai: dažreiz atbilde ir mazāka par robežu, dažreiz tā ir 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 vaicājumu, tas samazina maksimālo mainīgo skaitu, lai mēģinātu nonākt dziļāk ierīces drošajā diapazonā, bet ne vairāk kā divas reizes.
Iepriekš minētajā piemērā, ja vaicājums ar 32 mainīgajiem nejauši neizdodas, Zabbix samazinās skaitu līdz 31. Ja arī tas nejauši 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 izraisa UDP pakešu zudums, nevis ierīces ierobežojums.
Ja tomēr ierīce citu iemeslu dēļ nespēj korekti 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 atspējot kombinētos pieprasījumus.
Ja kombinētie pieprasījumi izraisa daļējas vai kļūdainas atbildes, kuru rezultātā rodas nepareizi aprēķini sekundē (delta) (piemēram, šķietami lēcieni saskarnes skaitītājos), atspējojiet Use combined requests ietekmētajai saskarnei, lai piespiestu atsevišķus katra vienuma vaicājumus; tas bieži novērš nepatiesus lēcienus.
Alternatīvi apsveriet asinhronu get[] vai walk[] vienumu izmantošanu, kas tiek izpildīti asinhroni un uz kuriem neattiecas katras saskarnes Use combined requests paketēšana — 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 ir līdzīgi Pārskata sadaļā parādītajam, lai palīdzētu noteikt ietekmētās ierīces.
Papildus tam, ja saskarne bieži kļūst nepieejama, var būt nepieciešams palielināt UnavailableDelay parametru Zabbix serveris vai Zabbix starpniekserveris 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.