How do I show GitHub commits and pull requests against Prometheus metrics?

Tares shows GitHub commits and pull requests next to Prometheus metrics by giving both sources the same service label. Tares then merges them into one timeline per service in time order. Your agent or you can check whether a metric moved after a change landed.

How it works

Tares joins events on a shared key. Each source declares a primary label, and every source that carries the same value for it lands on the same entity timeline.

• The prometheus source polls the metrics you pick and stores each series as a metric event. The numeric value is kept in a number-typed value label, so a trigger can aggregate it. The service comes from a label such as metric.service.
• The github source polls a repository’s commits and its pull requests opened, merged or closed. With a personal token it polls every 2 minutes by default. Commits arrive as commit events and pull requests as pull_request events. Each carries labels such as repo, action, author, sha and title.
• You add a service label to the GitHub source with a constant value that equals the service name your metrics carry. Both sources are then keyed by the same service, and Tares puts commits, merges and metric samples on one clock.

The agent reads that single timeline. A merge at 14:02 followed by a rise in a metric at 14:04 shows up as two adjacent events for one service. For the full picture of how timelines, triggers and agents fit together, see AI SRE.

Set it up

1. Install Tares and start it. The console opens at http://127.0.0.1:8787.

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

2. Add the Prometheus source under Sources > Add source > Prometheus. Enter the base URL, run Discover, and tick the metrics you want, by name or by label. Tares generates the selector, so you write no PromQL. See Prometheus for every field. Make sure the primary label is service.

3. Give Tares access to GitHub. Under Settings > GitHub, choose Add a personal token and paste a fine-grained token with Metadata, Contents and Pull requests read access. The GitHub page also covers the GitHub App, which delivers events as they happen.

4. Add a GitHub source for each repository under Sources > Add source > GitHub. Pick the credential and the repository, and add a service label with a constant value that matches your metrics. Both sources in config form:

- name: metrics
  connector: prometheus
  poll: 10s
  config:
    url: http://localhost:9090
    queries:
      - promql: '{__name__=~"(pg_stat_database_xact_commit|pg_up)"}'   # generated from your picks
        by_name: true
    labels:
      - { name: service, field: metric.service, primary: true }
      - { name: value, field: value, type: number }   # the metric value, aggregate it in triggers
- 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. Check the result. Open each source and look at Recent events and Fields. Then open Explore and pick the service. You see metric samples and GitHub events merged in time order.

6. To investigate with your own agent, start the MCP endpoint in a second terminal and connect your client.

tares mcp

Ask something like: what changed on checkout-api before its metrics moved? The agent answers from the correlated timeline.

What you get

• One timeline per service with commits, pull requests and metric samples in time order.
• Change context on every metric move: who changed what, which pull request merged, and the commit sha, title and url, right beside the series that moved.
• A numeric value label on metric events, so a trigger can aggregate it while the agent still sees the GitHub events around it.
• A filterable stream of GitHub events. For example, a trigger can match event_type equal to pull_request and action equal to merged for a set of repositories.
• An agent that starts from evidence, with the change and the metric on the same page of context instead of in two tools.

When something else fits

• If you need pushes, reviews, issues, releases or CI runs on the timeline, use the GitHub App path. It delivers events by webhook, covers every repository it is installed on in one source, and needs GitHub to reach your Tares, so a local setup needs a tunnel.
• If you want to react to alerts your Prometheus rules already fire, add the alerts source next to the metrics and keep alerting where it is. The metric-and-change timeline then supports the investigation after the alert.

Related