How do I line up OpenTelemetry log records with OpenTelemetry metric series for one service?

Tares lines up OpenTelemetry logs and metrics for one service when both carry the same primary service label, filled from the service.name resource attribute. One read of that service then returns the log lines and the metric values merged on one clock. The otlp connector takes both signals over OTLP, so you set the label once and point your exporter at Tares.

How it works

The OpenTelemetry connector receives OTLP/HTTP logs, traces and metrics at POST /v1/{logs,traces,metrics}. One otlp source ingests every service. Resource attributes, such as service.name, become labels, so everything an OTel SDK or Collector exports correlates by service with no per-service setup.

The alignment comes from one rule: every source that should share a timeline carries the same primary label. For OpenTelemetry that label is service, read from service.name.

• A log record from the checkout service arrives with service set to checkout.
• A metric point from the checkout service arrives with service set to checkout.
• Because both carry the same primary service label, Tares puts them on one timeline for that service.

The AI SRE guide uses the same pattern. Its metric, log and alert sources are all keyed by the same service label, and a single read of one service returns metrics, logs and alerts merged on one clock. You can keep logs and metrics in one otlp source, or split them across two otlp sources. Either way, give each source the same primary service label.

Set it up

1. Start Tares locally.

   tares up

2. Create the otlp source. Ask a connected agent to “use tares to create an OTLP source keyed by service”, or go to Sources → Add source → otlp in the console. There is no required config. The service label is the natural key. You can also send the same object to POST /api/sources.

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

3. If you want logs and metrics in separate otlp sources, create a second source with the same labels entry. Keep service as the primary label in both.

4. Point your exporter at Tares. OTLP/HTTP sends logs and metrics to /v1/logs and /v1/metrics under the endpoint you set. For gRPC, install the otlp-grpc extra with pip install 'tares[otlp-grpc]'. The receiver then listens on port 4317. You can change that with TARES_OTLP_GRPC_PORT, or set it to off to disable it.

   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. If your Tares has auth on, the exporter sends a Bearer Authorization header holding an ingest-scoped API key. Set it with the OTEL_EXPORTER_OTLP_HEADERS environment variable. Without auth, no header is needed.

6. Make sure your SDK or Collector sets service.name on both its logs and its metrics. A signal without it has no service value, so it cannot join the service’s timeline.

7. Verify. Recent events shows logs and metric points as they arrive. Explore lists your services under the service key. Open one service to see its log lines and metric values together.

8. To read the same timeline from an agent, start the MCP endpoint in a second terminal and connect your client.

   tares mcp

   Then ask, for example, “Use tares: what happened to checkout in the last 15 minutes?”. The client reads the service’s correlated timeline and answers from it.

What you get

• One timeline per service, with log lines and metric values merged on one clock instead of two separate views to compare by hand.
• No per-service setup. A new service that exports OTLP with a service.name shows up under the service key in Explore on its own.
• The same read for people and agents. You open the service in Explore, and a connected MCP client reads the same correlated evidence.
• A base for the rest of an incident workflow. Because the service label is shared, you can add other sources keyed by service, such as Prometheus alerts or a deploy webhook, and they land on the same timeline. Triggers keyed by service can then wake an agent with that timeline, as the AI SRE guide shows.

When something else fits

• If your metrics come from a Prometheus server rather than an OTel pipeline, use the prometheus connector and key it by the same service label. It lines up with OTLP logs the same way.
• If your logs come from a container rather than OTLP, the docker_logs connector also joins the same service timeline when it carries the same primary label.
• If you are only exporting traces and have no logs or metrics yet, the otlp source still receives them, but there is nothing to line up until a second signal arrives.

Related