BetterDB vs general APM tools
New Relic, Dynatrace, Grafana Cloud, Sematext and CubeAPM all monitor Redis, and as shipped they stop at about the same depth: server metrics, charted. That is the right depth for one integration among hundreds. BetterDB goes deeper on one thing. It stores the slow commands, the large requests, the ACL denials and the client history, runs detectors built around how Valkey fails, forecasts when you run out of memory, checks your version against known CVEs - and sends its metrics and events to any of the five.
BetterDB is a monitoring service for Valkey and Redis: one container from Docker, Helm or npx, or BetterDB Cloud. It connects as an ordinary client, keeps history, runs detectors and forecasts, and serves a UI, REST API and Prometheus endpoint on port 3001.
Which one do you need?
Stay on your APM alone when…
- The cache is a small part of the stack and server-level metrics are enough
- You need Redis calls inside your application traces
- One vendor and one on-call tool is the priority
Run both when…
- The APM tells you the cache is slow, and you need to know which command pattern and which client
- You want Valkey history and anomaly events on your APM's dashboards - BetterDB exports OTLP, which all five ingest
- You want failovers, split brain, replication divergence and CVEs detected by something that knows Valkey
Use BetterDB instead when…
- The cache is the only thing you need to watch
- Monitoring data has to stay in your network
- You are on Valkey 8.x and want COMMANDLOG and slot stats
- You run clusters or Sentinel and want nodes discovered and failovers tracked for you
The category, side by side
| Capability | BetterDB | General APM platforms |
|---|---|---|
| Scope | Valkey and Redis only | Hosts, applications, logs and traces across the whole stack |
| How Redis data is collected | Its own poller; the schedule is below | A vendor agent check, the OpenTelemetry Redis receiver, or redis_exporter. As these platforms ship them, they report server metrics and at most slowlog counters |
| Valkey | Yes. COMMANDLOG and slot stats switch on where the version has them | Not named in the Redis integration docs of any of the five |
| Slowlog | The entries, with arguments, duration and client; grouped by pattern, key prefix and client | A count or a few gauges at most. None of the four that document their collector keep the entries |
| COMMANDLOG and CLUSTER SLOT-STATS | Both: entries grouped by pattern, and a heatmap of all 16,384 slots with per-slot key counts | Not collected by any of the five as shipped |
| ACL audit and client history | Both, persisted: ACL LOG by reason and user; CLIENT LIST snapshots every 60 seconds, rolled up for 90 days | Not available |
| Cluster and Sentinel | One seed: auto-registration (opt-in) adds every node; a Sentinel failover is picked up on the next 30-second sync | One target per node |
| Anomaly detection | Built for Valkey: more than 20 detectors scored against a rolling five-minute baseline and correlated into named patterns with a diagnosis - split brain, replication divergence, retry amplification | Generic anomaly detection on any metric, where the vendor offers it |
| Forecasting | Per instance and ready-made: time-to-limit for memory, CPU, ops/sec and fragmentation, plus a cache size simulator that recommends a node size | Generic forecasting on any metric, where the vendor offers it |
| Security | Server and module versions matched against five CVE feeds every 6 hours; config drift and hazard checks | Not for Redis |
| Traffic capture | Opt-in MONITOR captures: on demand, scheduled, or armed for the next recurrence of an anomaly; 30 seconds by default, capped and health-gated | Not available |
| Traces, logs and host metrics | Only OTLP traces from your own application; no host or log monitoring | Yes - this is what they are for |
| Working together | Exports OTLP metrics and events, and Prometheus metrics | All five ingest OTLP |
Scope
BetterDB
Valkey and Redis only
General APM platforms
Hosts, applications, logs and traces across the whole stack
How Redis data is collected
BetterDB
Its own poller; the schedule is below
General APM platforms
A vendor agent check, the OpenTelemetry Redis receiver, or redis_exporter. As these platforms ship them, they report server metrics and at most slowlog counters
Valkey
BetterDB
Yes. COMMANDLOG and slot stats switch on where the version has them
General APM platforms
Not named in the Redis integration docs of any of the five
Slowlog
BetterDB
The entries, with arguments, duration and client; grouped by pattern, key prefix and client
General APM platforms
A count or a few gauges at most. None of the four that document their collector keep the entries
COMMANDLOG and CLUSTER SLOT-STATS
BetterDB
Both: entries grouped by pattern, and a heatmap of all 16,384 slots with per-slot key counts
General APM platforms
Not collected by any of the five as shipped
ACL audit and client history
BetterDB
Both, persisted: ACL LOG by reason and user; CLIENT LIST snapshots every 60 seconds, rolled up for 90 days
General APM platforms
Not available
Cluster and Sentinel
BetterDB
One seed: auto-registration (opt-in) adds every node; a Sentinel failover is picked up on the next 30-second sync
General APM platforms
One target per node
Anomaly detection
BetterDB
Built for Valkey: more than 20 detectors scored against a rolling five-minute baseline and correlated into named patterns with a diagnosis - split brain, replication divergence, retry amplification
General APM platforms
Generic anomaly detection on any metric, where the vendor offers it
Forecasting
BetterDB
Per instance and ready-made: time-to-limit for memory, CPU, ops/sec and fragmentation, plus a cache size simulator that recommends a node size
General APM platforms
Generic forecasting on any metric, where the vendor offers it
Security
BetterDB
Server and module versions matched against five CVE feeds every 6 hours; config drift and hazard checks
General APM platforms
Not for Redis
Traffic capture
BetterDB
Opt-in MONITOR captures: on demand, scheduled, or armed for the next recurrence of an anomaly; 30 seconds by default, capped and health-gated
General APM platforms
Not available
Traces, logs and host metrics
BetterDB
Only OTLP traces from your own application; no host or log monitoring
General APM platforms
Yes - this is what they are for
Working together
BetterDB
Exports OTLP metrics and events, and Prometheus metrics
General APM platforms
All five ingest OTLP
Checked against each vendor's public documentation and repositories, and BetterDB 0.54.0, November 2026. Spot something out of date? Tell us and we will fix it.
Sources: New Relic Redis integration · Dynatrace Redis extension · Grafana Cloud Redis integration · Sematext Redis integration · CubeAPM infrastructure monitoring
What none of the five collect
A general platform integrates Redis once and moves on. Three things that need a tool that lives with Valkey, and what each looks like once it reaches your APM over OTLP.
The entries, with the client
Every slowlog and COMMANDLOG entry stored with its arguments, duration, client address and name, fingerprinted into patterns. The APM sees a count; BetterDB shows you the call and exports the pattern as a series your APM can chart.
Example
betterdb_slowlog_pattern_count{pattern="HGETALL session:*",connection="cache-eu-1"} 24
from 10.0.4.17 (checkout-api) last seen 03:12:40Events your APM can route
A rolling five-minute baseline per metric, more than 20 detectors - failover churn, duplicate primaries, lagging promotions, stuck replicas, Sentinel endpoint drift, replication divergence, retry amplification - correlated into a named pattern with a diagnosis, and sent as an OTLP log record and as a webhook.
Example
logger=betterdb-events event=anomaly.detected severity=critical connection=cache-eu-1 pattern=REPLICATION_DIVERGENCE
CVEs for your exact version
The server version from INFO and module versions from MODULE LIST are matched every 6 hours against GitHub advisories, NVD, MITRE, CISA KEV and EPSS. New critical or known-exploited findings fire a webhook and an OTLP event; nothing fires twice for the same finding.
Example
event=cve.kev_detected connection=cache-eu-1 engine=valkey 8.0.1 CVE-2025-XXXXX critical listed in CISA KEV
A few collectors behind the brand names
Four of the five document how they read Redis, and between them there are three mechanisms: a vendor agent check, the OpenTelemetry Collector Redis receiver, and redis_exporter. Sematext does not document its collector publicly. The agent checks and the receiver work from the INFO command. redis_exporter can go further in recent versions, but what you get depends on the version and flags the platform bundles.
What none of the documented four keep is the entries: the slow commands, the large requests, the ACL denials and the client list over time. Those need their own commands and somewhere to store the results. And none of them know what a Valkey failover, a split brain or a lagging promotion looks like - a generic anomaly monitor sees a metric move, not the failure behind it. That is the part a general platform leaves out and BetterDB is built around.
Vendor by vendor
What each one actually runs against Redis, and how it would receive BetterDB metrics.
New Relic
How it reads Redis
Its nri-redis agent check (INFO, CONFIG GET, lengths of listed keys), or the OpenTelemetry Redis receiver
Slowlog
Not collected
Takes BetterDB metrics via
OTLP or Prometheus remote write
Dynatrace
How it reads Redis
A Redis extension on OneAgent hosts, reading Redis on localhost; 22 metrics
Slowlog
Entry count only
Takes BetterDB metrics via
OTLP over HTTP
Grafana Cloud
How it reads Redis
Grafana Alloy with redis_exporter embedded; one dashboard and six alerts
Slowlog
Length, last ID and last duration
Takes BetterDB metrics via
Prometheus remote write or OTLP
Sematext
How it reads Redis
Not documented publicly; 13 metrics
Slowlog
Not documented
Takes BetterDB metrics via
OTLP
CubeAPM
How it reads Redis
The OpenTelemetry Collector Redis receiver
Slowlog
Not collected
Takes BetterDB metrics via
OTLP, or Prometheus through the Collector
How BetterDB runs
The operational facts behind every row above, taken from BetterDB 0.54.0.
What it is
One Node.js service in one container (310 MB image) from Docker, Helm or npx, or hosted as BetterDB Cloud. It serves the web UI, the REST API and the Prometheus endpoint on port 3001, and can push metrics and events over OTLP. The Helm chart requests 100m CPU and 256 MiB with a 1 CPU, 1 GiB limit, and runs one replica: the process holds the anomaly baselines and capture sessions, and the chart notes that more replicas only make sense with Postgres and are not load-balanced work.
How it connects
As an ordinary client. Every poller shares one long-lived connection per monitored instance, named BetterDB-Monitor in CLIENT LIST, plus a few helpers: a discovery connection on clusters and Sentinels, a scratch connection for key sampling on databases other than 0, and a dedicated socket for each MONITOR capture. TLS is per connection. For instances with no inbound path, such as ElastiCache or Memorystore, the BetterDB agent runs inside your network and connects outbound over WebSocket to BetterDB Cloud or to your self-hosted BetterDB. Nothing is installed on the Valkey nodes.
Storage and retention
History is in memory by default and lost on restart. Set STORAGE_TYPE to sqlite or postgres and everything it stores - slowlog and COMMANDLOG entries, client snapshots, anomaly events, captures - is kept until you set a retention window in Settings or LOCAL_RETENTION_DAYS. Client-list snapshots are also rolled into 5-minute buckets kept 90 days. SQLite means one replica on a volume, and the -no-ai image variant ships without it; Postgres is the choice when the history must outlive the pod.
When BetterDB is down
Polling, detectors, forecasts and webhooks stop, and if BetterDB is your only Prometheus source, so do your Valkey metrics. Alert on up for the betterdb scrape job, and on betterdb_poll_stale, which is 1 when a connection has had no successful poll within the staleness bound (15 seconds by default). Self-hosted installs send usage telemetry to PostHog EU - version, deployment mode and events such as app start and page views - unless BETTERDB_TELEMETRY=false; an offline license forces it off, and CVE_ENABLED=false removes the only other outbound call.
What it needs from your database
Read-only. The base user below covers monitoring; it has no CONFIG SET, no KEYS, no FLUSH and no RESET commands. Key sampling adds a read-only key pattern with SCAN and MEMORY USAGE, and capture sessions add +monitor, both opt-in.
ACL SETUSER betterdb reset on >CHANGE_ME -@all +ping +info +select +client|setname +client|getname +client|list +client|no-touch +config|get +slowlog|get +slowlog|len +commandlog|get +commandlog|len +latency|latest +latency|histogram +latency|history +latency|doctor +memory|stats +memory|doctor +acl|whoami +acl|log +role +cluster|info +cluster|nodes +cluster|shards +cluster|slot-stats +cluster|myid +command|info +dbsize +lastsave +time +module|list
- Deny CONFIG GET and config drift, hazard checks and scaling readiness skip the connection.
- Deny CLIENT LIST and client pages and client history are unavailable.
- Deny ACL LOG and the audit trail is unavailable.
- Deny SLOWLOG or COMMANDLOG and those pages are unavailable; everything else keeps running.
- Deny MONITOR and capture sessions cannot start. It is not in the base line above.
What it runs, and how often
All on the one shared connection. KEYS is never used. MONITOR runs only inside a capture session you start, schedule or arm on an anomaly: 30 seconds by default, capped at 50 MB or 5 million lines, refused while memory is above 85% or a failover is in progress, with MONITOR_REDACT_VALUES to scrub values.
INFO
Every 1s for anomaly baselines, 5s for metrics. Both intervals configurable. The 5s loop also reads INFO keysizes and two cached CONFIG GET keys for persistence checks.
PING
Every 10s. Health check.
SLOWLOG GET 128; COMMANDLOG GET 128 for slow, large-request and large-reply
Every 30s. COMMANDLOG on Valkey 8.1+ only, three calls.
CLIENT LIST, ACL LOG 100, LATENCY LATEST and HISTOGRAM, INFO commandstats and latencystats
Every 60s. CLIENT LIST is unbounded; cost grows with connected clients.
CLUSTER INFO, NODES, SLOT-STATS (top 100)
Every 5s. Cluster connections only.
CLUSTER NODES or SENTINEL MASTERS for auto-registration
Every 30s. Only when auto-registration is turned on.
CONFIG GET for a short allowlist of keys, one per call; ACL LIST
Every 60 anomaly polls (about 60s). Config drift and hazard checks; skipped if denied. Never CONFIG GET *.
SCAN sample of 10,000 keys with TYPE, TTL, MEMORY USAGE and OBJECT FREQ or IDLETIME
Every 5 min. Key analytics; needs the optional read-only key rules.
CVE dataset refresh
Every 6h. Outbound to GitHub, NVD, MITRE, CISA and FIRST (EPSS); CVE_ENABLED=false turns it off.
Full references: minimum ACL · configuration and retention · capture sessions · Kubernetes guide
The detailed comparisons
Related comparisons, each checked against source.
Other comparisons: redis_exporter · Prometheus and Grafana · OTel Redis receiver · Datadog · Percona PMM · Valkey Admin · Redis Insight · CloudWatch · cloud monitoring · RedisShake · ElastiCache migration
FAQ
Does New Relic support Valkey?
Its Redis integration documentation does not mention Valkey; it lists Redis 3.0 to 7.0. The integration reads INFO and CONFIG GET, which Valkey also answers. New Relic also documents an OpenTelemetry path that uses the Collector Redis receiver.
Does Dynatrace support Valkey?
The Dynatrace Redis extension page does not name Valkey. The extension runs on a host with OneAgent and expects Redis to listen on localhost, so it is meant for instances you host yourself. It collects 22 INFO-style metrics, including the slowlog length.
What does the Grafana Cloud Redis integration use?
Grafana Alloy with redis_exporter embedded, plus one prebuilt dashboard and six alert rules. Alloy accepts valkey:// addresses. The exporter version bundled in Alloy can trail the upstream release, so newer upstream metrics such as COMMANDLOG counts may not be available yet.
Can BetterDB send metrics to these platforms?
Yes. BetterDB mirrors its metrics over OTLP every 15 seconds and sends its monitoring events as OTLP logs, and all five accept OTLP. New Relic and Grafana Cloud also accept Prometheus remote write, so a Prometheus that scrapes BetterDB can forward the same series. Cumulative values arrive as gauges over OTLP, so use a delta or rate function in the backend.
Do I still need an APM if I run BetterDB?
For the rest of your stack, yes. BetterDB does not monitor hosts, applications or logs. It answers what happened inside Valkey or Redis - which command, which client, which node, and why; an APM answers what happened around it.
Deciding between more tools? When should you use BetterDB? →
Run it locally in one command
docker run -d -p 3001:3001 betterdb/monitor:latest
Then open http://localhost:3001 - see the Docker guide.
See it on your own data
BetterDB Cloud runs the service and its storage for you. Or self-host it next to the tools you already use.