Streaming para sistemas externos

Visão geral

É possível transmitir valores de item e eventos do Zabbix para sistemas externos via HTTP (consulte os detalhes do protocolo).

O filtro de tags pode ser usado para transmitir subconjuntos de valores de item ou eventos.

Dois tipos de processos do Zabbix server são responsáveis pela transmissão de dados: connector manager e connector worker. Um item interno do Zabbix, zabbix[connector_queue], permite monitorar a quantidade de valores enfileirados na fila do conector.

Configuração

As etapas a seguir são necessárias para configurar o streaming de dados para um sistema externo:

1. Configure um sistema remoto para receber dados do Zabbix. Para isso, estão disponíveis as seguintes ferramentas:

  • Um exemplo de um receiver simples que registra as informações recebidas nos arquivos events.ndjson e history.ndjson.
  • Kafka connector for Zabbix server - um server leve escrito em Go, desenvolvido para encaminhar valores de item e eventos de um server Zabbix para um broker Kafka.

2. Defina no Zabbix o número necessário de workers do connector ajustando o parâmetro StartConnectors em zabbix_server.conf. O número de workers do connector deve corresponder ao número configurado de connectors no frontend do Zabbix (ou ser maior, se houver mais de uma sessão simultânea). Em seguida, reinicie o server Zabbix.

3. Configure um novo connector no frontend do Zabbix (Administração > Geral > Connectors) e recarregue o cache do server com o comando zabbix_server -R config_cache_reload.

Os campos obrigatórios são marcados com um asterisco.

Parâmetro Descrição
Nome Insira o nome do connector.
Tipo de dados Selecione o tipo de dados a transmitir:
Valores de item - transmite valores de item do Zabbix para sistemas externos;
Eventos - transmite eventos do Zabbix para sistemas externos.
URL Insira a URL do receiver. Macros de usuário são compatíveis.
Filtro de tags Exporte somente valores de item ou eventos que correspondam ao filtro de tags. Se não for definido, tudo será exportado.
É possível incluir e excluir tags e valores de tags específicos. Várias condições podem ser definidas. A correspondência do nome da tag sempre diferencia maiúsculas de minúsculas.

Há vários operadores disponíveis para cada condição:
Existe - inclui os nomes de tag especificados;
É igual a - inclui os nomes e valores de tag especificados (diferencia maiúsculas de minúsculas);
Contém - inclui os nomes de tag especificados cujos valores contêm a string inserida (correspondência de substring, sem diferenciar maiúsculas de minúsculas);
Não existe - exclui os nomes de tag especificados;
Não é igual a - exclui os nomes e valores de tag especificados (diferencia maiúsculas de minúsculas);
Não contém - exclui os nomes de tag especificados cujos valores contêm a string inserida (correspondência de substring, sem diferenciar maiúsculas de minúsculas).

Há dois tipos de cálculo para as condições:
E/Ou - todas as condições devem ser atendidas; as condições que têm o mesmo nome de tag serão agrupadas pela condição Ou;
Ou - basta que uma condição seja atendida.
Tipo de informação Selecione o tipo de informação (numérico (sem sinal), numérico (ponto flutuante), caractere etc.) pelo qual filtrar os valores de item que o connector deve transmitir.
Este campo está disponível quando Tipo de dados está definido como "Valores de item".
Autenticação HTTP Selecione a opção de autenticação:
Nenhuma - nenhuma autenticação é usada;
Básica - é usada autenticação básica;
NTLM - é usada autenticação NTLM (Windows NT LAN Manager);
Kerberos - é usada autenticação Kerberos (consulte também: Configurando o Kerberos com o Zabbix);
Digest - é usada autenticação Digest;
Bearer - é usada autenticação Bearer.
Nome de usuário Insira o nome de usuário (até 255 caracteres). Macros de usuário são compatíveis.
Este campo está disponível quando Autenticação HTTP está definida como "Básica", "NTLM", "Kerberos" ou "Digest".
Senha Insira a senha do usuário (até 255 caracteres). Macros de usuário são compatíveis.
Este campo está disponível quando Autenticação HTTP está definida como "Básica", "NTLM", "Kerberos" ou "Digest".
Token Bearer Insira o token Bearer. Macros de usuário são compatíveis.
Este campo está disponível e é obrigatório quando Autenticação HTTP está definida como "Bearer".
Configuração avançada Clique no cabeçalho Configuração avançada para exibir as opções de configuração avançada (veja abaixo).
Máximo de registros por mensagem Especifique o número máximo de valores ou eventos que podem ser transmitidos em uma mensagem.
Sessões simultâneas Selecione o número de processos de envio a serem executados para este connector. Podem ser especificadas até 100 sessões; o valor padrão é "1".
Tentativas Número de tentativas para transmitir dados. Podem ser especificadas até 5 tentativas; o valor padrão é "1".
Intervalo entre tentativas Especifique quanto tempo o connector deve aguardar após uma tentativa malsucedida de transmitir dados. Podem ser especificados até 10s; o valor padrão é "5s".
Este campo está disponível quando Tentativas está definido como "2" ou mais.
Tentativas malsucedidas são aquelas em que não foi possível estabelecer uma conexão ou em que o código de resposta HTTP não é 200, 201, 202, 203 ou 204. As novas tentativas são acionadas em caso de erros de comunicação ou quando o código de resposta HTTP não é 200, 201, 202, 203, 204, 400, 401, 403, 404, 405, 415 ou 422. Os redirecionamentos são seguidos; portanto, 302 -> 200 é uma resposta positiva, enquanto 302 -> 503 acionará uma nova tentativa.
Tempo limite Especifique o tempo limite da mensagem (1-60 segundos, padrão - 5 segundos).
Sufixos de tempo são compatíveis (por exemplo, 30s, 1m). Macros de usuário são compatíveis.
Proxy HTTP Você pode especificar um proxy HTTP no seguinte formato:
[protocol://][username[:password]@]proxy.example.com[:port]
Macros de usuário são compatíveis.

O prefixo opcional protocol:// pode ser usado para especificar protocolos de proxy alternativos (o suporte ao prefixo de protocolo foi adicionado no cURL 7.21.7). Quando nenhum protocolo é especificado, o proxy será tratado como um proxy HTTP. Por padrão, será usada a porta 1080.

Se Proxy HTTP for especificado, o proxy substituirá variáveis de ambiente relacionadas a proxy, como http_proxy e HTTPS_PROXY. Se não for especificado, o proxy não substituirá variáveis de ambiente relacionadas a proxy. O valor inserido é repassado como está, sem qualquer verificação de validade.
Você também pode inserir um endereço de proxy SOCKS. Se especificar o protocolo incorreto, o connector não conseguirá transmitir valores de item ou eventos do Zabbix.

Observe que somente a autenticação simples é compatível com proxy HTTP.
Verificar peer SSL Marque a caixa de seleção para verificar o certificado SSL do web server.
O certificado do server será obtido automaticamente do local de autoridade certificadora (CA) em todo o sistema. Você pode substituir o local dos arquivos de CA usando o parâmetro de configuração do server ou proxy Zabbix SSLCALocation.
Verificar host SSL Marque a caixa de seleção para verificar se o campo Common Name ou Subject Alternate Name do certificado do web server corresponde.
Isso define a opção cURL CURLOPT_SSL_VERIFYHOST.
Arquivo de certificado SSL Nome do arquivo de certificado SSL usado para autenticação do cliente. O arquivo de certificado deve estar no formato PEM1. Macros de usuário são compatíveis.
Se o arquivo de certificado também contiver a chave privada, deixe o campo Arquivo de chave SSL vazio. Se a chave estiver criptografada, especifique a senha no campo Senha da chave SSL. O diretório que contém este arquivo é especificado pelo parâmetro de configuração do server ou proxy Zabbix SSLCertLocation.
Arquivo de chave SSL Nome do arquivo de chave privada SSL usado para autenticação do cliente. O arquivo de chave privada deve estar no formato PEM1. Macros de usuário são compatíveis.
O diretório que contém este arquivo é especificado pelo parâmetro de configuração do server ou proxy Zabbix SSLKeyLocation.
Senha da chave SSL Senha do arquivo de chave privada SSL. Macros de usuário são compatíveis.
Descrição Insira a descrição do connector.
Habilitado Marque a caixa de seleção para habilitar o connector.

Quando o Kafka connector é configurado com uma lista de endereços de brokers de inicialização separados por vírgulas (por exemplo, Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093), o cliente Kafka se conecta ao(s) broker(s) que responder(em) primeiro e usa os metadados do cluster. Se a lista contiver endereços de diferentes clusters Kafka, somente o cluster que responder mais rapidamente será usado, e os outros endereços serão registrados como indisponíveis; como resultado, avisos de inicialização como o seguinte podem aparecer mesmo quando o connector está conectado:

kafka cluster connected, but broker(s) "kafka1.example.com:9093, kafka2.example.com:9093" unavailable; will retry on message send if active brokers fail 

Em alguns ambientes (redes privadas, redes de containers ou configurações não padrão de DNS/hosts), nomes de host ou IPs podem ser resolvidos para endereços de loopback (por exemplo, 127.0.0.1/localhost) ou normalizados pelo cliente, o que pode tornar esses avisos enganosos. Para reduzir a confusão, certifique-se de que todos os endereços Kafka.URL pertençam ao mesmo cluster Kafka, verifique a resolução DNS a partir do host do connector e os advertised.listeners dos brokers, e prefira endereços que sejam resolvidos para o endereço anunciado pelo broker.

Protocolo

A comunicação entre o server e o receiver é feita via HTTP usando a REST API, NDJSON, "Content-Type: application/x-ndjson".

Para mais detalhes, consulte Newline-delimited JSON export protocol.

Solicitação do servidor

Exemplo de transmissão de valores de item:

POST /v1/history HTTP/1.1
Host: localhost:8080
Accept: */*
Accept-Encoding: deflate, gzip, br, zstd
Content-Length: 628
Content-Type: application/x-ndjson

{"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"foo","value":"test"}],"itemid":44457,"name":"foo","clock":1673454303,"ns":800155804,"value":0,"type":3}
{"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"foo","value":"test"}],"itemid":44457,"name":"foo","clock":1673454303,"ns":832290669,"value":1,"type":3}
{"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"bar","value":"test"}],"itemid":44458,"name":"bar","clock":1673454303,"ns":867770366,"value":123,"type":3}

Exemplo de transmissão de eventos:

POST /v1/events HTTP/1.1
Host: localhost:8080
Accept: */*
Accept-Encoding: deflate, gzip, br, zstd
Content-Length: 333
Content-Type: application/x-ndjson

{"clock":1673454303,"ns":800155804,"value":1,"eventid":5,"name":"trigger for foo being 0","severity":0,"hosts":[{"host":"Zabbix server","name":"Zabbix server"}],"groups":["Zabbix servers"],"tags":[{"tag":"foo_trig","value":"test"},{"tag":"foo","value":"test"}]}
{"clock":1673454303,"ns":832290669,"value":0,"eventid":6,"p_eventid":5}
Resposta do receiver

A resposta consiste no código de status da resposta HTTP e na carga JSON. O código de status da resposta HTTP deve ser "200", "201", "202", "203" ou "204" para requisições processadas com sucesso; qualquer outro indica falha na requisição.

Exemplo de sucesso:

HTTP/1.1 200 OK
Content-Type: application/json
X-Content-Type-Options: nosniff
Date: Tue, 21 Apr 2026 10:13:04 GMT
Content-Length: 23

{"response":"success"}

Exemplo com erros:

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
X-Content-Type-Options: nosniff
Date: Tue, 21 Apr 2026 12:15:01 GMT
Content-Length: 55

{"error":"invalid character '{' after top-level value"}