Skip to content

redis: optional health probe that reflects whether Redis answers - #1300

Merged
psbrar99 merged 2 commits into
envoyproxy:mainfrom
nacx:pr/i-redis-health-probe
Nov 9, 2026
Merged

psbrar99 merged 2 commits into
envoyproxy:mainfrom
nacx:pr/i-redis-health-probe

Conversation

@nacx

@nacx nacx commented Nov 4, 2026

Copy link
Copy Markdown
Member

The health check does not touch Redis after startup. REDIS_HEALTH_CHECK_ACTIVE_CONNECTION only fails once every pooled connection has been closed, so while every connection is stuck on a Redis that stopped answering, pods stay healthy and keep receiving traffic.

Add REDIS_HEALTH_CHECK_PING_INTERVAL (off by default): each Redis client PINGs Redis at that interval through the same path as rate limit calls, bounded by the I/O timeout capped to the interval, and fails a new health component (redis_ping / redis_per_second_ping) after REDIS_HEALTH_CHECK_FAILURE_THRESHOLD (default 3) consecutive failures, recovering after one success. The components are separate from "redis" so they do not interfere with REDIS_HEALTH_CHECK_ACTIVE_CONNECTION. HealthChecker gets AddComponent to register them.

The README recommends using it for readiness only.

@nacx
nacx force-pushed the pr/i-redis-health-probe branch 2 times, most recently from 0d50672 to 3416648 Compare November 9, 2026 22:05
psbrar99
psbrar99 previously approved these changes Nov 9, 2026
nacx and others added 2 commits November 9, 2026 23:20
The health check does not touch Redis after startup.
REDIS_HEALTH_CHECK_ACTIVE_CONNECTION only fails once every pooled
connection has been closed, so while every connection is stuck on a
Redis that stopped answering, pods stay healthy and keep receiving
traffic.

Add REDIS_HEALTH_CHECK_PING_INTERVAL (off by default): each Redis
client PINGs Redis at that interval through the same path as rate limit
calls, bounded by the I/O timeout capped to the interval, and fails a
new health component (redis_ping / redis_per_second_ping) after
REDIS_HEALTH_CHECK_FAILURE_THRESHOLD (default 3) consecutive failures,
recovering after one success. The components are separate from "redis"
so they do not interfere with REDIS_HEALTH_CHECK_ACTIVE_CONNECTION.
HealthChecker gets AddComponent to register them.

The README recommends using it for readiness only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Ignasi Barrera <ignasi@tetrate.io>
The Redis health probe failed /healthcheck, which deployments commonly
use for liveness as well as readiness: Envoy Gateway points its startup,
readiness and liveness probes at /healthcheck, and lets users set the
rate limit container's environment. Enabling the probe there would
restart every replica during a Redis outage, which cannot fix Redis and,
through CrashLoopBackOff, delays recovery once Redis is back.

Register the probe's components as readiness components, which only
affect a new /ready endpoint. /ready is healthy when everything
/healthcheck covers is healthy and the Redis probes pass. /healthcheck
and the gRPC health service are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Ignasi Barrera <ignasi@tetrate.io>
@psbrar99
psbrar99 merged commit ee12fae into envoyproxy:main Nov 9, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants