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. Ter um sistema remoto configurado para receber dados do Zabbix. Para esse fim, as seguintes ferramentas estão disponíveis:

• 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, projetado para encaminhar valores de item e eventos de um Zabbix server para um broker Kafka.

2. Defina o número necessário de workers de connector no Zabbix ajustando o parâmetro StartConnectors em zabbix_server.conf. O número de workers de connector deve corresponder (ou exceder, se as sessões simultâneas forem mais de 1) à contagem de connectors configurada no Zabbix frontend. Em seguida, reinicie o Zabbix server.

3. Configure um novo connector no Zabbix frontend (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 bootstrap separados por vírgula (por exemplo, Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093), o cliente Kafka se conecta ao(s) broker(s) que respondem primeiro e usa seus metadados de cluster. Se a lista contiver endereços de diferentes clusters Kafka, apenas o cluster com resposta mais rápida será usado, e os outros endereços serão registrados como indisponíveis; como resultado, avisos na inicialização como o seguinte podem aparecer mesmo que o connector esteja 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 contêineres 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 ser 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 do 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"}