Why are my traces and metrics going to "unknown_service" or "unknown_metrics" datasets?

Last updated: November 2, 2026

When data lands in a dataset named unknown_service (or one starting with unknown_service:) or unknown_metrics instead of the dataset you expected, Honeycomb could not tell which service or dataset the data belonged to. The cause and fix are different for traces and metrics.

Traces: the unknown_service dataset

Honeycomb routes trace data to datasets based on the service.name resource attribute. If your application does not set one, OpenTelemetry SDKs fall back to a default value that starts with unknown_service, and your data is routed to a dataset with that name.

To fix it, set the service.name resource attribute in your OpenTelemetry configuration, for example with the OTEL_SERVICE_NAME environment variable or in your SDK's resource setup. The value you set becomes the dataset name, so make sure it matches the dataset you want.

Metrics: the unknown_metrics dataset

What happens depends on which metrics experience your environment uses:

  • With the current metrics experience, Honeycomb routes all metrics automatically to a managed dataset named Metrics. The x-honeycomb-dataset header is no longer used for metrics, and unknown_metrics does not apply.

  • With the legacy metrics experience, metrics go to the dataset named in the x-honeycomb-dataset header. If that header is missing, they go to unknown_metrics.

So if you see metrics arriving in unknown_metrics, your environment is on the legacy metrics experience and your exporter is not sending the dataset header. Add it where you configure your OTLP exporter:

export OTEL_EXPORTER_OTLP_HEADERS="x-honeycomb-team=your-api-key,x-honeycomb-dataset=your-metrics-dataset"

Or, if you send metrics through an OpenTelemetry Collector:

exporters:
  otlp/metrics:
    endpoint: "api.honeycomb.io:443" # US instance
    headers:
      "x-honeycomb-team": "YOUR_API_KEY"
      "x-honeycomb-dataset": "YOUR_METRICS_DATASET"

For more detail, see Send Application Metrics to Honeycomb.

Keeping unidentified data out entirely

If you would rather drop telemetry that has no service.name than have it land in unknown_service, you can use the OpenTelemetry Collector's filter processor to drop data that is missing the attribute. See Filter with the Filter Processor.

If data still shows up in unexpected datasets after these changes, reach out to Honeycomb Support and we can dig into your specific setup.