How do I let an AI SRE look at Postgres tables when investigating error spikes?

Tares reads your Postgres tables incrementally and puts each new or changed row in the timeline beside your telemetry, so an AI SRE can see who was affected by an error spike. Add a postgres source with a connection URL, a table and a cursor column, and mark the entity column, such as tenant_id, as the primary label. If the data sits behind an API instead, an http_poll source reads any JSON endpoint on a schedule.

How it works

• The Postgres connector polls a table on the interval you set. A cursor tracks a column that only ever grows. Use an autoincrement id to catch inserts, or updated_at to catch inserts and updates too.
• Each new or changed row becomes one event. Your application’s source-of-truth data lands in the timeline next to your logs, metrics and alerts.
• An entity column, for example tenant_id, becomes the key through a label marked primary. Each row then carries the customer it belongs to.
• You choose which columns to pull. The cursor, key and time columns are always included. time_column sets the event time, and limit caps the rows fetched per poll.
• The dsn is stored as a secret. The API redacts it and catalog exports omit it.
• The Postgres driver ships with Tares, so there is nothing extra to install. The database must be reachable from the Tares host.
• For data that lives behind an API, the HTTP API (poll) connector calls a JSON endpoint on a schedule and stores one event per item. Nested values are reachable by dotted name in labels, trigger filters and trigger conditions.

Set it up

1. Check that the Postgres you want to read is reachable from the Tares host, and that you have its connection URL.

2. Ask a connected agent to do it:

   Use tares to ingest the orders table at <dsn>, keyed by tenant_id.

   The agent calls discover_source, which lists the tables and proposes the cursor and labels from the columns. It then calls test_source for a dry run that fetches sample rows, and finally create_source.

3. Or use the UI. Go to Sources → Add source → Postgres, enter the Connection URL and press Discover. Pick a table, and Tares proposes the cursor, entity key and labels from its columns. Choose which columns to pull, then save.

4. Or declare the source yourself, or send the same object with 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 }

5. 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.
6. If the business data comes from an API, add an http_poll source. Press Discover and Tares calls the API once, shows the reply and proposes what becomes an event. A credential travels in one header and is stored as a secret:

config:
  url: https://api.example.com/v1/readings
  credential: abc123                   # an API key
  credential_header: X-API-Key

Set payload_key to the part of the reply that holds the items. Set id_field so an item seen in recent polls is not stored again.

What you get

• Rows from the tables that matter, such as orders, accounts or jobs, sit in the same timeline as your error telemetry. During an error spike you can check which tenants or customers have rows that changed.
• Incremental reads. Only new or changed rows are fetched on each poll, based on the cursor column.
• An entity key on every row, from the primary label, so rows are tied to the customer or tenant they describe.
• Control over what is pulled. You pick the columns, and Fields shows how reliably each one is present.
• A route for non-database data. Any JSON endpoint can be polled, with the reply stored as received, so labels you declare later can still reach every field.
• Safe handling of credentials. The Postgres dsn and the http_poll credential are stored as secrets and never returned by the API.
• Polling that protects the API. http_poll refuses an interval under 10 seconds. It backs off on a 429 or any 5xx, honoring Retry-After, and shows the wait in the source’s health.

When something else fits

• Use the HTTP API (poll) connector when the data is exposed by an API, such as a status page, a SaaS export or an endpoint of your own, and not read directly from a database.
• Use the webhook connector when the system can call Tares itself and you want its events pushed to an ingest URL. The Postgres and http_poll connectors are for data that Tares calls on a schedule.
• Pick a column that only ever grows as the cursor. A table with no such column does not suit the Postgres connector, and an API that serves the same data may suit http_poll better.
• The Postgres connector polls one table per source. If you need rows from several tables, add one source for each.

Related