How do I cut the noise in logs from Docker containers before an AI SRE reads them?

Tares cuts Docker log noise at the source with the match and drop regex settings on the docker_logs connector, then hands an AI SRE a window summary. The connector tails a container one event per line, and all lines are kept by default. Set match to keep only the lines you care about and drop to skip the ones you do not, such as access logs. A schedule trigger then gives the agent counts per label instead of raw lines.

How it works

Noise is cut in three places, from the source to the agent.

• match on the docker_logs connector keeps only lines that match a regex, for example ERROR|WARN. The default is all lines.
• drop skips lines that match a regex, for example HTTP/1.1" to drop access logs.
• label_pattern is a regex with named groups. It turns parts of each line into per-line label context, so the lines you keep carry fields you can count.

The second layer is the trigger. A trigger can filter events by field, with a field, an op and a value, so a rule only sees the events that matter. A schedule trigger goes further. It fires every interval for all the events of its sources and wakes the agent with a summary of the window instead of raw lines. For each label you name, the summary gives the count per value in this window against the window before, largest change first, plus a few recent lines. A stream of tens of thousands of lines becomes a page the model can read.

The Watch, then escalate guide builds on this summary. A cheap triage agent reads it every few minutes and says “normal” most of the time. Only when something moves does it hand that one entity to the main root-cause agent. This is the first level in front of the AI SRE.

Set it up

1. Add the docker_logs source in the console under Sources, Add source, docker_logs, or ask a connected agent to find your running containers and ingest the logs. Set container to the container or compose service name. If the container runs under Compose, set compose_file so the tail follows restarts.
2. Add match or drop to the source config. Label the fields you want counted, such as service, and mark one label primary.

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

3. 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>, the same access the connector needs.
4. Add a schedule trigger on the source, so the agent reads a window summary. Name the labels to count in summary_by. The interval is at least 1m.

triggers:
  - name: watch-web
    sources: [logs]
    key_field: service
    condition:
      every: 10m                          # at least 1m
      summary_by: [service, status_code]  # labels to count; default: the trigger's key field

5. Create a triage agent on the trigger and seed its prompt from the Triage (on a schedule) preset. Choose a small model and set a budget. At a 10 minute interval the agent runs 144 times a day, which is above the default limit of 50 runs per agent per day. Raise the limit under Settings, Agents.
6. Hand the flagged entity to a main agent for root cause, as described in Watch, then escalate.

What you get

• Only the lines you want leave the container. Health checks and access logs never reach the agent when you drop them.
• Labeled lines. With a label_pattern or fixed labels, each event carries fields that can be counted and filtered.
• A short read for the model. It sees what changed per label value, largest change first, not tens of thousands of lines.
• Low cost. A small model reading a summary costs well under a cent a run, and the thorough main agent runs only when triage flags an entity, at most once per cooldown per entity.
• A full record. Each tick, triage verdict, handoff and root-cause note sits on the entity’s timeline.

When something else fits

• If you need every line kept for later search, leave match and drop empty and do the narrowing in trigger filters and the window summary instead.
• If you want to react to a specific condition, such as a count of errors in a window, a condition trigger with filters fits better than a schedule trigger. The schedule trigger fires whether or not anything happened.
• If the logs come from a different tool, such as a Loki instance, pick the connector for that source from the connectors index.

Related