What is the difference between monitoring and observability, and what are metrics, logs and traces each good for?
What the interviewer wants to hear
- Monitoring watches known signals and alerts on known failure conditions
- Observability is the ability to ask new questions about unknown problems from telemetry
- Metrics are cheap numeric time series for trends, dashboards and alerts
- Logs give detailed event records for a single request or error
- Traces show the path and timing of a request across services
Model answer
Monitoring is watching signals we already know matter, like error rate or disk usage, and alerting when they cross a threshold. Observability is a property of the system: how well we can understand new, unexpected problems from the telemetry it emits, without shipping new code. The three main signals work together. Metrics are numeric time series that are cheap to store and great for dashboards, trends and alerts, but they lose detail. Logs are detailed records of individual events, useful for seeing the exact error and context for one request. Traces follow a single request across services as a tree of spans, showing where time was spent and which hop failed. In practice I start from a metric alert, jump to traces for slow or failed requests, and then read the logs linked by trace ID.
Can you answer it under time pressure?
Take a timed easy round and get scored on every answer.
More easy Site Reliability Engineer questions
- Explain the difference between an SLI, an SLO and an SLA, with an example.
- What is an error budget and how does a team use it?
- What are the four golden signals, and why are they useful for monitoring?
- You are on call and get paged for a high error rate. What are your first steps?
- What is toil, and how would you reduce it on your team?
- Why do SRE teams manage infrastructure with code tools such as Terraform instead of clicking in a cloud console?
- Explain blue-green and canary deployments. When would you choose each?
- You are asked to build the main Grafana dashboard for a web API. What would you put on it, and how would you lay it out?
- What makes an on-call rotation healthy and sustainable for the engineers on it?