Documentation
Table of Contents
2 SNMP agent
Overzicht
U wilt mogelijk SNMP-bewaking gebruiken op apparaten zoals printers, netwerkswitches, routers of UPS'en die meestal SNMP-ingeschakeld zijn en waarop het praktisch onmogelijk zou zijn om complete besturingssystemen en Zabbix-agenten in te stellen.
Om gegevens te kunnen ophalen die door SNMP-agenten op deze apparaten worden verstrekt, moet de Zabbix-server initieel geconfigureerd worden met SNMP-ondersteuning door de --with-net-snmp vlag op te geven.
SNMP-controles worden alleen uitgevoerd via het UDP-protocol.
Zabbix-server- en proxy-daemons loggen regels vergelijkbaar met de volgende als ze een onjuist SNMP-antwoord ontvangen:
Hoewel ze niet alle problematische gevallen dekken, zijn ze nuttig voor het identificeren van individuele SNMP-apparaten waarvoor gecombineerde verzoeken moeten worden uitgeschakeld.
Zabbix-server/proxy zal altijd minstens één keer opnieuw proberen na een onsuccesvolle querypoging: ofwel via het retry-mechanisme van de SNMP-bibliotheek of via het interne gecombineerde verwerkingsmechanisme.
Bij het bewaken van SNMPv3-apparaten moet u ervoor zorgen dat msgAuthoritativeEngineID (ook bekend als snmpEngineID of "Engine ID") nooit wordt gedeeld door twee apparaten. Volgens RFC 2571 (sectie 3.1.1.1) moet het uniek zijn voor elk apparaat.
RFC3414 vereist dat de SNMPv3-apparaten hun engineBoots persistent maken. Sommige apparaten doen dat niet, waardoor hun SNMP-berichten als verouderd worden verworpen na opnieuw opstarten. In een dergelijke situatie moet de SNMP-cache op de server/proxy handmatig worden gewist (met behulp van -R snmp_cache_reload) of de server/proxy moet worden herstart.
SNMP-bewaking configureren
Om een apparaat via SNMP te gaan bewaken, moeten de volgende stappen worden uitgevoerd:
Stap 1
Ontdek de SNMP-string (of OID) van het item dat u wilt bewaken.
Om een lijst met SNMP-strings te krijgen, gebruikt u het snmpwalk-commando (een onderdeel van de net-snmp software die u geïnstalleerd zou moeten hebben als onderdeel van de Zabbix-installatie) of een equivalente tool:
Hier staat '2c' voor SNMP-versie, u kunt het ook vervangen door '1', om SNMP Versie 1 op het apparaat aan te geven.
Dit zou u een lijst met SNMP-strings en hun laatste waarde moeten geven. Als dat niet het geval is, kan het zijn dat de SNMP 'community' verschilt van de standaard 'public', in welk geval u moet uitzoeken wat het is.
U kunt dan door de lijst gaan tot u de string vindt die u wilt bewaken, bijvoorbeeld als u de bytes die binnenkomen op uw switch op poort 3 wilt bewaken, zou u de IF-MIB::ifHCInOctets.3 string gebruiken van deze regel:
U kunt nu het snmpget-commando gebruiken om de numerieke OID te vinden voor 'IF-MIB::ifHCInOctets.3':
Let op dat het laatste nummer in de string het poortnummer is dat u wilt bewaken. Zie ook: Dynamische indexen.
Dit zou u iets als het volgende moeten opleveren:
Opnieuw is het laatste nummer in de OID het poortnummer.
Sommige van de meest gebruikte SNMP-OIDs worden automatisch vertaald naar een numerieke weergave door Zabbix.
In het laatste hierboven gegeven voorbeeld is het waardetype "Counter64", wat intern overeenkomt met het ASN_COUNTER64-type. De volledige lijst van ondersteunde typen is 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 en ASN_OBJECT_ID. Deze typen komen grofweg overeen met "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" in de uitvoer van snmpget, maar kunnen ook worden weergegeven als "STRING", "Hex-STRING", "OID" en andere, afhankelijk van de aanwezigheid van een display hint.
Stap 2
Maak een host aan die overeenkomt met een apparaat.
Voeg een SNMP-interface toe aan de host:
- Voer het IP-adres/DNS-naam en poortnummer in
- Selecteer de SNMP-versie uit de vervolgkeuzelijst
- Voeg interfacegegevens toe afhankelijk van de geselecteerde SNMP-versie:
- SNMPv1, v2 vereisen alleen de community (meestal 'public')
- SNMPv3 vereist meer specifieke opties (zie hieronder)
- Specificeer de maximale herhalingwaarde (standaard: 10) voor native SNMP bulkverzoeken (GetBulkRequest-PDUs); alleen voor
discovery[]enwalk[]items in SNMPv2 en v3. Let op dat het instellen van deze waarde te hoog een time-out voor de controle van de SNMP-agent kan veroorzaken. - Markeer het selectievakje Use combined requests om gecombineerde verwerking van SNMP-verzoeken toe te staan (niet gerelateerd aan native SNMP bulkverzoeken)
| SNMPv3 parameter | Omschrijving |
|---|---|
| Contextnaam | Voer een contextnaam in om het item te identificeren op het SNMP-subnet. Contextnaam wordt ondersteund voor SNMPv3-items sinds Zabbix 2.2. Gebruikermacro's worden opgelost in dit veld. |
| Beveiligingsnaam | Voer de beveiligingsnaam in. Gebruikermacro's worden opgelost in dit veld. |
| Beveiligingsniveau | Selecteer het beveiligingsniveau: noAuthNoPriv - er worden geen authenticatie- of privacyprotocollen gebruikt AuthNoPriv - authenticatieprotocol wordt gebruikt, privacyprotocol niet AuthPriv - zowel authenticatie- als privacyprotocollen worden gebruikt |
| Authenticatieprotocol | Selecteer authenticatieprotocol - MD5, SHA1, SHA224, SHA256, SHA384 of SHA512. |
| Authenticatie-wachtwoord | Voer het authenticatiewachtwoord in. Gebruikermacro's worden opgelost in dit veld. |
| Privacyprotocol | Selecteer privacyprotocol - DES, AES128, AES192, AES256, AES192C (Cisco) of AES256C (Cisco). Let op dat: - op sommige oudere systemen net-snmp mogelijk AES256 niet ondersteunt; - op sommige nieuwere systemen (bijvoorbeeld RHEL9) kan de ondersteuning van DES worden verwijderd voor het net-snmp-pakket. |
| Privacy-wachtwoord | Voer het privacy-wachtwoord in. Gebruikermacro's worden opgelost in dit veld. |
In geval van onjuiste SNMPv3 referenties (beveiligingsnaam, authenticatieprotocol/wachtwoord, privacyprotocol):
- Zabbix ontvangt een FOUT van net-snmp, behalve bij een onjuist Privacy-wachtwoord, in welk geval Zabbix een TIME-OUT fout ontvangt van net-snmp;
- de beschikbaarheid van de SNMP-interface schakelt over naar rood (niet beschikbaar).
Wijzigingen in Authenticatieprotocol, Authenticatie-wachtwoord, Privacyprotocol of Privacy-wachtwoord die worden aangebracht zonder de Beveiligingsnaam te wijzigen, treden pas in werking nadat de cache op een server/proxy handmatig is gewist (door middel van -R snmp_cache_reload) of de server/proxy is herstart. In gevallen waarin Beveiligingsnaam ook wordt gewijzigd, worden alle parameters onmiddellijk bijgewerkt.
U kunt een van de meegeleverde SNMP-templates gebruiken die automatisch een set items toevoegen. Controleer voordat u een template gebruikt of deze compatibel is met de host.
Klik op Toevoegen om de host op te slaan.
Stap 3
Maak een item aan voor monitoring.
Ga nu terug naar Zabbix en klik op Items voor de SNMP-host die u eerder hebt aangemaakt. Afhankelijk van of u een sjabloon hebt gebruikt bij het aanmaken van uw host, hebt u ofwel een lijst met SNMP-items die zijn gekoppeld aan uw host, ofwel een lege lijst. We gaan ervan uit dat u het item zelf gaat aanmaken met behulp van de informatie die u zojuist hebt verzameld met snmpwalk en snmpget, dus klik op Item aanmaken.
Vul de vereiste parameters in op het nieuwe formulier voor het item:
| Parameter | Omschrijving |
|---|---|
| Naam | Voer de naam van het item in. |
| Type | Selecteer hier SNMP-agent. |
| Sleutel | Voer een betekenisvolle sleutel in. |
| Hostinterface | Zorg ervoor dat u de SNMP-interface selecteert, bijvoorbeeld van uw switch/router. |
| SNMP OID | Dit veld ondersteunt twee opties: 1) Voer een enkele tekstuele of numerieke OID in, bijvoorbeeld: 1.3.6.1.2.1.31.1.1.1.6.3 (in dit geval moet u een Verandering per seconde stap toevoegen in het tabblad Voorbewerking; anders krijgt u cumulatieve waarden van het SNMP-apparaat in plaats van de laatste wijziging). 2) Gebruik het walk[OID1,OID2,...] item, dat gebruik maakt van native SNMP bulkverzoeken (GetBulkRequest-PDUs). U kunt dit als het hoofditem gebruiken, met afhankelijke items die gegevens uit het hoofditem halen met behulp van voorbewerking. Bijvoorbeeld, walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].Dit item retourneert de output van het hulpprogramma snmpwalk met de parameters -Oe -Ot -On. MIB-namen worden ondersteund als parameters; dus walk[1.3.6.1.2.1.2.2.1.2] en walk[ifDescr] zullen dezelfde output retourneren.Als meerdere OIDs/MIBs worden gespecificeerd, bijvoorbeeld walk[ifDescr,ifType,ifPhysAddress], dan is de output een samengevoegde lijst.Dit item gebruikt GetBulk-verzoeken met SNMPv2- en v3-interfaces en GetNext voor SNMPv1-interfaces; het maximum aantal herhalingen voor bulkverzoeken is geconfigureerd op het interface-niveau. U kunt dit item als hoofditem gebruiken in SNMP-ontdekking. |
Alle verplichte invoervelden zijn gemarkeerd met een rode asterisk.
Sla het item nu op en ga naar Bewaking → Laatste gegevens voor uw SNMP-gegevens.
Voorbeeld 1
Algemeen voorbeeld:
| Parameter | Omschrijving |
|---|---|
| OID | 1.2.3.45.6.7.8.0 (of .1.2.3.45.6.7.8.0) |
| Sleutel | <Unieke tekenreeks om te worden gebruikt als referentie voor triggers> Bijvoorbeeld, "mijn_parameter". |
Let op dat OID in zowel numerieke als tekstuele vorm kan worden opgegeven. In sommige gevallen moet een tekstuele OID echter worden omgezet naar numerieke representatie. Het hulpprogramma snmpget kan hiervoor worden gebruikt:
Voorbeeld 2
Monitoring van uptime:
| Parameter | Omschrijving |
|---|---|
| OID | MIB::sysUpTime.0 |
| Sleutel | router.uptime |
| Type waarde | Float |
| Eenheden | uptime |
| Voorverwerkingsstap: Aangepaste vermenigvuldiger | 0,01 |
Native SNMP-bulkverzoeken
Het item walk[OID1,OID2,...] maakt gebruik van de native SNMP-functionaliteit voor bulkverzoeken (GetBulkRequest-PDUs), die beschikbaar is in SNMP-versies 2/3.
Een GetBulk-verzoek in SNMP voert meerdere GetNext-verzoeken uit en retourneert het resultaat in een enkele respons. Dit kan worden gebruikt voor reguliere SNMP-items en voor SNMP-ontdekking om het aantal netwerkverzoeken te minimaliseren.
Het SNMP-item walk[OID1,OID2,...] kan worden gebruikt als het master-item dat gegevens verzamelt in één verzoek, met afhankelijke items die de respons indien nodig analyseren met behulp van voorverwerking.
Merk op dat het gebruik van native SNMP-bulkverzoeken geen verband houdt met de optie om SNMP-verzoeken te combineren, wat de eigen manier van Zabbix is om meerdere SNMP-verzoeken te combineren (zie volgende sectie).
Interne werking van gecombineerde verwerking
Zabbix-server en -proxy kunnen SNMP-apparaten bevragen voor meerdere waarden in één enkel verzoek. Dit heeft invloed op verschillende soorten SNMP-items:
- reguliere SNMP-items
- SNMP-items met dynamische indexen
- SNMP-ontdekkingsregels op laag niveau
Alle SNMP-items op een enkele interface met identieke parameters worden gepland om tegelijkertijd te worden bevraagd. De eerste twee soorten items worden door pollers in batches van maximaal 128 items genomen, terwijl ontdekkingsregels op laag niveau individueel worden verwerkt, zoals voorheen.
Op lager niveau zijn er twee soorten bewerkingen voor het opvragen van waarden: het ophalen van meerdere gespecificeerde objecten en het doorlopen van een OID-boom.
Voor het "ophalen" wordt een GetRequest-PDU gebruikt met maximaal 128 variabele bindings. Voor het "doorlopen" wordt een GetNextRequest-PDU gebruikt voor SNMPv1 en wordt GetBulkRequest gebruikt met een "max-repetitions" veld van maximaal 128 voor SNMPv2 en SNMPv3.
Dus, de voordelen van gecombineerde verwerking voor elk type SNMP-item worden hieronder geschetst:
- reguliere SNMP-items profiteren van verbeteringen bij het "ophalen";
- SNMP-items met dynamische indexen profiteren van zowel verbeteringen bij het "ophalen" als het "doorlopen": "ophalen" wordt gebruikt voor indexverificatie en "doorlopen" voor het opbouwen van de cache;
- SNMP-ontdekkingsregels op laag niveau profiteren van verbeteringen bij het "doorlopen".
Er is echter een technisch probleem dat niet alle apparaten in staat zijn om 128 waarden per verzoek terug te geven. Sommige geven altijd een juiste respons, maar andere reageren met een "tooBig(1)" foutmelding of reageren helemaal niet zodra de potentiële respons over een bepaalde limiet gaat.
Om een optimaal aantal objecten te vinden om te bevragen voor een gegeven apparaat, gebruikt Zabbix de volgende strategie. Het begint voorzichtig met het bevragen van 1 waarde in een verzoek. Als dat succesvol is, bevraagt het 2 waarden in een verzoek. Als dat opnieuw succesvol is, bevraagt het 3 waarden in een verzoek en gaat het op dezelfde manier verder door het aantal bevraagde objecten met 1,5 te vermenigvuldigen, resulterend in de volgende reeks verzoekgroottes: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
Echter, zodra een apparaat weigert om een juiste respons te geven (bijvoorbeeld voor 42 variabelen), doet Zabbix twee dingen.
Ten eerste, voor de huidige batch items wordt het aantal objecten in een enkel verzoek gehalveerd en worden 21 variabelen bevraagd. Als het apparaat actief is, zou het verzoek in het overgrote deel van de gevallen moeten werken, omdat 28 variabelen bekend waren om te werken en 21 aanzienlijk minder is dan dat. Als dat nog steeds mislukt, valt Zabbix terug op het bevragen van waarden één voor één. Als dat op dit punt nog steeds mislukt, reageert het apparaat zeker niet en is de grootte van het verzoek geen probleem.
Het tweede wat Zabbix doet voor daaropvolgende item-batches is dat het begint met het laatst succesvolle aantal variabelen (28 in ons voorbeeld) en doorgaat met het verhogen van de verzoekgroottes met 1 totdat de limiet is bereikt. Bijvoorbeeld, als de grootste responsgrootte 32 variabelen is, zullen de daaropvolgende verzoeken groottes zijn van 29, 30, 31, 32 en 33. Het laatste verzoek zal mislukken en Zabbix zal nooit meer een verzoek van grootte 33 uitgeven. Vanaf dat moment zal Zabbix hoogstens 32 variabelen bevragen voor dit apparaat.
Als grote verzoeken mislukken met dit aantal variabelen, kan dit twee dingen betekenen. De exacte criteria die een apparaat gebruikt voor het beperken van de responsgrootte kunnen niet worden vastgesteld, maar we proberen dat te benaderen aan de hand van het aantal variabelen. Dus de eerste mogelijkheid is dat dit aantal variabelen in de buurt komt van de daadwerkelijke responsgroottegrens van het apparaat in het algemeen: soms is de respons kleiner dan de limiet, soms is deze groter dan dat. De tweede mogelijkheid is dat een UDP-pakket in beide richtingen eenvoudigweg verloren is gegaan. Om deze redenen, als Zabbix een mislukt verzoek krijgt, verlaagt het het maximale aantal variabelen om dieper in het comfortabele bereik van het apparaat te komen, maar (vanaf 2.2.8) slechts tot twee keer toe.
In het bovenstaande voorbeeld, als een verzoek met 32 variabelen toevallig mislukt, zal Zabbix het aantal verlagen naar 31. Als dat ook mislukt, zal Zabbix het aantal verlagen naar 30. Echter, Zabbix zal het aantal niet verlagen onder de 30, omdat het zal aannemen dat verdere mislukkingen te wijten zijn aan UDP-pakketten die verloren zijn gegaan, eerder dan aan de limiet van het apparaat.
Als een apparaat echter om andere redenen geen gecombineerde verzoeken goed kan verwerken en de hierboven beschreven heuristiek niet werkt, dan is er vanaf Zabbix 2.4 een "Gebruik gecombineerde verzoeken" instelling voor elke interface die het mogelijk maakt om gecombineerde verzoeken voor dat apparaat uit te schakelen.