What should I look for in OpenTelemetry log records when the problem is failed deploys?

Tares lets you look for the first error lines on a service right after a deploy event, because OTLP logs and deploys land on one timeline per service. Send your OpenTelemetry logs to an otlp source keyed by service, add a deploy event from your CD pipeline, and compare the log lines before and after it. A Tares trigger can count matching events over a window, so you watch the change in counts instead of reading raw lines.

How it works

Tares receives OTLP/HTTP logs at POST /v1/logs. One otlp source ingests every service, and resource attributes such as service.name become labels, so the logs correlate by service with no per-service setup.

Each log event carries three things you can read or label:

• resourceAttributes.<key>: where the service name lives, as resourceAttributes.service.name.
• attributes.<key>: the attributes of the log record.
• text: the rendered log line.

There is no bare service field. A label with field: service gets no value from an OTLP event.

For failed deploys, look for these things in the records:

• The service. Check that the failing lines carry the same service label as your deploy event. That shared label puts them on one timeline.
• The timing. Find the first error line after the deploy event. A pattern like “deploy landed 14:02, errors started 14:04” points at the change.
• The count. Compare how many error lines the service logs before and after the deploy. A jump right after the deploy matters more than any single line.
• The line text and record attributes. Use text and attributes.<key> to see which failure repeats.

Tares merges these logs with your other sources into one timeline per service. In the console, Explore lets you flip to What the agent gets to see the exact text an agent receives. A trigger watches the sources for a service and fires on a condition you choose. A condition can aggregate with count over a window, so the count change is computed for you rather than eyeballed from raw lines.

Set it up

1. Start Tares.

   tares up

2. Create an otlp source keyed by service. In the console, go to Sources, then Add source, then otlp, or ask a connected agent to create it.

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

3. Point your exporter or OpenTelemetry Collector at Tares. For gRPC, install the otlp-grpc extra first.

   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

   The sender uses a Bearer Authorization header holding an ingest-scoped API key, needed only when Tares has auth on.

4. Add the deploy signal, since most root causes are a change. Create a webhook source with a primary service label, event_type: deploy and a text template. Creating it gives you a stable ingest URL.

   - name: deploys
     connector: webhook
     config:
       event_type: deploy
       text_template: 'deploy {commit} by {author}: {message}'
       labels:
         - { name: service, field: service, primary: true }

5. Add one line to your CD pipeline, run on every deploy.

   curl -X POST https://<your-tares>/ingest/<ingest_key> \
     -H 'content-type: application/json' \
     -d '{"service": "checkout", "commit": "9f2c81d", "author": "dana", "message": "raise db pool size"}'

6. Connect an MCP client and ask about the window around the deploy. Start the endpoint with tares mcp, then ask: “Use tares: what happened to checkout in the last 15 minutes?” The client reads the correlated timeline for that service.

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

The Build an AI SRE guide walks through the same pattern end to end, including a trigger that wakes an agent and a finding written back to the timeline.

What you get

• Logs and deploys for a service on one clock, so the question “did the errors start after the deploy?” is answered by reading one timeline.
• One otlp source for every service. Resource attributes become labels, so you add no per-service setup.
• Triggers that count matching events over a window, so a change in counts can wake an agent.
• A finding written onto the service’s timeline when an agent runs. The next investigation, yours or another agent’s, starts from that conclusion.
• The same evidence for interactive work. Claude Code, Cursor and any other MCP client read the same timeline.

For how the pieces fit together, see Use AI to monitor your systems. The OTLP reference is on the OpenTelemetry connector page.

When something else fits

• If your deploys already reach you as GitHub commits and pull requests, the github connector can supply the deploy signal instead of a webhook call from your pipeline.
• If your logs come from containers or Vercel rather than OpenTelemetry, use the Docker logs or Vercel connectors and keep the same service label.

Related