Monitoring asks known questions such as “Is CPU above 90%?” Observability is the engineering ability to investigate a system from the telemetry it emits, including questions you did not predict before the incident.

For this track, use this mental model:

Application / Infrastructure
        |
        | emits or exposes telemetry
        v
 Metrics  Logs  Traces  Profiles
   |
   | scrape / ingest
   v
Prometheus-compatible metrics system
   |
   | PromQL
   v
Grafana / Alert rules / SLOs
   |
   v
Engineer decision -> mitigation -> verification

Prometheus is strongest at numeric time-series metrics. Grafana is a visualization, exploration and alerting layer that can query Prometheus and many other data sources.

Monitoring is not dashboards

A dashboard is useful only if it helps answer an operational question. A better starting point is:

1. What user experience must stay healthy?
2. Which system behavior would make it unhealthy?
3. Which signals reveal that behavior?
4. Which signal deserves a page versus a dashboard?

Symptoms vs causes

Prefer alerts on symptoms close to users:

High error rate
High latency
No successful requests
SLO burn

Use cause-oriented signals to diagnose:

CPU saturation
memory pressure
DB pool exhaustion
queue depth
pod restarts
packet loss

Paging only on CPU often creates noise because high CPU can be healthy during useful work.

Telemetry hierarchy during an incident

Alert -> symptom
Dashboard -> scope
PromQL -> isolate
Logs/traces -> explain
Infrastructure/app inspection -> confirm
Change/rollback -> mitigate
Metrics -> verify recovery