Resumo

  • timeQuality registra o que a origem afirma saber sobre fuso horário, sincronização e desvio esperado; o coletor não mede o relógio ao receber o campo.
  • syncAccuracy é o limite que a origem espera entre sincronizações. Sua utilidade depende da confiabilidade da fonte de tempo e de uma configuração operacional verificável.

O que ainda estará junto do timestamp quando o log for reaberto?

Logs são consultados muito depois da geração do evento: durante uma investigação, uma auditoria ou a reconstrução de uma sequência entre serviços. A hora gravada costuma sobreviver à migração de plataforma. As condições que permitiriam avaliá-la, porém, podem ficar em outro sistema, em um histórico de configuração ou em uma memória operacional que não foi arquivada. A RFC 5424 oferece um lugar no próprio registro para uma parte desse contexto: o elemento opcional timeQuality.

A seção 6.2.3 define o campo TIMESTAMP em uma forma limitada da RFC 3339 e recomenda frações de segundo quando a precisão e o desempenho do relógio permitem. A seção 7.1 separa da representação do instante a declaração da origem sobre sua noção de horário do sistema. Essa declaração pode acompanhar o evento em trânsito, mas continua sendo uma afirmação feita pelo emissor — não uma leitura independente feita pelo receptor.

A seção 7.1 recomenda escrever timeQuality quando a origem não está corretamente sincronizada a uma fonte externa confiável ou não sabe se as informações de fuso horário estão corretas. Seus parâmetros continuam opcionais: é possível sinalizar uma limitação sem preencher todos os detalhes.

Essa separação evita que a quantidade de casas decimais seja confundida com uma garantia de exatidão.

Três perguntas, três parâmetros

tzKnown informa se a origem conhece as informações de fuso horário usadas por seu relógio. Isso não é o mesmo que emitir o timestamp em UTC. A RFC diz que o fuso pode ser conhecido mesmo quando a hora aparece com Z. Também não permite a inferência inversa: um valor em UTC não prova que a configuração local seja compreendida. O apêndice A.7 recomenda cautela e aponta a configuração ou verificação administrativa como base para declarar o fuso conhecido.

isSynced informa se a origem se considera sincronizada a uma fonte externa confiável, como NTP. Um coletor que lê esse parâmetro não consulta a fonte e não confirma o estado. O campo comunica o que o emissor reporta; o estado observado do serviço de tempo precisa ser obtido por outra telemetria.

syncAccuracy é um número inteiro em microssegundos para o desvio máximo que a origem estima entre intervalos de sincronização. Ele não pode ser incluído quando isSynced="0". O exemplo da RFC usa 60.000.000 microssegundos, ou 60 segundos, e mostra que um evento marcado às 09:00 poderia corresponder a um intervalo entre 08:59 e 09:01. É uma forma de interpretar a expectativa do originador, não o resultado de uma medição feita por terceiro.

A RFC recomenda registrar esse limite apenas quando a origem conhece a confiabilidade da fonte de tempo. Segundo o apêndice, esse conhecimento normalmente depende de configuração do operador; a norma alerta contra uma aparência enganosa de precisão. Para o receptor, há uma consequência explícita: com isSynced="1" e sem syncAccuracy, um coletor ou relay pode assumir que a hora é precisa o suficiente para ser considerada correta. Isso define como interpretar a mensagem, não como comprovar o relógio.

A preservação é uma decisão de arquitetura

O registro da IANA classifica timeQuality, tzKnown, isSynced e syncAccuracy como opcionais. A plataforma deve aceitar mensagens que os tragam e mensagens que não os tragam. A falta dos campos não demonstra que o horário esteja errado; apenas limita o que o registro permite saber sobre sua qualidade.

Uma transformação que retenha o timestamp e descarte os dados estruturados ao redor cria um problema de arquivo. O analista futuro encontrará uma hora com aparência precisa, mas sem a ressalva que a origem enviou. Preservar o elemento é necessário. Também convém manter um vínculo recuperável com o host de origem, o responsável pela configuração e os registros de sincronização do período.

A RFC 8633 recomenda monitorar fontes de tempo e instâncias NTP e detectar servidores fora de sincronismo. Essa prática pode sustentar uma declaração operacional, mas não demonstra o que um sistema específico faz. As fontes consultadas tampouco medem adoção, incidentes ou taxas de erro em ambientes reais.

A mensagem transporta uma alegação delimitada

timeQuality é evidência do estado que a origem declara para seu relógio. Ajuda quem recebe a preservar incerteza em vez de tratar todos os timestamps como equivalentes. Não autentica o evento, não estabelece por si só causalidade entre máquinas e não transforma a declaração da origem em verificação independente.

A nota de Heng Lu sobre a primazia do código em execução serve aqui apenas como enquadramento editorial: o rótulo escrito não substitui o que o sistema implantado valida e executa. A RFC define a forma da declaração; sua sustentação está na configuração e no monitoramento em operação no emissor. Um coletor pode guardar o limite da evidência, mas não pode criá-lo retrospectivamente.

Fontes