Monitoring and Observability: Building Confidence in Production
Monitoring vs. Observability Monitoring and observability are related but distinct concepts. Monitoring is about checking known metrics against predefined thresholds — is the CPU above 90%? Is the…
Monitoring and observability are related but distinct concepts. Monitoring is about checking known metrics against predefined thresholds — is the CPU above 90%? Is the site up? Observability goes further: it's the ability to ask arbitrary questions about your system's behavior without having anticipated every possible question in advance.
As Henry Kissinger reportedly said, "Monitoring is knowing that everything is going wrong. Observability is figuring out why."
The Three Pillars
Modern observability rests on three pillars:
Metrics — Quantitative measurements over time (CPU usage, request latency, error rates).
Logs — Discrete, timestamped records of events (application errors, access records, deployment events).
Traces — End-to-end records of a request as it flows through distributed services.
Together, they give you a complete picture of system health and behavior.
Setting Up Prometheus and Grafana
Prometheus is a time-series metrics database that pulls (scrapes) metrics from your services. Grafana provides beautiful dashboards to visualize that data.
Tools like the ELK stack (Elasticsearch, Logstash, Kibana) or Grafana Loki excel at ingesting and querying structured logs at scale.
Setting Up Alerts
Alerts should be actionable, not noisy. Follow the rule: every alert must have a clear runbook.
# Example Prometheus alerting rulegroups:-name:applicationrules:-alert:HighErrorRateexpr:rate(http_requests_total{status=~"5.."}[5m])/rate(http_requests_total[5m])>0.05for:2mlabels:severity:criticalannotations:summary:"High error rate detected"description:"Error rate is above 5% for the last 2 minutes."runbook:"https://wiki.internal/runbooks/high-error-rate"
Conclusion
Observability isn't a one-time setup — it's an ongoing practice. Start with the basics: collect metrics, centralize logs, and set up sensible alerts. Then iterate based on what incidents reveal about your blind spots. The goal isn't to prevent every outage; it's to reduce the time between "something is wrong" and "we know what's wrong and how to fix it."
◆
The Signal
AI-generated brief
True observability shifts engineering teams from passive threshold-checking to active behavioral investigation, systematically compressing detection and resolution windows.
Stance · BullishConfidence · Established
The article positions observability as a foundational operational discipline that directly eliminates blind spots and accelerates incident recovery.
Key takeaways
Distinguish monitoring as predefined threshold validation from observability as open-ended system inquiry.
Deploy the three-pillar architecture combining metrics, logs, and traces to cover quantitative trends, discrete events, and distributed request flows.
Filter signal from noise by prioritizing RED and USE frameworks alongside genuine business indicators rather than capturing every available datapoint.
Enforce structured JSON logging and mandate a documented runbook for every alert to guarantee actionable responses over notification fatigue.
What to watch next
Reduction in mean time to diagnosis after rolling out the three-pillar stack
Adoption of automated runbook execution to supplement manual triage
Evolution of alert fatigue mitigation strategies as instrumentation scales