Logs are the part of observability most organisations switch on first and design last. A log strategy decides what is worth ingesting, how long it is worth keeping, and what question each log is there to answer.
What goes wrong
Every log from every source gets ingested because the platform can. Retention is set to the maximum because nobody wanted to be the one who deleted the evidence. Twelve months later the log estate is the largest and least used part of the platform, and the one log that would have explained the outage was from a source nobody had thought to include.
How C4C approaches it · Context
Every log source gets asked one question: which incident, audit or business question would this log answer? Sources that have an answer are ingested at a retention matched to the question. Sources that do not are sampled or left in place. Logs are then linked to the traces and topology so a log line arrives attached to the service and user action that produced it, rather than sitting in a search box waiting for someone to guess the right term.
What you instrument and how deep. Full depth, infrastructure only, or discovered but not monitored, decided on purpose for every part of the estate.
The topology and the business meaning attached to the telemetry, so a technical signal arrives already attached to its consequence.
Getting from symptom to root cause in minutes rather than hours. One problem, one cause, the owner obvious. It only works when Coverage and Context are right.
What you get
Delivered as part of the Instrumentation Blueprint.
Questions
No. Ingest the logs that answer a known incident, audit or business question, at a retention matched to that question. Everything else is cost without purpose. A log strategy is the list of those questions.
As long as the question they answer needs. Incident diagnosis rarely needs more than a few weeks. Audit and compliance questions may need longer, and those logs are often better held in cheaper storage than the observability platform.
Metrics are numbers over time, such as requests per second. Traces follow a single request across every service it touched. Logs are the messages each component wrote as it ran. Observability works when the three are linked, so a metric anomaly leads to the trace that caused it and the log that explains it.
An hour with the practice, no slides, no obligation. Bring your incident history and your tooling list. Leave with a plain view of where your observability is working, where it is not, and what to do first.
Book an observability sense check