How do I pair alerts from Prometheus with logs from Vercel projects for an AI SRE?

Tares pairs Prometheus alerts with Vercel logs when both sources carry the same primary service label. Each service then has one timeline, so a firing alert sits next to the log lines from the same window. You use the prometheus_alerts connector for the alerts and the vercel connector for the log drain, and an agent or trigger reads the merged timeline.

How it works

• The prometheus_alerts connector polls the alerts your Prometheus rules have fired, every 30 seconds by default. Each alert becomes one event with the alert name as its event type, its summary as text, and its labels as Tares labels plus a state of firing, pending or resolved. An alert fires once, and a resolved event follows when it clears.
• The vercel connector receives a Vercel log drain at an ingest URL. It makes one event per log entry. By default the key is the project label, with environment and source as further labels. One drain can carry several projects, and each appears as its own entity.
• Tares correlates sources that share a primary label. If both sources use a service label with the same values, metrics, logs and alerts for that service merge on one clock. The AI SRE guide builds its whole setup on this pattern, with every source keyed by the same service label.
• Prometheus keeps owning alerting. Tares ingests what fired, correlates it with the logs, and can wake an agent.

The values must match. The service label on your alerts has to equal the Vercel project name you use as the service label on the log source.

Set it up

1. Make the Vercel endpoint reachable. Vercel delivers from its cloud, so the ingest endpoint must be public. Use a deployed instance or a tunnel, because a bare localhost daemon does not receive drains. For a local try-out, start Tares first:

tares up

2. Add the alerts source under Sources → Add source → Prometheus alerts. Enter the Prometheus url and run Discover. It proposes the severity and state labels. Per-alert labels such as service only exist while an alert is firing, so add service from the Fields tab once alerts have been ingested. The finished source looks like this:

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

3. Add the logs source under Sources → Add source → vercel. It needs no connector-specific config. Instead of making project the key, name the primary label service and read it from the payload’s project field, so it lines up with the alerts:

- name: web-logs
  connector: vercel
  config:
    labels:
      - { name: service, field: project, primary: true }
      - { name: environment, field: environment }
      - { name: source, field: source }

4. Copy the source’s ingest endpoint from its page. It is a stable URL of the form https://<host>/ingest/<ingest_key>. In Vercel, go to Team Settings → Log Drains → Add Log Drain, set the endpoint to that URL and the delivery format to JSON. Vercel verifies the endpoint with an x-vercel-verify header, which Tares echoes back. If your instance runs with auth on, add an ingest-scoped API key to the drain as a custom header, Authorization: Bearer followed by the key.

5. Check both sources. Recent events shows entries arriving. Fields shows which service values appear and how dense each field is. The alert values and the Vercel project names must be the same strings. See the Prometheus alerts and Vercel pages for every option.

6. Open Explore and pick a service. The alerts and the Vercel log lines appear on one timeline. To let an agent read it, start the MCP endpoint and ask about the service by name:

tares mcp

What you get

• One timeline per service, with firing and resolved alerts and the Vercel log lines on the same clock, so you see what the logs said when the alert fired.
• An alert that fires once and clears with a resolved event, instead of a copy on every poll.
• A trigger that watches both sources keyed by service and fires when an alert event arrives, as in the AI SRE guide. It can wake a Tares agent, your own agent service over a webhook, or a Slack channel.
• An agent that reads the correlated timeline for one service, names the likely cause from the log lines, and writes its finding back to that timeline for the next investigation.
• Several Vercel projects through a single drain, each one its own service.

When something else fits

• If Alertmanager routes your alerts, use the alertmanager connector instead of polling Prometheus, and keep the same service label.
• If the Vercel project name is not the right key for your alerts, key both sources by another label, or slice the Vercel logs by source or environment.

Related