O log de cada máquina mostra a parte do problema que ela observou. A reunião dos registros de várias origens ajuda a reconstruir a ocorrência, desde que a ligação preserve a origem, os identificadores e as incertezas de tempo, porque a simples ordenação de linhas de arquivos diferentes não estabelece uma causa.
A pergunta que a linha do tempo responde
A linha do tempo começa pelo que precisa esclarecer: se o serviço estava disponível, em qual etapa a chamada falhou ou se uma operação foi concluída. Cada pergunta pode exigir origens diferentes. Para uma venda sem confirmação, o reinício do servidor é relevante, mas não substitui a verificação da situação da venda.
Um inventário curto organiza o material: a máquina, o arquivo ou o canal, o período disponível, o fuso e a forma de coleta de cada origem, com os arquivos de rotação que cobrem a operação. Uma origem não coletada, ou que começa depois da falha, fica marcada como lacuna. Uma cópia estática serve à análise daquele material, e o acompanhamento de outra ocorrência observa o arquivo ou o canal ativo.
A ligação dos registros pelo contexto
A ligação procura uma chave que acompanhe a operação, como o pedido, o documento, a transação, o lote ou o identificador de rastreio, e separa a operação, a etapa e a tentativa. O mesmo pedido pode gerar uma consulta, uma confirmação e uma repetição, que pertencem ao pedido sem serem a mesma chamada.
Quando cada componente cria a própria chave, a leitura procura o registro que liga as duas. O pedido PED-0042 pode aparecer ligado à requisição REQ-0187 em uma mensagem do cliente, e, sem essa ligação, horários próximos oferecem só uma associação provável. Uma numeração que se repete por filial ou por terminal precisa desse contexto para não cruzar pedidos diferentes.
Nos sistemas instrumentados, um TraceId acompanha o percurso entre os componentes, e um SpanId identifica uma etapa. Eles ajudam quando o contexto é propagado e registrado, mas não são campos obrigatórios de todos os arquivos nem provam que todas as etapas foram coletadas.
O horário original e a precisão declarada
O horário original fica preservado, ao lado de uma coluna de comparação, como o UTC ou o -03:00. A leitura confirma se o campo representa o evento na origem ou a chegada ao coletor, e a conversão do fuso não corrige um relógio adiantado, um atraso de transmissão nem uma gravação adiada.
Se os relógios não têm um alinhamento conhecido no período, uma diferença de dois segundos entre máquinas pode não permitir a ordenação dos eventos, e a ordem fica declarada como incerta. Dentro de uma operação, os identificadores de etapa, de tentativa e de sequência sustentam uma relação mesmo quando a comparação dos relógios não basta.
Uma verificação de sincronismo feita hoje descreve o estado atual. Para uma falha antiga, a evidência vem daquele período, como os registros de ajuste do relógio ou uma referência de tempo em comum, e qualquer correção estimada fica separada do registro original.
Uma linha do tempo limitada
Na manhã de 2 de outubro, a matriz informa que as vendas da filial 01 do dia anterior não aparecem no relatório. Os fusos das origens estão confirmados, mas não há histórico da precisão dos relógios. O serviço de sincronização do servidor da loja registra o envio na hora local, e o servidor geral, na matriz, registra os horários em UTC:
2026-10-01 22:00:04 -03:00 servidor-loja lote=LOTE-0815 vendas=312 enviado2026-10-02T01:00:06Z servidor-geral lote=LOTE-0815 recebido2026-10-02T01:00:09Z servidor-geral lote=LOTE-0815 rejeitado motivo=versao_layout
A conversão das linhas do servidor geral para -03:00 dá 22:00:06 e 22:00:09 do dia 1º, e a data muda na conversão. O identificador do lote liga as três linhas, e a sequência fica clara: a loja enviou o lote, e a matriz recebeu e recusou pelo layout. A diferença de dois segundos entre o envio e o recebimento, porém, não mede o tempo de transmissão, porque os relógios das duas máquinas não têm um alinhamento conhecido.
O log da loja não mostra o retorno da recusa, e essa falta também é uma informação: a loja pode não ter recebido a resposta ou pode não registrá-la. O material mostra o que aconteceu com o lote, e não por que a versão do layout era diferente. A investigação segue para a versão do serviço de sincronização na loja, para os lotes de outras filiais na mesma noite e para o procedimento de reenvio previsto pela matriz, com a conferência de que a recusa não aplicou nenhuma das 312 vendas, para que o reenvio não as duplique.
A conclusão verificável
Cada afirmação indica o registro que a sustenta, e a análise separa a observação, a associação provável e a causa confirmada. O registro também diz quais resultados do teste seguinte mudariam a decisão: uma versão do serviço diferente da esperada leva à atualização pelo procedimento da instalação, e a versão certa leva a investigação para o lado da matriz.
Uma linha do tempo útil pode terminar com uma lacuna. Uma frase como "lote recusado pela matriz por versão de layout, causa da diferença de versão ainda em verificação" permite continuar o atendimento sem uma explicação inventada.
No suporte
Antes de juntar as origens, convém ligar a operação, a tentativa, o terminal e o destino. O horário original, a conversão e os limites dos relógios ficam preservados, e a disponibilidade, o resultado da operação e a causa são investigados como perguntas com evidências próprias.
Para guardar
- Cada origem observa uma parte do problema e tem a própria cobertura.
- Os identificadores e os registros de ligação sustentam a correlação, e a proximidade no tempo ajuda, mas não basta.
- A conversão do fuso e a correção do relógio são ações diferentes, e a conversão pode mudar a data.
- Sem a precisão conhecida, a ordem entre as origens fica declarada como incerta.
- A volta do serviço ou uma recusa registrada não confirmam, sozinhas, a causa nem o resultado das operações.
Duas origens mostram erros separados por dois segundos, com os fusos já convertidos. É possível afirmar qual veio primeiro?
Só se a precisão dos relógios e o significado dos horários permitirem essa comparação. Um registro pode trazer o horário da coleta ou vir de um relógio desalinhado. Os identificadores e a sequência ajudam a ligar as etapas, e, sem evidência de tempo suficiente, a ordem entre as origens continua incerta.
O MySQL voltou a aceitar conexões depois de um reinício. A venda cuja resposta se perdeu está resolvida?
Não. A disponibilidade posterior do serviço não confirma o efeito da tentativa anterior. A venda e os efeitos relacionados são consultados pelo procedimento do sistema, o resultado é ligado à tentativa, e só então a reconciliação ou a retomada é decidida.