Bonito + Remo

Bonito is a deep database observability collector (PostgreSQL) that emits Prometheus metrics, JSON events and OTLP spans. When Bonito’s alert rules fire through Alertmanager, Remo enriches the triage with live DB context (R-007).

Bonito metrics → Prometheus rules → Alertmanager → POST /ingest
                                                   │
                                     isDBAlert()?  │ yes
                                                   ▼
                                     fetch bonito-api:
                                       /queries/top · /locks/active · /baseline/{fp}
                                                   ▼
                                     ENRICHMENT DATA → LLM prompt
                                                   ▼
                                     diagnosis with PID + CREATE INDEX

Setup (Alertmanager)

receivers:
  - name: remo
    webhook_configs:
      - url: https://api.remo.sofe.dev/ingest
        send_resolved: false
        http_config:
          http_headers:
            X-Webhook-Secret:
              values: [whsec_bonito_demo_001]

Alert rules: BonitoBlocking, BonitoIdleInTransaction, BonitoQuerySlow, BonitoRegression, BonitoCollectorDown, BonitoStoreDown.

Tenant enrichment config

# tenants/bonito-demo.yaml
enrichment:
  enabled: true
  bonito_endpoint: https://bonito-api.sofe.dev
  bonito_api_key: <key>
  bonito_timeout_ms: 3000

What enrichment adds to the diagnosis

Bonito endpoint	Context for the LLM
/queries/top	Slow queries with text + mean ms
/locks/active	Blocking tree — who blocks whom
/baseline/{fp}	Regression % vs 7-day baseline

Verified (Sprint 10)

A real blocking scenario produced:

PID 829705 holding transactionid lock, blocking PID 829718.

1. SELECT pg_cancel_backend(829705);
2. CREATE INDEX IF NOT EXISTS idx_orders_id ON orders(id);

See the Recipe: Alertmanager → Bonito → Remo.