quinta-feira, 23 de outubro de 2025

Zabbix — da Migração ao Fine-Tuning - capítulo 8

Auditoria invisível: o Zabbix monitorando a si mesmo

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Auditoria invisível: o Zabbix monitorando a si mesmo

Capítulo 8 da série “Zabbix — da Migração ao Fine-Tuning” no Sysadmin Urbano.

Depois de integrar, automatizar e distribuir, falta apenas um passo para fechar o ciclo: ensinar o Zabbix a monitorar a si mesmo. Afinal, quem monitora o monitoramento?

“Todo sistema crítico precisa de autoconsciência: um Zabbix sem auditoria é um médico que nunca mede sua própria pressão.”

1) Itens internos: os sensores do próprio Zabbix

O Zabbix possui chaves internas que permitem medir a saúde de seus próprios processos e bancos de dados. Esses itens não exigem agentes nem proxies — são nativos.

zabbix[queue]
zabbix[process,dbsyncer,avg,busy]
zabbix[process,poller,avg,busy]
zabbix[cache,usage,history]
zabbix[cache,usage,trends]
zabbix[cache,buffer,free,pct]
zabbix[triggers,enabled]
zabbix[items,not_supported]
zabbix[proxy,,lastaccess]

Essas chaves mostram tudo — do uso de memória cache à fila de itens não processados.


2) Criando um template de auditoria

Crie um novo template chamado Template Audit — Zabbix Self Check e adicione os seguintes itens:

  • zabbix[queue] → Tipo: Zabbix internal → Unidade: s → Intervalo: 60s
  • zabbix[items,not_supported] → Tipo: Zabbix internal → Intervalo: 300s
  • zabbix[cache,usage,history] → Unidade: % → Intervalo: 60s
  • zabbix[process,dbsyncer,avg,busy] → Unidade: % → Intervalo: 60s

Com isso, você passa a ter uma visão clara de como o Zabbix está se comportando internamente.


3) Criando triggers inteligentes

Essas triggers ajudam a detectar anomalias antes que o sistema pare completamente:

{Zabbix server:zabbix[queue].avg(5m)}>10
  → Fila de processamento atrasada

{Zabbix server:zabbix[items,not_supported].avg(10m)}>50
  → Muitos itens não suportados

{Zabbix server:zabbix[cache,usage,history].avg(5m)}>90
  → Cache de histórico quase cheio

{Zabbix server:zabbix[process,dbsyncer,avg,busy].avg(5m)}>80
  → Processos de sincronização sobrecarregados

Essas triggers permitem agir proativamente — antes que o banco trave, o cache sature ou a fila exploda.


4) Dashboard de saúde do Zabbix

Monte um dashboard interno com quatro widgets principais:

  • Gráfico de fila de processamento (zabbix[queue])
  • Uso de cache de histórico (zabbix[cache,usage,history])
  • Processos DB Syncer (zabbix[process,dbsyncer,avg,busy])
  • Itens não suportados (zabbix[items,not_supported])

Isso cria uma “sala de controle” visual, onde é possível perceber desvios em tempo real — e reagir antes que o impacto apareça.


5) Auditoria do banco de dados

Adicione uma checagem SQL simples para validar acessibilidade e latência do banco:

#!/usr/bin/env bash
MYSQL="mysql --defaults-extra-file=$HOME/.my.cnf --batch --skip-column-names"
T1=$(date +%s%3N)
$MYSQL -e "SELECT 1" >/dev/null 2>&1
T2=$(date +%s%3N)
echo $((T2 - T1))

O resultado (em milissegundos) pode ser enviado ao Zabbix via zabbix_sender para compor o painel de auditoria.


6) Verificação de proxies

Para ambientes distribuídos, é essencial garantir que todos os proxies estejam sincronizando corretamente:

zabbix_get -s proxy01 -k "proxy.ping"
zabbix_get -s proxy02 -k "proxy.history.lastsync"
zabbix_get -s proxy03 -k "proxy.offlinebuffer.size"

Esses testes simples confirmam se cada proxy ainda “fala” com o servidor — e há quanto tempo o fez pela última vez.


7) Auditoria invisível via API

Com a API do Zabbix, você pode criar uma rotina que compare configurações críticas (como templates, usuários e hosts ativos) e alerte em caso de discrepância.

#!/usr/bin/env python3
import requests

ZABBIX_URL = "http://zabbix.local/api_jsonrpc.php"
USER = "Admin"
PASSWORD = "zabbix"

def zbx_request(method, params):
    payload = {"jsonrpc": "2.0", "method": method, "params": params, "id": 1}
    r = requests.post(ZABBIX_URL, json=payload)
    return r.json()["result"]

auth = zbx_request("user.login", {"user": USER, "password": PASSWORD})
users = zbx_request("user.get", {"output": ["alias", "type"], "auth": auth, "id": 2})

if any(u["type"] == "3" for u in users):
    print("Há usuários com privilégios de Super Admin — revisar!")

Esse tipo de auditoria preventiva evita surpresas de segurança e inconsistências administrativas.


8) Boas práticas

  • Mantenha todos os itens internos em um template dedicado e documentado.
  • Use triggers silenciosas (com prioridade “Information”) para alertas não críticos.
  • Adicione verificações de auditoria também em proxies.
  • Armazene o resultado das checagens em dashboards consolidados.
  • Revise periodicamente os thresholds das triggers.

9) Conclusão

O Zabbix pode — e deve — ser o primeiro a saber quando algo está errado. Ao se monitorar, ele se torna autossuficiente, capaz de detectar lentidão, falhas internas e anomalias operacionais antes que alguém perceba.

Auditar o próprio sistema é o estágio final da maturidade em monitoração: quando o Zabbix deixa de ser apenas uma ferramenta e passa a ser uma consciência operacional.


Sobre o Sysadmin Urbano

O Sysadmin Urbano nasceu da vivência real no front das operações de infraestrutura moderna. Aqui falamos de servidores, containers, automação, boas práticas e também dos desafios invisíveis da rotina de quem mantém sistemas vivos. Sem fórmulas mágicas, sem tutoriais pela metade — apenas conteúdo prático, direto e feito para quem sabe que a TI é tanto técnica quanto sobrevivência.

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

Nenhum comentário:

Postar um comentário