Log Management
Log Management tests ingestion, parsing, correlation, querying, and retention. The exam cares less about forwarding syntax and more about whether a log line is searchable, attributable to an entity, and retained for the required investigation window.
Core rules
- Logs arrive through APM agent log forwarding, the infrastructure agent, Fluent Bit, Fluentd, Vector, syslog, or cloud log pipelines. Whatever the path, the timestamp and service identity must be parsed or the log is hard to use.
- Parsing turns unstructured text into attributes. JSON is parsed automatically; other formats use Grok or regex rules. Parse before you need it, because parsing after ingestion is limited.
- Logs in context links log lines to APM entities and traces using metadata such as entity GUID and trace.id. That correlation is what lets you jump from a slow trace to its logs.
- NRQL queries Log events. FACET groups by attribute, and log patterns cluster similar messages. Live tail is for immediate debugging; log-based metrics turn a query into a metric for alerting.
- Logs are retained longer than APM event data in the standard service (30 days versus 8 days for APM), and live archives extend retention further.
Worked example
An error rate spikes. Query: FROM Log SELECT count(*) WHERE level = 'ERROR' FACET error.code SINCE 1 hour. The facet shows connection refused. A log pattern groups the messages by host, and the trace.id on one line links to a database span. The pool is exhausted; the fix is a pool size and timeout change, not more log volume.
Traps
Do not ingest high-cardinality IDs as attributes without a plan. Do not assume logs are retained as long as you need. A missing trace.id usually means correlation metadata is not being forwarded. Dropping logs at ingest can remove the evidence you need later.