Structured logging without secrets

Goal

Produce logs that can be searched and aggregated by machines, understood by people, and shared with support staff without leaking secrets.

Prerequisites

A logging library that supports structured output (or a formatter that emits one JSON object per line) and a log collector.

Steps

1. Emit one record per event with a fixed set of keys: timestamp, level, logger, event name, and event-specific fields. Avoid free-form messages that concatenate values.
2. Define what each level means for your service (for example, WARNING = needs attention within a day, ERROR = a request failed) and stick to it.
3. Decide, per field, whether it may be logged. OWASP's guidance excludes credentials, session identifiers, payment data and other sensitive values; personal data needs a documented purpose and retention.
4. Redact at the source: build the record from allowed fields rather than filtering strings afterwards.
5. Include correlation identifiers (request id, trace id) so that records of one request can be joined.
6. Set rotation and retention limits and test that the application survives a full disk or an unreachable collector.

Expected result

Queries such as "all failed requests for endpoint X in the last hour" work without regular expressions; an accidental log export exposes no secrets.

Limits and test basis

Structured logs are larger than plain text; sample high-volume debug events. Redaction lists must be maintained as fields are added. The guidance follows the cited sources and the practice of this wiki's own service.