Slide 3 of 5

The decision framework

The decision framework

For any piece of log data, ask where it belongs.

  • If you filter by it in almost every query, and it’s bounded, make it a label. Example: env, app.
  • It’s high-cardinality but you query it often, attach it as structured metadata. It’s queryable with a label filter expression, such as {job="example"} | pod="myservice-abc1234-56789", without being indexed or creating streams. Examples: pod names, process IDs, trace IDs.
  • Everything else, leave it in the log line and extract it at query time with parsers like json or logfmt, or search it with filter expressions.
Decision tree routing a piece of log data to a label, structured metadata, or the log line, based on how often it's queried and whether it's bounded

Script

Put the last two slides together and you get a decision framework for any piece of log data.

If you filter by it in almost every query and it’s bounded, make it a label. That’s where your environment and application labels belong.

If it’s high-cardinality but you still query it often, attach it as structured metadata. It stays queryable with a label filter expression, without being indexed and without creating streams. Pod names, process IDs, and trace IDs all live here.

Everything else stays in the log line. Extract it at query time with a parser like json, or search it with filter expressions.

The diagram on this slide walks through the same decisions in order, so keep it in mind the next time you’re deciding where a field belongs.

Previous Next