Log management
Purpose: Aggregate, retain and exploit AEM logs across a fleet — beyond tailing error.log on one box.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Platform engineers | Pipeline owners |
| All engineers | Search-fluency for debugging |
What ships to the aggregation platform
| Log | Contains | Notes |
|---|---|---|
| error.log | The main application log | THE stream; per-package routing configured (logging) |
| access.log | Instance-level requests | Publish traffic truth (behind dispatcher misses) |
| request.log | Request durations | Render-latency source of record |
| Custom app logs (phi.log) | Your packages | Structured where possible |
| Dispatcher/httpd logs | Edge-of-origin picture | Cache HIT/MISS enrichment is gold: log %{Cache-Status} |
| audit-style events | Login failures, user admin | Security consumption (audit & compliance) |
Ship with instance identity (host, tier, environment) attached; without labels a fleet's logs are noise.
Retention & access
Hot/searchable 30 days, archived 1 year (or per compliance — audit retention decisions apply); production log access is itself audited (logs contain user behaviour); PII must not be there in the first place (logging rules) — scrubbing at the shipper is the backstop, not the plan.
Making logs earn their storage
- Log-based alerts: new-ERROR-pattern detection, login-failure bursts, integration failure rates.
- Saved searches per runbook entry: the triage method steps reference queries by name — during an incident nobody composes regex from scratch.
- Correlation IDs across tiers (CDN request ID → dispatcher → publish → outbound calls) turn "somewhere it failed" into a single filtered trace.
- The weekly review scans TOP recurring WARN/ERROR patterns: each is either fixed, downgraded deliberately, or ticketed — a stable error.log is the cheapest monitoring upgrade there is.