How do I tell an AI SRE that slow database queries is a known issue with a documented fix?

Tares lets you attach your slow database queries runbook to the entity it affects as a reference document, so the fix is always surfaced when an agent correlates on that entity. A reference document is declarative material, not a stream, so it is returned regardless of the read time window. You tag the runbook with the entity’s labels, and the agent sees the known issue and its fix alongside live events.

How it works

The reference connector turns documents (json, csv, md or txt) into always-surfaced events. Each document you attach becomes one event, and you tag it with the labels of the entity it describes, such as service and environment.

• Not a stream. Event connectors age out of a read window. A reference document does not. A runbook written months ago is still returned in a 15-minute read.
• The config is the data. Each attachment carries its own name, format, content and labels. There is no poll interval and no entity key, because correlation is label-native.
• Labels become real Tares labels. The label names you declare on the source let reads correlate on them, and you can read and trigger on those labels. Each attachment supplies the values.
• Editing re-materializes the source. Change the runbook and Tares rebuilds the document event from the new content.

For slow database queries, write the runbook as a short document that names the symptom and the documented fix, then label it with the service or database entity that shows the symptom. When an AI SRE investigation correlates on that entity, the runbook comes back in the same timeline as the live events, so the agent can see that the slowness is a known issue and what the fix is.

Set it up

1. Write the runbook as a md or txt file. Name the symptom (slow database queries) and write down the documented fix, step by step.
2. In Tares, go to Sources → Add source → Reference documents.
3. Upload the file. Tares reads it into text.
4. Tag the document with the labels of the entity that shows the symptom, for example service=tares and environment=production. Use the same label names and values your other sources use for that entity, so the document correlates with them.
5. Click Create. To add more runbooks later, re-open the source and use Upload more.

You can also declare the source as YAML, or send the same object with POST /api/sources. Here is the shape from the reference documents connector, with a runbook for slow queries:

- name: runbooks
  connector: reference
  config:
    attachments:
      - name: slow-database-queries.md
        format: md
        content: |
          Known issue: slow database queries.
          Documented fix: write the steps of your fix here.
        labels: { service: tares, environment: production }
    labels:
      - { name: service, field: service }
      - { name: environment, field: environment }

The labels list at the bottom declares the label names so reads can correlate on them. The labels object on each attachment provides the values. The fields name and content are required on every attachment. format is one of json, csv, md or txt.

To check it, open the source. Recent events shows one event per document, and Fields shows the labels they carry. Then read the entity the document describes, for example by its service label, and the runbook comes back in the timeline even outside the read window.

What you get

• A known issue the agent can see. When an investigation reads the entity, the runbook is in the timeline next to the live events, so the documented fix is part of what the agent works from.
• No expiry. The document is returned regardless of the read time window, so you do not refresh it to keep it visible.
• One place to maintain the fix. Edit the attachment and the source re-materializes with the new content.
• Labels you can use elsewhere. The labels on the document are real Tares labels, so you can read on them and use them in triggers.
• Several runbooks per entity. Each attachment becomes its own event, so you can keep one document per known issue and add more with Upload more.

When something else fits

• If you want an agent to see the slow queries as they happen, add an event connector for your database or metrics. A reference document describes the known issue and its fix, it does not report new occurrences. The reference documents connector page covers the document side.
• If the knowledge is an agent’s own observation rather than a document you wrote, the memory connector holds notes an agent writes with the remember tool.

Related