Valkey + OpenTelemetry
BetterDB speaks OTLP in both directions: your applications send traces in, and monitoring metrics and events flow out to any collector. The payoff is correlation - app spans joined with the live Valkey state underneath them.
At a glance
| Signal | Direction | Endpoint | Default |
|---|---|---|---|
| Traces | Ingest (receive) | POST /v1/traces | On by default |
| Metrics | Export (mirror) | ${OTLP endpoint}/v1/metrics | Opt-in |
| Events | Export (logs) | ${OTLP endpoint}/v1/logs | Opt-in |
Traces in: one env var away
The monitor exposes a standard OTLP/HTTP receiver. Point your app's exporter at it:
OTEL_EXPORTER_OTLP_ENDPOINT=http://monitor-host:3001 OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf # or http/json # if the monitor sets OTEL_INGEST_TOKEN: OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer <token>
Ingested spans - LLM calls, cache lookups, memory recalls, retrieval - render as request waterfalls correlated with the Valkey state at that moment. That's the difference between "the cache lookup was slow" and "the cache lookup was slow because memory pressure evicted the working set".
Metrics and events out: any OTLP backend
Set OTEL_EXPORTER_OTLP_ENDPOINT and the monitor mirrors its metrics registry to your collector and emits monitoring events - instance up/down, cluster failover, compliance alerts - as OTLP log records. Worth knowing: metrics are Prometheus-first, and the OTLP mirror skips histograms; for the complete set, scrape the Prometheus endpoint.
FAQ
Does BetterDB support OpenTelemetry?
Yes, in both directions. BetterDB Monitor ingests OTLP traces from instrumented applications at a standard /v1/traces receiver (protobuf and JSON encodings), and it can export its metrics and monitoring events to any OTLP collector endpoint. The collector handles fan-out to Jaeger, Tempo, CloudWatch, or whatever backend you run.
How do I send my application traces to BetterDB?
Point your OTLP exporter at the monitor: set OTEL_EXPORTER_OTLP_ENDPOINT to the monitor host and use http/protobuf or http/json. If the monitor sets OTEL_INGEST_TOKEN, add an Authorization: Bearer header. Ingested spans are rendered as request waterfalls in the AI Traces view, correlated with the live Valkey state underneath each request.
What makes trace ingestion useful for a database monitor?
Correlation. A span that says "cache lookup took 40ms" is a symptom; BetterDB joins that span with what Valkey was doing at that moment - memory pressure, a hot key, a slow command pattern - so you can tell whether a slow AI response came from the model, the cache, or the database. There is even an MCP tool (correlate_ai_trace) that does this join for AI assistants.
Is the OTLP metrics export a replacement for the Prometheus endpoint?
No - and this is deliberate. Metrics are Prometheus-first: the OTLP export mirrors the Prometheus registry, and histograms/summaries are skipped because they do not map cleanly onto OTLP instruments. For the complete set, scrape /api/prometheus/metrics; use the OTLP mirror when your pipeline is collector-based and a counter/gauge subset suffices.
Does BetterDB emit its own spans?
No. On the trace side, Monitor is a receiver: it stores and renders spans your applications send. Its own telemetry surfaces are the Prometheus endpoint, the OTLP metrics mirror, and OTLP log records for monitoring events (instance up/down, cluster failover, compliance alerts) - the same events that drive webhooks.
Start the receiver in one command
Ready to get started?
Start monitoring in minutes - no infrastructure to maintain. Team collaboration, agent-based monitoring for private databases, and more. Or self-host - open source core, zero lock-in.