A program manager says the permit platform already has logs, so it has full observability. How should engineers clarify the gap?
Select an answer to reveal the explanation.
Short Explanation
Logs are diary entries, metrics are the scoreboard, traces are the map. Having a diary does not mean you have the whole observability toolkit.
Full Explanation
When a program manager claims the permit platform already has logs and therefore has full observability, engineers should clarify that logs, metrics, and traces are complementary pillars. Logs explain detailed events, metrics show aggregates and SLOs over time, and traces connect multi-service citizen journeys. Logs alone leave latency ownership, saturation trends, and cross-hop failure maps incomplete for municipal operations.
Logs do not automatically include metrics and traces without further instrumentation and exporters.
Observability is not limited to billing dashboards; runtime signals are essential for citizen experience.
Metrics do not replace logs for every user-facing workflow that needs forensic detail.
Exam caveat: Associate developers should instrument all three pillars appropriately—not declare victory after console.log.
Operational check: For the permit platform, ensure key metrics and alarms exist, enable tracing on the critical path, keep structured logs, and demonstrate one incident drill that uses all three signals. Keep the civic/municipal context in mind: permit outages need both "what broke" (traces/metrics) and "for which citizen/case" (logs). Document the finding in the municipal incident ticket so the next on-call engineer inherits evidence rather than folklore.