2 Passive and active agent checks

Visão geral

Esta seção fornece detalhes sobre verificações passivas e ativas realizadas por agente Zabbix.

O Zabbix usa um protocolo de comunicação baseado em JSON para se comunicar com Agente Zabbix.

Verificações passivas

Uma verificação passiva é uma solicitação de dados simples. Servidor ou proxy Zabbix pergunta para alguns dados (por exemplo, carga da CPU) e o agente Zabbix envia de volta o resultado para o servidor.

Solicitação do servidor

Para definição de cabeçalho e comprimento de dados, consulte protocolo detalhes.

<chave de item>

Resposta do agente

<DADOS>[\0<ERRO>]

Acima, a parte entre colchetes é opcional e só é enviada para não itens suportados.

Por exemplo, para itens suportados:

1. O servidor abre uma conexão TCP
2. O servidor envia <HEADER><DATALEN>agent.ping
3. O agente lê a solicitação e responde com <HEADER><DATALEN>1
4. O servidor processa os dados para obter o valor, '1' no nosso caso
5. A conexão TCP está fechada

Para itens não suportados:

1. O servidor abre uma conexão TCP
2. O servidor envia <HEADER><DATALEN>vfs.fs.size[/nono]
3. O agente lê a solicitação e responde com <HEADER><DATALEN>ZBX_NOTSUPPORTED\0Não é possível obter informações do sistema de arquivos: [2] Arquivo ou diretório inexistente
4. O servidor processa os dados, altera o estado do item para não suportado com o mensagem de erro especificada
5. A conexão TCP está fechada

Verificações ativas

As verificações ativas requerem um processamento mais complexo. O agente deve primeiro recuperar do(s) servidor(es) uma lista de itens para processamento independente.

Os servidores para obter as verificações ativas estão listados no Parâmetro 'ServerActive' do agente configuração arquivo. A frequência de perguntas para essas verificações é definido pelo parâmetro 'RefreshActiveChecks' no mesmo arquivo de configuração. No entanto, se a atualização das verificações ativas falhar, é tentado novamente após 60 segundos codificados.

O agente então envia periodicamente os novos valores para o(s) servidor(es).

::: dica Se um agente estiver atrás do firewall, você pode considerar usando apenas verificações ativas porque nesse caso você não precisaria modifique o firewall para permitir conexões de entrada iniciais. :::

Obtendo a lista de itens

Solicitação do agente

{
    "request":"verificações ativas",
    "host":"<nome do host>"
}

Resposta do servidor

{
    "resposta":"sucesso",
    "dados":[
        {
            "key":"log[/home/zabbix/logs/zabbix_agentd.log]",
            "atraso":30,
            "lastlogsize":0,
            "mtime":0
        },
        {
            "key":"agente.versão",
            "atraso": 600,
            "lastlogsize":0,
            "mtime":0
        },
        {
            "key":"vfs.fs.size[/nono]",
            "atraso": 600,
            "lastlogsize":0,
            "mtime":0
        }
    ]
}

O servidor deve responder com sucesso. Para cada item devolvido, todos as propriedades key, delay, lastlogsize e mtime devem existir, independentemente de o item ser um item de log ou não.

Por exemplo:

1. O agente abre uma conexão TCP
2. O agente solicita a lista de cheques
3. O servidor responde com uma lista de itens (chave do item, atraso)
4. O agente analisa a resposta
5. A conexão TCP está fechada
6. O agente inicia a coleta periódica de dados

::: não importante Observe que os dados de configuração (sensíveis) podem tornar-se disponível para as partes que têm acesso ao servidor Zabbix trapper porta ao usar uma verificação ativa. Isso é possível porque qualquer pessoa pode fingir ser um agente ativo e solicitar dados de configuração do item; a autenticação não ocorre a menos que você use criptografia opções. :::

Enviando dados coletados

Agente envia

{
    "request":"dados do agente",
    "sessão": "12345678901234567890123456789012",
    "dados":[
        {
            "host":"<nome do host>",
            "key":"agente.versão",
            "valor":"2.4.0",
            "id": 1,
            "relógio": 1400675595,
            "ns":76808644
        },
        {
            "host":"<nome do host>",
            "key":"log[/home/zabbix/logs/zabbix_agentd.log]",
            "lastlogsize":112,
            "value":" 19845:20140621:141708.521 Iniciando o Zabbix Agent [<hostname>]. Zabbix 2.4.0 (revisão 50000).",
            "id": 2,
            "relógio": 1400675595,
            "ns":77053975
        },
        {
            "host":"<nome do host>",
            "key":"vfs.fs.size[/nono]",
            "estado":1,
            "value":"Não é possível obter informações do sistema de arquivos: [2] Arquivo ou diretório inexistente",
            "id": 3,
            "relógio": 1400675595,
            "ns":78154128
        }
    ],
    "relógio": 1400675595,
    "ns": 78211329
}

Um ID virtual é atribuído a cada valor. O ID do valor é um simples ascendente contador, único dentro de uma sessão de dados (identificado pela sessão símbolo). Este ID é usado para descartar valores duplicados que podem ser enviados em ambientes de baixa conectividade.

Resposta do servidor

{
    "resposta":"sucesso",
    "info":"processado: 3; falhou: 0; total: 3; segundos gastos: 0,003534"
}

::: não importante Se o envio de alguns valores falhar no servidor (por exemplo, porque o host ou item foi desabilitado ou excluído), o agente não tente enviar novamente esses valores. :::

Por exemplo:

1. O agente abre uma conexão TCP
2. O agente envia uma lista de valores
3. O servidor processa os dados e envia o status de volta
4. A conexão TCP está fechada

Observe como no exemplo acima o status não suportado para vfs.fs.size[/nono] é indicado pelo valor "state" de 1 e o mensagem de erro na propriedade "valor".

::: não importante A mensagem de erro será cortada para 2048 símbolos em lado do servidor. :::

Protocolo XML antigo

Veja também

1. Mais detalhes sobre o protocolo do Zabbix Agent (inglês)