Logging central que resiste a uma revisão de incidente

O verdadeiro teste do logging central não é se as mensagens chegam numa tarde sossegada. É se, na manhã seguinte a algo ter corrido mal, consegue montar em poucos minutos uma cronologia completa e corretamente ordenada entre routers, firewalls, storage e servidores. Isso exige um pipeline construído para o efeito. É assim que construímos o nosso em Graylog, e é isto que pode copiar para o seu.

Comece pela pergunta que vai fazer

Cada decisão de desenho num pipeline de logging deve servir uma única pergunta: «o que aconteceu, em todo o lado, entre estes dois instantes?» Essa pergunta falha de quatro formas previsíveis. Faltam mensagens para parte da janela. O mesmo dispositivo aparece com vários nomes, por isso uma pesquisa encontra só parte do seu histórico. Os relógios discordam, por isso os eventos caem na ordem errada. Ou está tudo num único monte indiferenciado, por isso as linhas importantes ficam soterradas. Cada secção abaixo remove uma dessas falhas.

Reencaminhe de forma fiável, e guarde em buffer no disco

O syslog clássico sobre UDP é «enviar e esquecer»: o emissor nunca fica a saber se alguma coisa recebeu a mensagem. Para servidores preferimos reencaminhamento por TCP com uma fila assistida por disco, para que um reinício do collector ou uma falha momentânea de rede atrase os logs em vez de os perder. Uma ação rsyslog mínima:

action(type="omfwd" target="<collector>" port="514" protocol="tcp"
       template="RSYSLOG_SyslogProtocol23Format"
       queue.type="LinkedList" queue.filename="fwd_central"
       queue.maxDiskSpace="1g" queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

O template envia mensagens estruturadas RFC 5424 com timestamp completo e hostname. A fila guarda as mensagens não entregues em disco e volta a tentar até o collector regressar. Valide com rsyslogd -N1 antes de reiniciar o serviço.

Os equipamentos de rede estão normalmente limitados a syslog simples, por isso para eles a proteção é outra: envie para o collector a partir de um endereço de origem e de uma routing instance que o consigam sempre alcançar, e verifique esse caminho sempre que o encaminhamento do equipamento mudar.

Dê a cada dispositivo exatamente um nome

Os fabricantes discordam sobre o que vai no cabeçalho syslog. Alguns equipamentos omitem o seu próprio hostname, alguns enviam um nome curto, alguns enviam um endereço, e o mesmo equipamento pode mudar de formato depois de uma atualização de software. Se o collector guardar o que chega, um router acaba espalhado por três nomes de origem, e uma pesquisa por ele devolve um terço do seu histórico.

Corrigimos isso à entrada. Uma regra de pipeline no Graylog reescreve a origem de cada mensagem para um nome canónico de dispositivo, com uma tabela de consulta indexada pelo endereço emissor:

rule "normalise source name"
when
  has_field("gl2_remote_ip")
then
  let name = lookup_value("device_names", to_string($message.gl2_remote_ip));
  set_field("source", name);
end

Mantenha a tabela de consulta a par do seu inventário, para que um dispositivo novo receba o seu nome limpo no dia em que é registado, não no dia em que alguém repara que falta.

Acerte os relógios

Todos os dispositivos devem registar em UTC ou transportar um desvio explícito. Misturar hora local e UTC entre dispositivos é a forma clássica de fazer um incidente parecer ter acontecido pela ordem errada. Duas verificações rápidas num host Linux:

chronyc tracking      # offset from the reference, should be tiny
timedatectl           # time zone and whether NTP is synchronised

Em equipamento de rede, verifique o comando de estado equivalente e certifique-se de que o timestamp do logging inclui a data, os milissegundos e o fuso horário. Segundos não chegam quando dois routers reagem ao mesmo evento.

Encaminhe as mensagens para streams por função

Uma única torrente é ilegível. Encaminhamos as mensagens para streams por função: core routing, fabric do datacenter, firewalls, storage, hosts. Como cada origem tem agora um nome limpo, o encaminhamento é uma questão de fazer corresponder nomes ou um campo de função definido pelo mesmo pipeline. Cada stream tem como leitores naturais as pessoas que operam esses sistemas, e cada um pode ter a sua própria retenção, desenhada para corresponder ao que o serviço e qualquer auditor exigem.

Alarme no problema, e no silêncio

Alarme no que antecede o problema

Com os logs limpos e no sítio certo, as linhas valiosas devem chegar a uma pessoa enquanto ainda importam. Definimos eventos para as mensagens que tendem a anteceder uma interrupção: uma sessão BGP a cair, uma ligação em flap, o BFD a declarar um caminho morto, sessões de encriptação em rotação num backbone, uma falha de hardware, um erro de fibre channel num fabric de storage, um pool de endereços a esgotar-se. Vão para o engenheiro de prevenção no chat de operações à medida que acontecem, para que o log se torne um aviso antecipado em vez de uma autópsia.

Alarme também no silêncio

Um dispositivo que deixa de enviar parece exatamente um dispositivo que não tem nada a dizer. Por isso, alarme na ausência: um evento que dispara quando uma origem que normalmente fala está em silêncio há mais tempo do que alguma vez esteve. Aos dispositivos naturalmente silenciosos, dê-lhes algo a dizer, como uma linha de heartbeat escrita por um timer de hora a hora, para que o silêncio se torne um sinal. Depois de qualquer alteração que possa perturbar o caminho, envie uma mensagem de teste e encontre-a na outra ponta. A nossa equipa de rede descreve essa verificação, e o resto de um autoteste de monitorização, em A sua monitorização também é um sistema: teste o caminho, não o dashboard.

Verifique o seu próprio pipeline

• Algum dispositivo aparece com mais do que um nome de origem?
• O que acontece aos logs de um servidor se o collector estiver em baixo durante dez minutos?
• Todos os relógios estão sincronizados com as mesmas fontes, com fusos horários explícitos?
• Consegue encontrar as mensagens de todas as firewalls num único stream?
• Existe um alarme para uma origem que se calou?

Se quer logs em que possa confiar durante uma revisão de incidente, teremos todo o gosto em ajudar a construir o pipeline e a testá-lo. Fale com um engenheiro

Related

Relacionados: Telemetria de rede e energia, logging, deteção de DDoS · Monitorização da frota e encaminhamento de alarmes