What should I look for in Docker container logs when the problem is slow database queries?

Tares tails a container’s logs with the docker_logs connector, so you can keep the lines that point at slow queries and read them next to your latency metrics. Look for lines about statement duration, timeouts, waiting for a connection or lock, and warnings that start to repeat. The built-in agent and your MCP client read those lines on one per-service timeline, so you see which lines arrived before latency climbed.

How it works

The docker_logs connector tails a running container’s logs and turns each line into one event. It keeps all lines by default. Two optional regex filters narrow that down:

• match keeps only lines that match the regex, for example ERROR|WARN.
• drop skips lines that match the regex, for example HTTP/1.1" to drop access logs.

Give the source the same service label as your other sources. Tares merges every source with that label into one timeline per service, so logs, metrics and alerts sit on one clock. In the demo setup, a trigger watches those sources, and when it fires it wakes an agent that starts with the correlated timeline already in front of it. The agent writes what broke, since when, and a likely cause tied to evidence lines.

For slow queries, these are the lines worth surfacing:

• Duration lines. Any line from the database or the app that reports how long a statement or request took.
• Timeouts and cancellations. Statements that hit a limit, or requests that gave up waiting on the database.
• Waits. Lines about waiting for a connection from a pool or for a lock.
• Repeats. One warning that shows up again and again in a short stretch, or a new error that was not there before.

Tail the database container and the container of the service that calls it. The database shows the slow statements, and the caller shows the effect.

A trigger condition can also count events over a window. Counting matching events is a way to react to a rise in slow-query lines without anyone reading the lines themselves. Tares ingests the lines and the timeline correlates them. You choose the condition.

Set it up

1. Install Tares and start it. The docs install with uv or Homebrew:

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

2. Make sure taresd can reach the Docker daemon. Run it on the host, or mount the Docker socket and include the Docker CLI in the image.

3. Add a docker_logs source for the database container. Use Sources → Add source → docker_logs, or ask a connected agent: “Use tares to find my running containers and ingest the database container’s logs.” The agent calls discover_docker, then test_source for a dry run, then create_source.

4. Set container to the container name from docker ps. 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.

5. Add a match regex if you only want the lines that matter, and give the source a service label that matches your other sources:

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

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

7. To investigate from your own client, start the MCP endpoint and connect Claude Code to it:

   tares mcp
   claude mcp add --transport http tares http://localhost:8788/mcp

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

What you get

• One event per log line from the database and the calling service, filtered by the regex you choose.
• A per-service timeline where those lines sit beside metrics such as p99 latency and database connections, and beside the alerts Prometheus fires. You can see whether the lines came before or after the latency rose.
• A finding on the timeline when a trigger wakes an agent. It says what broke, since when, a likely cause tied to evidence lines, and a next action.
• A starting point for the next investigation. A connected client reads the evidence and the earlier finding, so it does not start from scratch.

For the full path from sources to triggers to agents, see Build an AI SRE. For how the signals fit together, see Use AI to monitor your systems. Connector fields are in Docker logs.

When something else fits

• If the logs come from a platform other than local Docker, use another log source. The monitoring guide lists OpenTelemetry (OTLP) and Vercel logs for that.
• If the symptom is visible in a table rather than in log lines, the Postgres connector reads new and changed rows of a table, and the Prometheus connector polls metrics by name or label.

Related