The life of a log

The Elasticsearch essays · August 2026

A log line has a lifetime. It is born messy in some process's stdout, gets parsed and enriched in flight, lands in an index, is queried constantly for a day, occasionally for a month, and then must be kept, cheaply, because the law says so. This essay follows that whole life.

Let's zoom out from structures to a lifetime. A log line's story begins before indexing, in an ingest pipeline: a chain of processors that parse, enrich and reshape it in flight. Try the three raw lines:

1 · grok: pattern-match fields out of the text
2 · enrich: look up what the data can't say itself
3 · the document that gets indexed
Three very different raw lines, one pipeline: grok extracts structure, enrich adds context (owner team, geo), and a clean document comes out. Amber chips are fields that didn't exist in the raw text.

The indexed line lands in a data stream: an append-only front door backed by a rolling series of indices; when the current one grows big or old enough, it rolls over and a fresh one takes the writes. And then time does its work. Yesterday's logs are queried constantly; last quarter's, almost never, yet the law says keep them. So index lifecycle management migrates aging indices across hardware tiers, from fast expensive disks to object storage that costs almost nothing, while everything stays searchable. Drag time:

Hot
fast SSD · takes all writes
Warm
cheaper disk · read-only
Cold
no replicas · restores from snapshot
Frozen
object storage · searched directly
actual cost
if everything stayed hot
6
Each chip is one month of logs. Policy: hot for 1 month, warm until 3, cold until 9, frozen after. Drag retention out to 18 months and watch the two cost bars diverge; the frozen tier is why keeping years of logs stopped being a luxury.

What happens to the log once it lands is the subject of Anatomy of a search; what happens when it is a metric instead is The metrics engine.