liveBook · Manning

Telemetry

As explained in Effective Platform Engineering

Telemetry data consists of automatically emitted records such as metrics, logs, and traces that describe software-system behavior, performance, and state.

Telemetry is data emitted by running systems—including metrics, logs, and traces—that helps people understand behavior and diagnose problems. Its value depends on the questions it can answer: whether infrastructure is failing, an application is healthy, a service is stable, or a new feature is being used. section 5.2.1 section 5.1.2

Choose what to collect from the questions people need to ask, not just from what an application can emit. Operations teams may need resource consumption and failure data; engineers need evidence for diagnosis; product managers may need feature-usage data. Keeping each team's telemetry isolated makes failures involving multiple services harder to trace and can slow recovery. section 5.1.2 section 5.2.1

Match telemetry to the kind of uncertainty you face:

  • For a known failure condition, define the telemetry, query, and alert that reveal when a healthy state has been violated. section 5.1.3
  • For failures you cannot fully predict, instrument flows between systems and states so traces can help locate where behavior changed. section 5.1.3
  • Aggregate telemetry across the platform so people can investigate interactions between services rather than seeing only their own team's view. section 5.2.1

From signal to decision

Suppose sustained CPU activity above 90% indicates that a Kubernetes cluster is not scaling as expected. Collect the relevant telemetry and alert when that known condition occurs. Separately, measure adoption of a new platform service against a first-month target of six teams. Both signals need clear queries, but they answer different questions: operational health and business value. section 5.1.3

Make telemetry useful without creating a new support burden. When stakeholders build separate spreadsheets around changing data structures, releases can break their reports and pull developers into repairs. A shared observability platform should make data accessible across services while fitting existing single sign-on and role-based permissions. Evolve the data and queries alongside the decisions people rely on them to make. section 5.0 section 5.2.1

How Effective Platform Engineering covers it

How deep it goes
Explains collection choices, alerts, tracing, aggregation, and access through operational scenarios; does not specify record schemas or emitter implementations.
Examples
Uses Kubernetes CPU activity, a platform-service adoption target, cross-service incidents, and spreadsheets broken by data-structure changes.
What it assumes
Assumes familiarity with applications, services, and operational incidents; introduces telemetry choices through use cases rather than teaching data schemas from zero.
What you can do after
Diagnose/debug with it by querying shared telemetry across services and defining alerts for known unhealthy states.
How it connects
Links telemetry to observability, tracing, service health, incident response, and role-based access control.

Also explained in

Compare how 8 books explain telemetry →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Effective Platform Engineering. The section links point to the parts of the book it draws on.