2 Transmitindo 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 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, projetado 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 de connectors configurado 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 (Administration > General > 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.

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 broker ou brokers que respondem 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), os 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 receptor é feita via HTTP usando REST API, NDJSON, "Content-Type: application/x-ndjson".

Para mais detalhes, consulte Protocolo de exportação JSON delimitado por nova linha.

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"}