How do I show GitHub commits and pull requests against OpenTelemetry metric series?

Tares puts GitHub commits and pull requests on the same timeline as your OpenTelemetry metrics when both sources carry the same service label. The timeline orders them on one clock, so you or your agent can see whether a metric moved after a change. You set this up with an otlp source and a github source that share one service value.

How it works

Tares builds one timeline per service from every source that carries the same label. The AI SRE guide describes it as sources labeled by service, merged on one clock.

• The OpenTelemetry connector receives OTLP metrics, logs and traces. One source covers every service, and the resource attribute service.name becomes the service label.
• The GitHub connector with a personal token polls one repository every 2 minutes by default. It reports commits, and pull requests opened, merged or closed. Commits arrive as commit events and pull requests as pull_request events.
• A GitHub event carries repo as its label by default. You add a second label named service with a constant value that matches the service.name your app exports. That shared value joins the change to the metric series.

Open Explore, pick the service, and the metric points, commits and pull requests appear in time order. An agent reads the same timeline through MCP, so it can check whether a metric changed after a commit landed or a pull request merged.

Set it up

1. Create the OpenTelemetry source in Sources > Add source > otlp, or ask a connected agent to create an OTLP source keyed by service. It needs no required config, only the service label.

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

2. Point your exporter at Tares. Set the endpoint, and make sure the app’s service.name is the value you will use in step 4, for example checkout-api.

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

On a secured instance, the exporter sends an ingest-scoped API key as a Bearer Authorization header. That is needed only when Tares has auth on.

3. Add a GitHub credential. Create a fine-grained token with Metadata read, Contents read and Pull requests read. Open Settings > GitHub, choose Add a personal token, and paste it.

4. Add a source for each repository in Sources > Add source > GitHub, or with this object. The service label uses a constant that equals the OTel service.name. Keep repo as well if you want it as a label.

- 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 }

5. Verify. In Explore, pick checkout-api under the service key. You see metric points next to commits and pull requests. Then ask your connected agent:

Use tares: what happened to checkout-api in the last 15 minutes?

The first GitHub poll imports recent commits and no old pull requests, so earlier history does not appear. Each commit’s changed files are added to its payload by default, which gives the agent more to read next to the metric.

What you get

• One timeline per service that holds metric series, commits and pull requests in time order.
• Labels on GitHub events that you can use in a trigger or read from an agent: repo, action, author, branch, sha, title, number and url when they apply. A closed pull request that merged reads merged.
• An agent that starts from the correlated read. It can tie a metric change to a specific commit or merged pull request instead of searching GitHub separately.
• A trigger you can scope to changes. For example, a trigger on the github source can fire for every merged pull request in chosen repositories, using event_type equal to pull_request and action equal to merged.
• Findings the agent writes back, which land on the same service timeline for the next investigation.

When something else fits

• If you want pushes, reviews, releases and CI runs as they happen, connect the GitHub App instead. It delivers push events, not commit events, and covers every repository it is installed on in one source.
• If your metrics come from a Prometheus server rather than OTLP, use the Prometheus connector. The same shared service label approach applies, and the AI SRE guide shows it end to end.

Related