Three questions to ask before ingesting a single log
Logs are the part of observability most organisations switch on first and design last. The result, in almost every large estate, is a log platform that is the biggest thing they pay for and the least used thing they own.
It happens because ingestion is easy and design is work. The platform can take every log from every source, so it does. Retention gets set high because nobody wants to be the person who deleted the evidence. A year later the log estate is enormous, the bill is real, and when an outage finally needs a log, the one that would have explained it turns out to be from a source nobody thought to include.
The fix is not a bigger platform or a smaller one. It is to treat a log strategy as what it actually is: a list of questions, not a list of sources. Before a single log is ingested, three questions decide whether it belongs, how long it stays, and how it is wired in.
One. Which question does this log answer?
Every log source should be able to name the incident, audit requirement or business question it exists to answer. If it can, it earns its place. If it cannot, ingesting it is cost without purpose, and worse, it is noise that makes the logs that do matter harder to find.
This is uncomfortable because it means some sources do not make the cut, and someone has to say so. But a log nobody can attach a question to is not evidence, it is clutter that happens to be searchable. Most log estates were built the other way round, source first, question never, and it is why they grow without getting more useful.
Two. How long does that question need the log?
Retention should follow the question, not a blanket default. Incident diagnosis rarely reaches back more than a few weeks, so the logs whose only job is diagnosis do not need a year. Audit and compliance questions may genuinely need long retention, and those logs are often better held in cheaper storage than the live observability platform, where they sit ready without inflating the part of the bill that scales with query.
Setting one retention period across everything, usually the maximum, is the expensive habit that a strategy exists to break. Matched to the question, retention becomes a series of deliberate choices rather than a single defensive one.
Three. Does this log need to be linked, or is it enough on its own?
The third question is the one most often skipped, and it is where logs stop being a search problem. A log linked to its trace and to the topology arrives attached to the service and the user action that produced it. A metric anomaly leads to the trace that caused it, which leads to the log that explains it. That chain is what turns diagnosis from guessing search terms into following a thread.
Not every log needs it. Some are perfectly useful on their own. But the logs that matter during an incident almost always do, and deciding the linkage up front is far cheaper than retrofitting it while an outage is running.
The strategy is the questions
Put the three questions together and a log strategy stops being a diagram of sources and becomes a short, defensible list: these logs, for these questions, kept this long, linked in this way. Everything else is sampled or left in place. The estate gets smaller, the bill gets more predictable, and the one log that explains the next outage is far more likely to be one you deliberately kept.
Should every log be ingested into the observability platform?
No. A log earns ingestion only if it answers a known incident, audit or business question. Sources that answer nothing are cost without purpose, and they make the logs that do matter harder to find. A log strategy is the list of the questions worth keeping logs for.
Why link logs to traces?
So a log line arrives already attached to the service and the user action that produced it, rather than sitting in a search box waiting for someone to guess the right term. A log linked to its trace turns diagnosis from a search into a follow, which is the difference between minutes and hours.