Valkey monitoring with Prometheus
Keep your Prometheus. BetterDB monitors Valkey directly and exposes 100+ betterdb_* metrics - including the Valkey-native surfaces and analysis-level series that INFO-scraping exporters can't produce.
One scrape job away
scrape_configs:
- job_name: betterdb
metrics_path: /api/prometheus/metrics
scrape_interval: 15s
static_configs:
- targets: ['betterdb-host:3001']Metrics are computed on demand at each scrape, in standard Prometheus exposition format.
What's in the 100+ metrics
The difference from a generic exporter isn't the count - it's the analysis-level series:
Core engine
Server info, memory (incl. fragmentation), stats, CPU, replication, keyspace - the INFO-level families you expect from any exporter.
Slowlog & COMMANDLOG patterns
Slow, large-request, and large-reply counts broken down by command pattern (betterdb_commandlog_large_reply_by_pattern{pattern="LRANGE *"}) - not just a slowlog length gauge.
Cluster & SLOT-STATS
Per-slot keys, expires, reads, and writes for the top slots (Valkey 8.0+), auto-limited to prevent cardinality explosions.
Clients & ACL audit
Client analytics and ACL denial counters, so security anomalies are alertable.
Anomalies & forecasts
Anomaly counts by severity and pattern, plus forecast metrics with projected time-to-ceiling - alert on a diagnosis, not a raw gauge.
Vector search
Per-index health and FT.SEARCH inference latency for valkey-search / RediSearch deployments.
PromQL that answers real questions
Cache hit ratio
rate(betterdb_keyspace_hits[5m]) / (rate(betterdb_keyspace_hits[5m]) + rate(betterdb_keyspace_misses[5m]))Hottest cluster slots by writes
topk(10, betterdb_cluster_slot_writes_total)Critical anomalies in the last hour
increase(betterdb_anomalies_total{severity="critical"}[1h])And you don't start from a blank alert file: BetterDB ships nine ready-made Alertmanager rules - critical anomalies, memory pressure, auth anomalies, connection leaks, traffic bursts, and more.
FAQ
How do I monitor Valkey with Prometheus?
Two common paths: run an exporter (redis_exporter works against Valkey for INFO-level metrics), or run BetterDB, which monitors Valkey directly and exposes 100+ Prometheus metrics at /api/prometheus/metrics - including Valkey-native data (COMMANDLOG patterns, CLUSTER SLOT-STATS) and analysis-level series (slowlog patterns, anomalies, capacity forecasts) that no INFO-scraping exporter can produce. Point your existing Prometheus at either; a 15-second scrape interval is recommended for BetterDB.
Is there a dedicated Valkey exporter for Prometheus?
redis_exporter is the de-facto exporter and works with Valkey for the wire-compatible INFO metrics. But it has Valkey blind spots: no COMMANDLOG, no CLUSTER SLOT-STATS, no per-thread I/O metrics, and no command-pattern or client-level analysis. BetterDB acts as a Valkey-aware metrics source that covers those surfaces.
Do I need both redis_exporter and BetterDB?
No - BetterDB's endpoint includes the core engine families (memory, stats, CPU, replication, keyspace), so it can replace redis_exporter for Valkey instances. Keeping both is harmless if redis_exporter is already wired into dashboards; the betterdb_* prefix avoids any metric name collisions.
Are there ready-made alert rules?
Yes - BetterDB ships an Alertmanager rules file with nine rules covering critical anomalies, memory pressure, auth anomalies, connection leaks, traffic bursts, detection warmup, and persistent unresolved anomalies. Use them as-is or as a starting point.
Can I build Grafana dashboards on these metrics?
Yes. Everything is standard Prometheus exposition format with a betterdb_ prefix, so Grafana treats it like any other datasource series. A common split: Grafana for the fleet-wide overview, BetterDB's own UI for drill-down investigation (slowlog entries, client attribution, anomaly timelines) that doesn't reduce to time series.
Add the scrape target 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.