From e0e93b65fc002cdeb8898b20d7128e0c3aa5426b Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Tue, 4 Aug 2026 13:11:14 +0300 Subject: [PATCH 1/9] Add blog post: Monitoring Valkey with Prometheus This PR adds a new blog post, "Monitoring Valkey with Prometheus", explaining how to expose Valkey metrics to Prometheus, visualize them in Grafana, and choose the right exporter for the users deployment. Tested locally with `zola serve` and Docker Desktop. Signed-off-by: Dragos Andriciuc --- .../index.md | 285 ++++++++++++++++++ 1 file changed, 285 insertions(+) create mode 100644 content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md new file mode 100644 index 00000000..62c470fd --- /dev/null +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -0,0 +1,285 @@ ++++ +title = "Monitoring Valkey with Prometheus" +date = 2026-08-30 +description = "Learn how to expose Valkey metrics to Prometheus, visualize them in Grafana, and choose the right exporter for your deployment." +authors = ["dragosandriciuc"] +[taxonomies] +blog_type = ["Community Highlight"] +[extra] +featured = true ++++ + +A key trait of Valkey is speed, but "speed" doesn't equal "observability." Before memory fragmentation slowly increases, replication falls behind, or clients retry after latency spikes, all of it starts minutes or hours before anyone notices. That's where monitoring earns its keep. + +This blog post walks through pairing Valkey with Prometheus, it compares two popular ways to get Valkey metrics into the Prometheus format as well as wiring up Grafana for live dashboards. It also provides you with a docker-compose setup you can run locally in a few minutes. + +## What is Prometheus? + +Prometheus is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, PromQL. + +Each Prometheus server is standalone and runs independently, it relies only on: + +- a local storage such as an HDD or SSD +- and Alertmanager, which handles routing and deduplicating notifications + +In Valkey's case there is a catch, Prometheus does not talk to Valkey natively. Valkey does not expose any metrics endpoint on its own however it does expose operational data through the `INFO` command. + +## Why monitor Valkey with Prometheus? + +If you can't see your Valkey database or cache, it will continue to keep serving requests while its fragmentation goes unnoticed and memory creeps toward the `maxmemory` ceiling, or replicas lag behind and the first sign of trouble is often a latency spike somewhere downstream, long after the root cause started. + +Putting Valkey behind Prometheus gets you the following advantages: + +- **Trend visibility**: you can view the operations per second, hit ratio, memory usage, and connection counts over time, not just a snapshot from `INFO` when something's already broken. +- **Alerting before things break**: you can set alert rules and manage those alerts using Alertmanager +which send out notifications using methods such as email, on-call notification systems, and chat platforms. +- **A single pane of glass**: your Valkey metrics sit alongside your application, database, and infrastructure metrics in the same Prometheus and Grafana stack using a standalone exporter, so you can correlate a request-latency spike in your app with what Valkey was doing at that exact moment. +- **Capacity planning**: long-running historical data makes it much easier to answer "when do we need to scale this" instead of blindly guessing metrics. +- **Cluster and replication awareness**: for Valkey Cluster or primary/replica setups, per-node metrics make split-brain-adjacent issues (replication lag, slot imbalance) visible instead of silent by tracking deltas and slot assignments across them. + +## Tools for exporting Valkey metrics to Prometheus + +Two tools are useful when talking about exporting Valkey metrics with Prometheus: **BetterDB** and **redis_exporter**. They solve overlapping but distinct problems. + +### BetterDB + +[BetterDB](https://www.betterdb.com/) is a Valkey-native observability platform built by Kristiyan Ivanov (you'll find him active on the Valkey Slack). The project started because Valkey is growing quickly but it has mostly inherited tooling that predates it rather than tooling built to take advantage of what Valkey now offers natively, things like `COMMANDLOG` and `CLUSTER SLOT-STATS`. + +BetterDB is a full monitoring and observability application that provides real-time dashboards, anomaly detection, and operational intelligence for your Valkey deployment, not only a metrics-to-Prometheus bridge. It runs against Valkey **or** Redis, auto-detecting which one it's talking to and enabling Valkey-only features (Command Log support on Valkey 8.1+, Cluster Slot Stats on Valkey 8.0+) when it recognizes them, with graceful fallback on Redis. + +### What metrics does BetterDB cover + +It exposes its own metrics at `GET /prometheus/metrics` in the standard text/plain format and standard Node.js process metrics from `prom-client`. It covers the following: + +- **Core Valkey performance**: operations processed per second, memory usage, and network throughput, derived from `INFO`. +- **ACL audit metrics**: any denied ACL events, broken down by reason and by username, useful for catching misconfigured permissions or attempted unauthorized access. +- **Client connection metrics**: current and peak connection counts, broken down by client name and by ACL user. +- **Slowlog metrics**: slow-query data such as average duration, and percentage share, grouped by query *pattern* rather than raw individual queries, which makes it much easier to spot "this class of query is the problem" instead of scrolling through a slowlog manually. +- **COMMANDLOG metrics (Valkey 8.1+)**: large-request and large-reply counts, surfacing a Valkey-only capability that plain `INFO`-based tools cannot retrieve. +- **Vector Index / AI metrics**: this is for deployments running `valkey-search` or RediSearch, a dedicated set of per-index health metrics and gauges (indexed docs, index memory, indexing failures, percent indexed). +- **Node.js process metrics**: since the monitor itself is a Node.js application, it also exposes its own CPU, event-loop metrics, and HEAP/GC metrics, useful for keeping an eye on the monitoring tool's own health. + +### Example for BetterDB + +A snippet of what BetterDB exposes on its Prometheus endpoint looks like this: + +```text +# Client connections +betterdb_client_connections_current{connection="172.17.0.4:6379"} 1 +betterdb_client_connections_by_name{connection="172.17.0.4:6379",client_name="BetterDB-Monitor"} 1 + +# Memory +betterdb_memory_used_bytes{connection="172.17.0.4:6379"} 1281040 +betterdb_memory_fragmentation_ratio{connection="172.17.0.4:6379"} 10.35 + +# Throughput +betterdb_commands_processed_total{connection="172.17.0.4:6379"} 319 +betterdb_instantaneous_ops_per_sec{connection="172.17.0.4:6379"} 0 + +# Anomaly detection (this is BetterDB's differentiator) +betterdb_anomaly_events_total{connection="172.17.0.4:6379",severity="warning",metric_type="fragmentation_ratio",anomaly_type="spike"} 1 +betterdb_correlated_groups_total{connection="172.17.0.4:6379",pattern="memory_pressure",severity="warning"} 1 +``` + +You can get it to run using this one-liner with Docker or `npx`: + +```bash +docker run -d --name betterdb -p 3001:3001 -e DB_HOST=your-valkey-host-ip -e DB_PORT=6379 betterdb/monitor +``` + +Then point Prometheus at `http://:3001/prometheus/metrics`, and open `http://:3001` for your built-in dashboard. + +### Redis Exporter (Valkey-compatible) + +[redis_exporter](https://github.com/oliver006/redis_exporter) is a long-standing, community-standard Prometheus exporter for Valkey metrics. It supports Valkey 7.x, 8.x, and 9.x and with Valkey being protocol-compatible with Redis, it works against Valkey unchanged. + +However, redis_exporter has no UI of its own. It's a single-purpose exporter: you connect to the datastore, pull data, republish it in the Prometheus format, and export it. You can use this to feed Grafana dashboards and Prometheus alerting rules instead of an actual dashboard. + +### What metrics does redis_exporter cover + +Most items from Valkey's `INFO` command are exported directly: + +- **Memory**: covers used memory, RSS, fragmentation ratio, `maxmemory`, and (through `redis_memory_max_bytes`) the configured memory ceiling. +- **Throughput and commands**: total commands processed, ops/sec, commandstats (with `--include-config-metrics` and related flags), and latency histograms. +- **Keyspace**: per-database total key counts, expiring key counts, and average key TTL. +- **Clients and connections**: connected clients, blocked clients, rejected connections; optionally a full client list breakdown with `--export-client-list`. +- **Replication**: role (primary/replica), connected replicas, replication offset and lag. +- **Persistence**: RDB save status, AOF status, last save time and duration. +- **Keyspace hits/misses**: the raw data needed for a cache hit-ratio panel. +- **Cluster support**: with `--is-cluster`, it can discover and scrape every node in a Valkey Cluster using the `/discover-cluster-nodes` endpoint in the Prometheus configuration. +- **Custom and key-level metrics**: using `--check-keys`, `--check-single-keys`, and `--check-key-groups`, you can export the size or length of specific keys or key patterns (handy for tracking the size of a specific queue or sorted set), and even aggregate memory usage by key-naming convention using Lua scripts run on the server-side. + +**Example** + +Running the exporter and hitting `/metrics` gives you plain Prometheus text output like this: + +```text +# Server status +redis_up 1 +redis_instance_info{valkey_version="9.1.1",role="master",...} 1 + +# Memory +redis_memory_used_bytes 1.30248e+06 +redis_mem_fragmentation_ratio 10.22 + +# Throughput +redis_commands_processed_total 11823 +redis_net_input_bytes_total 237055 + +# Keyspace +redis_db_keys{db="db0"} 0 +redis_keyspace_misses_total 367 + +# Exporter self-metrics +redis_exporter_scrapes_total 1 +redis_exporter_last_scrape_error{err=""} 0 +``` + +This is an example of a minimal Prometheus scrape configuration for it: + +```yaml +scrape_configs: + - job_name: redis_exporter + static_configs: + - targets: ['redis-exporter:9121'] +``` + +## Pros and cons + +| | BetterDB | redis_exporter | +|---|---|---| +| **What it is** | Full monitoring application including dashboard, a Prometheus endpoint, an audit trail and anomaly detection | Single-purpose Prometheus exporter with no UI | +| **Setup** | One Docker container or `npx @betterdb/monitor`; storage backend (memory/Postgres/SQLite) is your only real decision | One Docker container; typically paired with your own Grafana dashboards | +| **Valkey-specific features** | The COMMANDLOG, CLUSTER SLOT-STATS, auto-detects Valkey vs. Redis and adapts | Coverage is largely the shared Redis-protocol surface (`INFO`, keyspace, replication); it does not surface Valkey-only commands like COMMANDLOG | +| **Vector/AI search visibility** | Dedicated tab and metrics for `valkey-search`/RediSearch | Optional, using the `--include-search-indexes-metrics` flag, less purpose-built | +| **Slowlog analysis** | Grouped by query pattern, with duration and percentage breakdowns | Not exported by default; requires custom Lua scripting | +| **Maturity / ecosystem** | Newer project, smaller community, actively evolving | Long-established (originally for Redis), ~3.6k GitHub stars, huge base of existing Grafana dashboards and alerting "mixins" | +| **Cluster support** | Supported, with docs specifically for cluster setup | Built-in cluster node discovery via `--is-cluster` and `/discover-cluster-nodes` | +| **Extensibility for custom app metrics** | Not really the point of the tool | Strong with Lua scripting (`--script`), custom key/key-group tracking | +| **Overhead** | Runs its own Node.js process with a storage backend; heavier footprint than a pure exporter | Lightweight single Go binary, minimal resource use | +| **Licensing model** | MIT-licensed monitor, with the company behind it (BetterDB Inc., a public benefit company) also offering commercial/managed features | Fully open source (MIT), community-maintained, no commercial layer | +| **Best fit** | Teams that want a ready-made dashboard, audit trail, and Valkey-native visibility without assembling Grafana dashboards themselves | Teams that already run Grafana, Prometheus, Alertmanager and want a proven, low-overhead metrics source to plug into that existing stack | + +These are not mutually exclusive and it is common to run redis_exporter feeding your existing Grafana and Alertmanager stack for the operational baseline (memory, ops/sec, replication, keyspace), and add BetterDB when you specifically want slowlog pattern analysis, ACL audit visibility, or vector-search monitoring that plain `INFO` scraping does not provide. + +## Running everything locally + +Here is a docker-compose setup that spins up Valkey, redis_exporter, Prometheus, and Grafana together, so you can see metrics flowing end-to-end on your laptop. + +Create a project directory with these files: + +1. Create the **`docker-compose.yml`** file: + + ```text + version: "3.8" + + services: + valkey: + image: valkey/valkey:8-alpine + container_name: valkey + ports: + - "6379:6379" + command: ["valkey-server", "--save", ""] + + redis_exporter: + image: oliver006/redis_exporter:latest + container_name: redis_exporter + environment: + - REDIS_ADDR=redis://valkey:6379 + ports: + - "9121:9121" + depends_on: + - valkey + + prometheus: + image: prom/prometheus:latest + container_name: prometheus + volumes: + - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro + ports: + - "9090:9090" + depends_on: + - redis_exporter + + grafana: + image: grafana/grafana:latest + container_name: grafana + ports: + - "3000:3000" + environment: + - GF_SECURITY_ADMIN_PASSWORD=admin + depends_on: + - prometheus + ``` + +2. Create the **`prometheus.yml`** file: + + ```text + global: + scrape_interval: 15s + + scrape_configs: + - job_name: redis_exporter + static_configs: + - targets: ['redis_exporter:9121'] + ``` + +3. Bring the whole setup up: + + ```bash + docker compose up -d + ``` + +For the above examples: + +- **Valkey** is reachable on `localhost:6379` +- The link to **redis_exporter metrics** is: `http://localhost:9121/metrics` +- You can access the **Prometheus UI** at: `http://localhost:9090` (try the query `redis_connected_clients` or `rate(redis_commands_processed_total[1m])`) +- You can access **Grafana** at: `http://localhost:3000` (login `admin` / `admin`), then add Prometheus (`http://prometheus:9090`) as a data source and import the [community redis_exporter dashboard](https://grafana.com/grafana/dashboards/763-redis-dashboard-for-prometheus-redis-exporter-1-x/) (ID `763`) for an instant, pre-built view. + +If you want to add BetterDB to the same stack instead of, or alongside, redis_exporter then add this service and point Prometheus at it too: + + ```text + betterdb: + image: betterdb/monitor + container_name: betterdb + environment: + - DB_HOST=valkey + - DB_PORT=6379 + - STORAGE_TYPE=memory + ports: + - "3001:3001" + depends_on: + - valkey + ``` + + ```text + # add to prometheus.yml scrape_configs: + - job_name: betterdb + static_configs: + - targets: ['betterdb:3001'] + metrics_path: /prometheus/metrics + ``` + +Then open `http://localhost:3001` to access BetterDB's own dashboard, in addition to querying its metrics from Prometheus and Grafana. + +You can also generate some traffic to see the dashboards move: + + ```text + docker exec -it valkey valkey-cli --no-raw + > SET foo bar + > GET foo + > DEBUG SLEEP 0.1 + ``` + +Or, for a sustained load, run `valkey-benchmark` from inside the container: + + ```text + docker exec -it valkey valkey-benchmark -q -n 100000 + ``` + +The above is a complete, disposable local loop with Valkey, an exporter, Prometheus scraping it, and Grafana visualizing it. This is a hypothetical mirror of what you'd run in production, just without the TLS, ACLs, and persistence you'd want to layer on before shipping it anywhere real. + +Monitoring is one of the easiest ways to improve the reliability of your Valkey deployment. Whether you choose a lightweight exporter such as redis_exporter or a more feature-rich platform like BetterDB, exposing metrics to Prometheus lets you detect memory pressure, replication issues, and performance regressions before they affect your applications and architecture. + +Start by deploying the local Docker Compose stack from this guide, explore the available metrics, then adapt the configuration for your own environment by adding authentication, TLS, alerting rules, and dashboards.Historical Valkey metrics collected by Prometheus make troubleshooting and capacity planning far easier than relying on isolated `INFO` snapshots. From a2f71e78f1d566807f7eba3835352d6696563e50 Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Mon, 17 Aug 2026 14:06:31 +0300 Subject: [PATCH 2/9] Update index.md Update the blog with feedback from comments, proper language identifiers added Signed-off-by: Dragos Andriciuc --- .../index.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index 62c470fd..651fa5a8 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -15,7 +15,7 @@ This blog post walks through pairing Valkey with Prometheus, it compares two pop ## What is Prometheus? -Prometheus is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, PromQL. +Prometheus is an open source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, PromQL. Each Prometheus server is standalone and runs independently, it relies only on: @@ -170,8 +170,7 @@ Create a project directory with these files: 1. Create the **`docker-compose.yml`** file: - ```text - version: "3.8" + ```yaml services: valkey: @@ -239,7 +238,7 @@ For the above examples: If you want to add BetterDB to the same stack instead of, or alongside, redis_exporter then add this service and point Prometheus at it too: - ```text + ```yaml betterdb: image: betterdb/monitor container_name: betterdb @@ -253,7 +252,7 @@ If you want to add BetterDB to the same stack instead of, or alongside, redis_ex - valkey ``` - ```text + ```yaml # add to prometheus.yml scrape_configs: - job_name: betterdb static_configs: @@ -265,7 +264,7 @@ Then open `http://localhost:3001` to access BetterDB's own dashboard, in additio You can also generate some traffic to see the dashboards move: - ```text + ```shell docker exec -it valkey valkey-cli --no-raw > SET foo bar > GET foo @@ -274,7 +273,7 @@ You can also generate some traffic to see the dashboards move: Or, for a sustained load, run `valkey-benchmark` from inside the container: - ```text + ```shell docker exec -it valkey valkey-benchmark -q -n 100000 ``` From 09b158f7af23552bd09f6de4cf027a15f351f0de Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Tue, 18 Aug 2026 16:21:55 +0300 Subject: [PATCH 3/9] Add feedback from comments Multiple updates to content, removing Redis mentions, standardize coma paragraph mentions, update table to remove apple with oranges comparison. Signed-off-by: Dragos Andriciuc --- .../index.md | 80 ++++++++++--------- 1 file changed, 41 insertions(+), 39 deletions(-) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index 651fa5a8..b4c61176 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -9,33 +9,33 @@ blog_type = ["Community Highlight"] featured = true +++ -A key trait of Valkey is speed, but "speed" doesn't equal "observability." Before memory fragmentation slowly increases, replication falls behind, or clients retry after latency spikes, all of it starts minutes or hours before anyone notices. That's where monitoring earns its keep. +Imagine this: your application is running fine, until one day, out of the blue, requests start timing out. The only thing you know for certain is that you implemented Valkey to be somewhere in the request path. Is it memory pressure? A lagging replica? A burst of slow commands? Without metrics, "somewhere in the request path" is as specific as your diagnosis gets. -This blog post walks through pairing Valkey with Prometheus, it compares two popular ways to get Valkey metrics into the Prometheus format as well as wiring up Grafana for live dashboards. It also provides you with a docker-compose setup you can run locally in a few minutes. +Enter Prometheus. This post covers two popular ways to get Valkey metrics into Prometheus format, shows how to wire them up for live dashboards in Grafana, and walks through a docker compose setup you can run locally in a few minutes. ## What is Prometheus? -Prometheus is an open source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, PromQL. +[Prometheus](https://prometheus.io/) is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, PromQL. Each Prometheus server is standalone and runs independently, it relies only on: - a local storage such as an HDD or SSD -- and Alertmanager, which handles routing and deduplicating notifications +- and [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), which handles routing and deduplicating notifications -In Valkey's case there is a catch, Prometheus does not talk to Valkey natively. Valkey does not expose any metrics endpoint on its own however it does expose operational data through the `INFO` command. +In Valkey's case there is a catch, Prometheus does not talk to Valkey natively. Valkey does not expose any metrics endpoint on its own however it does expose operational data through the [`INFO` command](https://valkey.io/commands/info/). ## Why monitor Valkey with Prometheus? If you can't see your Valkey database or cache, it will continue to keep serving requests while its fragmentation goes unnoticed and memory creeps toward the `maxmemory` ceiling, or replicas lag behind and the first sign of trouble is often a latency spike somewhere downstream, long after the root cause started. -Putting Valkey behind Prometheus gets you the following advantages: +Putting Valkey behind Prometheus provides several advantages. -- **Trend visibility**: you can view the operations per second, hit ratio, memory usage, and connection counts over time, not just a snapshot from `INFO` when something's already broken. -- **Alerting before things break**: you can set alert rules and manage those alerts using Alertmanager +- **Trend visibility**: View the operations per second, hit ratio, memory usage, and connection counts over time, not just a snapshot from `INFO` when something's already broken. +- **Alerting before things break**: Set alert rules and manage those alerts using Alertmanager which send out notifications using methods such as email, on-call notification systems, and chat platforms. -- **A single pane of glass**: your Valkey metrics sit alongside your application, database, and infrastructure metrics in the same Prometheus and Grafana stack using a standalone exporter, so you can correlate a request-latency spike in your app with what Valkey was doing at that exact moment. -- **Capacity planning**: long-running historical data makes it much easier to answer "when do we need to scale this" instead of blindly guessing metrics. -- **Cluster and replication awareness**: for Valkey Cluster or primary/replica setups, per-node metrics make split-brain-adjacent issues (replication lag, slot imbalance) visible instead of silent by tracking deltas and slot assignments across them. +- **A single pane of glass**: Your Valkey metrics sit alongside your application, database, and infrastructure metrics in the same Prometheus and [Grafana](https://grafana.com/) stack using a standalone exporter, so you can correlate a request-latency spike in your app with what Valkey was doing at that exact moment. +- **Capacity planning**: Long-running historical data makes it much easier to answer "when do we need to scale this" instead of blindly guessing metrics. +- **Cluster and replication awareness**: For Valkey Cluster or primary/replica setups, per-node metrics make split-brain-adjacent issues (replication lag, slot imbalance) visible instead of silent by tracking deltas and slot assignments across them. ## Tools for exporting Valkey metrics to Prometheus @@ -43,21 +43,21 @@ Two tools are useful when talking about exporting Valkey metrics with Prometheus ### BetterDB -[BetterDB](https://www.betterdb.com/) is a Valkey-native observability platform built by Kristiyan Ivanov (you'll find him active on the Valkey Slack). The project started because Valkey is growing quickly but it has mostly inherited tooling that predates it rather than tooling built to take advantage of what Valkey now offers natively, things like `COMMANDLOG` and `CLUSTER SLOT-STATS`. +[BetterDB](https://www.betterdb.com/) is a Valkey-native observability platform built by Kristiyan Ivanov (you'll find him active on the Valkey Slack). The project started because Valkey is growing quickly but it has mostly inherited tooling that predates it rather than tooling built to take advantage of what Valkey now offers natively, things like [`COMMANDLOG`](https://valkey.io/commands/commandlog/) and [`CLUSTER SLOT-STATS`](https://valkey.io/commands/cluster-slot-stats/). -BetterDB is a full monitoring and observability application that provides real-time dashboards, anomaly detection, and operational intelligence for your Valkey deployment, not only a metrics-to-Prometheus bridge. It runs against Valkey **or** Redis, auto-detecting which one it's talking to and enabling Valkey-only features (Command Log support on Valkey 8.1+, Cluster Slot Stats on Valkey 8.0+) when it recognizes them, with graceful fallback on Redis. +BetterDB is a full monitoring and observability application that provides real-time dashboards, anomaly detection, and operational intelligence for your Valkey deployment, not only a metrics-to-Prometheus bridge. ### What metrics does BetterDB cover It exposes its own metrics at `GET /prometheus/metrics` in the standard text/plain format and standard Node.js process metrics from `prom-client`. It covers the following: -- **Core Valkey performance**: operations processed per second, memory usage, and network throughput, derived from `INFO`. -- **ACL audit metrics**: any denied ACL events, broken down by reason and by username, useful for catching misconfigured permissions or attempted unauthorized access. -- **Client connection metrics**: current and peak connection counts, broken down by client name and by ACL user. -- **Slowlog metrics**: slow-query data such as average duration, and percentage share, grouped by query *pattern* rather than raw individual queries, which makes it much easier to spot "this class of query is the problem" instead of scrolling through a slowlog manually. -- **COMMANDLOG metrics (Valkey 8.1+)**: large-request and large-reply counts, surfacing a Valkey-only capability that plain `INFO`-based tools cannot retrieve. -- **Vector Index / AI metrics**: this is for deployments running `valkey-search` or RediSearch, a dedicated set of per-index health metrics and gauges (indexed docs, index memory, indexing failures, percent indexed). -- **Node.js process metrics**: since the monitor itself is a Node.js application, it also exposes its own CPU, event-loop metrics, and HEAP/GC metrics, useful for keeping an eye on the monitoring tool's own health. +- **Core Valkey performance**: Operations processed per second, memory usage, and network throughput, derived from `INFO`. +- **ACL audit metrics**: Denied ACL events, broken down by reason and by username, useful for catching misconfigured permissions or attempted unauthorized access. +- **Client connection metrics**: Current and peak connection counts, broken down by client name and by ACL user. +- **Slowlog metrics**: Metrics data such as average duration, and percentage share, grouped by query *pattern* rather than raw individual queries, which makes it much easier to spot "this class of query is the problem" instead of scrolling through a slowlog manually. +- **COMMANDLOG metrics (Valkey 8.1+)**: Large-request and large-reply counts, surfacing a Valkey-only capability that plain `INFO`-based tools cannot retrieve. +- **Vector Index / AI metrics**: This is for deployments running [`valkey-search`](https://valkey.io/topics/search/), a dedicated set of per-index health metrics and gauges (indexed docs, index memory, indexing failures, percent indexed). +- **Node.js process metrics**: Since the monitor itself is a Node.js application, it also exposes its own CPU, event-loop metrics, and HEAP/GC metrics, useful for keeping an eye on the monitoring tool's own health. ### Example for BetterDB @@ -89,9 +89,9 @@ docker run -d --name betterdb -p 3001:3001 -e DB_HOST=your-valkey-host-ip -e DB_ Then point Prometheus at `http://:3001/prometheus/metrics`, and open `http://:3001` for your built-in dashboard. -### Redis Exporter (Valkey-compatible) +### redis_exporter (Valkey-compatible) -[redis_exporter](https://github.com/oliver006/redis_exporter) is a long-standing, community-standard Prometheus exporter for Valkey metrics. It supports Valkey 7.x, 8.x, and 9.x and with Valkey being protocol-compatible with Redis, it works against Valkey unchanged. +[redis_exporter](https://github.com/oliver006/redis_exporter) is a long-standing, community-standard Prometheus exporter for Valkey metrics. It supports Valkey 7.x, 8.x, and 9.x. However, redis_exporter has no UI of its own. It's a single-purpose exporter: you connect to the datastore, pull data, republish it in the Prometheus format, and export it. You can use this to feed Grafana dashboards and Prometheus alerting rules instead of an actual dashboard. @@ -99,15 +99,15 @@ However, redis_exporter has no UI of its own. It's a single-purpose exporter: yo Most items from Valkey's `INFO` command are exported directly: -- **Memory**: covers used memory, RSS, fragmentation ratio, `maxmemory`, and (through `redis_memory_max_bytes`) the configured memory ceiling. -- **Throughput and commands**: total commands processed, ops/sec, commandstats (with `--include-config-metrics` and related flags), and latency histograms. -- **Keyspace**: per-database total key counts, expiring key counts, and average key TTL. -- **Clients and connections**: connected clients, blocked clients, rejected connections; optionally a full client list breakdown with `--export-client-list`. -- **Replication**: role (primary/replica), connected replicas, replication offset and lag. +- **Memory**: Used memory, RSS, fragmentation ratio, `maxmemory`, and (through `redis_memory_max_bytes`) the configured memory ceiling. +- **Throughput and commands**: Total commands processed, ops/sec, commandstats (with `--include-config-metrics` and related flags), and latency histograms. +- **Keyspace**: Per-database total key counts, expiring key counts, and average key TTL. +- **Clients and connections**: Connected clients, blocked clients, rejected connections and optionally a full client list breakdown with `--export-client-list`. +- **Replication**: Role (primary/replica), connected replicas, replication offset and lag. - **Persistence**: RDB save status, AOF status, last save time and duration. -- **Keyspace hits/misses**: the raw data needed for a cache hit-ratio panel. -- **Cluster support**: with `--is-cluster`, it can discover and scrape every node in a Valkey Cluster using the `/discover-cluster-nodes` endpoint in the Prometheus configuration. -- **Custom and key-level metrics**: using `--check-keys`, `--check-single-keys`, and `--check-key-groups`, you can export the size or length of specific keys or key patterns (handy for tracking the size of a specific queue or sorted set), and even aggregate memory usage by key-naming convention using Lua scripts run on the server-side. +- **Keyspace hits/misses**: The raw data needed for a cache hit-ratio panel. +- **Cluster support**: With `--is-cluster`, it can discover and scrape every node in a Valkey Cluster using the `/discover-cluster-nodes` endpoint in the Prometheus configuration. +- **Custom and key-level metrics**: Using `--check-keys`, `--check-single-keys`, and `--check-key-groups`, you can export the size or length of specific keys or key patterns (handy for tracking the size of a specific queue or sorted set), and even aggregate memory usage by key-naming convention using Lua scripts run on the server-side. **Example** @@ -146,29 +146,31 @@ scrape_configs: ## Pros and cons +BetterDB and redis_exporter operate at different layers of the monitoring stack. While BetterDB is an integrated monitoring application that collects, stores, analyzes, and presents Valkey data, redis_exporter focuses on exposing Valkey metrics to Prometheus so you can build your own dashboards and alerts around them. The comparison below focuses on what each tool provides rather than treating the absence of a built-in UI or analysis feature as a lack of underlying metrics. + | | BetterDB | redis_exporter | |---|---|---| | **What it is** | Full monitoring application including dashboard, a Prometheus endpoint, an audit trail and anomaly detection | Single-purpose Prometheus exporter with no UI | -| **Setup** | One Docker container or `npx @betterdb/monitor`; storage backend (memory/Postgres/SQLite) is your only real decision | One Docker container; typically paired with your own Grafana dashboards | -| **Valkey-specific features** | The COMMANDLOG, CLUSTER SLOT-STATS, auto-detects Valkey vs. Redis and adapts | Coverage is largely the shared Redis-protocol surface (`INFO`, keyspace, replication); it does not surface Valkey-only commands like COMMANDLOG | -| **Vector/AI search visibility** | Dedicated tab and metrics for `valkey-search`/RediSearch | Optional, using the `--include-search-indexes-metrics` flag, less purpose-built | -| **Slowlog analysis** | Grouped by query pattern, with duration and percentage breakdowns | Not exported by default; requires custom Lua scripting | +| **Setup** | One Docker container or `npx @betterdb/monitor`; configurable storage backend | One Docker container; typically paired with your own Grafana dashboards | +| **Valkey-specific features** | The `COMMANDLOG`, `CLUSTER SLOT-STATS` | Exposes many Valkey metrics through INFO and dedicated collectors, including `COMMANDLOG`; does not provide BetterDB's higher-level analysis of those features | +| **Vector/AI search visibility** | Dedicated tab and metrics for `valkey-search` | Optional, using the `--include-search-indexes-metrics` flag, less purpose-built | +| **Slowlog analysis** | Grouped by query pattern, with duration and percentage breakdowns | Exported by default but no detailed slowlog entry analysis | | **Maturity / ecosystem** | Newer project, smaller community, actively evolving | Long-established (originally for Redis), ~3.6k GitHub stars, huge base of existing Grafana dashboards and alerting "mixins" | | **Cluster support** | Supported, with docs specifically for cluster setup | Built-in cluster node discovery via `--is-cluster` and `/discover-cluster-nodes` | | **Extensibility for custom app metrics** | Not really the point of the tool | Strong with Lua scripting (`--script`), custom key/key-group tracking | -| **Overhead** | Runs its own Node.js process with a storage backend; heavier footprint than a pure exporter | Lightweight single Go binary, minimal resource use | -| **Licensing model** | MIT-licensed monitor, with the company behind it (BetterDB Inc., a public benefit company) also offering commercial/managed features | Fully open source (MIT), community-maintained, no commercial layer | +| **Overhead** | Runs its own Node.js process and storage backend; larger footprint than a pure exporter | Lightweight single Go binary; designed for low-overhead metrics collection | +| **Licensing model** | MIT-licensed core with additional proprietary/source-available features | Fully open-source (MIT), community-maintained, no commercial layer | | **Best fit** | Teams that want a ready-made dashboard, audit trail, and Valkey-native visibility without assembling Grafana dashboards themselves | Teams that already run Grafana, Prometheus, Alertmanager and want a proven, low-overhead metrics source to plug into that existing stack | These are not mutually exclusive and it is common to run redis_exporter feeding your existing Grafana and Alertmanager stack for the operational baseline (memory, ops/sec, replication, keyspace), and add BetterDB when you specifically want slowlog pattern analysis, ACL audit visibility, or vector-search monitoring that plain `INFO` scraping does not provide. ## Running everything locally -Here is a docker-compose setup that spins up Valkey, redis_exporter, Prometheus, and Grafana together, so you can see metrics flowing end-to-end on your laptop. +Here is a docker compose setup that spins up Valkey, redis_exporter, Prometheus, and Grafana together, so you can see metrics flowing end-to-end on your laptop. Create a project directory with these files: -1. Create the **`docker-compose.yml`** file: +1. Create the **`compose.yml`** file: ```yaml @@ -178,7 +180,7 @@ Create a project directory with these files: container_name: valkey ports: - "6379:6379" - command: ["valkey-server", "--save", ""] + command: ["valkey-server", "--save", "", "--enable-debug-command", "yes"] redis_exporter: image: oliver006/redis_exporter:latest From 147ca1232f3239d3758ec809a2704d6b535907aa Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Tue, 18 Aug 2026 16:34:33 +0300 Subject: [PATCH 4/9] Add PromQL link Signed-off-by: Dragos Andriciuc --- .../blog/2026-08-30-monitoring-valkey-with-prometheus/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index b4c61176..8f94faac 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -15,7 +15,7 @@ Enter Prometheus. This post covers two popular ways to get Valkey metrics into P ## What is Prometheus? -[Prometheus](https://prometheus.io/) is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, PromQL. +[Prometheus](https://prometheus.io/) is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/). Each Prometheus server is standalone and runs independently, it relies only on: From 729f8e5c602db82f3fedf61cc5e4c2610b2df436 Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Wed, 26 Aug 2026 13:47:02 +0300 Subject: [PATCH 5/9] Remove pro and cons mention and add note on metric prefix change possibility Signed-off-by: Dragos Andriciuc --- .../2026-08-30-monitoring-valkey-with-prometheus/index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index 8f94faac..f8caf6ce 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -135,6 +135,8 @@ redis_exporter_scrapes_total 1 redis_exporter_last_scrape_error{err=""} 0 ``` +**Note:** The `redis_` metric prefix is just the exporter's default Prometheus namespace. The prefix is configurable using `--namespace=valkey` (or any string) if you want `valkey_` metric names instead. For more information, see the `namespace` flag in [redis_exporter's command line flags table](https://github.com/oliver006/redis_exporter/blob/master/README.md#command-line-flags). + This is an example of a minimal Prometheus scrape configuration for it: ```yaml @@ -144,7 +146,7 @@ scrape_configs: - targets: ['redis-exporter:9121'] ``` -## Pros and cons +## Where each one fits BetterDB and redis_exporter operate at different layers of the monitoring stack. While BetterDB is an integrated monitoring application that collects, stores, analyzes, and presents Valkey data, redis_exporter focuses on exposing Valkey metrics to Prometheus so you can build your own dashboards and alerts around them. The comparison below focuses on what each tool provides rather than treating the absence of a built-in UI or analysis feature as a lack of underlying metrics. From 782273338ff90d64dcd71f449d14c1b9d6818a8f Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Thu, 27 Aug 2026 16:40:37 +0300 Subject: [PATCH 6/9] Add Availability Zone Awareness to redis_exporter notes Signed-off-by: Dragos Andriciuc --- .../blog/2026-08-30-monitoring-valkey-with-prometheus/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index f8caf6ce..ca1ac788 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -107,6 +107,7 @@ Most items from Valkey's `INFO` command are exported directly: - **Persistence**: RDB save status, AOF status, last save time and duration. - **Keyspace hits/misses**: The raw data needed for a cache hit-ratio panel. - **Cluster support**: With `--is-cluster`, it can discover and scrape every node in a Valkey Cluster using the `/discover-cluster-nodes` endpoint in the Prometheus configuration. +- **Availability Zone awareness**: Support for Valkey's AZ-aware replica routing metrics is available in [PR 1177](https://github.com/oliver006/redis_exporter/pull/1177). When Valkey reports an `availability_zone` field in its `INFO` output, the exporter includes it automatically. - **Custom and key-level metrics**: Using `--check-keys`, `--check-single-keys`, and `--check-key-groups`, you can export the size or length of specific keys or key patterns (handy for tracking the size of a specific queue or sorted set), and even aggregate memory usage by key-naming convention using Lua scripts run on the server-side. **Example** From 8726ebabb72a481ae0fbb57f6219cc944e32445e Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Wed, 2 Sep 2026 18:11:09 +0300 Subject: [PATCH 7/9] Add quick walkthrough video, fix some issues left over, update date of release and add CTA title Signed-off-by: Dragos Andriciuc --- .../index.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index ca1ac788..4f7a83c9 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -1,6 +1,6 @@ +++ title = "Monitoring Valkey with Prometheus" -date = 2026-08-30 +date = 2026-09-07 description = "Learn how to expose Valkey metrics to Prometheus, visualize them in Grafana, and choose the right exporter for your deployment." authors = ["dragosandriciuc"] [taxonomies] @@ -155,7 +155,7 @@ BetterDB and redis_exporter operate at different layers of the monitoring stack. |---|---|---| | **What it is** | Full monitoring application including dashboard, a Prometheus endpoint, an audit trail and anomaly detection | Single-purpose Prometheus exporter with no UI | | **Setup** | One Docker container or `npx @betterdb/monitor`; configurable storage backend | One Docker container; typically paired with your own Grafana dashboards | -| **Valkey-specific features** | The `COMMANDLOG`, `CLUSTER SLOT-STATS` | Exposes many Valkey metrics through INFO and dedicated collectors, including `COMMANDLOG`; does not provide BetterDB's higher-level analysis of those features | +| **Valkey-specific features** | Native support for `COMMANDLOG` and `CLUSTER SLOT-STATS` | Exposes many Valkey metrics through INFO and dedicated collectors, including `COMMANDLOG`; does not provide BetterDB's higher-level analysis of those features | | **Vector/AI search visibility** | Dedicated tab and metrics for `valkey-search` | Optional, using the `--include-search-indexes-metrics` flag, less purpose-built | | **Slowlog analysis** | Grouped by query pattern, with duration and percentage breakdowns | Exported by default but no detailed slowlog entry analysis | | **Maturity / ecosystem** | Newer project, smaller community, actively evolving | Long-established (originally for Redis), ~3.6k GitHub stars, huge base of existing Grafana dashboards and alerting "mixins" | @@ -284,6 +284,18 @@ Or, for a sustained load, run `valkey-benchmark` from inside the container: The above is a complete, disposable local loop with Valkey, an exporter, Prometheus scraping it, and Grafana visualizing it. This is a hypothetical mirror of what you'd run in production, just without the TLS, ACLs, and persistence you'd want to layer on before shipping it anywhere real. +For a quick walkthrough, here's a one-minute video on exporting Valkey metrics to Prometheus with redis_exporter and BetterDB: +
+ +
+ +## What's next? + Monitoring is one of the easiest ways to improve the reliability of your Valkey deployment. Whether you choose a lightweight exporter such as redis_exporter or a more feature-rich platform like BetterDB, exposing metrics to Prometheus lets you detect memory pressure, replication issues, and performance regressions before they affect your applications and architecture. -Start by deploying the local Docker Compose stack from this guide, explore the available metrics, then adapt the configuration for your own environment by adding authentication, TLS, alerting rules, and dashboards.Historical Valkey metrics collected by Prometheus make troubleshooting and capacity planning far easier than relying on isolated `INFO` snapshots. +Start by deploying the local Docker Compose stack from this guide, explore the available metrics, then adapt the configuration for your own environment by adding authentication, TLS, alerting rules, and dashboards. Historical Valkey metrics collected by Prometheus make troubleshooting and capacity planning far easier than relying on isolated `INFO` snapshots. From b949f9aa89cf5b9c184bb7f40f590c22aa347004 Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Thu, 17 Sep 2026 16:09:48 +0300 Subject: [PATCH 8/9] Polish Prometheus blog copy, update Valkey image Editorial and example updates to the Prometheus + Valkey blog post: - improved punctuation and sentence clarity, clarified redis_exporter compatibility wording - bumped the docker-compose image to valkey/valkey:9-alpine - removed the embedded YouTube walkthrough video. Signed-off-by: Dragos Andriciuc --- .../index.md | 24 ++++++------------- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index 4f7a83c9..6a865dd7 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -17,18 +17,18 @@ Enter Prometheus. This post covers two popular ways to get Valkey metrics into P [Prometheus](https://prometheus.io/) is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/). -Each Prometheus server is standalone and runs independently, it relies only on: +Each Prometheus server is standalone and runs independently. It relies only on: -- a local storage such as an HDD or SSD -- and [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), which handles routing and deduplicating notifications +- a local storage such as an HDD or SSD, +- and [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), which handles routing and deduplicating notifications. -In Valkey's case there is a catch, Prometheus does not talk to Valkey natively. Valkey does not expose any metrics endpoint on its own however it does expose operational data through the [`INFO` command](https://valkey.io/commands/info/). +In Valkey's case, there is a catch: Prometheus does not talk to Valkey natively. Valkey does not expose any metrics endpoint on its own. However it does expose operational data through the [`INFO` command](https://valkey.io/commands/info/). ## Why monitor Valkey with Prometheus? If you can't see your Valkey database or cache, it will continue to keep serving requests while its fragmentation goes unnoticed and memory creeps toward the `maxmemory` ceiling, or replicas lag behind and the first sign of trouble is often a latency spike somewhere downstream, long after the root cause started. -Putting Valkey behind Prometheus provides several advantages. +Putting Valkey and Prometheus provides several advantages. - **Trend visibility**: View the operations per second, hit ratio, memory usage, and connection counts over time, not just a snapshot from `INFO` when something's already broken. - **Alerting before things break**: Set alert rules and manage those alerts using Alertmanager @@ -91,7 +91,7 @@ Then point Prometheus at `http://:3001/prometheus/metrics`, and open `http ### redis_exporter (Valkey-compatible) -[redis_exporter](https://github.com/oliver006/redis_exporter) is a long-standing, community-standard Prometheus exporter for Valkey metrics. It supports Valkey 7.x, 8.x, and 9.x. +[redis_exporter](https://github.com/oliver006/redis_exporter) is a long-standing, community-standard Prometheus exporter for Valkey metrics. At the time of writing, it supports Valkey 7.x, 8.x, and 9.x. However, redis_exporter has no UI of its own. It's a single-purpose exporter: you connect to the datastore, pull data, republish it in the Prometheus format, and export it. You can use this to feed Grafana dashboards and Prometheus alerting rules instead of an actual dashboard. @@ -179,7 +179,7 @@ Create a project directory with these files: services: valkey: - image: valkey/valkey:8-alpine + image: valkey/valkey:9-alpine container_name: valkey ports: - "6379:6379" @@ -284,16 +284,6 @@ Or, for a sustained load, run `valkey-benchmark` from inside the container: The above is a complete, disposable local loop with Valkey, an exporter, Prometheus scraping it, and Grafana visualizing it. This is a hypothetical mirror of what you'd run in production, just without the TLS, ACLs, and persistence you'd want to layer on before shipping it anywhere real. -For a quick walkthrough, here's a one-minute video on exporting Valkey metrics to Prometheus with redis_exporter and BetterDB: -
- -
- ## What's next? Monitoring is one of the easiest ways to improve the reliability of your Valkey deployment. Whether you choose a lightweight exporter such as redis_exporter or a more feature-rich platform like BetterDB, exposing metrics to Prometheus lets you detect memory pressure, replication issues, and performance regressions before they affect your applications and architecture. From 31238d3c20526f3b51de050310f18ccd5acf8bd5 Mon Sep 17 00:00:00 2001 From: Dragos Andriciuc Date: Thu, 17 Sep 2026 16:30:21 +0300 Subject: [PATCH 9/9] Reflow and clarify Prometheus blog post Reflows markdown in content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md for improved readability and consistency. Made minor wording clarifications (Prometheus uses local storage by default; Alertmanager is optional), expand explanatory notes (redis_exporter namespace), and tighten phrasing across BetterDB, redis_exporter, and examples. Signed-off-by: Dragos Andriciuc --- .../index.md | 49 +++++++++++++------ 1 file changed, 34 insertions(+), 15 deletions(-) diff --git a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md index 6a865dd7..3d511e4e 100644 --- a/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md +++ b/content/blog/2026-08-30-monitoring-valkey-with-prometheus/index.md @@ -9,20 +9,27 @@ blog_type = ["Community Highlight"] featured = true +++ -Imagine this: your application is running fine, until one day, out of the blue, requests start timing out. The only thing you know for certain is that you implemented Valkey to be somewhere in the request path. Is it memory pressure? A lagging replica? A burst of slow commands? Without metrics, "somewhere in the request path" is as specific as your diagnosis gets. +Imagine this: your application is running fine, until one day, out of the blue, requests start timing out. +The only thing you know for certain is that you implemented Valkey to be somewhere in the request path. +Is it memory pressure? A lagging replica? A burst of slow commands? +Without metrics, "somewhere in the request path" is as specific as your diagnosis gets. -Enter Prometheus. This post covers two popular ways to get Valkey metrics into Prometheus format, shows how to wire them up for live dashboards in Grafana, and walks through a docker compose setup you can run locally in a few minutes. +Enter Prometheus. +This post covers two popular ways to get Valkey metrics into Prometheus format, shows how to wire them up for live dashboards in Grafana, and walks through a docker compose setup you can run locally in a few minutes. ## What is Prometheus? -[Prometheus](https://prometheus.io/) is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/). +[Prometheus](https://prometheus.io/) is an open-source systems monitoring and alerting toolkit designed for reliability, multi-dimensional data collection and querying even during outages or broken architectures. +It scrapes and periodically pulls metrics from instrumented jobs exposed by the systems it monitors, storing them as time series (changes over time) in its own local database, which allows you to query, graph, and alert on that data using its flexible query language, [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/). Each Prometheus server is standalone and runs independently. It relies only on: -- a local storage such as an HDD or SSD, -- and [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), which handles routing and deduplicating notifications. +- a local storage such as an HDD or SSD by default, +- optionally, [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), which handles routing and deduplicating notifications. -In Valkey's case, there is a catch: Prometheus does not talk to Valkey natively. Valkey does not expose any metrics endpoint on its own. However it does expose operational data through the [`INFO` command](https://valkey.io/commands/info/). +In Valkey's case, there is a catch: Prometheus does not talk to Valkey natively. +Valkey does not expose any metrics endpoint on its own. +However it does expose operational data through the [`INFO` command](https://valkey.io/commands/info/). ## Why monitor Valkey with Prometheus? @@ -39,11 +46,13 @@ which send out notifications using methods such as email, on-call notification s ## Tools for exporting Valkey metrics to Prometheus -Two tools are useful when talking about exporting Valkey metrics with Prometheus: **BetterDB** and **redis_exporter**. They solve overlapping but distinct problems. +Two tools are useful when talking about exporting Valkey metrics with Prometheus: **BetterDB** and **redis_exporter**. +They solve overlapping but distinct problems. ### BetterDB -[BetterDB](https://www.betterdb.com/) is a Valkey-native observability platform built by Kristiyan Ivanov (you'll find him active on the Valkey Slack). The project started because Valkey is growing quickly but it has mostly inherited tooling that predates it rather than tooling built to take advantage of what Valkey now offers natively, things like [`COMMANDLOG`](https://valkey.io/commands/commandlog/) and [`CLUSTER SLOT-STATS`](https://valkey.io/commands/cluster-slot-stats/). +[BetterDB](https://www.betterdb.com/) is a Valkey-native observability platform built by Kristiyan Ivanov (you'll find him active on the Valkey Slack). +The project started because Valkey is growing quickly but it has mostly inherited tooling that predates it rather than tooling built to take advantage of what Valkey now offers natively, things like [`COMMANDLOG`](https://valkey.io/commands/commandlog/) and [`CLUSTER SLOT-STATS`](https://valkey.io/commands/cluster-slot-stats/). BetterDB is a full monitoring and observability application that provides real-time dashboards, anomaly detection, and operational intelligence for your Valkey deployment, not only a metrics-to-Prometheus bridge. @@ -91,9 +100,12 @@ Then point Prometheus at `http://:3001/prometheus/metrics`, and open `http ### redis_exporter (Valkey-compatible) -[redis_exporter](https://github.com/oliver006/redis_exporter) is a long-standing, community-standard Prometheus exporter for Valkey metrics. At the time of writing, it supports Valkey 7.x, 8.x, and 9.x. +[redis_exporter](https://github.com/oliver006/redis_exporter) is a long-standing, community-standard Prometheus exporter for Valkey metrics. +At the time of writing, it supports Valkey 7.x, 8.x, and 9.x. -However, redis_exporter has no UI of its own. It's a single-purpose exporter: you connect to the datastore, pull data, republish it in the Prometheus format, and export it. You can use this to feed Grafana dashboards and Prometheus alerting rules instead of an actual dashboard. +However, redis_exporter has no UI of its own. +It's a single-purpose exporter: you connect to the datastore, pull data, republish it in the Prometheus format, and export it. +You can use this to feed Grafana dashboards and Prometheus alerting rules instead of an actual dashboard. ### What metrics does redis_exporter cover @@ -136,7 +148,9 @@ redis_exporter_scrapes_total 1 redis_exporter_last_scrape_error{err=""} 0 ``` -**Note:** The `redis_` metric prefix is just the exporter's default Prometheus namespace. The prefix is configurable using `--namespace=valkey` (or any string) if you want `valkey_` metric names instead. For more information, see the `namespace` flag in [redis_exporter's command line flags table](https://github.com/oliver006/redis_exporter/blob/master/README.md#command-line-flags). +**Note:** The `redis_` metric prefix is just the exporter's default Prometheus namespace. +The prefix is configurable using `--namespace=valkey` (or any string) if you want `valkey_` metric names instead. +For more information, see the `namespace` flag in [redis_exporter's command line flags table](https://github.com/oliver006/redis_exporter/blob/master/README.md#command-line-flags). This is an example of a minimal Prometheus scrape configuration for it: @@ -149,7 +163,9 @@ scrape_configs: ## Where each one fits -BetterDB and redis_exporter operate at different layers of the monitoring stack. While BetterDB is an integrated monitoring application that collects, stores, analyzes, and presents Valkey data, redis_exporter focuses on exposing Valkey metrics to Prometheus so you can build your own dashboards and alerts around them. The comparison below focuses on what each tool provides rather than treating the absence of a built-in UI or analysis feature as a lack of underlying metrics. +BetterDB and redis_exporter operate at different layers of the monitoring stack. +While BetterDB is an integrated monitoring application that collects, stores, analyzes, and presents Valkey data, redis_exporter focuses on exposing Valkey metrics to Prometheus so you can build your own dashboards and alerts around them. +The comparison below focuses on what each tool provides rather than treating the absence of a built-in UI or analysis feature as a lack of underlying metrics. | | BetterDB | redis_exporter | |---|---|---| @@ -282,10 +298,13 @@ Or, for a sustained load, run `valkey-benchmark` from inside the container: docker exec -it valkey valkey-benchmark -q -n 100000 ``` -The above is a complete, disposable local loop with Valkey, an exporter, Prometheus scraping it, and Grafana visualizing it. This is a hypothetical mirror of what you'd run in production, just without the TLS, ACLs, and persistence you'd want to layer on before shipping it anywhere real. +The above is a complete, disposable local loop with Valkey, an exporter, Prometheus scraping it, and Grafana visualizing it. +This is a hypothetical mirror of what you'd run in production, just without the TLS, ACLs, and persistence you'd want to layer on before shipping it anywhere real. ## What's next? -Monitoring is one of the easiest ways to improve the reliability of your Valkey deployment. Whether you choose a lightweight exporter such as redis_exporter or a more feature-rich platform like BetterDB, exposing metrics to Prometheus lets you detect memory pressure, replication issues, and performance regressions before they affect your applications and architecture. +Monitoring is one of the easiest ways to improve the reliability of your Valkey deployment. +Whether you choose a lightweight exporter such as redis_exporter or a more feature-rich platform like BetterDB, exposing metrics to Prometheus lets you detect memory pressure, replication issues, and performance regressions before they affect your applications and architecture. -Start by deploying the local Docker Compose stack from this guide, explore the available metrics, then adapt the configuration for your own environment by adding authentication, TLS, alerting rules, and dashboards. Historical Valkey metrics collected by Prometheus make troubleshooting and capacity planning far easier than relying on isolated `INFO` snapshots. +Start by deploying the local Docker Compose stack from this guide, explore the available metrics, then adapt the configuration for your own environment by adding authentication, TLS, alerting rules, and dashboards. +Historical Valkey metrics collected by Prometheus make troubleshooting and capacity planning far easier than relying on isolated `INFO` snapshots.