Skip to main content

Infrastructure Telemetry

Layer: infrastructure observability (the where)

Platform and infrastructure teams own this layer. The goal is not more host graphs. It is binding resource stress to the services and journeys that consume those resources.

Outcome

When service latency spikes, you can answer:

  • Which nodes, pools, or volumes are saturated?
  • Is degradation localized or fleet-wide?
  • Which workload labels tie infra signals to a owning service?

Core signals

CategoryExamples
ComputeCPU throttling, memory pressure, OOM kills
KubernetesPod restarts, pending pods, eviction events
NetworkLatency, packet loss, connection errors
StorageDisk I/O wait, queue depth, replication lag
Data planeConnection pool usage, replica lag, lock waits

Steps

1. Label everything with service identity

LabelPurpose
service.nameJoin to service catalog
deployment / workloadRollback correlation
environmentProd vs non-prod separation
region / zoneBlast radius

2. Collect platform metrics

SourceMinimum set
KubernetesNode and pod CPU/memory, restarts, scheduling failures
Managed DBCPU, connections, IOPS, replication lag
Load balancersHealthy targets, 5xx from edge

In the observability graph, infra nodes attach to service spans via time alignment and shared resource IDs (cluster, instance, pool name).

4. Alert on saturation before hard failure

PatternExample
Sustained CPU > 85%Scale or shed load before timeouts
Pool exhaustion trendAlert at 80% connections, not 100%
Disk latency p95Storage tier degradation

5. Regulated retention

Infra metrics often live in shorter retention than audit logs. Document tier and access separately from business and audit stores.

Release gate

  • Tier-1 services have infra metrics with service.name (or equivalent)
  • Database and queue saturation visible on dashboards
  • Infra alerts include linked service and recent deploy
  • Runbooks name scale, failover, and capacity actions