Toda mensagem syslog começa com o mesmo <PRI>, mas o texto depois dele vem em dois formatos bem diferentes, e muita dor de parsing vem de não saber qual você tem.

RFC 3164: o formato BSD (Distribuição de Software de Berkeley, do inglês Berkeley Software Distribution)

O formato original foi documentado, depois do fato, na RFC 3164. Ele é solto: depois do (valor de prioridade, do inglês priority value) vem um timestamp como Oct 1 14:23:05, um hostname, e então uma tag e mensagem em forma livre. As fraquezas são reais:

  • O timestamp não tem ano nem timezone, então uma mensagem armazenada é ambígua sobre quando de fato aconteceu.
  • A estrutura é apenas frouxamente especificada, então a fronteira entre a tag e a mensagem varia conforme o remetente.
  • Ele precede qualquer noção de campos estruturados, então tudo de interessante fica enterrado em texto livre.

Ele ainda é extremamente comum em equipamentos de rede e sistemas mais antigos, que é por que os parsers precisam lidar com ele, esquisitices e tudo.

RFC 5424: o formato moderno

A RFC 5424 o substituiu por uma estrutura precisa e parseável: <PRI> então um número de versão, um timestamp ISO 8601 com timezone e frações de segundo, então hostname, app-name, procid e msgid como campos distintos, structured data opcional (elementos tipados de chave-valor entre colchetes), e por fim a mensagem, que é UTF-8 com um byte-order mark quando necessário. Os ganhos importam: tempo sem ambiguidade, campos claros, structured data legível por máquina e Unicode adequado.

Distinguindo-os e por que importa

O indício mais rápido está logo depois do PRI: um dígito e um espaço (a versão, quase sempre 1) significa RFC 5424; um mês de três letras significa RFC 3164. Isso importa porque os dois carregam informações diferentes. Uma mensagem 3164 não consegue lhe dizer o ano ou o timezone, então um coletor precisa adicioná-los e pode errar em um reboot ou uma mudança de fuso. Uma mensagem 5424 carrega isso por si. Quando timestamps parecem errados ou campos caem no lugar errado, a incompatibilidade de formato normalmente é o porquê, e implantações modernas preferem 5424 justamente para evitar essa ambiguidade.

Dois formatos, e parsers que adivinham entre eles

RFC 3164 e RFC 5424 são diferentes o bastante para quebrar um parser e parecidos o bastante para que um aceite o outro e produza besteira — um timestamp lido como hostname, um bloco de dados estruturados tratado como texto livre.

O risco prático é que a análise no formato errado normalmente tem sucesso. Campos caem nas colunas erradas, a mensagem é indexada, e a busca que a encontraria procura num campo que nunca recebeu o valor. O evento está presente e não é localizável — o que, durante uma investigação, é pior que ausente.

Fixe o formato explicitamente nas duas pontas em vez de confiar na detecção, e verifique buscando por um evento de teste conhecido, não confirmando que linhas estão chegando.