Modern Observability: Metrics, Logs and Traces
Monitoring used to mean a dashboard of CPU graphs and a pager that fired when a host went down. In a world of containers, autoscaling, and services that talk to a dozen other services per request, that model answers the wrong question. Modern observability is about answering “why is this request slow?” across a distributed system — and in 2026 the answer is built on three signals and one instrumentation standard.
The Three Signals
Metrics are cheap, aggregatable time series — request rates, error ratios, latency percentiles, queue depths. They tell you that something is wrong and are the right substrate for alerting. Logs are discrete events with full context; they tell you what happened at a specific moment. Traces follow a single request across service boundaries and tell you where time was spent and which downstream call failed. None of the three replaces the others; a stack that lacks one leaves you debugging blind in that dimension.
The Open-Source Standard: Prometheus, Grafana, Loki, OpenTelemetry
The de facto OSS observability stack has consolidated. Prometheus is the metrics backbone: a pull-based time-series database with a powerful query language (PromQL) and first-class Kubernetes service discovery. It is the default answer for infrastructure and application metrics, with Thanos or Grafana Mimir layered on when you need long-term retention and horizontal scale.
Grafana is the visualization and alerting layer that ties everything together — one place to correlate a latency spike with the logs and traces behind it. Loki handles logs with a deliberately different design from Elasticsearch-style full-text indexing: it indexes only labels, which makes it dramatically cheaper to run at volume, at the cost of slower free-text searches. For most teams that trade is worth it. Tempo or Jaeger completes the picture for distributed tracing.
OpenTelemetry is the piece that changed the game. It is a vendor-neutral standard for instrumenting applications — SDKs for every major language plus a Collector that receives, processes, and exports telemetry wherever you want it. Instrument once with OTel and you can ship data to Prometheus and Tempo today and to a commercial backend tomorrow without touching application code. In 2026, instrumenting directly against a vendor’s proprietary agent is a decision you will eventually pay to undo. If you run Kubernetes, this stack is effectively table stakes — most of the failure scenarios in our Kubernetes in real life write-up are only debuggable with metrics and traces already in place.
Commercial Platforms, Honestly
Datadog and New Relic are excellent products, and pretending otherwise would be dishonest. You get integrated metrics, logs, traces, APM, and synthetics in an afternoon, with polished correlation features the OSS stack makes you assemble yourself. The catch is the bill: pricing scales with hosts, ingested data, and custom metrics, and at container scale it can rival your compute spend. High-cardinality metrics and verbose logs are where the surprises live.
Our honest guidance: a small team with no platform capacity should buy a commercial platform and spend its energy on the product. A team with platform engineers, cost sensitivity at scale, or data-residency constraints should run the Grafana stack. Either way, instrument with OpenTelemetry so the choice stays reversible. Tools like Nagios and SolarWinds still exist for traditional host and network monitoring, but they are not where you should start a greenfield stack in 2026.
Alerting Design: Page on Symptoms, Not Causes
Most alerting failures are design failures. Alert on what users experience — error rate, latency against your SLO, availability — not on every cause underneath (CPU at 80% is not an incident; requests failing is). SLO burn-rate alerts are the mature version of this: page a human only when the error budget is burning fast enough to matter. Every page must be actionable and urgent; anything else goes to a ticket queue. And review the pager monthly — alerts nobody acts on get deleted, because alert fatigue is how real incidents get missed.
Where AI Fits
AI is genuinely useful in observability for anomaly detection on seasonal metrics, alert correlation during incident storms, and first-pass root-cause suggestions — and genuinely oversold as a replacement for good SLOs. Graf Clouds builds AI-assisted monitoring into its own products, so this is a distinction we deal with daily: AI shortens diagnosis, but it cannot rescue a system that was never instrumented properly.
Conclusion
Start with OpenTelemetry instrumentation, run Prometheus, Grafana, Loki, and Tempo unless you have a specific reason to buy, alert on symptoms against SLOs, and keep the pager quiet enough that a page still means something. If you want help designing or operating an observability stack, our DevOps practice does exactly this work.