Logs and observability

The audit trail

The richest operational record is the audit trail: an insert-only table that records every security-relevant state change (authentication and authorization decisions, disposition changes, report releases, key destruction), with who and when, by identifier and never by content value. It is where you look to answer "who did what, when" after the fact. Because it never copies content, it stays safe to keep and to read.

Health

The services should be up and, for the container path, the renderer healthy. docker compose ps should show peart-render as Up (healthy) before report generation works; the internal surface gates its own startup on the sidecar being healthy, so a report that will not generate usually means the sidecar is not ready or its shared token does not match on both sides.

What to watch

The things worth an alert are the ones that stop work or signal trouble: the services being down, the renderer unhealthy (reports will not generate), the disk filling (evidence and reports grow), and repeated authentication failures against the portal. PEART is self-hosted and offline by design, so observability is yours to wire into whatever the host already runs; there is no telemetry leaving the host to lean on, and that is deliberate.

Reading logs

Logs are structured, so they are meant to be shipped to and queried by whatever log stack the host uses. Between the structured logs and the audit trail you have both the operational view (what the process is doing) and the accountable view (what a user did), which are different questions and kept in different places on purpose.