Understand a system's internal state from the outside by collecting and correlating the telemetry it emits.
Observability is the ability to understand what's happening inside a software system from the outside, by collecting and correlating the telemetry it emits: traces, logs, and metrics.
The term comes from control theory, where a system is “observable” if you can infer its internal state from its outputs. Applied to software, it means a well-instrumented service produces enough signal that you can answer new questions about its behavior (including ones you didn't anticipate) without stopping to add new instrumentation first.
This matters most during incidents. In a distributed system, the failure you're debugging is often one nobody predicted. With good telemetry you can investigate it from data you already collect, without first shipping new logging.
A trace records the full path of a single request as it moves through your services, broken into timed spans. Traces show you where time went and which hop failed.
Logs are timestamped, structured records of discrete events: the detail you read when you need to know exactly what happened at a specific moment.
Metrics are numeric measurements sampled over time (request rate, error rate, latency, saturation), suited to dashboards, trends, and alerting.
The pillars are most useful together. A metric tells you the error rate spiked. A trace shows the request path responsible. The logs on that span tell you why. You need all three linked to get from a symptom to a cause.
Monitoring tells you whether a system is broken; observability helps you understand why.
Monitoring watches known failure modes with predefined dashboards and alerts. It is how you find out a service is down or latency crossed a threshold. It answers questions you knew to ask in advance.
Observability covers the cases monitoring can't. If you keep detailed, high-cardinality telemetry that you can query after the fact, you can investigate problems you never anticipated. Monitoring is one of the things an observable system lets you do.
OpenTelemetry is the open, vendor-neutral standard for generating and exporting traces, logs, and metrics. Instrumenting with OpenTelemetry means your telemetry isn't tied to any one vendor. You can send it to any compatible backend and switch tools without re-instrumenting your code.
Most new observability tooling now builds on OpenTelemetry. Read our guide to OpenTelemetry for how the standard works and how Maple follows it.
Look for native OpenTelemetry support so you avoid lock-in, unified traces, logs, and metrics in one place, query speed at high cardinality, transparent pricing that doesn't punish you for scaling, and the option to self-host.
For a side-by-side of the leading open-source options, see our roundup of the best open-source observability tools .
Last updated: June 2026
SDKを追加し、OTLPエクスポーターをMapleに向ければトレースが届きます。
maple.dev：OpenTelemetryの上のオブザーバビリティ