What is cloud native observability and what should you collect?

Cloud native observability is the ability to ask new questions about a distributed system from the data it emits, mainly logs, metrics and traces. Monitoring tells you something is wrong. Observability helps you find out where and why, across many services that no single person fully holds in their head.

What are the three signals?

The OpenTelemetry observability primer describes the pieces. A log is a timestamped message from a service or component, and on its own it often lacks context about where it came from in a request. A span represents a single unit of work, with a name, timing and attributes. A trace records the path of one request through the system, as a tree of spans.

Metrics, the third signal, are numeric measurements over time, such as request rate, error rate and latency percentiles. They are cheap to store and good for alerting. Traces and logs explain what the metric alert means.

Why does a request need an identity?

In a system of many services, one user action may touch a dozen of them. To stitch those together, each service must pass along a shared identifier. The W3C Trace Context specification defines a standard HTTP header, traceparent, that carries a trace ID and the parent span ID, plus flags, so that tools from different vendors can join the same trace.

If one service drops the header, the trace breaks into two pieces and the slow step hides in the gap.

A constructed example

Checkout latency alerts fire at 2 a.m. The metric shows the 99th percentile jumped. A trace of a slow request shows the time is spent in a call from the orders service to an inventory service, and inside that, in one database query. A log line attached to that span, with the same trace ID, shows a missing index on a table that grew this week. Without the shared ID, the on-call engineer would be guessing across three dashboards.

Why is this a security topic too?

Observability data is evidence. NIST SP 800-92 on log management explains why logs matter for incident response and for detecting policy violations. It also stresses protecting logs and handling them with care, since they can hold sensitive information.

Three risks come up often. Logs and span attributes can capture secrets, tokens and personal data if developers record whole requests. Telemetry stores become a rich target, since they show system structure and data. And gaps matter: if you cannot trace an authentication failure across services, you will not spot a slow credential attack.

What should you keep out?

Do not log passwords, tokens, full payment data or full request bodies. Scrub attributes at the source, with a collector rule as a second line. Set retention by purpose, shorter for verbose debug data and longer for audit events. Restrict who can query raw telemetry and log those queries.

What does it cost?

Telemetry volume grows with traffic and with the number of services, and so does the bill. Sample traces instead of keeping all of them, keep full detail for errors and slow requests, and cut metric labels that explode in number, such as a user ID. Decide what you are buying: a fast answer during an incident, with enough history to see a pattern.

How to check or apply this

1. Pick a standard instrumentation approach, such as OpenTelemetry, and use it across services.
2. Propagate trace context on every internal call, including queues and background jobs.
3. Add the trace ID to every log line so logs can be joined to traces.
4. Define a short list of service level indicators per service: rate, errors and latency.
5. Add a redaction rule for secrets and personal data in the telemetry pipeline, and test it with a sample.
6. Set retention and access rules, with separate handling for security audit events.
7. Run a game day: break one service and check that a trace shows where.

Quick check

Sources

• OpenTelemetry, Observability primer
• W3C Trace Context
• NIST SP 800-92, Guide to Computer Security Log Management

Last reviewed: 18 October 2026.