How do you build cloud observability?

Direct answer

What a strong answer covers

How it works

Observability across a cloud estate needs standards before tools. Every service emits metrics, structured logs, and traces in the same format, usually through OpenTelemetry, with the same resource attributes: service name, version, environment, region, account. Trace context propagates through every hop including queues and managed services. Signals from all accounts flow to a central backend with access controlled by team, and retention and cardinality are governed so a single high-cardinality label does not double the bill. Dashboards are built around SLOs per service, and alerts route by the ownership metadata carried on the signals themselves.

Example

A platform team ships an OpenTelemetry collector as a sidecar and a shared library that sets service, version, and deployment attributes; traces flow to a central backend from 40 accounts, and a query by trace ID crosses account boundaries. A cardinality guard rejected a metric labelled by user ID that would have created millions of series. Each service’s dashboard is generated from its SLO definition, and alert routing reads the owning team from the resource attributes.

Common mistakes

• Letting each team pick its own logging format so cross-service queries are impossible.
• Dropping trace context at the message queue and breaking every asynchronous trace.
• Storing everything forever at full resolution until the observability bill exceeds the compute bill.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.