Collect enough logs to diagnose and audit systems without turning logs into an uncontrolled copy of credentials, personal data, messages, or regulated records.
The result you're building
A logging schema and lifecycle policy with defined security/operational events, correlation, redaction, access control, integrity, retention, deletion, cost, and tested incident usefulness.
Use this guide when
- You need logs for reliability, security, billing, agent actions, or client support.
- Current logs contain inconsistent fields or sensitive payloads.
- Retention cost or privacy risk is growing.
Do not use it as a substitute for
- Logging complete request bodies, authorization headers, payment signatures, seed phrases, or private keys.
- Deleting evidence ad hoc without ownership, retention policy, or incident/legal-hold consideration.
Before you change anything
- Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- Event/use-case inventory, owners, users, threat model, and required investigations.
- Field schema, data classifications, prohibited fields, correlation IDs, and sampling.
- Collector/transport/store access, encryption, integrity, regions, and vendor subprocessors.
- Retention tiers, deletion, hold, backup, export, and cost.
- Redaction bypass, injection, access, clock, deletion, and incident-reconstruction tests.
Understand the system before fixing it
Observe before mutating
Capture state, logs, versions, ownership, and dependency health before restarting, reinstalling, deleting, or rotating anything.
Recovery must be exercised
A backup, rollback command, or spare endpoint is only a claim until a controlled restore or failover test proves it works.
Log events, not indiscriminate payloads
Record who/what/when/result/correlation and safe reason codes. Sensitive inputs usually do not improve diagnosis enough to justify exposure.
Logs are a production data system
They need authentication, authorization, encryption, integrity, availability, lifecycle, backups, cost controls, and incident response like any other datastore.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Auth token appears in trace | Redaction/instrumentation | Trace field through SDK, proxy, app, and exporter | Redaction occurs too late or misses a logging layer. |
| Incident cannot be reconstructed | Schema/coverage | Map required questions to events and correlation | Critical state transitions or identities are absent. |
| Tenant can query another tenant | Access control | Test scoped roles and query filters | Log-store authorization is broader than application authorization. |
| Deletion request leaves logs | Lifecycle | Trace subject key across hot/cold/backup tiers | Retention/deletion policy lacks searchable lifecycle keys. |
| Costs spike after debug enabled | Volume | Break ingestion by service/event/field/sampling | Verbose or high-cardinality logs are uncontrolled. |
Step-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
Step 01 — Define questions logs must answer
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: List reliability, security, financial, support, and compliance investigations; identify the minimum events, fields, precision, and retention each requires.
Read the result: Every retained field has a documented use and owner.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Create a safe event schema
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Use event name/version, time, service/release, actor/subject pseudonymous IDs as appropriate, action, target class, result, reason code, correlation, and confidence. Ban secret fields.
Read the result: Events are structured, attributable, and avoid unnecessary payload content.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Redact at the earliest boundary
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Allowlist safe fields; mask credentials, tokens, signatures, payment/auth headers, private keys, and sensitive query/body fields before app/proxy/SDK export.
Read the result: Canary secrets never reach any logging tier.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Protect transport and storage
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Authenticate collectors, encrypt transport/storage, use least-privileged roles, tenant boundaries, integrity controls, region policy, and audited admin access.
Read the result: Unauthorized identities cannot read, alter, or delete protected logs.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Set tiered retention and deletion
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Assign hot/cold/archive windows by event class, legal/contract needs, cost, and risk. Implement expiry, subject/tenant deletion where applicable, hold, and backup behavior.
Read the result: Lifecycle tests remove eligible data and preserve justified evidence.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Control volume and usefulness
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Use event-level sampling carefully, aggregation, rate limits, cardinality budgets, debug expiry, and alerts on drops or schema errors. Never sample away rare critical events blindly.
Read the result: Cost stays within budget while required investigations remain possible.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Run reconstruction and abuse tests
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Simulate incident, wrong-tenant query, log injection, clock skew, collector outage, redaction bypass, deletion, and restore. Document gaps and recovery.
Read the result: Operators reconstruct the event without secret leakage or unauthorized access.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet
Evidence record
- Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- Event/use-case inventory, owners, users, threat model, and required investigations.
- Field schema, data classifications, prohibited fields, correlation IDs, and sampling.
- Collector/transport/store access, encryption, integrity, regions, and vendor subprocessors.
- Retention tiers, deletion, hold, backup, export, and cost.
- Redaction bypass, injection, access, clock, deletion, and incident-reconstruction tests.
Acceptance scoreboard
- Required investigations map to minimum event fields, owners, and retention.
- Schema is versioned, structured, correlated, and bans raw secrets.
- Redaction canaries pass at proxy, app, SDK, collector, and storage layers.
- Log access, tenant scope, admin actions, transport, storage, and integrity are protected.
- Tiered retention, deletion/hold, backups, and restore behavior are tested.
- Incident reconstruction works within volume, cost, and availability limits.
Minimum handoff record
- Versioned logging, privacy, and retention scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Evidence collected
- Authorization headers are included at reverse proxy and app layers.
- Log store role is shared broadly.
- Tokens remain valid for hours.
- No canary secret test exists.
Decision: This is a credential exposure incident. Stop the field, restrict access, rotate affected tokens as required, and trace every logging layer.
Actions taken
- Changed to allowlisted headers and safe auth reason codes.
- Removed broad log-store access and audited queries.
- Rotated affected credentials under incident policy.
- Added redaction canaries in proxy, app, and exporter.
Why this example matters: The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests
- A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Required investigations map to minimum event fields, owners, and retention.
- Schema is versioned, structured, correlated, and bans raw secrets.
- Redaction canaries pass at proxy, app, SDK, collector, and storage layers.
- Log access, tenant scope, admin actions, transport, storage, and integrity are protected.
- Tiered retention, deletion/hold, backups, and restore behavior are tested.
- Incident reconstruction works within volume, cost, and availability limits.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Auth token appears in trace | Redaction occurs too late or misses a logging layer. | Trace field through SDK, proxy, app, and exporter |
| Incident cannot be reconstructed | Critical state transitions or identities are absent. | Map required questions to events and correlation |
| Tenant can query another tenant | Log-store authorization is broader than application authorization. | Test scoped roles and query filters |
| Deletion request leaves logs | Retention/deletion policy lacks searchable lifecycle keys. | Trace subject key across hot/cold/backup tiers |
Reusable handoff record
- Versioned logging, privacy, and retention scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| target | object | Versioned environment, resource, identity, or workflow being evaluated. |
| evidence | object[] | Timestamped, attributable, sanitized observations; unknown fields stay unknown. |
| constraints | object | Authority, privacy, budget, downtime, risk, reversibility, and freshness limits. |
| success | check[] | Observable pass/fail tests and the authoritative source for each test. |
Agent refusal and escalation rules
- Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
- Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
- Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
- Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule: Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low confidence; a controlled test that isolates the layer and passes verification can support high confidence.
Official reference starting points