tutorial

Monitoring Redict with Vigilmon

Redict is the BSD-licensed, community-governed Redis fork that keeps the RESP protocol and drops the SSPL. Here's how to monitor memory, hit rate, replication, persistence, and latency with Vigilmon.

Redict is an open-source fork of Redis 7.2, created after Redis Ltd relicensed Redis under the dual SSPL/RSALv2 license in 2024. Redict restores the original BSD-3 license and is community-governed via a Codeberg-hosted project. It is a drop-in replacement at the protocol level — it speaks the Redis Serialization Protocol (RESP) on port 6379, so every existing Redis client (redis-py, Jedis, StackExchange.Redis, go-redis) connects without modification. As a Redis-compatible in-memory store, Redict supports strings, hashes, lists, sets, sorted sets, streams, Pub/Sub, Lua scripting, and optional persistence via RDB snapshots and AOF. Monitoring Redict is essentially identical to Redis monitoring, using the same INFO command interface. Vigilmon gives you TCP and HTTP uptime checks, while cron heartbeats cover persistence and slow-log health.

What You'll Set Up

  • TCP liveness check on port 6379
  • Memory usage alert before eviction storms begin
  • Connected client count monitoring for reconnect failures and leaks
  • Keyspace hit rate alerting for cache effectiveness
  • Replication health check for replica deployments
  • Persistence health via heartbeat for RDB/AOF failures
  • Rejected connection and command latency alerting

Prerequisites

  • Redict running on a server accessible over TCP (default port 6379)
  • redis-cli (or compatible client) available for scripted checks
  • Optional: replica configured for high-availability deployments
  • A free Vigilmon account

Step 1: TCP Liveness Check

Redict serves all traffic on port 6379. A TCP failure means every cache read, session lookup, and queue pop dependent on Redict is failing. Add a TCP monitor first:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to TCP.
  3. Enter your-redict-host:6379.
  4. Set Check interval to 30 seconds.
  5. Set Alert threshold to 2 consecutive failures.
  6. Click Save.

For stricter uptime, add a Vigilmon HTTP monitor against a thin health sidecar that issues a PING command and checks for PONG:

#!/bin/bash
# /usr/local/bin/redict-health-server.sh
# Runs a minimal HTTP health endpoint using socat + redis-cli
while true; do
  PONG=$(redis-cli -h 127.0.0.1 -p 6379 PING 2>/dev/null)
  if [ "$PONG" = "PONG" ]; then
    echo -e "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\n\r\n{\"status\":\"ok\"}" | \
      socat - TCP-LISTEN:9379,reuseaddr,fork
  fi
done

Or use a simple Python sidecar:

#!/usr/bin/env python3
import redis
from http.server import BaseHTTPRequestHandler, HTTPServer

r = redis.Redis(host="127.0.0.1", port=6379, socket_timeout=2)

class HealthHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        try:
            r.ping()
            self.send_response(200)
            self.end_headers()
            self.wfile.write(b'{"status":"ok"}')
        except Exception:
            self.send_response(503)
            self.end_headers()
            self.wfile.write(b'{"status":"down"}')
    def log_message(self, *args):
        pass

HTTPServer(("0.0.0.0", 9379), HealthHandler).serve_forever()

Run this sidecar and add an HTTP monitor in Vigilmon for http://your-redict-host:9379/.

Step 2: Memory Usage Alert

Redict operates primarily in memory. When used_memory approaches maxmemory, Redict begins evicting keys (if an eviction policy is set) or rejecting writes (if maxmemory-policy noeviction). Alert before that threshold:

#!/bin/bash
# /usr/local/bin/redict-memory-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_MEMORY_HEARTBEAT_ID"
THRESHOLD=85  # alert at 85% maxmemory

INFO=$(redis-cli -h 127.0.0.1 INFO memory)
USED=$(echo "$INFO" | grep "^used_memory:" | awk -F: '{print $2}' | tr -d '[:space:]')
MAX=$(echo "$INFO" | grep "^maxmemory:" | awk -F: '{print $2}' | tr -d '[:space:]')

if [ "$MAX" -eq 0 ]; then
  # No maxmemory set — always ping (unbounded memory is a risk, but not an alert)
  curl -s "$HEARTBEAT_URL" > /dev/null
  exit 0
fi

PERCENT=$(( USED * 100 / MAX ))
if [ "$PERCENT" -lt "$THRESHOLD" ]; then
  curl -s "$HEARTBEAT_URL" > /dev/null
fi
# If over threshold, heartbeat is NOT pinged → Vigilmon alerts

Add a cron heartbeat in Vigilmon with a 5-minute interval, then schedule:

*/5 * * * * /usr/local/bin/redict-memory-check.sh

An 85% threshold gives you time to flush expired keys, scale up, or reduce the dataset before evictions cascade.

Step 3: Connected Clients and Rejected Connections

A sudden drop in connected_clients means applications are failing to reconnect after a restart or network blip. A spike may indicate a client connection leak. rejected_connections going above 0 means Redict is actively refusing clients because maxclients is reached:

#!/bin/bash
# /usr/local/bin/redict-clients-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_CLIENTS_HEARTBEAT_ID"
MAX_REJECTED=0  # any rejected connection is a problem

REJECTED=$(redis-cli -h 127.0.0.1 INFO stats | grep "^rejected_connections:" | awk -F: '{print $2}' | tr -d '[:space:]')

if [ "$REJECTED" -le "$MAX_REJECTED" ]; then
  curl -s "$HEARTBEAT_URL" > /dev/null
fi

Schedule every 2 minutes:

*/2 * * * * /usr/local/bin/redict-clients-check.sh

For connected client count, monitor the value via your existing metrics pipeline (Prometheus redis_exporter works with Redict since the INFO interface is identical) and alert on drops >20% from baseline.

Step 4: Keyspace Hit Rate

The keyspace hit rate is the ratio of cache hits to total lookups. For a caching layer, a sustained hit rate below 80% means your application is generating significant load on the backing database:

#!/bin/bash
# /usr/local/bin/redict-hitrate-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_HITRATE_HEARTBEAT_ID"
MIN_HITRATE=80  # alert if hit rate drops below 80%

INFO=$(redis-cli -h 127.0.0.1 INFO stats)
HITS=$(echo "$INFO" | grep "^keyspace_hits:" | awk -F: '{print $2}' | tr -d '[:space:]')
MISSES=$(echo "$INFO" | grep "^keyspace_misses:" | awk -F: '{print $2}' | tr -d '[:space:]')
TOTAL=$(( HITS + MISSES ))

if [ "$TOTAL" -gt 0 ]; then
  RATE=$(( HITS * 100 / TOTAL ))
  if [ "$RATE" -ge "$MIN_HITRATE" ]; then
    curl -s "$HEARTBEAT_URL" > /dev/null
  fi
else
  # No traffic yet — ping to avoid false alert on fresh start
  curl -s "$HEARTBEAT_URL" > /dev/null
fi

Note: Redict's INFO stats counters are cumulative since startup. For a rate-based check, either use Prometheus with a rate() function, or delta the values between two readings in the script.

Step 5: Replication Health

If you run Redict in primary/replica mode for high availability, monitor the replication link. A broken replication link means your replica is serving stale data:

#!/bin/bash
# /usr/local/bin/redict-replication-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_REPL_HEARTBEAT_ID"
MAX_LAG_BYTES=5242880  # 5 MB replication lag threshold

INFO=$(redis-cli -h 127.0.0.1 INFO replication)
ROLE=$(echo "$INFO" | grep "^role:" | awk -F: '{print $2}' | tr -d '[:space:]')

if [ "$ROLE" = "master" ]; then
  # Check replica link status
  LINK_STATUS=$(echo "$INFO" | grep "^master_link_status:" | awk -F: '{print $2}' | tr -d '[:space:]')
  # For a primary, check that all connected replicas report "up"
  REPLICA_COUNT=$(echo "$INFO" | grep "^connected_slaves:" | awk -F: '{print $2}' | tr -d '[:space:]')

  if [ "$LINK_STATUS" != "down" ] && [ "$REPLICA_COUNT" -gt 0 ]; then
    curl -s "$HEARTBEAT_URL" > /dev/null
  fi
elif [ "$ROLE" = "slave" ]; then
  LINK=$(echo "$INFO" | grep "^master_link_status:" | awk -F: '{print $2}' | tr -d '[:space:]')
  LAG=$(echo "$INFO" | grep "^master_repl_offset:" | awk -F: '{print $2}' | tr -d '[:space:]')

  if [ "$LINK" = "up" ]; then
    curl -s "$HEARTBEAT_URL" > /dev/null
  fi
fi

Schedule every minute. A missed heartbeat means the replication link is down or the replica is falling behind.

Step 6: Persistence Health (RDB / AOF)

If you rely on Redict for durable storage (sessions, job queues), persistence failures are silent by default. Monitor them with a cron heartbeat:

#!/bin/bash
# /usr/local/bin/redict-persistence-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_PERSIST_HEARTBEAT_ID"

INFO=$(redis-cli -h 127.0.0.1 INFO persistence)
RDB_STATUS=$(echo "$INFO" | grep "^rdb_last_bgsave_status:" | awk -F: '{print $2}' | tr -d '[:space:]')
AOF_ENABLED=$(echo "$INFO" | grep "^aof_enabled:" | awk -F: '{print $2}' | tr -d '[:space:]')
AOF_REWRITE_STATUS=$(echo "$INFO" | grep "^aof_last_rewrite_status:" | awk -F: '{print $2}' | tr -d '[:space:]')

RDB_OK=true
AOF_OK=true

[ "$RDB_STATUS" != "ok" ] && RDB_OK=false
[ "$AOF_ENABLED" = "1" ] && [ "$AOF_REWRITE_STATUS" != "ok" ] && AOF_OK=false

if $RDB_OK && $AOF_OK; then
  curl -s "$HEARTBEAT_URL" > /dev/null
fi

Schedule every 10 minutes. Configure this heartbeat in Vigilmon with a 15-minute interval to allow for a single missed check before alerting.

Step 7: Slow Log Alert

Redict's SLOWLOG GET returns commands that exceeded slowlog-log-slower-than microseconds. New slow log entries indicate blocking operations that degrade the entire instance (since Redict is single-threaded for command execution):

#!/bin/bash
# /usr/local/bin/redict-slowlog-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_SLOWLOG_HEARTBEAT_ID"
SLOWLOG_COUNT_FILE="/tmp/redict_slowlog_count"

CURRENT=$(redis-cli -h 127.0.0.1 SLOWLOG LEN)
PREVIOUS=$(cat "$SLOWLOG_COUNT_FILE" 2>/dev/null || echo "0")

echo "$CURRENT" > "$SLOWLOG_COUNT_FILE"

if [ "$CURRENT" -le "$PREVIOUS" ] || [ "$CURRENT" -eq 0 ]; then
  # No new slow log entries
  curl -s "$HEARTBEAT_URL" > /dev/null
fi
# If new entries appeared, heartbeat is skipped → Vigilmon alerts

Step 8: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and connect Slack, email, or a webhook.
  2. For the TCP monitor: 2 consecutive failures before alerting (Redict restarts are fast but take a few seconds).
  3. For memory, replication, and persistence heartbeats: 1 missed ping — these are already rate-limited by the cron interval.
  4. For the hit rate heartbeat: 2 missed pings to avoid noise from brief traffic spikes resetting cumulative counters.

Summary

| Monitor | Type | Interval | Alert Threshold | |---|---|---|---| | TCP port 6379 | TCP | 30s | 2 failures | | PING health sidecar | HTTP | 1m | 2 failures | | Memory usage | Cron heartbeat | 5m | 1 missed ping | | Rejected connections | Cron heartbeat | 2m | 1 missed ping | | Keyspace hit rate | Cron heartbeat | 5m | 2 missed pings | | Replication health | Cron heartbeat | 1m | 1 missed ping | | Persistence (RDB/AOF) | Cron heartbeat | 10m | 1 missed ping | | Slow log | Cron heartbeat | 5m | 1 missed ping |

Redict's full compatibility with the Redis INFO protocol means you can adopt it without changing your monitoring scripts — only the binary changes, not the interface. Vigilmon covers both TCP-level availability and the operational health checks that matter most for a caching tier: memory headroom, replication lag, and persistence integrity.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles