How do I show GitHub App events beside logs from Docker containers for an AI SRE?

Tares puts GitHub App events and Docker container logs on one timeline when both sources carry the same label. The agent then reads the change and the log lines in time order and can check whether the first error lines start after the change. You connect the GitHub App, add a docker_logs source, and give the log source the same label value that the GitHub events carry.

How it works

Tares builds one timeline per value of a label that your sources share. The Build an AI SRE guide keys its metrics, logs and alerts sources on one label and gets one merged timeline for each value. You do the same here with a change source and a log source.

• GitHub App events arrive as they happen, by webhook. They include pushes, pull requests, reviews, releases and CI runs (workflow_run). Every event carries the repo label, plus action, branch, sha, title and others when they apply. See GitHub for the full list.
• Docker logs are tailed from a running container, one event per line, by the docker_logs connector. You choose the labels on that source.
• The join happens on the label. The GitHub events already carry repo, so you give the log source a repo label with a fixed value, the repository that builds the container.

Both sources write to the same timeline, ordered by time. A push event for a repository, followed by error lines from its container, appear as neighbours. The agent reads that one timeline through the MCP read surface, or receives it when a trigger wakes it.

Set it up

1. Connect the GitHub App. On Tares Cloud, open your workspace settings, choose Connect GitHub, pick the organization and repositories, and confirm on GitHub. Self-hosted, open Settings > GitHub, choose Create GitHub App, confirm on GitHub, then choose Install on GitHub and pick the repositories. Tares stores the App as a credential and creates a github source for its webhook. You paste nothing by hand.

2. Make a local Tares reachable. GitHub must reach your Tares for webhooks to arrive. A local tares up is not reachable from the internet, so run a tunnel and use its address as the public URL:

cloudflared tunnel --url http://localhost:8787
TARES_PUBLIC_URL=https://<your-tunnel>.trycloudflare.com tares up

3. Add the Docker log source. Run taresd on the host so it can reach the Docker daemon. Alternatively, mount the Docker socket and include the Docker CLI in the image. Go to Sources > Add source > docker_logs, use Discover to pick the container, and set the repo label to the repository the GitHub App watches:

- name: logs
  connector: docker_logs
  poll: 5s
  config:
    container: tares-demo-api-server   # the container name (docker ps)
    labels:
      - { name: repo, const: acme/checkout-api, primary: true }

If the container runs under Compose without a fixed container_name, set container to the service name and add compose_file so the tail follows restarts. To keep the timeline readable, set match to a regex such as ERROR|WARN, or set drop to skip access logs.

4. Check both sources. Open each source in the console. Recent events shows Docker lines on the next poll, and GitHub events as deliveries arrive. If nothing arrives from the App, check that Tares is reachable at the address the App uses and that the App is installed on the repository. If nothing arrives from Docker, check that taresd can run docker logs on the container.

5. Read the timeline. In Explore, pick the repository value. Push or merge a pull request, then watch the change event and the container’s log lines appear in time order. Ask your connected agent: “Did the errors start after the last push?” The agent answers from the one correlated read.

What you get

• One timeline where a push, a merged pull request, a release or a failed CI run sits right beside the container’s log lines.
• A direct way for the agent to compare timestamps: the change event comes first, the first error line comes after it, or it does not.
• Event details the agent can cite, such as sha, branch, title, author and action on the GitHub side, and the exact log lines on the Docker side.
• Coverage of every repository the App is installed on, in one github source. Webhook deliveries are verified against the App’s secret, and a delivery GitHub sends twice is stored once.
• A base for triggers. The github source can be used in a trigger, as in the merged pull request example on the GitHub page, so a change can wake an agent.

When something else fits

• If you use a personal token, not the App, you get commits and pull requests opened, merged or closed, polled every 2 minutes. That is fine for coarse change history but slower than webhook delivery.
• If your logs come from an OpenTelemetry pipeline, not from a container on the host, use the OTLP connector for the log side. The labeling idea stays the same.

Related