Documentation
Table of Contents
2 SNMP агент
Преглед
Можда ћете желети да користите SNMP праћење на уређајима као што су штампачи, мрежни прекидачи, рутери или UPS уређаји који обично подржавају SNMP и на којима би било непрактично покушати подесити комплетне оперативне системе и Zabbix агенте.
Да бисте могли да преузмете податке које пружају SNMP агенти на овим уређајима, Zabbix сервер мора бити првобитно конфигурисан са SNMP подршком навођењем заставице --with-net-snmp. Препоручује се и инсталирање MIB датотека како би се осигурало да се вредности ставки приказују у исправном формату. Без MIB датотека, могу се јавити проблеми са форматирањем, као што је приказивање вредности у HEX уместо UTF-8 или обрнуто.
SNMP провере се врше само преко UDP протокола.
Zabbix сервер и прокси демони евидентирају линије сличне следећим ако добију нетачан SNMP одговор:
SNMP одговор од домаћина "gateway" не садржи сва тражена повезивања променљивих
Иако не покривају све проблематичне случајеве, корисни су за идентификацију појединачних SNMP уређаја за које комбиновани захтеви треба да буду онемогућени.
Zabbix сервер/прокси ће увек поново покушати барем једном након неуспешног покушаја упита: или путем механизма за поновни покушај SNMP библиотеке, или путем интерног механизма комбиноване обраде.
Ако пратите SNMPv3 уређаје, уверите се да msgAuthoritativeEngineID (такође познат као snmpEngineID или "Engine ID") никада није дељен између два уређаја. Према RFC 2571 (одељак 3.1.1.1) мора бити јединствен за сваки уређај.
RFC3414 захтева да SNMPv3 уређаји сачувају своје engineBoots. Неки уређаји то не раде, што доводи до тога да се њихове SNMP поруке одбацују као застареле након поновног покретања. У таквој ситуацији, SNMP кеш меморију је потребно ручно обрисати на серверу/проксију (коришћењем -R snmp_cache_reload) или сервер/прокси је потребно поново покренути.
Конфигурисање SNMP праћења
Да бисте започели праћење уређаја путем SNMP-а, потребно је извршити следеће кораке:
Корак 1
Пронађите SNMP стринг (или OID) ставке коју желите да пратите.
Да бисте добили листу SNMP стрингова, користите команду snmpwalk (део софтвера net-snmp који би требало да имате инсталиран као део Zabbix инсталације) или еквивалентан алат:
snmpwalk -v 2c -c public <host IP> .
Пошто '2c' овде означава SNMP верзију, можете је заменити и са '1', да бисте назначили SNMP верзију 1 на уређају.
Ово би требало да вам да листу SNMP стрингова и њихову последњу вредност. Ако се не разликује, онда је могуће да се SNMP 'заједница' разликује од стандардног 'јавног' у ком случају ћете морати да сазнате шта је то.
Затим можете прегледати листу док не пронађете стринг који желите да пратите, нпр. Ако желите да пратите бајтове који долазе на ваш прекидач на порту 3, користили бисте стринг IF-MIB::ifHCInOctets.3 из ове линије:
IF-MIB::ifHCInOctets.3 = Counter64: 3409739121
Сада можете користити команду snmpget да бисте сазнали нумерички OID за 'IF-MIB::ifHCInOctets.3':
snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3
Имајте на уму да је последњи број у стрингу број порта који тражите да пратите. Погледајте такође: Динамички индекси.
Ово би требало да вам да нешто попут следећег:
.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941
Поново, последњи број у OID-у је број порта.
Неки од најчешће коришћених SNMP OIDs се аутоматски преводе у нумеричку репрезентацију од стране Zabbix-а.
У последњем примеру изнад, тип вредности је "Counter64", што интерно одговара типу ASN_COUNTER64. Комплетна листа подржаних типова је 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 и ASN_OBJECT_ID. Ови типови отприлике одговарају типовима "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" у snmpget излазу, али могу бити приказани и као "STRING", "Hex-STRING", "OID" и други, у зависности од присуства назнаке за приказ.
Корак 2
Креирајте домаћина који одговара уређају.
Додајте SNMP интерфејс за домаћина:
- Унесите IP адресу/DNS име и број порта
- Изаберите SNMP верзију из падајућег менија
- Додајте акредитиве интерфејса у зависности од изабране SNMP верзије:
- SNMPv1, v2 захтевају само заједницу (обично "јавну")
- SNMPv3 захтева специфичније опције (видети доле)
- Наведите максималну вредност понављања (подразумевано: 10) за нативне SNMP групне захтеве (GetBulkRequest-PDUs); само за ставке
discovery[]иwalk[]у SNMPv2 и v3. Имајте на уму да подешавање ове вредности превисоко може проузроковати истека времена провере SNMP агента. - Означите поље за потврду Користи комбиноване захтеве да бисте омогућили комбиновану обраду SNMP захтева (нису повезани са изворним SNMP групним захтевима "walk" и "get")
| SNMPv3 parameter | Description |
|---|---|
| Назив контекста | Унесите назив контекста за идентификацију ставке на SNMP подмрежи. Кориснички макрои се решавају у овом пољу. |
| Назив безбедности | Унесите назив безбедности. Кориснички макрои се решавају у овом пољу. |
| Ниво безбедности | Изаберите ниво безбедности: noAuthNoPriv - не користе се протоколи за аутентификацију нити протоколи за приватност AuthNoPriv - користи се протокол за аутентификацију, протокол за приватност се не користи AuthPriv - користе се и протоколи за аутентификацију и протоколи за приватност |
| Протокол за аутентификацију | Изаберите протокол за аутентификацију - MD5, SHA1; са net-snmp 5.8 и новијим SHA224, SHA256, SHA384 или SHA512. |
| Шифраза за аутентификацију | Унесите лозинку за аутентификацију. Кориснички макрои се решавају у овом пољу. |
| Протокол за приватност | Изаберите протокол за приватност - DES, AES128, AES192, AES256, AES192C (Cisco) или AES256C (Cisco). Погледајте напомене о подршци за протокол приватности |
| Шифраза за приватност | Унесите лозинку за приватност. Кориснички макрои се решавају у овом пољу. |
У случају погрешних SNMPv3 акредитива (безбедносно име, протокол/лозинка за аутентификацију, протокол приватности):
- Zabbix добија грешку ГРЕШКА од net-snmp, осим у случају погрешне Лозинка за приватност у ком случају Zabbix добија грешку TIMEOUT од net-snmp;
- Доступност SNMP интерфејса ће се пребацити на црвено (недоступно).
Промене у Протоколу за аутентификацију, Лозинка за аутентификацију, Протоколу за приватност или Лозинка за приватност, направљене без промене Безбедносног имена, ступиће на снагу тек након што се кеш на серверу/проксију ручно обрише (коришћењем -R snmp_cache_reload) или се сервер/прокси поново покрене. У случајевима када се Безбедносно име такође промени, сви параметри ће бити одмах ажурирани.
Можете користити један од обезбеђених SNMP шаблона који ће аутоматски додати скуп ставки. Пре коришћења шаблона, проверите да ли је компатибилан са домаћином.
Кликните на Додај да бисте сачували домаћина.
Подршка за протокол приватности
У зависности од вашег оперативног система и конфигурације net-snmp, неки протоколи приватности можда неће бити доступни:
На неким новијим оперативним системима (на пример, RHEL9) подршка за DES је укинута за пакет net-snmp.
Протоколи за шифровање AES192 и јачи нису подржани одмах на оперативним системима старијим од RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.
Да бисте проверили да ли библиотека net-snmp подржава AES192+, користите једну од следећих опција:
net-snmp-config:
net-snmp-config --configure-options
Ако излаз садржи --enable-blumenthal-aes, AES192+ је подржан.
Имајте на уму да је net-snmp-config део развојног пакета за SNMP (libsnmp-dev за Debian/Ubuntu, net-snmp-devel за CentOS/RHEL/OL/SUSE) и можда неће бити инсталиран подразумевано.
snmpget:
snmpget -v 3 -x AES-256
Ако излаз садржи Invalid privacy protocol specified after -3x flag: AES-256, AES192+ није подржан. Ако излаз садржи No hostname specified., AES192+ није подржан.
Ако ваша net-snmp библиотека не подржава AES192 и новије протоколе, поново компајлирајте net-snmp са опцијом --enable-blumenthal-aes, а затим поново компајлирајте Zabbix сервер наводећи опцију --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.
Step 3
Create an item for monitoring.
So, now go back to Zabbix and click on Items for the SNMP host you created earlier. Depending on whether you used a template or not when creating your host, you will have either a list of SNMP items associated with your host or just an empty list. We will work on the assumption that you are going to create the item yourself using the information you have just gathered using snmpwalk and snmpget, so click on Create item.
Fill in the required parameters in the new item form:
| Parameter | Description |
|---|---|
| Name | Enter the item name. |
| Type | Select SNMP agent here. |
| Key | Enter the key as something meaningful. |
| Host interface | Make sure to select the SNMP interface, e.g. of your switch/router. |
| SNMP OID | Use one of the supported formats to enter OID value(s): walk[OID1,OID2,...] - retrieve a subtree of values. For example: walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].This option makes use of native SNMP bulk requests (GetBulkRequest-PDUs) asynchronously. The timeout settings for this item can be set in the item configuration form. You may use this as the master item, with dependent items that extract data from the master using preprocessing. It is possible to specify multiple OIDs in a single snmp walk, such as walk[OID1,OID2,...] to asynchronously process one OID at a time.If the bulk request returns no results then it is attempted to retrieve a single record without bulk request. MIB names are supported as parameters; thus walk[1.3.6.1.2.1.2.2.1.2] and walk[ifDescr] will return the same output.If several OIDs/MIBs are specified, i.e. walk[ifDescr,ifType,ifPhysAddress], then the output is a concatenated list.GetBulk requests are used with SNMPv2 and v3 interfaces and GetNext for SNMPv1 interfaces; max repetitions for bulk requests are configured on the interface level. This item returns the output of the snmpwalk utility with -Oe -Ot -On parameters. You may use this item as a master item in SNMP discovery. get[OID] - retrieve a single value asynchronously. For example: get[1.3.6.1.2.1.31.1.1.1.6.3]The timeout settings for this item can be set in the item configuration form. OID - (legacy) enter a single textual or numeric OID to retrieve a single value synchronously, optionally combined with other values. For example: 1.3.6.1.2.1.31.1.1.1.6.3.For this option, the item check timeout will be equal to the value set in the server configuration file. It is recommended to use walk[OID] and get[OID] items for better performance. All walk[OID] and get[OID] items are executed asynchronously - it is not required to receive the response to one request before other checks are started. DNS resolving is asynchronous as well.The maximum concurrency of asynchronous checks is 1000 (defined by MaxConcurrentChecksPerPoller). The number of asynchronous SNMP pollers is defined by the StartSNMPPollers parameter. Note that for network traffic statistics, returned by any of the methods, a Change per second step must be added in the Preprocessing tab; otherwise you will get the cumulative value from the SNMP device instead of the latest change. |
All mandatory input fields are marked with a red asterisk.
Now save the item and go to Monitoring → Latest data for your SNMP data.
Пример 1
Општи пример:
| Parameter | Description |
|---|---|
| OID | 1.2.3.45.6.7.8.0 (или .1.2.3.45.6.7.8.0) |
| Key | <Unique string to be used as reference to triggers> На пример, "my_param". |
Имајте на уму да OID може бити дат у нумеричком или стринг облику. Међутим, у неким случајевима, стринг OID мора бити конвертован у нумеричку репрезентацију. Услужни програм snmpget може се користити за ову сврху:
snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0
Пример 2
Праћење времена непрекидног рада:
| Parameter | Description |
|---|---|
| OID | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | Float |
| Units | uptime |
| Preprocessing step: Custom multiplier | 0.01 |
Изворни SNMP групни захтеви
Ставка walk[OID1,OID2,...] омогућава коришћење изворне SNMP функционалности за групне захтеве (GetBulkRequest-PDU), доступне у SNMP верзијама 2/3.
GetBulk захтев у SNMP-у извршава више GetNext захтева и враћа резултат у једном одговору. Ово се може користити за редовне SNMP ставке, као и за SNMP откривање ради минимизирања мрежних обртаја.
SNMP ставка walk[OID1,OID2,...] може се користити као главна ставка која прикупља податке у једном захтеву са зависним ставкама које анализирају одговор по потреби користећи претходну обраду.
Имајте на уму да коришћење изворних SNMP групних захтева није повезано са опцијом комбиновања SNMP захтева, што је Zabbix-ов сопствени начин комбиновања више SNMP захтева (погледајте следећи одељак).
Поновни покушај ће се десити за SNMP групне ставке како би се избегао неуспех ако се један од пакета изгуби. Временско ограничење за SNMP ставке са get и walk (подешено у форми item configuration) је подешено за целу сесију. Ако се временско ограничење достигне, доћи ће до поновног покушаја, временско ограничење ће бити ресетовано, а последњи захтев ће бити поново послат, што омогућава наставак сесије од последњег захтева ако је један пакет изгубљен или је стигао прекасно. Размислите о подешавању ниске вредности временског ограничења како бисте избегли дуга кашњења ако је уређај недоступан, јер ће се извршити до 5 поновних покушаја (од Zabbix-а 7.2.8) ако претходни покушаји истекну или не успеју (нпр. временско ограничење од 3 секунде може резултирати временом чекања од 15 секунди).
Унутрашње функционисање комбиноване обраде
Zabbix сервер и прокси могу да упитују SNMP уређаје за више вредности у једном захтеву. Ово утиче на неколико врста SNMP ставки:
- редовне SNMP ставке
- SNMP ставке са динамичким индексима
- SNMP правила за откривање ниског нивоа
Све SNMP ставке на једном интерфејсу са идентичним параметрима су заказане да буду упитане у исто време. Прве две врсте ставки се узимају од стране анкетара у групама од највише 128 ставки, док се правила за откривање ниског нивоа обрађују појединачно, као и раније.
На нижем нивоу, постоје две врсте операција које се изводе за упит вредности: добијање више одређених објеката и обилазак OID стабла.
За "getting", користи се GetRequest-PDU са највише 128 променљивих везивања. За "walking", користи се GetNextRequest-PDU за SNMPv1 и GetBulkRequest са пољем "max-repetitions" од највише 128 се користи за SNMPv2 и SNMPv3.
Стога, предности комбиноване обраде за сваки тип SNMP ставке су наведене у наставку:
- редовне SNMP ставке имају користи од побољшања "getting";
- SNMP ставке са динамичким индексима имају користи и од "getting" и од побољшања "walking": "getting" се користи за верификацију индекса, а "walking" за изградњу кеша;
- SNMP правила откривања ниског нивоа имају користи од побољшања "walking".
Међутим, постоји технички проблем да нису сви уређаји способни да врате 128 вредности по захтеву. Неки увек враћају исправан одговор, али други или одговарају грешком "tooBig(1)" или уопште не одговарају када потенцијални одговор пређе одређену границу.
Да би пронашао оптималан број објеката за упит за дати уређај, Zabbix користи следећу стратегију. Почиње опрезно са упитом 1 вредности у захтеву. Ако је то успешно, упитује 2 вредности у захтеву. Ако је и то успешно, упитује 3 вредности у захтеву и наставља слично множењем броја упитаних објеката са 1,5, што резултира следећим низом величина захтева: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
Међутим, када уређај одбије да да исправан одговор (на пример, за 42 променљиве), Zabbix ради две ствари.
Прво, за тренутну серију елемената преполовљује број објеката у једном захтеву и испитује 21 променљиву. Ако је уређај активан, онда би упит требало да ради у великој већини случајева, јер је познато да 28 променљивих ради, а 21 је знатно мање од тога. Међутим, ако то и даље не успе, Zabbix се враћа на испитивање вредности једну по једну. Ако и даље не успе у овом тренутку, онда уређај дефинитивно не реагује и величина захтева није проблем.
Друга ствар коју Zabbix ради за наредне серије елемената је да почиње са последњим успешним бројем променљивих (28 у нашем примеру) и наставља да повећава величине захтева за 1 док се не достигне ограничење. На пример, под претпоставком да је највећа величина одговора 32 променљиве, накнадни захтеви ће бити величина 29, 30, 31, 32 и 33. Последњи захтев ће бити неуспешан и Zabbix никада више неће издати захтев величине 33. Од тог тренутка, Zabbix ће упитивати највише 32 променљиве за овај уређај.
Ако велики упити не успеју са овим бројем променљивих, то може значити једну од две ствари. Тачни критеријуми које уређај користи за ограничавање величине одговора не могу се знати, али покушавамо да то приближно утврдимо користећи број променљивих. Дакле, прва могућност је да је овај број променљивих око стварног ограничења величине одговора уређаја у општем случају: понекад је одговор мањи од ограничења, понекад је већи од тога. Друга могућност је да се UDP пакет у било ком смеру једноставно изгубио. Из ових разлога, ако Zabbix добије неуспешан упит, смањује максималан број променљивих како би покушао да се дубље уклопи у удобан опсег уређаја, али само до два пута.
У горњем примеру, ако упит са 32 променљиве не успе, Zabbix ће смањити број на 31. Ако и то не успе, Zabbix ће смањити број на 30. Међутим, Zabbix неће смањити број испод 30, јер ће претпоставити да су даљи неуспеси последица губитка UDP пакета, а не ограничења уређаја.
Међутим, ако уређај не може правилно да обрађује комбиноване захтеве из других разлога и хеуристика описана горе не функционише, постоји подешавање "Користи комбиноване захтеве" за сваки интерфејс које омогућава онемогућавање комбинованих захтева за тај уређај.
Поред тога, ако интерфејс често постаје недоступан, може бити потребно повећати параметар UnavailableDelay у конфигурационим датотекама Zabbix сервер или Zabbix прокси како би се смањила учесталост захтева. Ставке могу постати неподржане ако се делимични подаци приме током откривања или OID прегледа.