Resposta direta
A contratação precisa tratar o log como parte do escopo, não como sobra técnica. O contrato define quais eventos entram no registro, quantos níveis de severidade existem e o que cada nível dispara: abertura de chamado, alerta para plantão ou apenas arquivo. Também fixa retenção, campos obrigatórios e quem responde quando o log não permite identificar a causa. O critério de aceite é prático: provocar uma falha conhecida e verificar se o registro aponta origem, horário, identificador e efeito. Log sem nível de erro transfere ao time operacional uma investigação que deveria estar resolvida na origem.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o log como item de contrato e critério de aceite, com foco em severidade, retenção e responsabilidade definida.
O que o nível de erro precisa distinguir
Severidade não é o mesmo que tipo de falha. Um registro rejeitado por campo obrigatório vazio e uma indisponibilidade do sistema de destino chegam como erro, mas pedem respostas diferentes. O primeiro exige correção do dado na origem. O segundo exige reprocessamento e verificação de duplicidade.
Vale separar três situações: erro que impede a gravação, erro que grava com ressalva e evento apenas informativo. Cada uma tem destino próprio. Sem essa separação, o time trata tudo como urgente ou não trata nada.
Cláusulas que mudam a rotina de operação
Retenção, formato e acesso definem se o log serve para investigar. Registro guardado por tempo insuficiente não ajuda quando a divergência aparece semanas depois. O contrato precisa dizer onde o log fica, quem consulta e em quanto tempo a consulta é respondida.
Outro ponto é a mudança de esquema. Campo removido ou renomeado sem aviso quebra a leitura automática. Fornecedor e área interna precisam de um responsável nomeado para comunicar alteração e de um período de convivência entre versões.
O que o log não resolve
Log organizado não corrige regra de negócio errada. Se o cadastro nasce duplicado na origem, o registro mostra a duplicidade e segue adiante. Também não substitui conciliação periódica de totais nem conferência por amostra.
Em operações pequenas, o custo de manter classificação detalhada pode superar o ganho. Nesse caso, faz sentido limitar o escopo aos eventos que geram dinheiro ou obrigação legal, e assumir que o restante será tratado por conferência manual. Esse limite precisa estar escrito, não implícito.
Recurso prático
Itens de verificação antes de assinar o contrato de log
- Lista fechada de níveis de severidade, com o gatilho operacional de cada um
- Campos mínimos por evento: origem, destino, identificador do registro, horário, código e mensagem
- Definição do que é erro de negócio e do que é falha técnica, com exemplos acordados
- Retenção e forma de consulta, incluindo o tempo para recuperar ocorrências antigas
- Identificador que permita acompanhar o mesmo registro entre sistemas
- Rotina de teste com falha provocada e conferência do que foi efetivamente registrado
- Responsável nomeado por alteração de esquema e aviso prévio a quem consome o log
- Procedimento para registros que falharam e não foram reprocessados
O ponto mais ignorado é a mudança de esquema. O log nasce correto e deixa de servir quando um campo é renomeado ou removido sem aviso a quem lê o registro.
Conceitos usados nesta página
- Trilha de auditoria — Trilha de auditoria é o conjunto de registros que permite reconstruir quem fez o quê, quando e com qual dado — inclusive depois que o resultado já foi usado.
Sobre o que está escrito aqui
Conceitos relacionados: log de integração · nível de severidade · trilha de auditoria · retenção de registro · fila de reprocessamento. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Migração de dados: o que conferir antes e depois — migração sem conferência
- Dados desatualizados: o que precisa estar em dia — dados desatualizados
Páginas relacionadas
O mesmo problema em outro objetivo
- Log de integração sem nível de erro: isolar a falha pelo fluxo — Diagnosticar
- Log de integração sem nível de erro: o que registrar — Organizar um processo
- Log de integração sem nível de erro: o que cada saída prova — Comparar alternativas
- Log de integração sem nível de erro: o que medir na saída — Explicar medição
- Log de integração sem nível de erro: o que registrar — Orientar implementação
Outras leituras em Integrações, sistemas e qualidade de dados
- Sem identificador de execução: como a integração deixa rastro — O que registrar e como correlacionar uma integração sem identificador de execução, incluindo chave natural, janela de reconciliação e limites da abordagem.
- Integração sem identificador de execução: o que carimbar — Define o identificador de execução, onde gravá-lo e o que ele não resolve na conferência entre sistemas integrados.
- Falha na sincronização: como comparar o monitoramento — Compara as formas de acompanhar falha na sincronização, o que cada uma percebe, em quanto tempo e a que custo de operação.
- Registro excluído sem trilha: como implantar o rastro — O que definir para que exclusões deixem rastro: eventos a registrar, onde guardar o histórico, retenção e responsabilidade pelo acesso.
- Número que ninguém explica: trilha da origem ao relatório — Roteiro para tornar cada número do relatório rastreável, da origem ao total, com regra, responsável e horário registrados.