How do I show GitHub commits and pull requests beside OpenTelemetry log records for an AI SRE?

Tares shows GitHub commits and pull requests beside OpenTelemetry log records when both sources carry the same service label. Create an otlp source that reads service from the resource attribute service.name, and a github source with a service label set to the same value. The agent then reads one time-ordered timeline per service and can check whether the first error lines start after the change. This is the same per-service correlation that the Build an AI SRE guide uses for metrics, logs and alerts.

How it works

Tares builds one timeline per service from every source that carries a service label. Two sources feed this one:

• OpenTelemetry logs. The OTLP connector receives OTLP/HTTP logs, traces and metrics. One source ingests every service. A label reads its value by path, so the service label is resourceAttributes.service.name. The rendered log line is available as text. There is no bare service field, so a label that uses field: service gets no value from an OTLP event.
• GitHub changes. The GitHub connector with a personal token polls one repository every 2 minutes by default. It reports commits (event_type is commit) and pull requests opened, merged or closed (event_type is pull_request, with an action label such as merged).

A GitHub source has no service field in its events, so you give it one. A label with const sets a fixed value. Put the same value there that your application reports as service.name, and the commits and pull requests land on the same timeline as that service’s log lines. Both kinds of event are then merged on one clock. The agent reads that timeline with one call and sees a merged pull request, then the first error lines, in order.

Set it up

1. Start Tares and, in a second shell, the MCP endpoint your agent reads from.

   tares up
   tares mcp

2. Add an OTLP source keyed by service. In the console choose Sources, Add source, otlp, or use this definition:

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

3. Point your exporter or OpenTelemetry Collector at Tares:

   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

   When Tares has auth on, the exporter sends a Bearer Authorization header holding an ingest-scoped API key. Without auth, no header is needed.

4. Create a personal token on GitHub with Metadata, Contents and Pull requests read. In Settings > GitHub choose Add a personal token and paste it.

5. Add one GitHub source per repository, under Sources, Add source, GitHub, and give it a service label with the same value as the service’s service.name. Here the service is checkout-api:

   - name: checkout-api
     connector: github
     poll: 2m
     config:
       repo: acme/checkout-api
       credential: github
       labels:
         - { name: service, const: checkout-api, primary: true }
         - { name: repo, field: repo }

   Keep prs at its default of true so pull requests are reported with the commits. The first poll imports recent commits and no old pull requests.

6. Open Explore and pick the service. Recent events on each source also shows events as they arrive. You see commit and pull_request events interleaved with the log lines.

7. Ask your connected agent, for example:

   Use tares: what happened to checkout-api in the last hour, and did errors start after the last merge?

   The agent calls read with the service and answers from the correlated timeline.

What you get

• One timeline per service with commits, merged pull requests and OpenTelemetry log lines in time order.
• An agent that can answer the question every incident starts with: did the first error lines come after a change? It does not have to query GitHub and your logs separately.
• GitHub events that carry their own labels, such as repo, action, author, branch, sha, title and url, so the agent can name the pull request or commit it suspects.
• Triggers that can use the same events. A trigger on the github source with event_type equal to pull_request and action equal to merged fires once per merged pull request.
• The same service key for later additions. Metrics, alerts and deploy events that carry the same service label join the timeline without extra wiring.

When something else fits

• If you want GitHub events as they happen and across every repository in one source, use the GitHub App. It delivers pushes, reviews, issues, releases and CI runs by webhook. Its events carry the repo label, so check in Explore that they line up with your service names before you rely on them.
• If your changes ship through a CD pipeline rather than GitHub, the Build an AI SRE guide shows a webhook source that records each deploy with a service label.

Related