Embora você possa encontrar o número de índice necessário (por exemplo, de uma interface de rede) entre os OIDs SNMP, às vezes não pode confiar completamente que o número de índice permanecerá o mesmo.
Os números de índice podem ser dinâmicos - eles podem mudar com o tempo e seu item pode parar de funcionar como consequência.
Para evitar esse cenário, é possível definir um OID que leve em conta a possibilidade de um número de índice mudar.
Por exemplo, se você precisa recuperar o valor do índice para anexar ao ifInOctets que corresponde à interface GigabitEthernet0/1 em um dispositivo Cisco, use o seguinte OID: ifInOctets["index","ifDescr","GigabitEthernet0/1"]
Uma sintaxe especial para OID é usada:
<OID of data>["index","<base OID of index>","<string to search for>"]
Parâmetro | Descrição |
---|---|
OID dos dados | OID principal a ser usado para a recuperação de dados no item. |
index | Método de processamento. Atualmente, um método é suportado: index – procurar pelo índice e anexá-lo ao OID dos dados |
OID da base de índice | Este OID será consultado para obter o valor do índice correspondente à string. |
string a ser procurada | A string a ser usada para uma correspondência exata com um valor ao fazer a busca. Sensível a maiúsculas e minúsculas. |
Obtendo o uso de memória do processo apache process.
Se estiver usando esta sintaxe de OID:
o número de índice será procurado aqui:
...
HOST-RESOURCES-MIB::hrSWRunPath.5376 = STRING: "/sbin/getty"
HOST-RESOURCES-MIB::hrSWRunPath.5377 = STRING: "/sbin/getty"
HOST-RESOURCES-MIB::hrSWRunPath.5388 = STRING: "/usr/sbin/apache2"
HOST-RESOURCES-MIB::hrSWRunPath.5389 = STRING: "/sbin/sshd"
...
Agora temos o índice, que é 5388. O índice será anexado ao OID de dados para receber o valor de interesse:
Quando um item de índice dinâmico é solicitado, o Zabbix recupera e armazena em cache toda a tabela SNMP sob o OID base para o índice, mesmo que uma correspondência seja encontrada antes. Isso é feito para que, caso outro item se refira ao mesmo OID base mais tarde, o Zabbix procure o índice no cache, em vez de consultar o host monitorado novamente. Observe que cada processo de poller usa um cache separado.
Em todas as operações subsequentes de recuperação de valor, apenas o índice encontrado é verificado. Se ele não mudou, o valor é solicitado. Se ele mudou, o cache é reconstruído - cada poller que encontra um índice alterado percorre a tabela SNMP do índice novamente.