How does an AI SRE read logs from Docker containers while investigating 5xx errors on an API?

Tares tails a running container’s logs with the docker_logs connector, one event per line, and labels them by service. When the alert for a 5xx spike arrives, the agent reads the API’s log lines on the same timeline and clock as the alert and the metrics. You connect the source once, and every investigation of that service starts from the correlated evidence.

How it works

The docker_logs connector polls a container you name and turns each log line into an event. It keeps all lines by default, and you can narrow them with regex filters.

The label is what ties the logs to the rest of your evidence. You give the log source a primary service label, and you give your alert and metric sources the same service label. Tares then builds one timeline per service. For an API called api-server, the 5xx alert, the metric that tripped it and the error log lines sit on one clock.

An agent reaches that timeline in two ways:

• Pull. A connected agent calls read with the service name and answers from the correlated read.
• Push. A trigger watches the alert source, fires when an alert event arrives, and wakes a Tares agent. That agent reads the timeline, ties the failure to specific log lines and writes a finding back onto the service’s timeline.

The next investigation then starts from that finding instead of from scratch. The AI SRE guide walks through the full loop with a demo API that produces 5xx spikes.

Set it up

1. Give Tares access to the Docker daemon. Run taresd on the host, or mount the Docker socket and include the Docker CLI in the image. Install and start Tares:

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

2. Add the log source. The quickest route is to ask a connected agent: “Use tares to find my running containers and ingest the api-server’s logs.” The agent scans the running containers, dry-runs a tail of a few lines, then creates the source. You can also go to Sources, Add source, docker_logs, set container to the container or compose service name, and use Discover to pick from running containers.

3. Label it by service. Use the same object the console saves:

- 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. Handle Compose and filters. 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. Use match to keep only matching lines, for example ERROR\|WARN. Use drop to skip noise. Be careful with drop on an API: dropping access lines removes the status codes you need for 5xx work, so keep them unless they swamp the timeline. Use label_pattern, a regex with named groups, if you want per-line label context.

5. Key the alerts the same way. Give your alert source, and your metrics source if you have one, a service label with the same value, api-server here. That shared label is what puts the alert and the log lines in one window.

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 on that container.

7. Connect your agent. Start the MCP endpoint in a second shell and point your client at http://127.0.0.1:8788/mcp:

tares mcp

Then ask: “Use tares: what happened to api-server in the last 15 minutes?”

What you get

• One timeline for api-server with log lines, alerts and metrics merged on one clock, visible in Explore.
• An agent that reads the error lines around the moment a 5xx alert fired, instead of querying each system separately.
• Automatic first looks. A trigger on the alert source wakes an agent, which writes a finding naming what broke, since when, the likely cause tied to evidence lines, and a next action.
• A timeline that improves over time. Findings stay on the service, so the next investigation, yours or an agent’s, begins with the earlier conclusion.
• Control over volume. match and drop filters keep the log stream focused on what matters for the incident.

When something else fits

• If your logs already flow 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 API does not run in Docker, docker_logs does not apply. Pick the connector that matches where the logs live, from the connectors index.

Related