Missing Service Name

Problem

Some of your telemetry arrives without the service.name resource attribute. OpenTelemetry requires it: it’s the one field that says which service produced a trace, metric, or log. Without it, that data can’t be attributed to anything.

Common sources:

• An SDK initialized without a resource, so it falls back to unknown_service, or a Collector strips the field before export.
• A Collector pipeline that rewrites or drops resource attributes.
• A custom exporter or legacy agent that never set the field.

Insights flags any payload (traces, metrics, or logs) whose resource attributes lack service.name, and includes the resource attributes it did find, so you can work out which workload is sending the anonymous data.

Impact

• The telemetry can’t be grouped, searched, or alerted on per service.
• Dashboards and service maps show gaps or an unknown_service blob.
• Nobody owns the data, so nobody fixes or trims it; it just accrues cost.

Example

Anonymous telemetry:

# resource attributes
telemetry.sdk.language: go
telemetry.sdk.version: 1.32.0
# service.name is missing: whose spans are these?

Identified telemetry:

# resource attributes
service.name: checkout
service.namespace: shop
deployment.environment.name: production

How to fix

1. Use the resource attributes reported with the finding to identify the workload (a pod name or host often gives it away).
2. Set the service name in that workload’s SDK setup: the OTEL_SERVICE_NAME environment variable is the quickest way, or set it in the resource when initializing the SDK.
3. If the SDK is configured correctly, check your Collector pipeline for a processor that drops or rewrites resource attributes.

Expected gains

Every signal becomes attributable: per-service dashboards, alerts, and ownership all start working, and the service starts contributing to your Instrumentation Score, tracked like the rest of your fleet.

See the Insights catalog for everything Insights can detect.