Logs com timestamp e fáceis de interpretar: RFC 5424 vs. RFC 3164, templates JSON e por que usar UTC

O que é

A RFC 3164, que descreve o protocolo syslog BSD legado, ainda emitido por muitos dispositivos, define uma mensagem como uma parte PRI seguida de um HEADER e de um MSG; o timestamp não tem ano nem fuso horário, e sua precisão é de um segundo. A RFC 5424 a substituiu por um formato estruturado cujo HEADER sempre contém PRI, VERSION e um campo TIMESTAMP, definido como o NILVALUE - ou como FULL-DATE "T" FULL-TIME, derivado explicitamente da RFC 3339, que acrescenta o ano, frações de segundo e um deslocamento de fuso horário explícito (ou Z para UTC). A própria RFC 5424 afirma que o timestamp descrito na RFC 3164 "offers less precision than the timestamp specified in this document" e "also lacks the year and time zone information" (ou seja, tem menos precisão e não traz ano nem fuso horário). É justamente por isso que mensagens que passam de um formato para o outro exigem tratamento especial: converter de 5424 para 3164 significa descartar o ano e o fuso, e converter de 3164 para 5424 significa adivinhar os dois.

O rsyslog pode gerar qualquer um dos estilos por meio de templates internos (RSYSLOG_SyslogProtocol23Format para o estilo 5424, RSYSLOG_TraditionalForwardFormat para o estilo 3164) ou uma estrutura totalmente personalizada: um template do tipo list com option.jsonf="on" e campos property(... format="jsonf") gera as propriedades selecionadas, incluindo timestamps, como um objeto JSON com escape correto, muito mais fácil de ser consumido de forma confiável por um parser ou um agente a jusante do que texto livre.

Por que importa

Um agente ou script que busca timestamps de log com grep ou regex precisa saber, sem adivinhar, qual formato está lendo, que precisão ele tem e qual fuso horário se aplica. Um timestamp no estilo 3164 não tem ano, de modo que uma mensagem registrada perto da virada do ano é realmente ambígua de reconstruir meses depois. Um timestamp no estilo 5424 com deslocamento explícito, ou um campo JSON com uma string ISO 8601/RFC 3339, elimina essa ambiguidade desde a origem.

Como aplicar

• Prefira origens e encaminhadores configurados para saída RFC 5424 em vez da RFC 3164 legada, quando houver essa opção.
• Ao criar um template personalizado do rsyslog para um pipeline de análise de logs, emita os timestamps no formato RFC 3339 com Z ou um deslocamento explícito, e considere um template baseado em jsonf para que os limites dos campos sejam inequívocos.
• Defina o fuso horário dos servidores como UTC (timedatectl set-timezone UTC, como root) ou, no mínimo, registre um deslocamento UTC explícito em cada timestamp, para que a correlação de eventos entre hosts em fusos locais diferentes não exija nenhuma etapa de conversão.
• Ao interpretar logs de terceiros, detecte primeiro o formato (a presença de um ano com 4 dígitos e de um deslocamento ou Z sugere 5424/RFC 3339; um mês de 3 letras sem ano sugere 3164), em vez de presumir um deles.

Armadilhas

• Supor que todas as mensagens "syslog" compartilham o mesmo formato de timestamp; dispositivos com RFC 3164 ainda são comuns em campo.
• Armazenar logs em horário local sem deslocamento, o que torna impossível ordenar corretamente, a posteriori, uma transição de horário de verão ou uma implantação em várias regiões.
• Perder os zeros à esquerda das frações de segundo ao reformatar, algo que o apêndice A.4 da RFC 5424 classifica como um erro de codificação muito comum: .003 escrito como .3 transforma 3 ms em 300 ms.