Log analysis is the practice of reading the records your systems write to work out what happened, find the cause of a problem, and confirm it is fixed. Log management is collecting and storing those records; analysis is making sense of them. This is how you investigate production from logs: what to look at, how to find root cause, and the tools that help.
What log analysis is, vs log management
A log is a timestamped record of something that happened: a request came in, a query ran, an error was thrown. The syslog standard, which most logging still descends from, defines a log entry as a message with a timestamp, a source, and a severity, on a scale from emergency down to debug.1 A running system produces a constant stream of these.
The two terms people mix up are log management and log analysis, and the difference is simple.
- Log management is the plumbing: collecting logs from every service, shipping them somewhere central, storing and indexing them, and deciding how long to keep them. It is what makes logs searchable at all.
- Log analysis is what you do with them once they are searchable: querying, filtering, correlating, and reasoning to answer a question. Usually one question: what is going wrong, and why?
You need management before analysis is useful, but management is not the goal. Storing every log forever and never reading them helps no one. The value is in the analysis, and that is the part most tools leave to you.
Structured logs: what makes analysis possible
The single biggest thing that decides whether log analysis is easy or painful is whether your logs are structured. An unstructured log is a line of text: payment failed for user 4821. A structured log is the same event as machine-readable fields, usually JSON: timestamp, severity, service, user id, and so on. OpenTelemetry, the open standard for telemetry, treats structured logs as a first-class signal alongside metrics and traces for exactly this reason.2
Structure is what lets you ask precise questions instead of grepping for substrings: show every error on the checkout service for paying users in the last hour. The field that matters most is the trace id. When a log line carries the id of the request it belongs to, you can pull every log across every service for one user's failed action and see it in order. That correlation is standardized as W3C Trace Context, the way a request's id is passed from service to service.3 Logs joined to traces this way are the difference between guessing and knowing.
How to investigate production from logs
Most real investigations follow the same path, whether you do it by hand or a tool does it for you.
- Start from a symptom and a time window. "Checkout started failing around 14:20." A symptom plus a rough time is enough to begin and cuts the search space hard.
- Narrow to the service and the error. Filter to the affected service and the error severity in that window. You are looking for the first place the failure appears, not the last.
- Follow one request end to end. Take a single failing trace id and pull every log line for it across services. This turns a pile of lines into the story of one request, and usually shows exactly where it broke.
- Find the change. Most production issues line up with a change, almost always a recent deploy or config flip. Match the start of the errors to what changed just before.
- Confirm the blast radius. Before you call it, check how many users and which paths are affected, and since when. That tells you how urgent it is and whether your fix actually worked.
None of this is hard in principle. It is just slow and fiddly when you are doing it by hand at the moment something is on fire, jumping between a log search, a deploy history, and a dashboard. That is the part worth removing. We cover the broader version of this, where the investigation runs before you even look, in automated alert investigation.
Log analysis tools
Tools sit on a spectrum from raw command line to hosted platforms, with a different trade between control and effort.
| Tool | Best for | Approach |
|---|---|---|
| grep / jq | Small volumes, one box, quick checks | Command line, no infrastructure |
| ELK / OpenSearch | Self-hosted full-text search at scale | You run and tune the stack |
| Grafana Loki | Label-based logs, often with Grafana | Self-hosted or managed, query language |
| Datadog logs | Hosted management with the wider suite | Dashboards and query syntax, priced by volume |
| Fixter | Small teams that want answers, not queries | Plain-language investigation over MCP |
The split is real: the self-hosted options give you control and cost you maintenance, the hosted ones save setup and bill by volume, and all of them still expect you to know the query language and do the analysis yourself. For small teams that is the catch, and it is where the next section comes in.
Log analysis in plain language with Fixter
Fixter stores your logs and lets you analyze them without a query language and without a dashboard. You ask in plain language from your editor, over MCP, and it runs the investigation for you: it filters the logs, follows the trace, finds the change that lines up, and reports the cause and the blast radius. The five steps above happen for you, and you read the conclusion.
The stance stays the same as everywhere else on Fixter: it does the investigation and hands you the conclusion, you decide and guide the fix. Log analysis is one side of the same coin as watching the right signals in the first place, which is covered in APM for small teams, and the broader idea of getting answers instead of graphs is in observability without dashboards.
Key takeaways
- Log management is collecting and storing logs; log analysis is making sense of them to find a cause
- Structured logs (JSON with fields like trace id) are what make precise analysis possible
- The trace id lets you follow one request across every service, which is how you find root cause
- Investigate by starting from a symptom and time, narrowing, following one trace, and finding the change
- Most tools still leave the analysis to you; Fixter runs it from a plain-language question over MCP
Frequently asked questions
What is log analysis?
Log analysis is the practice of reading and interpreting the log records your applications and infrastructure emit, to understand what happened, find the root cause of an issue, and confirm a fix. It turns raw, timestamped events into an explanation of how the system behaved.
What is the difference between log management and log analysis?
Log management is the infrastructure side: collecting, shipping, storing, indexing, and retaining logs so they are searchable. Log analysis is what you do with them: querying, correlating, and reasoning to answer a question or find a cause. You need management in place before analysis is useful.
What are structured logs?
Structured logs record events as machine-readable key-value data, often JSON, rather than free-form text. A structured log carries fields like timestamp, severity, service, user id, and trace id, which makes logs filterable and joinable instead of something you grep by hand.
How do you analyze logs to find root cause?
Start from a symptom and a time window, narrow to the affected service, then follow the request: correlate the log lines to a single trace using the trace id, and look for the change that lines up, usually a recent deploy. The goal is to get from 'something is wrong' to the specific line and cause.
What tools are used for log analysis?
Options range from command-line tools like grep and jq for small volumes, to the ELK/OpenSearch stack and Grafana Loki for self-hosted search, to hosted log management like Datadog. Fixter takes a different approach: you query logs in plain language over MCP and it runs the investigation for you.