Agente fica indisponível por 1-2 minutos e volta sozinho: indisponibilidade real ou flapping?

Um host aparecer indisponível no Zabbix e voltar sozinho um minuto depois pode significar várias coisas:

queda real do servidor;
reinício do Agent;
perda de rota;
firewall intermitente;
atraso no Server/Proxy;
timeout pontual;
flapping de comunicação.

Em um log real, o padrão era bem específico.

Repetidamente aparecia algo equivalente a:

1
2
active check configuration update ... started to fail
(ZBX_TCP_READ() timed out)

E aproximadamente um minuto depois:

1
active check configuration update ... is working again

O ciclo se repetiu em vários horários e dias.

Isso não prova a causa da falha. Mas prova que tratar cada evento como “servidor caiu” seria uma interpretação ruim.

Primeiro: o que exatamente falhou? #

O log era de um Agent usando active checks.

Nesse fluxo, o Agent conversa com Server ou Proxy para obter/atualizar sua configuração de checks ativos.

A mensagem:

1
ZBX_TCP_READ() timed out

indica que houve timeout de leitura na comunicação.

Ela não diz, sozinha:

1
2
3
4
firewall bloqueou
server caiu
rede perdeu pacote
agent travou

Essa diferença é o centro do diagnóstico.

A duração do evento é uma pista importante #

No histórico analisado, muitos pares eram próximos de:

1
2
18:29:38  começou a falhar
18:30:38  voltou

ou:

1
2
23:01:11  começou a falhar
23:02:11  voltou

Havia também episódios um pouco maiores.

Quando o padrão se repete e se recupera automaticamente, vale medir:

1
2
3
4
5
quantos episódios por dia?
qual duração mediana?
acontece nos mesmos horários?
outros hosts apresentam o mesmo padrão?
Server/Proxy também apresenta pressão nesse momento?

Sem essa visão, o dashboard pode transformar flapping em uma sequência de incidentes independentes.

Reinício do Agent é outro evento — e deve ser separado #

O mesmo arquivo de log também continha registros explícitos de parada e inicialização do Agent:

1
2
3
Got signal [SIGTERM]
Zabbix Agent stopped
Starting Zabbix Agent

Isso é diferente de um simples timeout de active check.

Portanto eu separaria pelo menos duas classes:

1
2
CLASSE A → processo reiniciou
CLASSE B → processo continuou, mas comunicação teve timeout

Se misturar as duas, pode parecer que o serviço reinicia a cada flapping quando o log não sustenta isso.

O Agent pode estar vivo enquanto a monitoria sofre #

Um teste local ajuda:

1
systemctl status zabbix-agent --no-pager

ou, dependendo da instalação:

1
ps aux | grep '[z]abbix_agent'

Também:

1
ss -lntp | grep 10050

Mas, em active checks, o fato de 10050 estar escutando não prova que o Agent consegue falar com Server/Proxy em 10051.

São fluxos diferentes.

Teste o caminho que o log está reclamando #

A partir do host:

1
getent ahosts zabbix-server.example.com

Depois:

1
nc -vz -w 3 zabbix-server.example.com 10051

Se a falha é intermitente, um teste único saudável também não encerra a investigação.

Pode ser necessário amostrar ao longo do tempo:

1
2
3
4
while sleep 30; do
  date -Is
  nc -vz -w 3 zabbix-server.example.com 10051
done

Em uma coleta operacional, eu registraria stdout/stderr em arquivo com timestamp para correlacionar as falhas depois.

Melhor: correlacionar Server/Proxy no mesmo minuto #

O lado do Agent mostra o sintoma visto pelo cliente da conexão.

Para entender a causa, eu procuraria no Server/Proxy no mesmo período:

1
2
3
4
5
6
7
8
CPU/load
processos busy
queue
cache pressure
logs de conexão
rede
firewall/NAT
reinícios

Se dezenas de Agents registram timeout no mesmo minuto, a hipótese de problema concentrado no Server/Proxy ou caminho comum ganha peso.

Se apenas um host apresenta o padrão, a investigação tende para rede/localidade daquele host.

Isso ainda é hipótese até a correlação comprovar.

`zabbix_get` não testa active checks diretamente #

zabbix_get é útil para testar itens passivos contra um Agent:

1
zabbix_get -s HOST -k agent.ping

Mas não deve ser usado como “prova definitiva” de que o caminho de active checks está saudável.

São sentidos e comportamentos diferentes.

A pergunta precisa combinar com o teste.

Flapping também é problema de observabilidade #

Mesmo que a aplicação esteja funcionando, um monitoramento que alterna estado a cada minuto pode gerar:

alarmes demais;
fadiga de alerta;
incidentes falsos;
automações disparadas sem necessidade;
perda de confiança na monitoria.

Então não basta dizer:

voltou sozinho, ignora.

O objetivo é entender se o flapping representa uma falha curta real de comunicação e definir uma política adequada de trigger.

Trigger deve considerar duração e dependência #

Dependendo do item, pode fazer sentido usar uma janela antes de disparar um incidente crítico.

Por exemplo, em vez de reagir ao primeiro check perdido, considerar múltiplas falhas consecutivas ou tempo mínimo.

A configuração exata depende do SLA e do que está sendo medido.

Não existe um for 2m universal para qualquer trigger.

Um serviço financeiro e uma coleta auxiliar têm tolerâncias diferentes.

Um roteiro de investigação #

1
2
3
4
5
6
7
8
9
1. identificar se houve restart real do Agent
2. separar passive x active checks
3. medir duração dos episódios
4. contar frequência
5. testar DNS/rota/TCP 10051
6. correlacionar Server/Proxy no mesmo minuto
7. comparar outros hosts
8. revisar trigger/recovery expression
9. só então ajustar tolerância de alerta

O que a fonte prova #

O log recuperado mostra:

Zabbix Agent 5.0.x em execução;
diversos episódios de ZBX_TCP_READ() timed out durante atualização de active checks;
recuperação automática registrada como is working again;
muitos episódios com intervalo próximo de um minuto;
reinícios explícitos do Agent em outros momentos, distinguíveis dos timeouts.

A fonte não prova uma causa raiz única para os timeouts.

O hostname original e demais identificadores foram removidos deste artigo.

Checklist #

1
2
3
4
5
6
7
8
9
[ ] processo reiniciou ou não?
[ ] item usa active ou passive check?
[ ] duração do flapping medida
[ ] frequência medida
[ ] DNS validado
[ ] TCP 10051 testado
[ ] Server/Proxy correlacionado
[ ] outros hosts comparados
[ ] trigger revisada sem mascarar outage real

O principal aprendizado #

“Unavailable” é um estado do monitoramento, não uma causa raiz.

Quando o log mostra falha e recuperação repetidas em janelas curtas, o trabalho é descobrir qual parte da comunicação está oscilando e ajustar a observabilidade sem esconder indisponibilidade real.