Monitoring vs Observability

• Monitoring alerts you when something is wrong (based on predefined metrics), while observability lets you understand why it’s wrong by analyzing logs, traces, and metrics in context. If your CPU usage spikes and your monitoring system fires an alert, observability lets you dig into that spike to trace exactly which service call or database query caused it
  • Monitoring just looks at the knowns (errors, logs, alerts, usages, etc.). Observability is all about making the unknowns known, say a CPU goes high in one of the areas of the distributed system, observability allows us to pinpoint it quickly and see the flow and effect, trace it back to the root cause
• Three pillars of observability: Logs, Metrics, and Tracing
  • Some say its logging, monitoring, and observability
  • Metrics answer the "what", logs answer the "why", traces answer the "where” and “how”
• Logs are timestamped event records. They tell you what exactly happened and why. They capture things like errors, user IDs, stack traces, and system state, which helps you debug and do forensic analysis
• Metrics are about quantifying system health over time, like request rate, error rate, CPU usage, or latency. They give you a high-level, numerical view of how things are performing, which is great for spotting trends or triggering alerts
• Tracing is about following a request’s full path through your system, understanding how different services interact, and measuring how long each part takes. It’s super useful for debugging and optimizing distributed systems
  • A trace represents the entire journey of a request (e.g. a user action, an API call) through a system
  • Trace is made up of spans. A span captures one unit of work. For instance, a call to a database, a call between microservices, or a local computation. Spans have a start and end time, so you can measure latency per operation

Types Of Logs

Common Performance Metrics

Tracing Key Concepts

Choose Your Visuals

Reference

Tools

Monitoring can be push or pull based: in a push model, the monitored system sends metrics to a central service (for example, AWS CloudWatch or a StatsD agent), while in a pull model, the monitoring system queries targets at intervals (such as Prometheus scraping /metrics)

Push-based monitoring is especially useful for short-lived, ephemeral workloads (like batch jobs or serverless functions), since pull-based systems may miss them if the job ends before the next scrape interval

Metrics

Logs

Traces