How does an AI SRE read logs from Docker containers while investigating failed deploys?

Tares tails a running container’s logs with the docker_logs connector, one event per line, and labels them by service. Those lines share one timeline with that service’s alerts and metrics. When a deploy fails, the agent reads the log lines in the same window as the alert, so it can tie the failure to specific lines.

How it works

• The docker_logs connector tails a running container and stores one event per log line. All lines are kept by default, and the source polls every 5 seconds in the example below.
• You label the source with a service label marked primary. Give your metrics and alert sources the same service label and Tares builds one timeline per service, with logs, alerts and metrics merged on one clock.
• A trigger watching those sources wakes an agent when an alert event arrives. Tares keeps the alerting you already run and ingests what fired. The agent then reads the correlated timeline, so the error lines from the failed deploy sit next to the alert that tripped.
• You can also pull. A connected MCP client calls read for a service, such as api-server, and answers from the same correlated timeline.
• Tares needs access to the Docker daemon. Run taresd on the host, or mount the Docker socket and include the Docker CLI in the image.

The AI SRE guide walks through this whole chain, from log source to finding, on a demo system.

Set it up

1. Install Tares and start it. Then open the console.

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

2. Add the log source. You can ask a connected agent: “Use tares to find my running containers and ingest the api-server’s logs.” The agent scans your containers, dry-runs a few lines, then creates the source. Or go to Sources, Add source, docker_logs in the console, where Discover lists running containers to pick from.

3. Set container to the container or compose service name, and label the source by service:

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

4. If the container runs under Compose without a fixed container name, set container to the service name and add compose_file, an absolute path or one relative to where the daemon runs. The tail then follows restarts, which matters when a failed deploy restarts the container.

5. Cut noise if you need to. Set match to keep only lines matching a regex, such as ERROR|WARN. Set drop to skip lines matching a regex, such as access logs. Use label_pattern, a regex with named groups, to add per-line label context.

6. Verify. Open the source in the console. Recent events shows lines on the next poll. If nothing arrives, check that taresd can run docker logs for that container.

7. Line up the other signals. Give your Prometheus metrics and alert sources the same service label. To see the deploy itself on the timeline, add a webhook source with the same service label and event_type: deploy, and post to it from your CD pipeline. The agent then sees when the deploy landed next to when the errors started.

8. To investigate on demand, start the MCP endpoint in a second shell and connect your client.

tares mcp

Then ask: “Use tares: what happened to api-server in the last 15 minutes?” The client reads the correlated timeline for that service.

What you get

• Container log lines arrive as events labeled by service, so they line up with the alerts and metrics for the same service.
• An agent woken by a trigger starts from one correlated timeline instead of querying each system. It can name the failing lines from the deploy window.
• Your own MCP client gets the same evidence on demand, including any finding an earlier investigation wrote back, so you start from the last conclusion.
• Filters keep the timeline readable. match keeps error lines and drop removes access logs.
• Compose restarts during a bad rollout stay in the tail when you set compose_file.

The full field list is on the Docker logs connector page.

When something else fits

• If your services already ship logs through an OpenTelemetry pipeline, use the OTLP connector instead of tailing containers. The AI SRE guide lists it as the alternative for logs.
• If your containers are not reachable from a Docker daemon that taresd can use, tailing with docker_logs does not apply. Choose a connector that matches where your logs live.

Related