How does an OTLP source know which service each log, span or metric came from?

Tares reads the service from the resource attributes your OpenTelemetry exporter sends, and turns service.name into a label called service. One otlp source ingests every service, so logs, traces and metrics correlate by service with no per-service setup. Explore lists the services under the service key.

How it works

An otlp source receives OTLP/HTTP logs, traces and metrics as POST requests to /v1/logs, /v1/traces and /v1/metrics. You create one source and every instrumented service exports into it.

Each OTLP payload carries resource attributes that describe where the data came from. Tares exposes those attributes as label fields. The attribute service.name becomes the field named service, and you declare a label on that field.

• One source for all services. You do not create a source per service. The service name travels with every log, span and metric point.
• Resource attributes become labels. Any resource attribute is available as a label field, and service is the one that comes from service.name.
• The primary label is the natural key. The service label is marked primary, so events from different services are grouped and correlated under it.
• All three signals share the key. A log line, a span and a metric point from the same service carry the same service label, so they line up when you correlate them.

The otlp connector has no connector-specific fields. Its only configuration is labels. This is part of how Tares supports the investigation flow described in AI SRE: the service label gives every signal a common handle.

Set it up

1. Create the source. Ask a connected agent: “Use tares to create an OTLP source keyed by service.” The agent calls create_source. Or open Sources, choose Add source, pick otlp and save. No config is required.
2. If you prefer to define it yourself, use this source object, either in the UI or by sending it with POST /api/sources:

- name: otel
  connector: otlp
  config:
    labels:
      - { name: service, field: service, primary: true }

3. Point your exporter at Tares. For OTLP/HTTP, set the endpoint to your Tares daemon. For gRPC, use port 4317:

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:8787   # OTLP/HTTP → /v1/{logs,traces,metrics}
# or gRPC (otlp-grpc extra): OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

4. For gRPC, install the extra first with pip install 'tares[otlp-grpc]'. The receiver listens on 4317. Set TARES_OTLP_GRPC_PORT to change the port, or to off to disable it.
5. Make sure your services set service.name in their OpenTelemetry resource. An OTel SDK or Collector usually does this from its configuration. That attribute is what fills the service label.
6. If your Tares has auth on, the exporter sends a Bearer Authorization header holding an ingest-scoped API key. Without auth, no header is needed.
7. Verify. Recent events shows spans, logs and metric points as they arrive. Explore lists your services under the service key.

For the full connector reference, see the OpenTelemetry otlp connector page.

What you get

• Automatic service identity. Every log, span and metric point is tagged with the service it came from, read from service.name.
• No per-service setup. A new service starts exporting and appears in Explore under the service key. You do not add a source or edit config for it.
• Cross-signal correlation. Logs, traces and metrics from one service share a label, so you can look at them together.
• A clear check. Recent events confirms data is arriving, and the service list in Explore confirms each service was recognised by name.
• Room for more labels. Because resource attributes are label fields, you can add more labels beside service in the same labels list when you need another way to group events.

The service label is only as good as the service.name your exporters send. If a service does not set it, fix it in the exporter or Collector configuration, and the service appears under its name once data flows again.

When something else fits

• If your data does not arrive as OTLP, such as a vendor that posts its own JSON, use the webhook connector instead and declare labels for the fields its payload carries.
• If you want Tares to pull metrics from a Prometheus server rather than receive them, use the Prometheus connector, which polls on an interval.

Related