How do I let an AI SRE look at Postgres tables when investigating high latency?

Tares reads a Postgres table with the postgres connector, which polls it incrementally and stores one event per new or changed row. During a high latency investigation, your application’s own rows sit in the timeline next to your telemetry, so an agent can see which tenants or orders were affected. You set it up by asking a connected agent or by adding the source in the UI. For data behind a JSON API, the http_poll connector does the same job.

How it works

The postgres connector polls a table on the source’s schedule. A cursor tracks a column that only ever grows, either an autoincrement id for inserts or updated_at for inserts and updates. Each poll fetches the rows past the cursor and stores each one as an event.

• Entity key. A label marked primary, such as tenant_id, becomes the key. Events about the same tenant line up with the rest of your telemetry for that entity.
• Columns. You choose which columns to pull. Empty means every column, and the cursor, key and time columns are always included.
• Event time. time_column sets the event time. By default it is the cursor if that is a timestamp, otherwise the ingest time.
• Row summary. An optional text_template turns each row into a one-line summary.
• Discovery. Given the connection URL, Tares lists the tables it can see, then reads the chosen table’s columns and proposes the cursor and labels.
• Secrets. The dsn is stored as a secret. The API redacts it and catalog exports omit it.

The prerequisite is a Postgres reachable from the Tares host. The driver ships with Tares, so there is nothing extra to install.

The http_poll connector is the second route. It polls any JSON endpoint and stores one event per item, which suits business data that already sits behind an API.

Set it up

Pick the tables that answer “who was affected?”, for example orders keyed by tenant_id. The AI SRE guide covers how the rest of the investigation uses them.

1. Ask a connected agent. Say: Use tares to ingest the orders table at your connection URL, keyed by tenant_id. The agent calls discover_source to list tables and propose the cursor and labels, then test_source for a dry run that fetches sample rows, then create_source.
2. Or use the UI. Open Sources, then Add source, then Postgres. Enter the Connection URL (dsn) and press Discover. Pick a table, review the proposed cursor, entity key and labels, choose the columns to pull, and save.
3. Or declare it yourself. Use this source definition, or send the same object to POST /api/sources:

- name: orders
  connector: postgres
  poll: 10s
  config:
    dsn: postgresql://user:pass@host:5432/appdb
    table: orders
    cursor_column: updated_at
    columns: id,tenant_id,status,amount,updated_at   # empty = every column
    labels:
      - { name: tenant_id, field: tenant_id, primary: true }
      - { name: status, field: status }

4. Limit what you pull. Use columns to leave out sensitive fields, and limit to cap the rows fetched per poll.
5. Verify. Open the source. Recent events shows rows on the next poll. Fields reports each column’s coverage, so you can confirm the key column is reliably present.

For an API-backed dataset, add an http_poll source instead. In the UI, choose Sources, then Add source, then HTTP API (poll), fill in the request and press Discover. Tares calls the API once, shows the reply and fills in what becomes an event. Set id_field so an item already seen in recent polls is not stored again, and use payload_key to point at the list of items in the reply. A credential travels in one header, stored as a secret.

What you get

• Your source-of-truth rows in the timeline, next to the telemetry that shows the latency.
• An entity key such as tenant_id, so the agent can name the tenants or customers behind a slow period instead of only reporting a latency number.
• Incremental reads. Only new or changed rows past the cursor become events, one event per row.
• Control over what is stored. You choose the columns, the event time and the summary line.
• A clear check that the source works. Recent events shows the rows, and Fields shows how often each column is present.
• With http_poll, the same view for any JSON endpoint. Nested values are reachable by dotted name in labels, trigger filters and trigger conditions. It backs off on a 429 or any 5xx, and it refuses a poll interval under 10 seconds when you save the source.

When something else fits

• Choose http_poll when the business data is already served by a JSON API, such as a status page, a SaaS export or an endpoint of your own, and you do not want Tares to connect to the database.
• Choose the postgres connector when the table is the source of truth and has a column that only grows, such as an id or updated_at.
• Use neither for telemetry itself. Metrics, logs and traces come in through the connectors made for them.

Related