How do I tell an AI SRE that high latency is a known issue with a documented fix?

Tares lets you attach your high latency runbook to the affected entity as a reference document, so it comes back whenever the AI SRE correlates on that entity. A reference document is declarative material, not a stream, so it is always surfaced regardless of the read time window. You tag the runbook with the entity’s labels, such as service and environment, and the fix travels with the entity.

How it works

The reference connector holds documents (json, csv, md or txt) that describe an entity: project notes, schemas and runbooks. Each document is tagged with the labels of the entity it describes, for example service=tares and environment=production.

The key difference from event connectors is that a reference source is not a stream. A log line or an alert ages out of a 15-minute read. A runbook does not. When the AI SRE reads or correlates on an entity, every document attached to that entity’s labels is surfaced, whatever the read time window is.

• The config is the data. Each attachment carries its own name, format, content and labels.
• Each attachment becomes one always-surfaced event.
• There is no poll interval and no entity key. Correlation is label-native, so the labels you tag a document with are what connect it to the entity.
• The labels become real Tares labels that you can read and trigger on.
• Editing the source re-materializes it.

For the high latency case, write the symptom and the documented fix into one document and attach it to the service that shows the latency. The next time the AI SRE looks at that service, the runbook is in the timeline next to the live events. For the wider picture of how Tares investigates, see AI SRE.

Set it up

1. Write the runbook as a text or markdown file. Name the symptom, for example high-latency.md, and put the documented fix steps in the body.
2. Decide which entity the fix applies to and note its labels, such as service and environment.
3. In Tares, open Sources → Add source → Reference documents. Upload your json, csv, md or txt files, which are read into text.
4. Tag each file with the labels of the entity it describes, then click Create.
5. Or declare the same thing as a source. This example attaches a markdown runbook to the service tares in production. Replace the content with your own latency fix:

- name: runbooks
  connector: reference
  config:
    attachments:
      - name: restart.md
        format: md
        content: |
          1. kubectl rollout restart deploy/tares
          2. watch the pod come healthy
        labels: { service: tares, environment: production }
    labels:
      - { name: service, field: service }
      - { name: environment, field: environment }

6. You can also send the same object with POST /api/sources.
7. To add more documents later, re-open the source and choose Upload more.

The labels list under config declares the label names, so reads can correlate on them. Each attachment provides the values. Each attachment needs a name and content. format is one of json, csv, md or txt, and labels is an object of entity labels.

To verify, 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 the one with service=tares. The documents come back in the timeline even outside the read window. The full field list is on the reference documents connector page.

What you get

• The documented fix for high latency is always part of the context when the AI SRE correlates on the entity you tagged, not only when the document is recent.
• The runbook does not age out of short reads, so a 15-minute window still includes it.
• One document becomes one event, so you can see exactly what is attached to an entity in Recent events.
• The labels on each document are real Tares labels, so you can read on them and use them in triggers.
• You maintain the fix in one place. Edit the source and Tares re-materializes it.

When something else fits

• Use a reference document for stable knowledge such as runbooks, schemas and notes. If you want to bring in live data such as logs, metrics or alerts, use an event connector instead, because those are streams that follow the read time window.
• If the knowledge is an observation an agent wrote itself, the memory connector holds an agent’s own notes. A reference document is the better fit for a runbook you author and maintain.

Related