How to Monitor & Secure Redis on Linux Server – Easy Guide

To monitor and secure Redis on a Linux server, keep Redis off the public internet, enforce ACL/password auth and TLS, and continuously track health metrics (memory, ops/sec, latency, key evictions). Use firewalls, minimal permissions, backups, and Prometheus/Grafana alerts. Regular audits, patching, and log reviews keep production Redis stable and safe.

Running Redis in production demands two disciplines: visibility and hardening. In this guide, I’ll show you how to monitor and secure Redis on a Linux server using proven, beginner-friendly steps, commands, and configs. You’ll learn real-world techniques we use at scale to keep Redis fast, stable, and locked down.

Why Monitoring and Security Matter for Redis?

Redis is often a hot path for APIs, sessions, caching, and queues. Unmonitored, it can silently hit memory limits, evict keys, or stall under latency spikes. Unsecured, it’s a prime target for ransomware, cryptominers, and data exfiltration—especially if exposed to the internet.

Good news: Redis provides robust observability and security controls. With a few Linux best practices—firewalls, ACLs, TLS, backups—you can harden Redis and gain deep insight into performance and reliability.

Search Intent and What You’ll Learn

This tutorial is for Linux users and DevOps teams who want a practical, step-by-step way to monitor Redis performance and apply Redis security best practices without guesswork. We’ll cover built-in tools, Prometheus/Grafana, firewalling, ACLs, TLS, and ongoing maintenance.

Quick Security Checklist (Start Here)

• Do not expose Redis to the public internet.
• Bind Redis to localhost or a private VPC subnet.
• Enable authentication (ACLs in Redis 6+).
• Use TLS encryption for in-transit data.
• Harden redis.conf (protected-mode, disable dangerous commands).
• Lock down the Linux firewall and system permissions.
• Keep Redis updated; patch regularly.
• Enable backups (RDB/AOF) and test restore.
• Monitor metrics, logs, and slow queries with alerts.

How to Monitor Redis on a Linux Server

1) Check Service Health and Logs

Start by confirming Redis is healthy and logging correctly. Service names differ by distro.

# Ubuntu/Debian
sudo systemctl status redis-server
sudo journalctl -u redis-server --since "1 hour ago"

# CentOS/RHEL
sudo systemctl status redis
sudo journalctl -u redis --since "1 hour ago"

Set an appropriate log level in redis.conf: debug, verbose, notice (default), or warning.

loglevel notice
logfile /var/log/redis/redis-server.log

2) Use redis-cli for Fast Diagnostics

Redis exposes rich runtime metrics via INFO. Use this first when performance changes.

# If using ACLs/password
redis-cli -a <password> INFO

# Key sections: Server, Clients, Memory, Persistence, Stats, Replication, CPU, Cluster, Keyspace

Key metrics to watch:

• used_memory, used_memory_rss, mem_fragmentation_ratio
• connected_clients, blocked_clients
• instantaneous_ops_per_sec, instantaneous_input_kbps
• keyspace_hits/misses (cache efficiency)
• evicted_keys, expired_keys (memory pressure)
• rejected_connections (rate limiting/limits hit)
• rdb_last_bgsave_status, aof_last_bgrewrite_status
• master_link_status (replication health)

3) Investigate Latency and Slow Commands

Slow queries degrade user experience. Enable and review SLOWLOG to find hot spots.

# Show the most recent 128 slow entries
redis-cli -a <password> SLOWLOG GET 128

# Configure thresholds (microseconds) in redis.conf
slowlog-log-slower-than 10000    # 10ms
slowlog-max-len 1024

Correlate slow entries with app code paths and optimize data structures (e.g., prefer hashes/sets over large lists when appropriate).

4) Stream Live Operations Carefully

MONITOR streams every command and is expensive. Use only for short, targeted debugging on non-peak traffic.

redis-cli -a <password> MONITOR  # Ctrl+C to stop

5) Prometheus + Grafana (Recommended)

For continuous monitoring and alerting, deploy the official Redis exporter (oliver006/redis_exporter) and scrape it with Prometheus. Visualize dashboards in Grafana.

# Download a release binary (example version)
curl -L -o redis_exporter.tar.gz https://github.com/oliver006/redis_exporter/releases/download/v1.61.0/redis_exporter-v1.61.0.linux-amd64.tar.gz
tar xzf redis_exporter.tar.gz
cd redis_exporter-v1.61.0.linux-amd64
./redis_exporter --redis.addr=redis://127.0.0.1:6379 --redis.password=<password> &

Prometheus scrape config:

scrape_configs:
  - job_name: 'redis'
    static_configs:
      - targets: ['127.0.0.1:9121']

Example alert rules (tune thresholds to your workload):

groups:
- name: redis-alerts
  rules:
  - alert: RedisHighMemory
    expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.8
    for: 5m
    labels: { severity: warning }
    annotations:
      description: "Redis using >80% of max memory"

  - alert: RedisReplicationDown
    expr: redis_master_link_up == 0
    for: 2m
    labels: { severity: critical }
    annotations:
      description: "Replication link is down"

  - alert: RedisEvictions
    expr: rate(redis_evicted_keys_total[5m]) > 1
    for: 10m
    labels: { severity: warning }
    annotations:
      description: "Keys are being evicted; investigate memory pressure"

How to Secure Redis on a Linux Server

1) Network Isolation and Firewalling

Never expose Redis directly to the internet. Bind to localhost for single-host apps or to a private IP within your VPC/VNet.

# redis.conf
bind 127.0.0.1 10.0.1.10
protected-mode yes
port 6379

Block external access with ufw or firewalld and allow only approved app servers.

# UFW (Ubuntu/Debian)
sudo ufw deny 6379/tcp
sudo ufw allow from 10.0.1.20 to any port 6379 proto tcp

# firewalld (CentOS/RHEL)
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.0.1.20/32 port protocol=tcp port=6379 accept'
sudo firewall-cmd --permanent --add-port=6379/tcp --remove-port=6379/tcp
sudo firewall-cmd --reload

If SELinux is enforcing and you change ports, update the policy:

sudo semanage port -a -t redis_port_t -p tcp 6379  # if moved to a non-default port

2) Enable Authentication and ACLs (Redis 6+)

Use ACLs to enforce least privilege. Avoid relying only on requirepass; define explicit users and permissions.

# redis.conf (Redis 6+)
# Disable default user or limit it
user default off

# Create an app user with strong password and limited permissions
# Allow all keys (~*) but only safe command categories (+@read +@write)
# Remove dangerous commands (-@dangerous)
aclfile /etc/redis/users.acl

# /etc/redis/users.acl
user default off
user app on >p@ssw0rd-ChangeMe ~* +@read +@write -@dangerous
user admin on >S3cureAdmin! ~* +@all

For Redis versions < 6, set a strong password and restrict network access tightly.

# redis.conf (legacy)
requirepass p@ssw0rd-ChangeMe

3) Encrypt Traffic with TLS

Use TLS to protect credentials and data in transit. Redis 6+ supports native TLS.

# redis.conf (TLS)
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file  /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-auth-clients yes
tls-protocols "TLSv1.2 TLSv1.3"

Connect with TLS:

redis-cli --tls \
  --cert /etc/redis/tls/client.crt \
  --key /etc/redis/tls/client.key \
  --cacert /etc/redis/tls/ca.crt \
  -a p@ssw0rd-ChangeMe -h redis.internal -p 6379

Alternatively, wrap with stunnel/Nginx stream if you must support older clients.

4) Disable or Rename Dangerous Commands

Commands like FLUSHALL, CONFIG, KEYS, MODULE, and SHUTDOWN can be risky in production. With ACLs, remove the dangerous category or explicitly rename commands to empty string for legacy setups.

# redis.conf (legacy hardening)
rename-command FLUSHALL ""
rename-command FLUSHDB  ""
rename-command CONFIG   ""
rename-command KEYS     ""
rename-command SHUTDOWN ""

5) Secure Persistence, Files, and Process

Run Redis under the dedicated redis user with locked-down directories.

# redis.conf
dir /var/lib/redis
dbfilename dump.rdb
appendonly yes
appendfilename "appendonly.aof"

# Linux permissions
sudo chown -R redis:redis /var/lib/redis /var/log/redis
sudo chmod 700 /var/lib/redis

Check persistence health via INFO and ensure background saves succeed. Store offsite backups and test restore regularly.

6) OS-Level Hardening

• Patch regularly: keep Redis and OpenSSL up to date.
• Limit shell access; disable password SSH; use SSH keys and sudo for admins.
• Use fail2ban for SSH; restrict sudoers; enable auditd for change tracking.
• Keep swap minimal; monitor memory to avoid swapping delays.
• Pin CPU and set transparent hugepages off if latency sensitive.

Backup, Replication, and High Availability

Backups protect you from corruption and accidental deletes; replication protects availability. Use both.

• Backups: Keep RDB snapshots and/or AOF; copy to offsite/cloud storage with encryption.
• Replication: Configure read replicas; monitor replication lag and link status.
• Failover: Use Redis Sentinel or a managed orchestrator for automatic failover.

# On replica
replicaof 10.0.1.10 6379
masterauth p@ssw0rd-ChangeMe

Test restores quarterly. A backup you haven’t restored is a backup you don’t have.

Common Monitoring and Security Mistakes

• Exposing port 6379 to the public internet.
• Running without authentication or TLS in multi-host deployments.
• Ignoring memory metrics until evictions or OOM kill occur.
• Leaving dangerous commands enabled for app users.
• No alerting on replication failure or persistence errors.
• Backups enabled but never tested.

Container and Kubernetes Notes

• Use Kubernetes NetworkPolicies to restrict access.
• Mount redis.conf via ConfigMap and ACL/TLS secrets via Secret volumes.
• Sidecar the redis_exporter for Prometheus scraping.
• Persist data with StatefulSets and reliable storage classes.

Ongoing Maintenance and Incident Response

• Monthly: review INFO trends, slowlog, and adjust memory limits and eviction policies.
• Quarterly: test backup restore and failover; rotate credentials and TLS certs.
• After incidents: rotate ACL passwords, invalidate exposed keys, review logs, and patch.

If you lack in-house bandwidth, a managed provider helps. At YouStable, our managed servers include Redis hardening, 24×7 monitoring, firewalling, backups, and Prometheus/Grafana dashboards—so you can focus on your app while we keep Redis fast and secure.

Step-by-Step: Putting It All Together

• Update Redis to the latest stable release.
• Bind to localhost or private IP; enable protected-mode.
• Lock down firewall: allow only trusted app hosts.
• Create ACL users for app and admin; disable default user.
• Enable TLS and rotate strong certificates.
• Harden redis.conf: logging, slowlog, disable dangerous commands (or -@dangerous via ACL).
• Enable persistence; verify RDB/AOF health; script encrypted offsite backups.
• Install redis_exporter; wire Prometheus and Grafana dashboards.
• Add alert rules for memory, evictions, latency, replication, and persistence failures.
• Document, test, and review quarterly.

FAQ’s