How do I label OpenTelemetry log records by service so they join the right timeline?

Tares labels OpenTelemetry log records by service when you declare a service label on an otlp source and mark it primary. The label reads the service field, which comes from the service.name resource attribute. Your logs then share a key with the metrics and alerts for the same service and land on one timeline.

How it works

The otlp connector receives OTLP/HTTP logs, traces and metrics. One source ingests every service you export, and resource attributes such as service.name become label fields. The service field comes from service.name, so you do not set up each service separately.

A label has a name and a field, and you can mark one label as primary. The primary label is the key Tares uses to line records up across sources. When your Prometheus metrics source and your alerts source carry a service label too, all three signals for a service merge on one clock. The AI SRE guide builds on this: every source is keyed by the same service label, and each service gets one correlated timeline that a trigger and an agent read from.

If your records do not carry a service attribute, a label can take a fixed value with the const key instead of a field. The Docker logs connector uses this form, for example a label named service with const set to api-server and primary set to true. Use const only when a source belongs to one service.

Set it up

1. Make sure something exports OTLP, such as an instrumented app or an OpenTelemetry Collector. For OTLP/gRPC, install the extra with pip install 'tares[otlp-grpc]'. The receiver then listens on port 4317.
2. Start Tares locally with tares up.
3. 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 this object. You can also send the same object to POST /api/sources.

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

4. Point your exporter at Tares. OTLP/HTTP posts to the logs, traces and metrics paths under the base URL, and gRPC uses 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

5. On a secured instance, the exporter sends a Bearer Authorization header holding an ingest-scoped API key. For example, set OTEL_EXPORTER_OTLP_HEADERS with the Authorization header and the Bearer key. You need this only when Tares has auth on.
6. Key your other sources the same way. Give your metrics and alerts sources a primary label named service, so the values match what the log records carry. The full connector details are on the OpenTelemetry connector page.
7. Verify. Recent events shows log records as they arrive, and Explore lists your services under the service key. Pick a service to see its logs next to its other signals.

What you get

• Log records, spans and metric points from every exporting service arrive through one source, each labeled by service.
• Logs share a key with that service’s metrics and alerts, so they appear on the same per-service timeline in Explore.
• Triggers and agents that key on service read logs together with the other evidence, so an investigation starts from one correlated view.
• A new service needs no extra Tares setup. Once it exports OTLP with a service.name, it appears under the service key.

When something else fits

• If your logs come from a container and not an OpenTelemetry pipeline, the Docker logs connector tails the container and takes a constant service label.
• If you only need to label one fixed service, a const label is simpler than reading a field. If many services share one exporter, keep the field-based label so each service gets its own timeline.

Related