Before you start. You need logs arriving. Patterns are derived
continuously — there is nothing to configure and no rules to write.
What this is for
Seeing what a service actually logs
A new service’s entire log vocabulary in a page, instead of scrolling
through a million lines of the same three messages.
Spotting a new failure
A pattern that did not exist yesterday is a genuinely new kind of error —
which raw search will not surface, because you do not know what to search
for.
Finding your volume
The pattern with the highest count is usually where your log bill is, and
it is usually something nobody reads.
Triage during an incident
Which errors are one-offs and which are happening thousands of times.
How grouping works
Log bodies are clustered by structure: the stable words become the template and the varying parts become placeholders. Nothing is configured — the clustering adapts to what your services actually log.Patterns are discovered from the body text, not from attributes. Two log
lines with identical bodies and completely different attributes are one
pattern. Use patterns to find the shape, then filter on attributes in
search to narrow within it.
From a pattern to the lines behind it
A pattern is a starting point, not an answer. Once you have found the interesting one, filter logs by its identifier to get the individual records — with their timestamps, services, trace ids and attributes. That round trip is the workflow: pattern to find what is happening, search to find why.What it will not do
Retention
Patterns follow log retention — 30 days. A pattern with no recent matches ages out along with the lines behind it.Next
Searching logs
The query syntax for drilling into a pattern.
Live tail
Watching new lines as they arrive.
Reduce log volume
What to do about the pattern with the highest count.