Zabbix Documentation 4.0

3.04.04.45.0 (current)| In development:5.2 (devel)| Unsupported:1.82.02.22.43.23.44.2Guidelines

User Tools

Site Tools

This translation is older than the original page and might be outdated. See what has changed.

Sidebar

pt:manual:config:items:itemtypes:snmp

This is an old revision of the document!


2 Agente SNMP

Visão geral

Você poderá precisar utilizar o protocolo SNMP para monitorar dispositivos como impressoras, switches, roteadores ou nobreaks que, normalmente, possuem interfaces SNMP habilitadas e onde é impraticável manter um Zabbix Agent funcionando.

Para que o Zabbix Server esteja apto a receber dados coletados por um agente SNMP, ele deverá ser configurado com o suporte SNMP.

As coletas SNMP são feitas somente através do protocolo UDP.

Desde o Zabbix 2.2.3 o Zabbix Server e o Zabbix Proxy tem a capacidade de coletar múltiplos dados de um dispositivo a partir de uma única requisição. Isso afeta todos os tipos de itens SNMP (itens normais SNMP, itens SNMP com índice dinâmico, e o processo de autobusca SNMP) os tornando mais eficientes. Mais detalhes sobre coletas múltiplas podem ser obtidos. Desde o Zabbix 2.4 existe uma opção chamada “Usar requisições em lote” em cada interfce SNMP que permite habilitar ou desabilitar requisições em lote naquela interface.

Desde o Zabbix 2.2.7 e o Zabbix 2.4.2 os processos do Zabbix Server e do Zabbix Proxy registram de forma similar respostas incorretas do SNMP:

SNMP response from host "gateway" does not contain all of the requested variable bindings
Enquanto não forem mapeadas todas as situações problemáticas, elas são úteis para identificar dispositivos cuja coleta em lote (bulk) pode ser desabilitada.

Desde o Zabbix 2.2 os processos do Zabbix Server e do Zabbix Proxy utilizam o parâmetro de 'Timeout' nas requisições SNMP. Adicionalmente eles não realizam o reteste após uma requisição que falhar (por 'timeout' ou credenciais erradas). Anteriormente era padrão que a bibilioteca SNMP tivesse o 'timeout' de 1 segundo e 5 tentativas.

Desde o Zabbix 2.2.8 e o Zabbix 2.4.2 os processos do Zabbix Server e do Zabbix Proxy semre irão repetir pelo menos uma vez, seja através do mecanismo interno da biblioteca SNMP ou através do mecanismo interno de processamento em lote.

Se estiver monitorando dispositivos SNMPv3, certifique-se que o 'msgAuthoritativeEngineID' (também conhecido como 'snmpEngineID' or “Engine ID”) nunca seja repetido entre dois dispositivos. Conforme a RFC 2571 (seção 3.1.1.1) este valor deve ser único para cada dispositivo.

Configurando a monitoração SNMP

Para começar a monitoração através do SNMP, utilize os passos a seguir:

Passo 1

Criar um host para o dispositivo que possui interface SNMP.

Informe o endereço IP de sua interface. Você pode aproveitar um dos templates de SNMP (Template SNMP Device e outros) que são fornecidos junto com o Zabbix, eles irão adicionar automaticamente um conjunto de itens. Entretanto, o dispositivo que você deseja monitorar poderá não ser compatível com eles. Clique em Adicionar para salvar o host.

As requisições SNMP não utilizam a porta do agente, ela será ignorada.
Passo 2

Descubra o OID que você deseja monitorar (normalmente na documentação do dispositivo).

Para obter uma lista dos OIDs do dispositivo o comando snmpwalk poderá ser utilizado (ele é parte do pacote net-snmp que você adicionou durante a instalação do Zabbix Server) ou alguma ferramenta equivalente:

shell> snmpwalk -v 2c -c public <host IP> .

O '2c' utilizado no comando se refere à versão do SNMP, caso seu dispositivo trabalhe, por exemplo, com a primeira versão do protocolo você pode substitui-lo por '1', para indicar que o 'snmpwalk' deverá utilizar esta versão do protocolo.

Você deverá ter como resultado uma lista contendo os nomes dos OIDs, seus tipos e último valor de cada um. É possível que o nome de comunidade configurada no dispositivo seja outro que não o 'public', neste caso você deverá descobrir o nome correto e utiliza-lo.

Você pode recorrer a esta lista para localizar qual nome de OID que você deseja monitorar, por exemplo, se você desejar monitorar o volume em bytes que é recebido pela terceira porta do dispositivo, você poderia utilizar o nome de OID IF-MIB::ifInOctets.3, conforme o exemplo a seguir:

IF-MIB::ifInOctets.3 = Counter32: 3409739121

Agora utilizaremos o comando snmpget para descobrir o número associado ao nome de OID selecionado ('IF-MIB::ifInOctets.3'):

shell> snmpget -v 2c -c public -On 10.62.1.22 IF-MIB::ifInOctets.3

Observe que o último número neste nome de OID é o número da porta que você deseja monitorar. Mais detalhes em índices dinâmicos do SNMP.

O resultado do comando deve ser algo similar ao texto a seguir:

.1.3.6.1.2.1.2.2.1.10.3 = Counter32: 3472126941

Novamente, o último número no OID é o número da porta.

Alguns fabricantes, como a 3COM, preferem nomear as suas portas começando no número 100, exemplos: porta 1 = porta 101, porta 3 = porta 103. A CISCO (e a maioria dos fornecedores) usa uma sequência simples, exemplo: port 3 = 3.
Alguns dos OIDs mais utilziados são traduzidos automaticamente para a representação numérica de forma nativa no Zabbix.

No último exemplo o tipo do valor recebido é “Counter32”, que corresponde internamente ao tipo ASN_COUNTER. A lista completa de tipos suportados é: 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 e ASN_OBJECT_ID (desde o Zabbix 2.2.8 ou 2.4.3). Estes tipos correspondem, respectivamente, à: “Counter32”, “Counter64”, “UInteger32”, “INTEGER”, “Float”, “Double”, “Timeticks”, “Gauge32”, “IpAddress”, “OCTET STRING”, “OBJECT IDENTIFIER” na saida do snmpget, mas também podem ser apresentados como “STRING”, “Hex-STRING”, “OID” ou outro.

Passo 3

Criar o item de monitoração.

FIXME This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)

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. In the new item form, enter the item 'Name'. Make sure the 'Host interface' field has your switch/router in it and change the 'Type' field to “SNMPv* agent”. Enter the community (usually public) and enter the textual or numeric OID that you retrieved earlier into the 'SNMP OID' field, for example: .1.3.6.1.2.1.2.2.1.10.3

Enter the SNMP 'Port' as 161 and the 'Key' as something meaningful, e.g. SNMP-InOctets-Bps. Choose a custom multiplier if you want one and enter an 'Update interval' and 'History storage period' if you want them to be different from the padrão. Set the 'Type of information' to Numeric (float) and the 'Store value' to Delta (important, otherwise you will get cumulative values from the SNMP device instead of the latest change).

Now save the item and go to MonitoringLatest data for your SNMP data!

Take note of specific options available for SNMPv3 items:

ParâmetroDescrição
Context name Enter context name to identify item on SNMP subnet.
Context name is supported for SNMPv3 items Desde o Zabbix 2.2.
User macros are resolved in this field.
Security name Enter security name.
User macros are resolved in this field.
Security level Select security level:
noAuthNoPriv - no authentication nor privacy protocols are used
AuthNoPriv - authentication protocol is used, privacy protocol is not
AuthPriv - both authentication and privacy protocols are used
Authentication protocol Select authentication protocol - MD5 or SHA.
Authentication passphrase Enter authentication passphrase.
User macros are resolved in this field.
Privacy protocol Select privacy protocol - DES or AES.
Privacy passphrase Enter privacy passphrase.
User macros are resolved in this field.
Desde o Zabbix 2.2, SHA and AES protocols are supported for SNMPv3 authentication and privacy, in addition to MD5 and DES supported before that.
Example 1

General example:

ParâmetroDescrição
Community public
OID 1.2.3.45.6.7.8.0 (or .1.2.3.45.6.7.8.0)
Key <Unique string to be used as reference to triggers>
For example, “my_param”.

Note that OID can be given in either numeric or string form. However, in some cases, string OID must be converted to numeric representation. Utility snmpget may be used for this purpose:

shell> snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

Monitoring of SNMP Parâmetros is possible if --with-net-snmp flag was specified while configuring Zabbix sources.

Example 2

Monitoring of uptime:

ParâmetroDescrição
Community public
Oid MIB::sysUpTime.0
Key router.uptime
Value type Float
Units uptime
Multiplier 0.01

Internal workings of bulk processing

Starting from 2.2.3 Zabbix Server e o Zabbix Proxy query SNMP devices for multiple values in a single request. This affects several types of SNMP items:

All SNMP items on a single interface with identical Parâmetros are scheduled to be queried at the same time. The first two types of items are taken by pollers in batches of at most 128 items, whereas low-level discovery rules are processed individually, as before.

On the lower level, there are two kinds of operations performed for querying values: getting multiple specified objects and walking an OID tree.

For “getting”, a GetRequest-PDU is used with at most 128 variable bindings. For “walking”, a GetNextRequest-PDU is used for SNMPv1 and GetBulkRequest with “max-repetitions” field of at most 128 is used for SNMPv2 and SNMPv3.

Thus, the benefits of bulk processing for each SNMP item type are outlined below:

  • regular SNMP items benefit from “getting” improvements;
  • SNMP items with dynamic indexes benefit from both “getting” and “walking” improvements: “getting” is used for index verification and “walking” for building the cache;
  • SNMP low-level discovery rules benefit from “walking” improvements.

However, there is a technical issue that not all devices are capable of returning 128 values per request. Some always return a proper response, but others either respond with a “tooBig(1)” error or do not respond at all once the potential response is over a certain limit.

In order to find an optimal number of objects to query for a given device, Zabbix uses the following strategy. It starts cautiously with querying 1 value in a request. If that is successful, it queries 2 values in a request. If that is successful again, it queries 3 values in a request and continues similarly by multiplying the number of queried objects by 1.5, resulting in the following sequence of request sizes: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

However, once a device refuses to give a proper response (for example, for 42 variables), Zabbix does two things.

First, for the current item batch it halves the number of objects in a single request and queries 21 variables. If the device is alive, then the query should work in the vast majority of cases, because 28 variables were known to work and 21 is significantly less than that. However, if that still fails, then Zabbix falls back to querying values one by one. If it still fails at this point, then the device is definitely not responding and request size is not an issue.

The second thing Zabbix does for subsequent item batches is it starts with the last successful number of variables (28 in our example) and continues incrementing request sizes by 1 until the limit is hit. For example, assuming the largest response size is 32 variables, the subsequent requests will be of sizes 29, 30, 31, 32, and 33. The last request will fail and Zabbix will never issue a request of size 33 again. From that point on, Zabbix will query at most 32 variables for this device.

If large queries fail with this number of variables, it can mean one of two things. The exact criteria that a device uses for limiting response size cannot be known, but we try to approximate that using the number of variables. So the first possibility is that this number of variables is around the device's actual response size limit in the general case: sometimes response is less than the limit, sometimes it is greater than that. The second possibility is that a UDP packet in either direction simply got lost. For these reasons, if Zabbix gets a failed query, it reduces the maximum number of variables to try to get deeper into the device's comfortable range, but (starting from 2.2.8) only up to two times.

In the example above, if a query with 32 variables happens to fail, Zabbix will reduce the count to 31. If that happens to fail, too, Zabbix will reduce the count to 30. However, Zabbix will not reduce the count below 30, because it will assume that further failures are due to UDP packets getting lost, rather than the device's limit.

If, however, a device cannot handle bulk requests properly for other reasons and the heuristic described above does not work, Desde o Zabbix 2.4 there is a “Use bulk requests” setting for each interface that allows to disable bulk requests for that device.