Logs e observabilidade

A trilha de auditoria

O registro operacional mais rico é a trilha de auditoria: uma tabela apenas de inserção que registra toda mudança de estado relevante para segurança (decisões de autenticação e autorização, mudanças de disposição, liberações de relatório, destruição de chave), com quem e quando, por identificador e nunca por valor de conteúdo. É onde você olha para responder "quem fez o quê, quando" depois do fato. Como nunca copia conteúdo, ela fica segura de guardar e de ler.

Saúde

Os serviços devem estar de pé e, no caminho por container, o renderizador saudável. docker compose ps deve mostrar peart-render como Up (healthy) antes de a geração de relatório funcionar; a superfície interna condiciona sua subida à saúde do sidecar, então um relatório que não gera geralmente significa que o sidecar não está pronto ou que o token compartilhado dele não bate dos dois lados.

O que observar

As coisas que merecem alerta são as que param o trabalho ou sinalizam problema: os serviços caídos, o renderizador não saudável (relatórios não geram), o disco enchendo (evidências e relatórios crescem), e falhas repetidas de autenticação contra o portal. O PEART é auto-hospedado e offline por desenho, então a observabilidade é sua para ligar ao que o host já roda; não há telemetria saindo do host para se apoiar, e isso é deliberado.

Ler logs

Os logs são estruturados, então são feitos para serem enviados e consultados por qualquer stack de log que o host use. Entre os logs estruturados e a trilha de auditoria você tem a visão operacional (o que o processo está fazendo) e a visão de responsabilização (o que um usuário fez), que são perguntas diferentes e mantidas em lugares diferentes de propósito.