How do I record config changes so an AI SRE can see them?

Tares records config changes through a second webhook source that sets a fixed event type of config. Your pipeline or tooling POSTs each change to that source’s ingest URL, and Tares stores it as an event beside the events from your deploy source. Setup takes one source and one HTTP call per change.

How it works

The webhook connector accepts arbitrary JSON (one object, a list, or NDJSON) posted to the source’s ingest endpoint. Tares stores the payload lossless, so every field you send is kept.

A second source for config changes works like this:

• Fixed event type. Set event_type to config in the source’s config. Every event from this source is typed as a config change, whatever the payload looks like. If your payload carries its own type, event_type_field reads it from a payload field instead.
• Labels. Declare a label for each payload field you want to correlate on, and mark one as primary. A service field is a natural choice for a config change.
• Readable text. text_template renders a one-line description from payload fields, so a change reads clearly when an agent or a person looks at it.
• Event time. If the payload holds an ISO-8601 timestamp, point event_time_field at it so the event carries the time the change happened.

The config source is separate from your deploy source, so config changes and deploys stay distinct event types. For the full list of connector fields, see the webhook connector page. For how an AI SRE uses what Tares collects, start at the AI SRE guide.

Set it up

1. Create the source. Ask a connected agent, for example: “Use tares to create a webhook source for my config changes, with a fixed event type of config and a primary label for the service.” The agent calls create_source and returns the ingest URL. Or open Sources → Add source → webhook in the console and enter the same values.

2. Declare the source. This is the same object you would send with POST /api/sources:

- name: config-changes
  connector: webhook
  config:
    event_type: config
    text_template: '{change} by {sender}'
    labels:
      - { name: service, field: service, primary: true }

3. Check the label mapping before you wire up a producer. Ask the agent to run test_source with a sample payload.

4. Copy the ingest endpoint from the source page. The response from POST /api/sources also includes the ingest_key.

5. Have your pipeline, deploy script or config tool POST each change:

curl -X POST http://localhost:8787/ingest/<ingest_key> \
  -H 'Content-Type: application/json' \
  -d '{"change": "max_connections 100 to 200", "sender": "ci", "service": "web"}'

6. If Tares has auth on (tares up --auth), the sender uses a Bearer Authorization header holding an ingest-scoped API key. Creating a push source in the console mints one for it and shows it once. Without auth, no header is needed.

7. Verify. Open the source and check Recent events for your test payload. Fields shows which payload fields arrive and how often, which helps you pick a reliable primary label.

What you get

• Each config change arrives in Tares as an event with the type config, with the full payload stored lossless.
• The labels you declared map payload fields such as the service into the event, so the change can be correlated on those fields.
• A one-line description from text_template, so a change is readable at a glance.
• A check loop: Recent events confirms the change landed, and Fields shows what your producer actually sends.
• No new software on the sender side. Anything that can make an HTTP request can report a config change.

When something else fits

• If one source already receives both deploys and config changes, you can keep a single webhook source and set event_type_field to a payload field that tells them apart. A second source with a fixed config type is simpler when the producers are different.
• If the change you care about lives in a Git repository, the GitHub connector reads commits and pull requests directly, with no custom producer.
• If the config sits in a Postgres table, the Postgres connector reads new and changed rows on a cursor column instead.

Related