{
"schema_version": 2,
"id": "operate/rs/monitoring/get-started",
"title": "Get started with monitoring Redis Software",
"url": "https://redis.io/docs/latest/operate/rs/monitoring/get-started/",
"summary": "Collect and visualize Redis Software metrics.",
"aliases": [
"/operate/rs/monitoring/prometheus_and_grafana/"
],
"tags": [
"docs",
"integrate",
"rs"
],
"last_updated": "2026-10-01T15:48:36+01:00",
"page_type": "content",
"content_hash": "732370eac4f185d2971f52e2d4480670d2a4f9005c856feb35d03a043b0d5016",
"sections": [
{
"id": "overview",
"title": "Overview",
"role": "overview",
"text": "You can use Prometheus and compatible integrations to collect and visualize your Redis Software metrics.\n\nMetrics are exposed at the cluster, node, database, shard, and proxy levels.\n\n- [Prometheus](https://prometheus.io/) is an open source systems monitoring and alerting toolkit that aggregates metrics from different sources.\n\nYou can use Prometheus integrations to:\n- Collect and display metrics not available in the Cluster Manager UI\n\n- Set up automatic alerts for all resources\n\n- Display Redis Software metrics alongside data from other systems"
},
{
"id": "prometheus-integrations",
"title": "Prometheus integrations",
"role": "content",
"text": "You can integrate Redis Software with Prometheus and one of the following tools to collect and visualize your deployment's metrics:\n\n- [Grafana](https://redis.io/docs/latest/integrate/prometheus-with-redis-enterprise)\n\n- [Datadog](https://redis.io/docs/latest/integrate/datadog-with-redis-enterprise)\n\n- [Dynatrace](https://redis.io/docs/latest/integrate/dynatrace-with-redis-enterprise)\n\n- [New Relic](https://redis.io/docs/latest/integrate/new-relic-with-redis-enterprise)"
},
{
"id": "best-practices-for-monitoring",
"title": "Best practices for monitoring",
"role": "content",
"text": "Follow these best practices when monitoring your Redis Software cluster using the metrics stream engine."
},
{
"id": "monitor-host-level-metrics",
"title": "Monitor host-level metrics",
"role": "content",
"text": "For cluster health, resources, and node stability, monitor these metrics:\n\n| Group | Metric | Why monitor | Unit |\n|-------|--------|-------------|------|\n| CPU utilization | `node_cpu_user`,
`node_cpu_system` | Detect CPU saturation from Redis or the OS that results in higher latency and queueing. | Seconds (counter) |\n| Memory (freeable) | `node_memory_MemTotal_bytes`,
`node_memory_MemFree_bytes`,
`node_memory_Buffers_bytes`,
`node_memory_Cached_bytes` | Detect memory pressure early. Low free memory or cache can precede swapping or out-of-memory errors. | Bytes (gauge) |\n| Swap usage | `node_ephemeral_storage_free` | Monitor memory and disk pressure in your setup. Sustained pressure leads to latency spikes. | Bytes (gauge) |\n| Network traffic | `node_ingress_bytes`,
`node_egress_bytes` | Ensure the network interface is not saturated. Protects replication and client responsiveness. | Bytes (counter) |\n| Disk space | `node_filesystem_avail_bytes`,
`node_filesystem_size_bytes` | Prevent persistence and logging outages from low disk space. | Bytes (gauge) |\n| Cluster state | `has_quorum{…}` | Monitor whether quorum is maintained (1) or lost (0). | Boolean |\n| | `node_metrics_up` | Monitor whether the node is connected and reporting to the cluster. | Gauge |\n| Licensing | `license_shards_limit` | Track shard capacity limits by type (RAM or flash). | Count |\n| Certificates | `node_cert_expires_in_seconds` | Avoid downtime from expired node certificates. | Seconds (gauge) |\n| Services – CPU | `namedprocess_namegroup_cpu_seconds_total` | Identify abnormal CPU usage by platform services that can starve Redis, such as `alert_mgr`, `redis_mgr`, `dmc_proxy`. | Seconds (counter) |\n| Services – memory | `namedprocess_namegroup_memory_bytes` | Detect memory leaks or outliers in platform services, such as `alert_mgr`, `redis_mgr`, `dmc_proxy`. | Bytes (gauge) |"
},
{
"id": "monitor-database-level-metrics",
"title": "Monitor database-level metrics",
"role": "content",
"text": "For database performance, availability, and efficiency, monitor the following metrics:\n\n| Group | Metric | Why monitor | Unit |\n|-------|--------|-------------|------|\n| Memory | `redis_server_used_memory` | Track actual data memory to prevent out-of-memory errors and evictions. | Bytes |\n| Memory | `redis_server_allocator_allocated` | Monitor bytes allocated by allocator (includes internal fragmentation). | Bytes |\n| Memory | `redis_server_allocator_active` | Monitor bytes in active pages (includes external fragmentation). Use delta/ratio versus allocated to infer defraggable memory. | Bytes |\n| Memory | `redis_server_active_defrag_running` | Monitor if defragmentation is active and the intended CPU %. High values can affect performance. | % (gauge) |\n| Latency | `endpoint_read_requests_latency_histogram`,
`endpoint_write_requests_latency_histogram`,
`endpoint_other_requests_latency_histogram` | Monitor server-side command latency. | Microseconds |\n| High availability | `redis_server_master_repl_offset` | Compute replica throughput and lag using deltas over time. | Bytes (counter) |\n| High availability | `redis_server_master_link_status` | Monitor replica link status (up or down) for early warning of high availability risk. | Status |\n| Active-Active | `database_syncer_dst_lag`,
`database_syncer_lag_ms` | Detect cross-region synchronization delays that impact consistency and SLAs. | Milliseconds (gauge) |\n| Active-Active | `database_syncer_state` | Monitor operational state for troubleshooting synchronization issues. | Gauge |\n| Traffic – requests | `endpoint_read_requests`,
`endpoint_write_requests`,
`endpoint_other_requests` | Monitor workload mix and spikes that drive capacity and latency. Total equals the sum of all three. | Counter |\n| Traffic – responses | `endpoint_read_responses`,
`endpoint_write_responses`,
`endpoint_other_responses` | Validate service responsiveness and symmetry with requests. | Counter |\n| Traffic – bytes | `endpoint_ingress`,
`endpoint_egress` | Monitor size trends and watch for sudden growth that impacts egress costs or bandwidth. | Bytes (counter) |\n| Egress queue | `endpoint_egress_pending`,
`endpoint_egress_pending_discarded` | Monitor back-pressure and drops that indicate network or client issues. | Bytes (counter) |\n| Connections | `endpoint_client_connection` | Monitor accepted connections over time and match against client rollouts or spikes. | Counter |\n| Connections | `endpoint_client_connection_expired` | Monitor connections closed due to TTL expiry, which can indicate idle policy or client issues. | Counter |\n| Connections | `endpoint_longest_pipeline_histogram` | Monitor long pipelines that can amplify latency bursts and detect misbehaving clients. | Histogram (count) |\n| Connections | `endpoint_client_connections`,
`endpoint_client_disconnections`,
`endpoint_proxy_disconnections` | Monitor connection churn and identify who closed the socket (client versus proxy). Current connections ≈ connections − disconnections. | Counter |\n| Cache efficiency | `redis_server_db_keys`,
`redis_server_db_avg_ttl` | Monitor key inventory and TTL coverage to inform eviction strategy. | Counter |\n| Cache efficiency | `redis_server_evicted_keys\t`,
`redis_server_expired_keys` | Monitor eviction and expiry rates. Frequent evictions indicate memory pressure or poor sizing. | Counter |\n| Cache efficiency | `cache_hits`,
`cache_hit_rate` | Monitor hit rate, which drives read latency and cost. Cache hit rate equals cache_hits/(cache_hits+cache_misses). | Count / Ratio (%) |\n| Cache efficiency | `endpoint_client_tracking_on_requests`,
`endpoint_client_tracking_off_requests`,
`endpoint_disposed_commands_after_client_caching` | Track client-side caching usage and misuse. | Counter |\n| Big / complex keys | `redis_server___` | Monitor oversized keys and cardinality that cause fragmentation, slow replication, and CPU spikes. Track to prevent incidents. Examples:
`strings_sizes_over_512M`,
`zsets_items_over_8M` | Gauge |\n| Security – clients | `endpoint_client_expiration_refresh`,
`endpoint_client_establishment_failures` | Monitor unstable clients or problems with authentication or setup. | Counter |\n| Security – LDAP | `endpoint_successful_ldap_authentication`,
`endpoint_failed_ldap_authentication`,
`endpoint_disconnected_ldap_client` | Monitor authentication health and detect brute-force attacks or misconfigurations. | Counter |\n| Security – cert-based | `endpoint_successful_cba_authentication`,
`endpoint_failed_cba_authentication`,
`endpoint_disconnected_cba_client` | Monitor certificate authentication status and failures. | Counter |\n| Security – password | `endpoint_disconnected_user_password_client` | Monitor password-authentication client disconnects and correlate with policy changes. | Counter |\n| Security – ACL | `redis_server_acl_access_denied_auth`,
`redis_server_acl_access_denied_cmd`,
`redis_server_acl_access_denied_key`,
`redis_server_acl_access_denied_channel` | Monitor unauthorized access attempts and incorrectly scoped ACLs. | Counter |\n| Configuration | `db_config`| This is an information metric that holds database configuration within labels such as: db_name, db_version, db_port, tls_mode. | counter |"
},
{
"id": "prometheus-quick-start",
"title": "Prometheus quick start",
"role": "content",
"text": "To get started with Prometheus:\n\n1. Create a directory called `prometheus` on your local machine.\n\n1. Within that directory, create a configuration file called `prometheus.yml`.\n\n1. Add the following contents to the configuration file and replace `` with your Redis Software cluster's FQDN:\n\n **v2 (metrics stream engine):**\n\n[code example]\n\n**v1:**\n\n[code example]\n\n\n\n > [!NOTE]\n > **Use a single scrape target.** The v2 endpoint is cluster-wide. Every node aggregates metrics from all nodes and returns the same complete result, so one target is enough. If you list one target per node, Prometheus stores every series once per target and multiplies each `sum()`-based dashboard panel by the number of targets. This produces no error. Prometheus reports every target as up and Grafana renders normally. Use your cluster FQDN as the single target so metrics remain available if a node goes down.\n\n1. Set up your Prometheus server.\n\n > [!NOTE]\n > We recommend running Prometheus in Docker only for development and testing.\n\n To set up Prometheus on Docker:\n\n 1. Create a _docker-compose.yml_ file:\n\n [code example]\n\n 1. To start the containers, run:\n\n [code example]\n\n 1. To check that all of the containers are up, run: \n \n [code example]\n\n 1. In your browser, sign in to Prometheus at `http://localhost:9090` to make sure the server is running.\n\n 1. Select **Status** and then **Targets** to check that Prometheus is collecting data from your Redis Software cluster.\n\n \n\n If Prometheus is connected to the cluster, you can type **node_up** in the Expression field on the Prometheus home page to see the cluster metrics.\n\n To confirm you are not scraping duplicate targets, query `count(up{job=\"redis-enterprise\"})`. A correct configuration returns `1`. To confirm the cluster can reach every node, query `node_metrics_up`, which reports `0` for any node the aggregator failed to scrape.\n\n1. Integrate Redis Software and your Prometheus server with one of the [compatible tools](#prometheus-integrations). For help, see the integration guide and official documentation for your chosen tool.\n\n1. Add dashboards for cluster, database, node, and shard metrics."
}
],
"examples": [
{
"id": "prometheus-quick-start-ex0",
"language": "yml",
"code": "global:\n scrape_interval: 15s\n evaluation_interval: 15s\n\n# Attach these labels to any time series or alerts when communicating with\n# external systems (federation, remote storage, Alertmanager).\n external_labels:\n monitor: \"prometheus-stack-monitor\"\n\n# Load and evaluate rules in this file every 'evaluation_interval' seconds.\n#rule_files:\n# - \"first.rules\"\n# - \"second.rules\"\n\nscrape_configs:\n# scrape Prometheus itself\n - job_name: prometheus\n scrape_interval: 10s\n scrape_timeout: 5s\n static_configs:\n - targets: [\"localhost:9090\"]\n\n# scrape Redis Software\n - job_name: redis-enterprise\n scrape_interval: 30s\n scrape_timeout: 30s\n metrics_path: /v2\n scheme: https\n tls_config:\n insecure_skip_verify: true\n static_configs:\n - targets: [\":8070\"]",
"section_id": "prometheus-quick-start"
},
{
"id": "prometheus-quick-start-ex1",
"language": "yml",
"code": "global:\n scrape_interval: 15s\n evaluation_interval: 15s\n\n# Attach these labels to any time series or alerts when communicating with\n# external systems (federation, remote storage, Alertmanager).\n external_labels:\n monitor: \"prometheus-stack-monitor\"\n\n# Load and evaluate rules in this file every 'evaluation_interval' seconds.\n#rule_files:\n# - \"first.rules\"\n# - \"second.rules\"\n\nscrape_configs:\n# scrape Prometheus itself\n - job_name: prometheus\n scrape_interval: 10s\n scrape_timeout: 5s\n static_configs:\n - targets: [\"localhost:9090\"]\n\n# scrape Redis Software\n - job_name: redis-enterprise\n scrape_interval: 30s\n scrape_timeout: 30s\n metrics_path: /\n scheme: https\n tls_config:\n insecure_skip_verify: true\n static_configs:\n - targets: [\":8070\"]",
"section_id": "prometheus-quick-start"
},
{
"id": "prometheus-quick-start-ex2",
"language": "yml",
"code": "version: '3'\n services:\n prometheus-server:\n image: prom/prometheus\n ports:\n - 9090:9090\n volumes:\n - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml",
"section_id": "prometheus-quick-start"
},
{
"id": "prometheus-quick-start-ex3",
"language": "sh",
"code": "$ docker compose up -d",
"section_id": "prometheus-quick-start"
},
{
"id": "prometheus-quick-start-ex4",
"language": "sh",
"code": "docker ps",
"section_id": "prometheus-quick-start"
}
]
}