How does an AI SRE read OpenTelemetry log records while investigating failed deploys?

Tares receives OpenTelemetry log records through the otlp connector and labels them by service, so an AI SRE reads them on the same per-service timeline as the alert. You create one otlp source, point your exporter at Tares, and the agent reads the log lines for the failing service next to the alert that woke it. The same source takes traces and metrics too.

How it works

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

• Labeling. The service label reads resourceAttributes.service.name and is the primary key. A label reads its value by path from the event: resourceAttributes for resource attributes, attributes for the attributes of a log record, span or data point, and text for the rendered log line. There is no bare service field, so a label with field: service gets no value from an OTLP event.
• One timeline. Sources that carry the same service label merge into one timeline per service, on one clock. Log lines from your OTLP source sit beside alerts and metrics for that service.
• Two ways the agent reads. A trigger can wake an agent with the correlated timeline when an alert arrives. You can also connect an MCP client and ask about a service, and it answers from the same correlated read.

For the full connector reference, see the OpenTelemetry connector page. For the end-to-end incident flow, see Build an AI SRE.

Set it up

1. Install Tares and start it locally.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up

2. Create the otlp source. In the console, go to Sources, then Add source, then otlp. No connector-specific config is required, only the service label. You can also ask a connected agent to create an OTLP source keyed by service, or POST /api/sources with the same object.

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

3. Point your exporter at Tares. Use OTLP/HTTP, or gRPC if you install the otlp-grpc extra, which listens on 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. If Tares has auth on, the exporter sends a Bearer Authorization header holding an ingest-scoped API key. If auth is off, it needs no header.

5. Check that logs arrive. Recent events shows log records as they come in, and Explore lists your services under the service key.

6. Connect your agent. For on-demand investigation, start the MCP endpoint in a second shell and point your MCP client at it.

   tares mcp

   Then ask: what happened to your service in the last 15 minutes? The client calls read for that service and answers from the correlated timeline. For automatic investigation, add a trigger over the sources keyed by service and subscribe an agent to it.

7. Add deploys to the same timeline. Create a webhook source with a primary service label and event_type: deploy, and post to its ingest URL from your CD pipeline on every deploy. Each post lands as a deploy event on that service’s timeline, so the agent sees the deploy next to the error logs that follow it.

What you get

• Log lines from every instrumented service in one source, labeled by service.
• A per-service timeline where the alert, the log records and any deploy event share one clock, so the agent reads the lines around the failure in one pass.
• An agent that is woken by a trigger with that timeline already assembled, or that you query through MCP.
• A finding the agent writes back onto the service’s timeline, so the next investigation starts from the previous conclusion.
• No per-service setup. A new service that exports OTLP with a service.name appears under the service key automatically.

When something else fits

• If your logs come from a container you run on one host, the docker_logs connector tails them directly. Both can feed the same service timeline.
• If you only want alert delivery without log reading, use the alertmanager or prometheus_alerts connector and let the agent read what is already on the timeline.

Related