How do I add Postgres tables to the evidence an AI SRE reads when alerts from Prometheus fire?

In Tares, you add a postgres source next to a prometheus_alerts source. Alerts and table rows then sit in the same Tares timeline. Each new or changed row becomes an event, so your application data shows who or what an incident touched.

How it works

Two sources feed Tares, and each one does a single job.

• Prometheus alerts polls Prometheus’s own alerts endpoint, the alerts its alerting rules have already fired. You need no Alertmanager and no PromQL. Each active alert becomes one event with event_type set to the alert name, text set to its summary, and its labels as Tares labels plus a state of firing, pending or resolved. Each alert fires once, re-emits only on a state change, and produces a resolved event when it clears. Tares correlates the alert and can dispatch it to an agent.
• Postgres table polls a table incrementally and creates one event per new or changed row. A cursor tracks a column that only grows, such as an autoincrement id or updated_at. A column such as tenant_id becomes the entity key through a primary label. This is your application’s source-of-truth data in the timeline.

The result is a second signal beside telemetry. The alert says that something broke. The rows say which tenant, order or account was involved. You choose the columns you pull, so the evidence holds only the fields that matter.

Set it up

1. Add the alerts source. Go to Sources → Add source → Prometheus alerts. Enter the url of your Prometheus server, plus any auth, and press Discover. It lists your alerting rules and their severities. You can filter by severity and include pending alerts if you want them. Or ask a connected agent to ingest the firing alerts from your Prometheus. See Prometheus alerts for every field.

   - name: alerts
     connector: prometheus_alerts
     poll: 30s
     config:
       url: http://localhost:9090
       severities: critical,warning   # blank = all
       labels:
         - { name: severity, field: labels.severity, primary: true }
         - { name: state, field: state }

2. Add the Postgres source. Go to Sources → Add source → Postgres. Your Postgres must be reachable from the Tares host. The driver ships with Tares, so you install nothing extra. Enter the connection URL (dsn) and press Discover. It lists the tables it can see. Pick the table that shows what the incident touched. Tares proposes the cursor, entity key and labels from the columns.

3. Choose the columns and the key. Pull only the columns you want in the evidence. Leave columns empty to pull all of them. The cursor, key and time columns are always included. Set the entity column, for example tenant_id, as the primary label. The dsn is stored as a secret.

   - 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 }

   Use updated_at as the cursor to catch updates as well as inserts. An id cursor catches inserts only. See Postgres table for the full configuration table.

4. Verify both sources. Open each source. On the alerts source, Recent events shows one event per active alert, and Fields shows the labels the alerts carry, such as namespace or service. You can add those as labels once real alerts have been ingested. On the Postgres source, Recent events shows rows on the next poll, and Fields reports each column’s coverage, so you can confirm the key column is reliably present.

5. Add an API signal if a table is not enough. If who or what the incident touched lives behind a JSON API instead of a table, add an http_poll source. It polls the endpoint on a schedule and stores one event per item. See HTTP API (poll).

What you get

• Firing and resolved Prometheus alerts, each as one event, with the alert name, summary and labels.
• Rows from your own tables as events in the same timeline, one per new or changed row, with the columns you chose.
• An entity key on the table events, such as tenant_id, that you pick with a primary label.
• A check on each source: Recent events shows what arrived, and Fields shows which labels and columns are present.
• Credentials kept as secrets. The Postgres dsn is redacted in the API and left out of catalog exports.

When something else fits

• The data sits behind an API, not a table. Use HTTP API (poll). It reads any JSON endpoint on a schedule, with one credential sent in one header, and gives you one event per item.
• You want metric values, not fired alerts. The Prometheus metrics connector polls metrics you pick by name or label. Use the alerts connector when Prometheus rules already decide what counts as an alert.
• Your alerts come from Alertmanager. The Alertmanager connector takes the alerts it routes to a webhook receiver pointed at a Tares ingest URL. Use the alerts connector when you want Tares to poll Prometheus directly.

Related