A sua monitorização também é um sistema: teste o caminho, não o dashboard

Um ecrã de monitorização silencioso tem dois significados possíveis: está tudo bem, ou a monitorização não consegue ver. Só pelo ecrã não se distingue qual dos dois. Toda a stack de monitorização é uma cadeia de dispositivos, agents, collectors, regras e canais de notificação, e cada elo pode falhar sem levantar um alarme próprio. Este artigo é sobre como provar que a cadeia funciona, de forma rotineira, antes do dia em que for precisa.

O silêncio não é evidência

A maioria dos desenhos de monitorização verifica cuidadosamente as coisas monitorizadas e dá a própria monitorização como garantida. Um switch está configurado para enviar syslog, logo presume-se que os logs chegam. Existe uma regra de alarme, logo presume-se que uma notificação chega a alguém. Há uma tarefa de backup agendada, logo presume-se que existe uma cópia da configuração. Nenhuma dessas presunções é uma medição.

Os pontos onde esta cadeia normalmente parte são banais: uma interface de origem ou routing instance de logging que não alcança o collector, uma regra de firewall pelo meio, um input do collector que foi reconfigurado, uma integração de notificações cujo token expirou, um filtro de severidade que exclui silenciosamente o tipo de evento que interessa. Nenhum destes faz um dispositivo parecer doente a partir da sua própria linha de comandos.

Verificação um: cada dispositivo está mesmo a ser ouvido?

A perspetiva do dispositivo (show logging lista um servidor e diz que está ativo) é uma afirmação. A perspetiva do collector é a evidência. Inverta a pergunta e questione o collector: quando foi a última vez que cada dispositivo enviou alguma coisa?

No Graylog, uma pesquisa agrupada por source sobre o último dia mostra todos os dispositivos que falaram. Compare essa lista com o inventário, e tudo o que faltar é a sua descoberta. Um teste simples de ponta a ponta, a partir do próprio dispositivo, remove qualquer dúvida. Em Cisco IOS e NX-OS, gere uma mensagem inofensiva e procure-a no collector em segundos:

send log 6 "monitoring path test from this device"

Num host Linux:

logger -p user.notice "monitoring path test from $(hostname)"

Se a mensagem não aparecer, siga o caminho por ordem: endereço de origem e routing instance usados para o logging, alcance do collector a partir dessa origem, qualquer firewall pelo meio, e depois o input e as stream rules do collector.

Faça a mesma comparação para os backups de configuração. Um dispositivo cuja última configuração guardada tem semanas tem um caminho de backup partido, mesmo que nunca nada tenha dado erro.

Verificação dois: um alarme chega a um humano?

Dispare de propósito um alarme real através de toda a cadeia: um trigger de teste, um item fictício que ultrapassa um limiar, ou uma assinatura de log que injeta. Confirme que a notificação chega ao canal que os engenheiros realmente leem, com a severidade certa, dentro do tempo esperado. Faça-o depois de qualquer alteração à própria plataforma de monitorização, e de forma agendada mesmo quando nada mudou, porque os tokens expiram e as integrações desviam-se.

No Zabbix, um item de teste num host monitorizado mais um trigger na severidade com que notifica é suficiente. Envie um valor e veja-o viajar:

zabbix_sender -z <zabbix-server> -s "<host>" -k monitoring.selftest -o 1

Depois confirme três coisas: o problema apareceu, a notificação foi entregue, e a recuperação foi entregue quando repôs o valor.

Verificação três: as severidades são honestas?

Reveja que eventos chegam a uma pessoa e quais não chegam. Uma lista curta e explícita de assinaturas que notificam sempre (routing neighbour down, link down, BFD down, falhas de crypto VPN, avarias de alimentação, ventoinhas e temperatura, erros da rede de storage, tabelas de estado de firewall perto do limite) é mais fácil de defender do que um limiar que alguém definiu há anos.

Uma segunda opinião ajuda aqui. As regras filtram primeiro o ruído conhecido, e depois tudo o que sobra é analisado em tempo real por modelos de IA nas nossas próprias GPU NVIDIA A100, dentro do nosso datacenter. A análise lê um alarme juntamente com o seu histórico recente e os eventos relacionados e oferece aos engenheiros uma segunda opinião sobre o que provavelmente se passa. Os dados dos alarmes nunca saem da nossa infraestrutura, e o engenheiro continua a ser quem decide.

Verificação quatro: olhe de fora

Toda a perspetiva a partir de dentro da sua rede partilha os pontos cegos da sua rede. Uma plataforma de medição global como o RIPE Atlas, com um anchor ou probes a medir na sua direção, mostra como lugares reais da internet o alcançam: latência, perdas e alterações de percurso. Quando um carrier faz manutenção, a perspetiva exterior diz-lhe quanto tempo demorou a reconvergência e se alguém poderia ter reparado, algo que nenhum contador interno consegue.

Para circuitos privados, uma probe dedicada em cada ponta a medir latência, jitter e throughput em ambas as direções a cada minuto, com os dados guardados permanentemente, transforma qualquer conversa com um carrier de opinião em dados. Exclua o tráfego da probe das estatísticas do próprio circuito, para que a evidência fique limpa.

Verificação cinco: faça varrimentos quando nada está errado

Corra varrimentos de saúde read-only de forma agendada, não apenas depois de um alarme. Os parâmetros ambientais, o estado do routing e do overlay, a consistência da redundância entre pares, os níveis das óticas e os contadores de erros das interfaces mudam devagar, e a mudança lenta é exatamente o que os alarmes por limiar deixam escapar. Uma ótica a deslizar para o seu limite inferior de luz é uma substituição calma esta semana ou uma indisponibilidade no próximo mês.

A lista de autoverificação da sua monitorização

• Consegue listar todos os dispositivos que não enviaram um log no último dia?
• Consegue listar todos os dispositivos cuja configuração guardada é mais antiga do que a sua última alteração?
• Quando foi a última vez que disparou um alarme real de ponta a ponta, e chegou?
• As severidades que notificam uma pessoa correspondem a uma lista escrita?
• Vê a sua rede de fora, continuamente?
• Faz varrimentos quando não se sabe de nada errado?

Monitorizamos a nossa rede com Zabbix, Graylog, Observium e um anchor RIPE Atlas, e corremos estas verificações sobre ela de forma agendada. Se quer um fornecedor que responde com medições, ou ajuda para testar a sua própria cadeia, fale connosco.

Fale com um engenheiro

Relacionados: Monitorização de rede e evidências · Como alteramos as coisas: disciplina de alterações de rede · Rede própria: dois ASN, vários carriers, peering