↓Pular para o conteúdo principal
  1. blog/
ARTIGO TÉCNICO

Os external checks de Zabbix que eu realmente uso em produção

Catálogo de scripts de checagem externa usados em produção — expiração de domínio e certificado SSL, configuração de storage errada detectada via SSH, atualização de pacote pendente — cada um com o porquê e o mapeamento de retorno no Zabbix.

·3 minutos

Por que external check em vez de agente #

Nem toda métrica cabe num UserParameter de agente local. Expiração de domínio, certificado SSL de um serviço de terceiro, configuração incorreta detectada via SSH remoto — tudo isso é mais simples como external check, rodando de fora, sem precisar instalar nada no alvo.


Expiração — domínio e certificado, os dois mordem igual #

1
2
3
4
5
6
# dias até o domínio expirar
CheckDomainExpire.sh[{HOST.HOST}]   # whois + grep + date, Numeric, unidade "dias"

# dias até o certificado SSL expirar
zext_ssl_cert.sh[-d,{HOST.HOST},443]    # dias restantes
zext_ssl_cert.sh[-i,{HOST.HOST},443]    # emissor do certificado (Character)

O segundo (zext_ssl_cert.sh) é a versão evoluída de um check SSL mais simples que existia antes — suporta SNI diferente do host e devolve dois itens (dias + emissor) em vez de só o número. Certificado expirado é sempre incidente evitável; o check existe pra virar alerta com antecedência, não pra descobrir no dia que o site já está fora do ar.


Detectar configuração errada via SSH, sem agente #

1
2
# CheckS3Endpoint.sh — lógica invertida de propósito
# 0 = OK, 1 = problema encontrado, 2 = erro de SSH

Conecta via SSH com usuário dedicado e faz grep no .env remoto procurando storage configurado errado (local ou provider errado em vez do esperado). A lógica de retorno é invertida (0 = tudo bem) só porque faz mais sentido pro caso de uso: o Zabbix dispara ação quando o valor muda de 0 pra qualquer coisa diferente de zero — problema encontrado vira 1, não zero.


Atualização de pacote pendente, detectando o SO primeiro #

1
2
CheckLinuxUpdates.sh[{HOST.IP}]
# 0=Atualizado, 1=Pendentes, 2=Erro/Não suportado

Conecta via SSH, detecta a distro (Debian, RHEL, Arch) e usa o gerenciador de pacote nativo de cada uma — um único check cobrindo frota heterogênea, sem precisar de um script por família de SO.


Health check HTTP, o mais simples de todos #

1
2
CheckApiEnterprise.sh[{HOST.HOST}]
# curl -s -o /dev/null -w "%{http_code}" https://$1/status

Às vezes o check certo é mesmo o mais simples possível — só o código HTTP de um endpoint de status, sem parsing extra, sem lógica condicional. Complexidade desnecessária num check é só mais uma coisa que pode quebrar o próprio monitoramento.


O padrão comum #

Todo check aqui devolve um tipo de dado que o Zabbix entende nativamente (Numeric pra threshold/trigger, Character pra texto informativo como o emissor do certificado) e documenta explicitamente o mapeamento de retorno — porque um script que devolve “1” sem dizer se isso é bom ou ruim é um script que só o autor original consegue debugar.


Tecnologias #

Bash · Zabbix (external checks) · SSH · whois · openssl

TEM UM CENÁRIO PARECIDO?

Me chama.

Manda o contexto, os sintomas e o que já foi testado. Bora organizar as evidências antes de sair mexendo.

Falar com Castro →
Sem enrolação. Com evidência.