What does good observability look like for a service you own?

You should be able to answer questions you did not anticipate. That means structured logs with a trace id on every line, metrics covering rate, errors and duration plus saturation of your key resources, and distributed traces that follow a request across services. Alerts fire on user visible symptoms tied to your service level objectives, dashboards start from the customer experience, and every signal shares consistent labels so you can pivot between them.

The test I use is whether I can answer a question nobody thought of when the service was built, for example why requests are slow only for one customer on one endpoint. To get there the three signals have to be joined up. Every log line is structured and carries the trace id, so from a slow trace I can jump straight to that request's logs rather than grepping by timestamp. Metrics cover the rate, errors and duration of every endpoint as percentiles rather than averages, plus saturation of the things that actually run out, connection pools, queue depth, disk. Traces are sampled, but I always keep the errors and the slow tail, because the average request teaches me nothing. Alerts are the part people get wrong: I alert on symptoms customers feel, tied to the objective, not on CPU being at eighty percent. And I watch cost, because putting a user id in a metric label is how you turn a two hundred dollar bill into six thousand overnight; user level detail belongs in traces and logs.