Observability
Also called o11y, monitoring.
How well you can understand what a running system is doing, and why, from the data it gives off: logs, metrics and traces.
Last updated
What it is.
Logs record events in detail. Metrics are numbers over time, such as requests per second or error rate. Traces follow one request through every service it touches. Together they let a team answer questions it did not plan for, such as why checkout is slow only for one customer.
Monitoring checks known things and alerts when they cross a line. Observability is the wider ability to explore the unknown. APM tools cover a large part of it.
Why it matters
When something breaks in production, time to fix depends on how quickly you can see what went wrong. Good observability turns hours of guessing into minutes. It also shows whether reliability targets are being met.
In a product build
We add structured logs with a request ID, a few key metrics per service and tracing from the first deploy, and keep personal data out of logs. Alerts go to the people on call and are tied to user impact, such as failed payments, not just CPU.
Common mistakes.
- 01
Logging everything with no structure, then paying to store noise.
- 02
Logging personal or secret data.
- 03
Alerts nobody owns, which get muted and forgotten.
Related terms.
- APM (application performance monitoring)Tools that measure how fast and how reliably an application handles requests, and show which part of the code or which call is slow.
- Audit logA record of who did what in a system, when and from where, kept so actions can be traced later.
- Canary releaseA release method that sends a small share of users to a new version first, watches for problems, and widens the rollout step by step.
- Event-driven architectureA way of designing software where parts of the system publish events about what happened, and other parts react to them on their own.
- MicroservicesA way of building an application as many small services, each owning one job and its own data, deployed independently.
