{"skill":{"slug":"redis-cluster-analyzer","displayName":"Redis Cluster Analyzer","summary":"Analyze Redis Sentinel and Cluster configurations for high availability, performance, and memory efficiency. Checks sentinel topology, cluster slot distribut...","description":"---\nname: cm-redis-cluster-analyzer\ndescription: Analyze Redis Sentinel and Cluster configurations for high availability, performance, and memory efficiency. Checks sentinel topology, cluster slot distribution, memory policies, persistence settings, connection pooling, replication lag, and key patterns. Use when asked to review Redis config, audit Redis cluster, check sentinel setup, optimize Redis memory, review Redis HA, troubleshoot Redis failover, or analyze Redis performance. Triggers on \"redis\", \"redis cluster\", \"redis sentinel\", \"redis ha\", \"redis memory\", \"redis config\", \"redis failover\", \"redis replication\", \"redis performance\", \"redis audit\".\nmetadata:\n  tags: [\"redis\", \"cache\", \"database\", \"sentinel\", \"cluster\", \"high-availability\", \"memory\", \"performance\", \"replication\", \"infrastructure\"]\n---\n\n# Redis Cluster Analyzer\n\nAnalyze Redis Sentinel and Cluster configurations for high availability, performance, and memory efficiency. Reviews sentinel topology, cluster slot distribution, replication health, memory policies, persistence settings, connection pooling, and key design patterns. Acts as a senior infrastructure engineer auditing your Redis deployment for production readiness.\n\n## Usage\n\nInvoke this skill when you need to review Redis configurations, validate HA setup, optimize memory usage, or troubleshoot failover issues.\n\n**Basic invocation:**\n> Analyze the Redis configuration files in /etc/redis/\n> Review this Redis Sentinel setup for high availability\n> Audit Redis Cluster configuration for production readiness\n\n**Focused analysis:**\n> Check memory policies and eviction strategy\n> Audit sentinel failover configuration\n> Review cluster slot distribution for hotspots\n> Analyze connection pooling settings\n\nThe agent reads Redis configuration files, sentinel configs, cluster node definitions, and application connection code, then produces a comprehensive quality report.\n\n## How It Works\n\n### Step 1: Discover and Parse Redis Configuration\n\nThe agent locates all Redis-related configuration:\n\n```bash\n# Find Redis configuration files\nfind /etc/redis/ -name \"*.conf\" -type f\nfind /path/to/project/ -name \"redis*.conf\" -o -name \"sentinel*.conf\"\n\n# Find application Redis connection code\ngrep -rl \"Redis\\|redis\\|ioredis\\|redis-py\\|RedisCluster\" /path/to/app/ --include=\"*.py\" --include=\"*.ts\" --include=\"*.js\" --include=\"*.go\"\n\n# Check running Redis processes\nredis-cli INFO server 2>/dev/null\nredis-cli CLUSTER INFO 2>/dev/null\nredis-cli SENTINEL masters 2>/dev/null\n```\n\nThe agent parses each configuration to extract:\n- **Server configuration** (bind, port, requirepass, maxclients)\n- **Memory settings** (maxmemory, maxmemory-policy, lazyfree)\n- **Persistence** (RDB snapshots, AOF, hybrid)\n- **Replication** (replica-of, repl-backlog-size, min-replicas)\n- **Sentinel topology** (masters, quorum, failover-timeout)\n- **Cluster settings** (cluster-enabled, node-timeout, migration-barrier)\n- **Connection pool config** (from application code)\n- **Key patterns** (TTL, naming conventions, data structures)\n\n### Step 2: Audit Sentinel Configuration\n\nFor Redis Sentinel deployments, the agent checks HA topology:\n\n```\nSentinel Topology Analysis:\n\n  Sentinels: 3 nodes\n    sentinel-1: 10.0.1.10:26379\n    sentinel-2: 10.0.1.11:26379\n    sentinel-3: 10.0.1.12:26379\n\n  Monitored Masters: 2\n    mymaster: 10.0.1.20:6379 (2 replicas)\n    cachemaster: 10.0.1.30:6379 (1 replica)\n\n  PASS: 3 sentinels — meets minimum for quorum (need N/2 + 1)\n  PASS: Sentinels on separate hosts — survives single-node failure\n\n  FAIL: Master \"cachemaster\" has only 1 replica\n    RISK: If replica fails, no failover target available\n    During maintenance on the single replica, master has zero redundancy\n    FIX: Add at least 1 more replica for cachemaster\n\n  FAIL: Sentinels co-located with Redis nodes\n    sentinel-1 (10.0.1.10) hosts both sentinel and Redis replica\n    RISK: Node failure takes out both sentinel and data node\n    FIX: Run sentinels on independent infrastructure\n```\n\n**Sentinel configuration audit:**\n\n```\nSentinel Config Analysis:\n\n  Master \"mymaster\":\n    sentinel monitor mymaster 10.0.1.20 6379 2\n    sentinel down-after-milliseconds mymaster 5000\n    sentinel failover-timeout mymaster 60000\n    sentinel parallel-syncs mymaster 1\n\n  FAIL: down-after-milliseconds = 5000 (5 seconds)\n    Too aggressive — network blips trigger unnecessary failovers\n    Each failover causes ~10s of write unavailability\n    FIX: sentinel down-after-milliseconds mymaster 30000 (30 seconds)\n    Balances detection speed vs. false positive failovers\n\n  WARN: failover-timeout = 60000 (60 seconds)\n    If failover fails, retry waits 120 seconds (2x timeout)\n    Total downtime in worst case: 3+ minutes\n    CONSIDER: failover-timeout 180000 (3 min) for complex resyncs\n    Prevents premature failover abort during large dataset sync\n\n  WARN: parallel-syncs = 1\n    Only 1 replica syncs from new master at a time after failover\n    With 3 replicas, full sync takes 3x single replica sync time\n    FIX: parallel-syncs = 2 (if replicas can handle sync load)\n    Tradeoff: Faster recovery vs. higher load on new master during sync\n\n  FAIL: No sentinel auth-pass configured\n    Sentinels connect to master without authentication\n    RISK: Unauthorized sentinel can trigger failover\n    FIX: sentinel auth-pass mymaster <password>\n\n  FAIL: No sentinel notification-script configured\n    No alerting on failover events\n    FIX: sentinel notification-script mymaster /opt/redis/notify.sh\n    Script receives: event-type, event-description\n    Hook into PagerDuty/Slack for operational awareness\n\n  FAIL: No sentinel client-reconfig-script configured\n    Application does not know about master change\n    FIX: sentinel client-reconfig-script mymaster /opt/redis/reconfig.sh\n    OR: Use Sentinel-aware client library (recommended):\n      redis-py: Redis.from_url(\"redis+sentinel://...\")\n      ioredis: new Redis({ sentinels: [...], name: \"mymaster\" })\n```\n\n### Step 3: Analyze Cluster Configuration\n\nFor Redis Cluster deployments, the agent checks slot distribution and node health:\n\n```\nCluster Topology Analysis:\n\n  Nodes: 6 (3 masters, 3 replicas)\n    master-1: 10.0.1.50:6379 — slots 0-5460 (5461 slots)\n    master-2: 10.0.1.51:6379 — slots 5461-10922 (5462 slots)\n    master-3: 10.0.1.52:6379 — slots 10923-16383 (5461 slots)\n    replica-1: 10.0.1.60:6379 — replicates master-1\n    replica-2: 10.0.1.61:6379 — replicates master-2\n    replica-3: 10.0.1.62:6379 — replicates master-3\n\n  PASS: Slots evenly distributed (5461/5462/5461)\n  PASS: Each master has at least 1 replica\n  PASS: Replicas on different hosts than their masters\n```\n\n**Cluster configuration audit:**\n\n```\nCluster Config Analysis:\n\n  FAIL: cluster-node-timeout = 15000 (15 seconds)\n    Too aggressive for cross-AZ deployments\n    Network latency spikes between AZs can trigger false failovers\n    FIX: cluster-node-timeout 30000 for cross-AZ\n    Keep 15000 for single-AZ deployments\n\n  FAIL: cluster-migration-barrier = 1 (default)\n    Master with only 1 replica won't donate replica to orphaned master\n    If a master loses all replicas, no automatic migration occurs\n    FIX: cluster-migration-barrier 0 — allow replica migration when needed\n    NOTE: Only effective if some masters have 2+ replicas\n\n  FAIL: cluster-require-full-coverage = yes (default)\n    If any slot range has no master, ENTIRE cluster stops accepting writes\n    RISK: Single master failure can take down whole cluster\n    FIX: cluster-require-full-coverage no\n    Allows cluster to serve keys in available slot ranges\n\n  WARN: cluster-allow-reads-when-down = no (default)\n    Cluster rejects all operations when marked as down\n    FIX: cluster-allow-reads-when-down yes\n    Allows read operations during partial failures (stale reads possible)\n\n  WARN: No cluster-announce-ip configured\n    In Docker/NAT environments, nodes advertise internal IPs\n    Clients outside the network cannot connect\n    FIX: Set cluster-announce-ip to external/routable IP\n\n  FAIL: All nodes in same availability zone\n    master-1, master-2, master-3 all in us-east-1a\n    RISK: AZ failure takes down entire cluster\n    FIX: Distribute across 3 AZs:\n      AZ-a: master-1, replica-2\n      AZ-b: master-2, replica-3\n      AZ-c: master-3, replica-1\n```\n\n**Key distribution analysis:**\n\n```\nSlot Hotspot Analysis:\n\n  WARN: Uneven key distribution detected\n    master-1 (slots 0-5460): 2.1M keys, 1.8 GB\n    master-2 (slots 5461-10922): 850K keys, 600 MB\n    master-3 (slots 10923-16383): 3.2M keys, 2.4 GB\n\n  FAIL: master-3 has 3.8x more keys than master-2\n    Likely cause: Hot key prefix hashes to slot range 10923-16383\n    Common pattern: All \"user:{id}\" keys hash similarly\n    FIX: Use hash tags to control distribution:\n      user:{12345} — hashes on \"12345\", distributed\n      {user}:12345 — hashes on \"user\", all same slot (BAD)\n    OR: Reshard slots to balance memory across masters\n\n  WARN: Large key detected\n    Key \"cache:product_catalog\" — 450 MB (hash with 100K fields)\n    RISK: Migration of this key's slot blocks cluster operations\n    FIX: Split into smaller keys using key prefixing:\n      cache:product_catalog:{category_id}\n```\n\n### Step 4: Review Memory Configuration\n\nThe agent audits memory settings:\n\n```\nMemory Configuration Analysis:\n\n  FAIL: maxmemory not set\n    Redis will use all available system memory\n    RISK: OOM killer terminates Redis process — data loss\n    FIX: maxmemory 4gb (set to ~75% of available RAM)\n    Reserve 25% for fork operations (RDB/AOF), OS, and buffer\n\n  FAIL: maxmemory-policy = noeviction (default)\n    When maxmemory reached, all write operations return OOM error\n    RISK: Application crashes when cache is full\n    FIX: Choose policy based on workload:\n      allkeys-lru — cache workload, evict least recently used\n      volatile-lru — mixed workload, only evict keys with TTL\n      allkeys-lfu — frequency-based, better hit rate than LRU\n      volatile-ttl — evict keys closest to expiry\n\n  WARN: maxmemory-samples = 5 (default)\n    LRU/LFU approximation uses 5 samples — may evict suboptimally\n    FIX: maxmemory-samples 10 — better eviction accuracy, minimal CPU cost\n\n  FAIL: lazyfree-lazy-eviction = no\n    Eviction blocks the main thread — large key eviction causes latency spike\n    FIX: lazyfree-lazy-eviction yes\n    AND: lazyfree-lazy-expire yes\n    AND: lazyfree-lazy-server-del yes\n    AND: lazyfree-lazy-user-del yes\n    Lazy-free delegates memory reclamation to background thread\n\n  Memory Efficiency:\n    Used memory: 3.2 GB\n    Peak memory: 3.8 GB\n    Fragmentation ratio: 1.42\n    WARN: Fragmentation ratio > 1.2 — 42% wasted memory\n    FIX: Set activedefrag yes (Redis 4.0+)\n      active-defrag-enabled yes\n      active-defrag-threshold-lower 10\n      active-defrag-threshold-upper 100\n      active-defrag-cycle-min 1\n      active-defrag-cycle-max 25\n```\n\n### Step 5: Audit Persistence Settings\n\nThe agent checks data durability configuration:\n\n```\nPersistence Analysis:\n\n  RDB Snapshots:\n    save 900 1      — snapshot if 1 change in 15 min\n    save 300 10     — snapshot if 10 changes in 5 min\n    save 60 10000   — snapshot if 10000 changes in 1 min\n\n  WARN: RDB snapshot frequency may be too aggressive\n    save 60 10000 causes fork every 60 seconds under write load\n    Fork on 4 GB dataset copies page tables — 100-500ms freeze\n    FIX: For cache-only workloads, disable RDB:\n      save \"\"\n    For durability, prefer AOF over frequent RDB\n\n  AOF Configuration:\n    appendonly no\n\n  FAIL: AOF disabled — data loss window = RDB interval\n    With save 300 10, up to 5 minutes of data lost on crash\n    FIX: appendonly yes\n    appendfsync everysec (good balance of performance and durability)\n    auto-aof-rewrite-percentage 100\n    auto-aof-rewrite-min-size 64mb\n\n  FAIL: No hybrid persistence (RDB + AOF)\n    Redis 4.0+ supports aof-use-rdb-preamble for faster restart\n    FIX: aof-use-rdb-preamble yes\n    AOF file starts with RDB snapshot, followed by append-only log\n    Combines fast restart (RDB) with minimal data loss (AOF)\n\n  WARN: stop-writes-on-bgsave-error = yes\n    If RDB snapshot fails, Redis stops accepting writes\n    Correct for primary data store, too strict for cache\n    FIX: For cache workloads: stop-writes-on-bgsave-error no\n\n  Replica Persistence:\n    FAIL: Replicas have RDB enabled (same schedule as master)\n    RISK: Fork storm — master and all replicas fork simultaneously\n    FIX: Disable RDB on replicas, rely on replication + master RDB:\n      replica: save \"\"\n    Exception: Enable on ONE replica for backup purposes\n```\n\n### Step 6: Review Connection and Client Settings\n\nThe agent checks connection configuration:\n\n```\nConnection Analysis:\n\n  FAIL: maxclients = 10000 (default)\n    System file descriptor limit: 1024 (ulimit -n)\n    Redis needs: maxclients + 32 (internal FDs) = 10032\n    But only 1024 FDs available — effective maxclients = 992\n    FIX: Increase system limit:\n      /etc/security/limits.conf: redis soft nofile 65535\n    OR: Reduce maxclients to match available FDs\n\n  FAIL: timeout = 0 (no idle timeout)\n    Idle connections never close — accumulate until maxclients reached\n    RISK: Connection leak exhausts available connections\n    FIX: timeout 300 (close idle connections after 5 minutes)\n\n  WARN: tcp-keepalive = 300 (default)\n    Dead connections detected after 5 minutes of silence\n    For latency-sensitive apps, reduce to detect failures faster\n    FIX: tcp-keepalive 60\n\n  FAIL: No requirepass configured\n    Redis accessible without authentication\n    RISK: Data exposure, unauthorized access, crypto mining attacks\n    FIX: requirepass <strong-password>\n    AND: For Redis 6+, use ACL system for fine-grained access:\n      user app on >password ~app:* +@read +@write -@admin\n\n  Application Connection Pool:\n    Python (redis-py):\n      pool = redis.ConnectionPool(max_connections=50)\n\n    WARN: max_connections = 50 per application instance\n      With 10 app instances = 500 connections to Redis\n      Plus Sentinel connections = ~515 total\n      Verify: 515 < maxclients (992 effective)\n      PASS: Within limits\n\n    FAIL: No connection timeout configured\n      ConnectionPool(max_connections=50)\n      FIX: ConnectionPool(\n          max_connections=50,\n          socket_timeout=5,\n          socket_connect_timeout=2,\n          retry_on_timeout=True,\n          health_check_interval=30,\n      )\n\n    FAIL: No retry strategy for connection failures\n      Single connection failure raises exception to application\n      FIX: Use retry decorator or Retry class:\n        from redis.retry import Retry\n        from redis.backoff import ExponentialBackoff\n        retry = Retry(ExponentialBackoff(), 3)\n        Redis(retry=retry, retry_on_error=[ConnectionError, TimeoutError])\n```\n\n### Step 7: Analyze Key Design Patterns\n\nThe agent reviews key naming and TTL strategy:\n\n```\nKey Pattern Analysis:\n\n  FAIL: No consistent key naming convention\n    Found patterns: \"user:123\", \"USER_123\", \"cache-user-123\", \"u.123\"\n    FIX: Standardize on colon-delimited hierarchy:\n      {service}:{entity}:{id}:{field}\n      app:user:123:profile\n      app:session:abc-def\n      app:cache:products:category:5\n\n  FAIL: 45% of keys have no TTL set\n    Total keys: 2.1M, keys without TTL: 945K\n    RISK: Memory grows unbounded — keys never evicted (if policy=volatile-*)\n    FIX: Set TTL on all cache keys:\n      SET key value EX 3600  (1 hour)\n    For session data: match session expiry\n    For cache: match data freshness requirements\n\n  WARN: TTL distribution skewed\n    Keys with TTL < 60s: 12%\n    Keys with TTL 60s-1h: 8%\n    Keys with TTL 1h-24h: 15%\n    Keys with TTL > 24h: 20%\n    Keys with no TTL: 45%\n    RECOMMEND: Review keys with TTL > 24h — do they need to persist that long?\n\n  FAIL: Large keys detected (> 1 MB)\n    cache:all_products — 12 MB (JSON string)\n    RISK: Large key operations block event loop (single-threaded)\n    GET on 12 MB key takes ~6ms — blocks all other clients\n    FIX: Break into smaller keys or use Redis Hash with HSCAN\n    OR: Compress before storage: zlib.compress(json.dumps(data))\n\n  WARN: Hot key detected\n    cache:homepage_feed — 50K reads/sec from monitoring\n    RISK: Single master handles all reads for this key\n    FIX: Read from replicas for hot keys:\n      Redis(read_from_replicas=True) (cluster mode)\n    OR: Implement client-side caching (Redis 6+ client tracking)\n\n  FAIL: Key pattern \"lock:*\" without TTL safety\n    Distributed locks without TTL — if holder crashes, lock held forever\n    FIX: Always set TTL on lock keys:\n      SET lock:resource value NX EX 30\n    Use Redlock algorithm for distributed locking across nodes\n```\n\n### Step 8: Review Replication Health\n\nThe agent checks replication configuration:\n\n```\nReplication Analysis:\n\n  Master: 10.0.1.20:6379\n    Connected replicas: 2\n    Replication backlog: 1 MB (default)\n    Min replicas to write: 0\n\n  FAIL: repl-backlog-size = 1mb (default)\n    If replica disconnects for > backlog duration, full resync required\n    Full resync on 4 GB dataset: ~30 seconds of high CPU + network\n    FIX: repl-backlog-size 256mb\n    Size = write_rate_bytes_per_sec * max_acceptable_disconnect_seconds\n    At 1 MB/s writes: 256 MB covers 256 seconds of disconnect\n\n  FAIL: min-replicas-to-write = 0 (default)\n    Master accepts writes even if ALL replicas are down\n    RISK: Data only on master — if master fails, data lost\n    FIX: min-replicas-to-write 1\n    AND: min-replicas-max-lag 10\n    Master rejects writes if no replica acknowledged within 10 seconds\n\n  WARN: Replication lag detected\n    replica-1: lag = 0 bytes (healthy)\n    replica-2: lag = 45000 bytes (45 KB behind)\n    Possible causes: slow network, disk I/O on replica, large key writes\n    Monitor: redis-cli INFO replication | grep lag\n\n  WARN: replica-read-only = yes but no replica routing\n    Replicas accept read queries but application only connects to master\n    FIX: Route reads to replicas to reduce master load:\n      Python: Redis(host=master, port=6379).slave_for(\"mymaster\")\n      Node: new Redis({ role: \"slave\", preferredSlaves: [...] })\n\n  FAIL: replica-lazy-flush = no\n    Full resync flushes replica synchronously — blocks for seconds on large DB\n    FIX: replica-lazy-flush yes — flush in background thread\n```\n\n### Step 9: Security Audit\n\nThe agent evaluates security configuration:\n\n```\nSecurity Analysis:\n\n  FAIL: protected-mode = no\n    Redis accessible from any network interface\n    FIX: protected-mode yes (when bind is set)\n    OR: Ensure bind 127.0.0.1 or specific internal IPs\n\n  FAIL: bind 0.0.0.0\n    Listening on all interfaces including public\n    RISK: Internet-accessible Redis — common crypto mining target\n    FIX: bind 127.0.0.1 10.0.1.20 (localhost + internal network only)\n\n  FAIL: No TLS configured\n    Data in transit is unencrypted — visible to network sniffers\n    FIX: For Redis 6+:\n      tls-port 6380\n      tls-cert-file /etc/redis/tls/redis.crt\n      tls-key-file /etc/redis/tls/redis.key\n      tls-ca-cert-file /etc/redis/tls/ca.crt\n      port 0 (disable non-TLS port)\n\n  FAIL: Using single password (requirepass) instead of ACL\n    All clients share one password with full access\n    FIX: Use Redis ACL (6.0+) for least-privilege access:\n      user app-read on >readpass ~app:cache:* +@read -@all\n      user app-write on >writepass ~app:* +@read +@write -@admin\n      user admin on >adminpass ~* +@all\n\n  WARN: rename-command used for security\n    rename-command FLUSHALL \"\"\n    rename-command CONFIG \"\"\n    NOTE: rename-command is deprecated in Redis 7+\n    FIX: Use ACL to restrict dangerous commands instead:\n      user default on >pass -FLUSHALL -FLUSHDB -CONFIG -DEBUG\n```\n\n### Step 10: Produce the Analysis Report\n\nThe agent generates a comprehensive report:\n\n```\n# Redis Configuration Analysis Report\n# Deployment: Sentinel | Date: April 30, 2026\n\n## Overview\n  Deployment type: Sentinel (3 sentinels, 1 master, 2 replicas)\n  Redis version: 7.2\n  Total memory: 3.2 GB used / 4 GB max\n  Total keys: 2.1M\n  Connected clients: 127\n\n## Overall Health Score: 48/100\n\n## Category Scores\n  Sentinel/Cluster Config: 5/10  (aggressive timeouts, no alerting)\n  Memory Management:       4/10  (no eviction policy, fragmentation)\n  Persistence:             4/10  (AOF disabled, fork storm risk)\n  Connection Settings:     5/10  (no timeout, no auth, no TLS)\n  Replication:             5/10  (small backlog, no min-replicas)\n  Key Design:              4/10  (no TTL, large keys, hot keys)\n  Security:                3/10  (no TLS, no ACL, bound to 0.0.0.0)\n  Performance:             6/10  (lazy-free disabled, no defrag)\n\n## Critical Issues\n  1. No authentication — Redis accessible without password\n  2. Bound to 0.0.0.0 — exposed to public network\n  3. maxmemory-policy noeviction — writes fail when memory full\n  4. AOF disabled — up to 5 minutes of data loss on crash\n  5. Replication backlog 1 MB — full resync on brief disconnect\n\n## Recommendations Summary\n  Estimated effort: 2-3 days for critical + high priority fixes\n  Expected improvement: 48 -> 82 health score\n  Risk reduction: Eliminates security exposure and data loss scenarios\n```\n\n## Output\n\nThe agent produces:\n\n- **Health score**: 0-100 overall Redis configuration quality rating\n- **Category scores**: granular ratings for each quality dimension\n- **Topology diagram**: text-based visualization of Sentinel/Cluster layout\n- **Critical issues**: problems that pose availability or security risk\n- **Memory analysis**: usage, fragmentation, eviction, and key distribution\n- **Persistence review**: RDB/AOF configuration with durability assessment\n- **Replication health**: lag, backlog, and failover readiness\n- **Security audit**: authentication, encryption, and access control\n- **Remediation config**: exact redis.conf directives to fix each issue\n- **Priority matrix**: issues ranked by risk and effort\n\n## Deployment Type Support\n\n| Feature | Standalone | Sentinel | Cluster |\n|---------|-----------|----------|---------|\n| HA analysis | N/A | Full sentinel audit | Slot + node analysis |\n| Failover review | N/A | Quorum, timeouts | Node-timeout, migration |\n| Memory analysis | Single node | Master + replicas | Per-shard distribution |\n| Key distribution | N/A | N/A | Slot hotspot detection |\n| Scaling advice | Vertical only | Add replicas | Reshard + add nodes |\n\n## Tips for Best Results\n\n- Provide both redis.conf and sentinel.conf for complete analysis\n- Include application connection code for pool configuration review\n- Share Redis INFO output for runtime metrics correlation\n- For Cluster deployments, provide all node configurations\n- Run during peak traffic hours for realistic hotspot detection\n- Combine with slow log analysis (SLOWLOG GET) for performance correlation\n","tags":{"latest":"1.0.0"},"stats":{"comments":0,"downloads":397,"installsAllTime":15,"installsCurrent":0,"stars":0,"versions":1},"createdAt":1777635970453,"updatedAt":1778492821950},"latestVersion":{"version":"1.0.0","createdAt":1777635970453,"changelog":"Initial release — Analyze Redis Sentinel and Cluster configurations for high availability, performance, and memory efficiency.\n\n- Checks sentinel topology, cluster slot distribution, memory policies, persistence, connection pooling, replication lag, and key patterns.\n- Audits both application code and configuration files for comprehensive Redis infrastructure review.\n- Provides practical recommendations for improved production readiness in HA, failover, and performance scenarios.\n- Designed for use when reviewing or troubleshooting Redis, Sentinel, or Cluster deployments.","license":"MIT-0"},"metadata":null,"owner":{"handle":"charlie-morrison","userId":"s17cttbdxry5kkyafjw983mq8s83p4y3","displayName":"charlie-morrison","image":"https://avatars.githubusercontent.com/u/271589886?v=4"},"moderation":null}