How do I show Vercel deploys against OpenTelemetry metric series?

Tares shows Vercel deploys against OpenTelemetry metric series by giving both sources the same service label, so they merge on one timeline per service. Your agent reads the deploy and the metric points in time order and checks whether the metric moved after the change. You need an otlp source for the metrics and a vercel source for the log drain.

How it works

Tares builds one timeline per service from every source that carries the same label. In the AI SRE guide, metrics, logs, alerts and deploys all merge on one clock because they share a service label.

• The OpenTelemetry connector receives OTLP/HTTP logs, traces and metrics at /v1/logs, /v1/traces and /v1/metrics. Resource attributes become labels, and service.name becomes the service label. One source ingests every service.
• The Vercel connector takes a Vercel log drain as JSON and creates one event per log entry. Its entries carry project, environment, source, path, host, deployment and branch. Build entries show up with source set to build.
• The Vercel key is project by default, not service. To line it up with your metrics, add a label named service that reads the project field and mark it primary. The match works when the Vercel project name equals the service.name your exporter sends.

Once both sources carry the same service value, a deploy event and the metric points around it sit side by side in time order. The agent reads that one timeline and compares the metric before and after the deploy.

Set it up

1. Create the OTLP source. In the console go to Sources → Add source → otlp, or ask a connected agent to create an OTLP source keyed by service. No config is required beyond the label.

- name: otel
  connector: otlp
  config:
    labels:
      - { name: service, field: service, primary: true }

2. Point your exporter at Tares. For OTLP/HTTP, metrics go to /v1/metrics on the same endpoint.

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:8787   # OTLP/HTTP → /v1/{logs,traces,metrics}
# or gRPC (otlp-grpc extra): OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

3. Create the Vercel source with Sources → Add source → vercel. Add a service label that reads the project field, and keep environment and source as labels.

- 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. In Vercel go to Team Settings → Log Drains → Add Log Drain, set the endpoint to that URL and the delivery format to JSON. Tares echoes back the x-vercel-verify header from Vercel’s verification request. The endpoint must be publicly reachable, so use a deployed instance or a tunnel. A bare localhost daemon will not receive drains.

5. If Tares has auth on (tares up --auth), the sender uses a Bearer Authorization header holding an ingest-scoped API key. Add it to the exporter headers and to the log drain as a custom header. Without auth, skip this step.

6. Start the MCP endpoint so your agent can read the timeline, then ask it to compare.

tares mcp

Use tares: what happened to checkout in the last 15 minutes? Did the metrics change after the last deploy?

7. Verify. Recent events shows metric points and drain entries as they arrive. Explore lists the services under the service key, and a service present in both sources shows both signals on one timeline.

What you get

• One timeline per service with deploy entries and OpenTelemetry metric points in time order.
• An agent that reads the deploy time, the branch and deployment fields, and the metric points after it, then says whether the metric moved after the change.
• One OTLP source for every service, so a new service shows up on its own as soon as it exports metrics.
• A single Vercel drain that can carry several projects. Each project appears as its own entity.
• The same timeline in Explore for you and over MCP for your agent, so you and the agent look at the same evidence.

When something else fits

• If a service’s metrics live in Prometheus rather than OpenTelemetry, use the Prometheus connector with the same service label. The timeline works the same way.
• If your deploys come from a CD pipeline rather than Vercel, post them to a webhook source with a service label. The AI SRE guide shows how.
• If the Vercel project name differs from service.name, the two will not meet on one timeline until you make the values match.

Related