What telemetry must a new microservice ship with?

WHAT THIS TESTS The interviewer wants to know whether you understand the three pillars of observability and can pick signals that actually help during an incident, not just check a compliance box.

A GOOD ANSWER COVERS Metrics are aggregated numeric time series that are cheap to store and query, so use them for trends and alerting. A concrete example is a counter of HTTP responses split by status class, letting you compute error rate, plus a histogram of request duration so you can watch p99 latency. Logs are discrete structured events that carry rich context for a single occurrence. A concrete example is a JSON log line emitted on a failed payment that includes request id, user id, downstream error code, and the retry count. Traces follow one request as it fans out across services, recording spans with timing. A concrete example is a trace showing that a checkout call spent 400ms waiting on the inventory service, immediately pointing at the slow dependency.

COMMON WRONG ANSWERS Naming only host metrics like CPU and disk, which tell you a box is busy but not why users see errors. Treating logs as a firehose of unstructured text that cannot be queried. Assuming metrics alone can localize a fault across many services. Ignoring trace context propagation, which makes traces useless.

LIKELY FOLLOW-UPS How do you control logging cost and cardinality. How do trace and log correlate via a shared request id. What sampling strategy keeps traces affordable. Which of the three would you build first under time pressure.

ONE CONCRETE EXAMPLE A user reports slow checkout. The latency metric confirms p99 spiked at noon. A trace for one slow request shows the span on the recommendations call ballooned. The structured log on that span reveals a downstream timeout with a specific error code. The three signals together move you from symptom to root cause in minutes instead of guessing.