Kaique Mitsuo Silva Yamamoto
Arquitetura softwareInfra devops

Zabbix — Monitoramento de Infraestrutura

Guia técnico sobre Zabbix 7.x: arquitetura, instalação, itens e triggers, discovery, alertas, API, cloud/containers, integração com Grafana, alta disponibilidade e comparativo com Prometheus, Nagios e Datadog.

Arquitetura do Zabbix 7.x

Zabbix é uma plataforma de monitoramento de infraestrutura e aplicações composta por quatro blocos principais:

  • Zabbix Server: recebe dados, avalia triggers, gera eventos, ações, gráficos, mapas e dashboards; acessa diretamente o banco de dados.
  • Zabbix Proxy: intermediário opcional que coleta dados de hosts em regiões/remotos e os envia ao server; em 7.0 ganhou memory buffer (armazenar dados em memória antes de enviar ao server) e suporte a proxy groups para load balancing e alta disponibilidade.
  • Zabbix Agent: instalado nos hosts para coletar métricas (CPU, memória, disco, processos, etc.), em modo ativo ou passivo.
  • Database: armazena configuração, histórico, trends e eventos; normalmente MySQL/MariaDB ou PostgreSQL em produção.

Arquiteturas maiores usam múltiplos proxies (com proxy groups e redistribuição automática de hosts) para escalar coleta e garantir observabilidade mesmo com falhas regionais.

Instalação e configuração inicial

Passos típicos para um ambiente de laboratório/produção simples:

  1. Instalar banco de dados (MySQL/MariaDB ou PostgreSQL) e criar database/usuário zabbix com permissões adequadas.
  2. Subir o Zabbix Server + frontend (pacotes do SO ou containers).
  3. Rodar o wizard web para apontar o server ao DB, configurar usuário admin, timezone, idioma, etc.
  4. Instalar Zabbix Agent em hosts a serem monitorados e configurar Server/ServerActive com IP/DNS do servidor/proxies.

Em ambientes mais complexos, adicionam‑se proxies para regiões remotas/segmentos de rede, e a configuração inicial inclui criação de hosts, grupos e associação de templates.

Hosts, host groups, items e tipos de coleta

Hosts e host groups

  • Hosts representam dispositivos monitorados: servidores, VMs, switches, appliances, containers, etc.
  • Host groups organizam hosts por ambiente (prod/homolog), região, tipo de serviço, facilitando permissões, templates e relatórios.

Items e tipos de coleta

Itens definem o que será coletado em cada host:

  • Zabbix agent: coleta local (CPU, memória, disco, processos, logs, etc.).
  • SNMP: equipamentos de rede, storages, impressoras e appliances.
  • JMX: aplicações Java (JVM, servlets, datasources).
  • HTTP(s): checagem de endpoints, APIs, conteúdo de páginas.
  • IPMI: sensores de hardware (temperatura, fans, PSU).
  • Outros: scripts externos, Zabbix trapper (push), ODBC, WMI, Prometheus scrape, etc.

Cada item possui key, tipo de dado (float, uint, string, log), intervalo de coleta, preprocessing e retention.

Triggers, expressões e ações

Triggers

Triggers definem condições lógicas baseadas em itens para gerar eventos:

  • Ex.: last(/Server:system.cpu.load[percpu,avg1]) > 5 para CPU alta, ou comparação de tendências, percentuais e funções avançadas.
  • Podem usar múltiplos itens, host macros, user macros e funções como max(), min(), avg(), count(), nodata(), etc.

Quando uma trigger muda de OK → PROBLEM, um evento é criado; quando a condição volta, o evento é resolvido.

Alertas e ações

  • Actions definem o que fazer quando eventos/casos específicos ocorrem: enviar e‑mail, Slack, PagerDuty, abrir ticket via webhook, executar scripts remotos, etc.
  • Suportam condições por severidade, host group, tags, tempo, número de tentativas, etc.
  • Media types configuram canais (SMTP, webhook HTTP, Slack/Teams, SMS, PagerDuty, etc.) com parâmetros por usuário.

Isso permite construir playbooks de alerta detalhados (ex.: notificar SRE nível 1 no horário comercial e on‑call à noite).

Templates e template linking

Templates são conjuntos reutilizáveis de:

  • Items, triggers, graphs, discovery rules, dashboards, macros e até hosts prototypes.
  • Podem ser linkados a múltiplos hosts/host groups, garantindo consistência de monitoramento.

Exemplos:

  • Template “Linux by Zabbix agent” com CPU, memória, disco, FS discovery, etc.
  • Template “Cisco SNMP” para equipamentos de rede.

Ao atualizar um template (ex.: nova trigger de latência), todos os hosts vinculados herdam automaticamente a mudança.

Discovery: network discovery e low-level discovery (LLD)

Network discovery

  • Network discovery escaneia ranges de IP periodicamente e executa checks (ICMP, SNMP, ports TCP) para encontrar novos hosts/serviços.
  • Regras de discovery permitem autoregistrar hosts (auto‑registration) em grupos específicos, aplicar templates e enviar notificações.

Low-Level Discovery (LLD)

  • LLD automatiza criação de itens/triggers/graphs para entidades internas de um host (interfaces de rede, sistemas de arquivos, sensores IPMI, serviços, etc.).
  • Um discovery rule coleta JSON (ex.: vfs.fs.discovery para file systems, net.if.discovery para interfaces); macros LLD ({#FSNAME}, {#IFNAME}, etc.) são usadas em protótipos de itens/triggers/graphs, gerando instâncias para cada entidade descoberta.

LLD também pode criar hosts dinamicamente (ex.: VMs descobertas em um hypervisor ou containers) e fazer nested discovery.

Mapas de rede e dashboards

  • Network maps permitem desenhar topologias lógicas/físicas, representar hosts, links e dependências com ícones, status de triggers e labels dinâmicos.
  • Dashboards agregam widgets: gráficos simples, mapas, listas de problemas, top N, business services, SLA/SLO, etc.

Com LLD e discovery, mapas podem ser parcialmente automatizados, mas muitas equipes usam mapas customizados para visualização executiva.

Zabbix API para automação

A Zabbix API JSON‑RPC expõe praticamente todas as operações de configuração e consulta:

  • Criar/atualizar hosts, templates, items, triggers, ações, usuários e permissões.
  • Obter história, trends, problemas atuais e dados de configuração para integração com CMDBs e pipelines de IaC.

Casos comuns:

  • Provisionamento automático de monitoramento ao criar VMs/serviços (Terraform/Ansible + API).
  • Sincronização de inventário Zabbix ↔ CMDB.
  • Geração de relatórios customizados fora do frontend.

Monitoramento de cloud, Docker e Kubernetes

Zabbix 7.x oferece múltiplas abordagens:

  • Cloud: via agentes em VMs, SNMP em appliances cloud, APIs de provedores (AWS/Azure/GCP) com templates específicos, e coleta de métricas via HTTP/JSON ou Prometheus data discovery.
  • Docker: itens via Zabbix agent (docker.* keys), SNMP ou scripts que chamam docker stats, docker ps, etc.
  • Kubernetes:
    • Monitorar nós e pods com agentes em nodes.
    • Usar proxies/agentes em clusters e LLD para namespaces/pods/services.
    • Integrar com Prometheus endpoints do cluster e usar discovery de dados Prometheus (LLD using Prometheus data).

Ainda que Zabbix não seja tão nativo a Kubernetes quanto Prometheus/Datadog/Dynatrace, é possível atingir bom nível de visibilidade combinando agentes, SNMP, APIs e Prometheus scrapes.

Integração com Grafana

Grafana é frequentemente usado para visualizações avançadas dos dados do Zabbix:

  • Instala‑se o plugin Zabbix datasource (Alexander Zobnin, hoje plugin oficial do Grafana) e configura‑se a fonte apontando para a API do Zabbix (/zabbix/api_jsonrpc.php).
  • Opcionalmente, ativa‑se Direct DB Access: Grafana lê histórico/trends direto nas tabelas history, history_uint, trends e trends_uint de um MySQL/PostgreSQL configurado como datasource SQL.

Fluxo típico:

  1. Instalar Grafana e plugin Zabbix.
  2. Adicionar datasource Zabbix (URL da API, credenciais de usuário Zabbix).
  3. (Opcional) Configurar datasource SQL (MySQL/PostgreSQL) com acesso somente leitura ao DB Zabbix para leitura direta de history/trends.
  4. Criar dashboards personalizados com queries por host, item, macro, etc.

Alta disponibilidade (HA) do Zabbix Server e Proxy

Zabbix 7.0 introduz melhorias importantes:

  • Server HA: múltiplos nós de Zabbix Server em cluster; apenas um Active por vez, demais em Standby ou Stopped, com failover automático.
  • Proxy groups e proxy load balancing:
    • Proxy groups permitem que hosts sejam atribuídos a um grupo e o server redistribui automaticamente hosts entre proxies ativos para balanceamento e HA.
    • Requisitos: proxies e server 7.0+ com versões compatíveis, hosts configurados para monitoramento por proxy group.
  • Agentes/passive/active precisam ser configurados com lista de IPs dos nós de server/proxy para garantir failover (via parâmetros Server/ServerActive).

Esses recursos, aliados a bancos de dados replicados (MySQL/PostgreSQL HA ou cluster), permitem topologias altamente disponíveis para grandes ambientes.

Performance tuning do banco de dados

O banco é o gargalo comum de desempenho em grandes instâncias Zabbix:

  • Garantir hardware adequado (IOPS, SSD/NVMe, memória generosa para buffer/cache).
  • Ajustar parâmetros de MySQL/MariaDB/PostgreSQL (buffer pool/shared buffers, work_mem, autovacuum, etc.) voltados ao perfil de escrita constante nas tabelas de histórico/trends.
  • Usar particionamento, manutenção de histórico (housekeeping) e, se necessário, offload de histórico antigo para outro DB.
  • Minimizar itens com alta frequência desnecessária; usar preprocessing, dependências e trapper para reduzir carga.

Guias específicos de HA e performance geralmente detalham tamanho de buffer, índices relevantes e boas práticas para milhares de hosts e milhões de itens.

Comparativo: Zabbix vs Prometheus, Nagios e Datadog

Zabbix vs Prometheus

  • Zabbix:

    • Abordagem pull/push híbrida (agentes, SNMP, scripts, traps).
    • Forte em auto‑discovery LLD, mapas, templates ricos, triggers complexas e UI pronta.
    • Banco relacional centralizado (MySQL/PostgreSQL), com histórico estruturado, bom para relatórios clássicos e integrações via API.

  • Prometheus:

    • Enfoque em metrics only (time‑series), scrape HTTP/Prometheus exposition, PromQL e storage local/TSDB.
    • Integrado fortemente a Kubernetes/cloud‑native; data retention curto (com offload via Cortex/Thanos/Mimir).
    • Usado frequentemente em conjunto com Grafana, Alertmanager e eco‑stack.

Prometheus é excelente para métricas cloud‑native e alta cardinalidade; Zabbix se destaca em infra tradicional, SNMP, mapas e modelo all‑in‑one com UI/alerts.

Zabbix vs Nagios

  • Nagios (especialmente Core) é mais antigo, baseado em plugins, checks via scripts, arquivos de configuração textuais e interface mais simples.
  • Zabbix fornece:
    • UI moderna, LLD avançado, discovery dinâmico, API full‑stack, proxies para distribuição e dashboards integrados.
    • Melhor escalabilidade em ambientes grandes, com proxies e HA nativos.

Em muitos ambientes, Zabbix é visto como sucessor natural de Nagios para monitoramento infra + aplicações.

Zabbix vs Datadog

  • Datadog:

    • SaaS de observabilidade full‑stack (APM, logs, métricas, RUM, synthetics) com agentes leves e forte ecossistema de integrações; excelente para cloud‑native e microserviços.
    • Custo geralmente maior em larga escala, modelo de licenciamento por SKU/módulo.

  • Zabbix:

    • Self‑hosted, custo de licença zero (open source), mas com custo operacional de manutenção de infra e tuning de DB.
    • Foco maior em infra tradicional, SNMP, monitoramento on‑prem e modelos centralizados; APM e tracing não são core como em Datadog.

Resumo:

  • Use Zabbix quando quiser controle total on‑prem, forte SNMP/infra, UI integrada e custo de licença zero.
  • Use Prometheus/Grafana para stacks nativas de Kubernetes com métricas altamente dinâmicas.
  • Use Datadog para observabilidade SaaS full‑stack com APM/logs/RUM fortemente integrados, aceitando custo SaaS.

Fontes e leituras recomendadas

Documentação e artigos oficiais Zabbix:

Alta disponibilidade:

Integração com Grafana:

Esses recursos complementam o guia e servem como base para aprofundar em Zabbix 7.x, discovery, HA, API e integrações com Grafana e outros stacks de observabilidade.

SonarQube — Qualidade e Segurança de Código

Guia técnico sobre SonarQube Community e Developer Edition: arquitetura, Docker, análise de código, Quality Gates/Profiles, CI/CD, PR decoration, SonarCloud, métricas de dívida técnica, segurança e comparativo com outras ferramentas SAST.

Processo & Gestão

Metodologias ágeis, gestão de projetos e processos de desenvolvimento.

On this page

Arquitetura do Zabbix 7.xInstalação e configuração inicialHosts, host groups, items e tipos de coletaHosts e host groupsItems e tipos de coletaTriggers, expressões e açõesTriggersAlertas e açõesTemplates e template linkingDiscovery: network discovery e low-level discovery (LLD)Network discoveryLow-Level Discovery (LLD)Mapas de rede e dashboardsZabbix API para automaçãoMonitoramento de cloud, Docker e KubernetesIntegração com GrafanaAlta disponibilidade (HA) do Zabbix Server e ProxyPerformance tuning do banco de dadosComparativo: Zabbix vs Prometheus, Nagios e DatadogZabbix vs PrometheusZabbix vs NagiosZabbix vs DatadogFontes e leituras recomendadas