How do I pair Sentry issue alerts with OpenTelemetry log records for an AI SRE?

Tares pairs them when you give the Sentry source and the OpenTelemetry source the same primary service label. A Sentry issue alert then lands on the same per-service timeline as the log records from that service. Sentry reaches Tares through the webhook connector and a Sentry integration setup, and the log records arrive through the otlp connector. Your agent reads one timeline with the alert and the log lines on one clock.

How it works

• One label joins the sources. Tares builds one timeline per value of the primary label. When both sources carry a service label, a Sentry alert for checkout and the logs for checkout share one timeline. The AI SRE guide builds its agent on the same pattern.
• Logs come in through otlp. The OpenTelemetry connector receives OTLP/HTTP logs, traces and metrics. One source ingests every service. Resource attributes such as service.name become labels, so the service label needs no per-service setup.
• Sentry comes in through the webhook connector. Tares has no connector of its own for Sentry today. Sentry posts its deliveries to a webhook source’s ingest URL. The payload is stored lossless, and the resource is named in the Sentry-Hook-Resource header.
• The signature is the credential. Sentry signs each delivery with HMAC. The webhook source checks it with the integration Client Secret, so the Sentry source needs no Tares API key.
• A trigger wakes the agent. A trigger on the Sentry source fires when an alert arrives. The agent then reads the correlated timeline for that service, with the alert and the logs together.

Set it up

1. Create the OTLP source. Add an otlp source with a primary service label. In the console this is Sources, Add source, otlp. You can also ask a connected agent to create an OTLP source keyed by service.

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

2. Point your exporter at Tares. Set the OTLP endpoint on your app or Collector. On a secured instance, the exporter sends a Bearer Authorization header holding an ingest-scoped API key. This is needed only when Tares has auth on.

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 Sentry webhook source. Use a webhook source with the signing options for Sentry. Give it a service label with the same name and the same value your logs carry. The example uses a constant label, so use one Sentry integration per service. Replace the signing secret value with the Client Secret from step 4. Save the source and copy its ingest endpoint.

- name: sentry-issues
  connector: webhook
  config:
    event_type_field: action
    signature_scheme: hmac_sha256
    signature_header: Sentry-Hook-Signature
    signing_secret: your-client-secret
    labels:
      - { name: service, const: checkout, primary: true }

action is a top-level field in the Sentry payload, so it works as the event type field. The signing options are described in the release notes, not on the webhook connector page.

4. Add the integration in Sentry. Under Settings, Developer Settings, add an integration. Set its Webhook URL to the Tares ingest URL. Subscribe it to issues, and turn on Alert Action so your alert rules can use it. Copy the integration Client Secret into the Tares source as the signing secret.

5. Add a trigger on the Sentry source. The trigger fires when a delivery arrives and wakes your agent with the timeline for that service.

- name: sentry-issue
  sources: [sentry-issues]
  condition: { aggregate: count, predicate: "> 0", window: 5m }
  cooldown: 5m

6. Check the pairing. Open Recent events on each source to see deliveries arrive. Then open Explore, pick the service, and confirm that the alert and the log lines sit on one timeline. Fields on the webhook source shows which payload fields arrive.

What you get

• A firing Sentry issue alert and the log records from the same service on one timeline, merged on one clock.
• An agent that is woken by the alert and reads the logs next to it, so it starts from evidence and not from a bare notification.
• The full Sentry payload, stored lossless, next to the logs.
• Deliveries authenticated by Sentry’s signature, with no Tares API key on the Sentry side.
• One OTLP source for all your services. A new service appears under the service key as soon as it exports logs.

When something else fits

• If your alerts come from Prometheus or Alertmanager, use the prometheus_alerts or alertmanager connector from the AI SRE guide, since both are first-class sources in Tares.
• If your Sentry setup spans many services in one integration, the service label must come from a payload field. Check Fields on the source to see which fields reach Tares before you rely on one.
• If you only need logs, an otlp source alone is enough, with no Sentry source.

Related