韓誥傭痔

Table of Contents

3 Verifica??es passivas e ativas

3 Verifica??es passivas e ativas

Vis?o geral

Esta se??o fornece detalhes sobre as verifica??es passivas e ativas utilizando o 韓誥傭痔 Agent.

O 韓誥傭痔 utiliza o protocolo JSON para se comunicar com o 韓誥傭痔 Agent.

Existem algumas defini??es detalhadas nos protocolos utilizados pelo 韓誥傭痔:

<HEADER> - "ZBXD\x01" (5 bytes)
       <DATALEN> - tamanho do dado (8 bytes). 1 ser芍 formatado como 01/00/00/00/00/00/00/00 (oito bytes em HEX, n迆mero de 64 bit)

Para evitar o potencial esgotamento de mem車ria o 韓誥傭痔 Server 谷 limitado a aceitar no m芍ximo 128MB em uma mesma conex?o atrav谷s do protocolo.

Verifica??es passivas

Uma verifica??o passiva 谷 uma requisi??o simples de dados. O 韓誥傭痔 Server/Proxy solicita algum dado (por exemplo a carga de CPU) e o 韓誥傭痔 Agent retorna com o resultado.

Requisi??o do servidor

<item key>\n

Resposta do agente

<HEADER><DATALEN><DATA>[\0<ERROR>]

No exemplo de resposta acima, a parte enviada entre colchetes 谷 opcional e s車谷 enviada para itens (chaves) n?o suportadas.

Exemplo de fluxo com item suportado:

Servidor abre uma conex?o TCP
Servidor envia agent.ping\n
Agente l那 a requisi??o e responde com <HEADER><DATALEN>1
Servidor processa o dado para receber o valor ('1' neste exemplo)
Conex?o TCP 谷 fechada

Exemplo de fluxo para item n?o suportado:

Servidor abre uma conex?o TCP
Servidor envia vfs.fs.size[/nono]\n
Agente l那 a requisi??o e responde com <HEADER><DATALEN>ZBX_NOTSUPPORTED\0Cannot obtain filesystem information: [2] No such file or directory
Servidor processa o dado, modifica o estado do item para 'n?o suportado' com a mensagem de erro retornada
Conex?o TCP 谷 fechada

Verifica??es Ativas

As verifica??es ativas requerem um processamento mais complexo. Primeiramente o agente deve obter do servidor a lista com os itens a serem processados de forma independente.

Os servidores que ir?o fornecer a lista de verifica??es ativas dever?o estar listados no par?metro 'ServerActive' do arquivo de configura??o do agente. A frequ那ncia de consulta 角 estas verifica??es 谷 definida pelo par?metro 'RefreshActiveChecks' neste mesmo arquivo. Caso uma requisi??o da lista de itens ativos falhe, uma nova tentativa ser芍 feita a cada 60 segundos com aquele servidor.

O agente envia os dados periodicamente aos servidores.

Obtendo a lista de itens

Requisi??o do agente

<HEADER><DATALEN>{
           "request":"active checks",
           "host":"<hostname>"
       }

Resposta do servidor

<HEADER><DATALEN>{
           "response":"success",
           "data":[
               {
                   "key":"log[/home/zabbix/logs/zabbix_agentd.log]",
                   "delay":30,
                   "lastlogsize":0,
                   "mtime":0
               },
               {
                   "key":"agent.version",
                   "delay":600,
                   "lastlogsize":0,
                   "mtime":0
               },
               {
                   "key":"vfs.fs.size[/nono]",
                   "delay":600,
                   "lastlogsize":0,
                   "mtime":0
               }
           ]
       }

O servidor deve responder com sucesso. Para cada item retornado todas as propriedades (key, delay, lastlogsize e mtime) dever?o estar presentes, mesmo que o item n?o seja de log.

Exemplo do fluxo:

Agente abre uma conex?o TCP
Agente requisita a lista de verifica??es ativas
Servidor responde com uma lista de itens (item key, delay, lastlogsize e mtime)
Agente processa a resposta
Conex?o TCP 谷 fechada
O agente coleta de forma peri車dica os dados

Note que dados sens赤veis de configura??o podem se tornar dispon赤veis para terceiros que tenham acesso 角 porta de 'trapper' do servidor 韓誥傭痔, quando for utilizada a verifica??o ativa. Isso 谷 poss赤vel porque qualquer um pode se passar por um agente ativo e solicitar dados de configura??o de itens; n?o ocorre autentica??o neste caso.

Enviando os dados coletados

O agente envia os dados

<HEADER><DATALEN>{
           "request":"agent data",
           "data":[
               {
                   "host":"<hostname>",
                   "key":"agent.version",
                   "value":"2.4.0",
                   "clock":1400675595,            
                   "ns":76808644
               },
               {
                   "host":"<hostname>",
                   "key":"log[/home/zabbix/logs/zabbix_agentd.log]",
                   "lastlogsize":112,
                   "value":" 19845:20140621:141708.521 Starting 韓誥傭痔 Agent [<hostname>]. 韓誥傭痔 2.4.0 (revision 50000).",
                   "clock":1400675595,            
                   "ns":77053975
               },
               {
                   "host":"<hostname>",
                   "key":"vfs.fs.size[/nono]",
                   "state":1,
                   "value":"Cannot obtain filesystem information: [2] No such file or directory",
                   "clock":1400675595,            
                   "ns":78154128
               }
           ],
           "clock": 1400675595,
           "ns": 78211329
       }

O servidor responde

<HEADER><DATALEN>{
           "response":"success",
           "info":"processed: 3; failed: 0; total: 3; seconds spent: 0.003534"
       }

Se o envio de alguns itens falhar no lado do servidor (por exemplo, por que o host ou o item est?o desativados ou exclu赤dos), o agente n?o ir芍 tentar enviar novamente estes dados.

Exemplo de fluxo:

O agente abre a conex?o TCP
O agente envia a lista de valores
O servidor processa os dados e envia o status de volta
A conex?o TCP 谷 fechada

Observe no exemplo acima que o status de n?o suportado para a chave vfs.fs.size[/nono] 谷 indicado pela propriedade "state" tendo o valor '1' e a mensagem de erro vai na propriedade "value".

A mensagem de erro ser芍 limitada em 2048 caracteres no lado do servidor.

Protocolo XML antigo

O 韓誥傭痔 ir芍 tratar at谷 16 MB de dados XML codificados em Base64, mas um 迆nico valor decodificado n?o poder芍 ser superior a 64 KB ou ser芍 truncado para 64 KB durante a decodifica??o.