Observability is the property of a system that allows its internal state to be inferred from its external outputs. In distributed computing, the term refers to the engineering practice of instrumenting systems to produce sufficient telemetry data — metrics, logs, and distributed traces — to diagnose any failure or performance issue without requiring access to the system's internals.
The three pillars of observability
Metrics are numeric measurements of system behaviour over time — request rate, error rate, CPU utilisation, memory usage, queue depth. They are efficient to store and query, and excellent for alerting on known failure modes. Metrics answer: "Is the system behaving normally right now?"
Logs are timestamped, structured records of discrete events — a request received, an error thrown, a job completed. They provide the detail needed to understand what happened in a specific sequence. Logs answer: "What exactly happened at 14:32:07?"
Traces (distributed traces) follow a single request as it flows through multiple services — recording the duration and outcome of each hop. In a microservices architecture, a single user action may invoke dozens of services; traces make this visible. Traces answer: "Which service was the bottleneck, and why?"
Observability vs. monitoring
Monitoring is the practice of watching known metrics and alerting when they exceed thresholds — it tells you that something is wrong. Observability is the property that allows you to understand why something is wrong — even if you have never seen that failure mode before. A well-monitored but poorly observable system can tell you the error rate is high but not why. A highly observable system allows you to trace the root cause through logs, traces, and metrics correlation.
Observability in regulated environments
RBI's guidelines on IT governance and risk management, and SEBI's operational resilience requirements, effectively mandate observability as a compliance requirement — not just an engineering best practice. The ability to demonstrate system behaviour retrospectively (for audit and incident investigations) requires comprehensive, retained, tamper-evident logs and metrics.