Missing Service Instance ID

Problem

A service emits telemetry without the service.instance.id resource attribute. The service is identified, but its replicas aren’t: ten pods look like one anonymous blob, and there’s no way to tell whether a problem lives in one instance or all of them.

Insights checks traces, metrics, and logs uniformly and flags services whose telemetry lacks the attribute.

Impact

• “Is it one bad pod or the whole deployment?” becomes unanswerable from telemetry alone.
• Instance-level patterns (a memory leak in one replica, a node-local issue) hide inside aggregated data.
• Debugging falls back to correlating timestamps with infrastructure logs.

Example

Anonymous replicas:

# resource attributes
service.name: checkout
# which of the 10 pods sent this?

Distinguishable:

# resource attributes
service.name: checkout
service.instance.id: 27c1e-x2lqp # unique per instance

How to fix

1. Set service.instance.id in the SDK’s resource configuration: a pod name, hostname, or a UUID generated at startup all work, as long as each instance gets its own value.
2. On Kubernetes, the resource detectors (or the Collector’s k8s attributes processor) can derive it automatically.
3. Keep it stable for the lifetime of the instance, not per request.

Expected gains

Per-instance filtering works: you can isolate the sick replica, compare instances side by side, and answer “one pod or all of them?” in seconds.

See the Insights catalog for everything Insights can detect.