如何利用Redis的监控钩子（Hook）实现自定义告警？-Redis-PHP中文网

redis无内置hook机制，唯一原生事件源是keyspace notifications，需通过config set notify-keyspace-events ex启用，并订阅__keyevent@0__:expired等pub/sub频道实现键过期等轻量告警。

如何利用redis的监控钩子（hook）实现自定义告警？

Redis 本身没有内置的“监控钩子（Hook）”机制，redis-server 不提供类似数据库触发器或事件回调的接口。所谓“Hook”，在 Redis 生态中通常指通过外部手段捕获和响应 Redis 运行时行为——最常用、最可靠的方式是监听 MONITOR 命令输出或订阅 __keyspace@<db>__</db> / __keyevent@<db>__</db> 通道。直接依赖 Redis 自身的 Hook 是行不通的。

为什么不能用 Redis 内置 Hook？

Redis 没有暴露可注册回调函数的 API，也没有配置项支持加载自定义插件（v7.0+ 的 modules 是二进制扩展，不是通用 Hook）。社区里提到的 “hook” 多数是误传，或指第三方代理（如 RedisInsight、telegraf）、中间件（如 redis-cell）、或用户自己写的监听程序——本质都是“旁路采集”，而非服务端主动调用。

MONITOR 是调试命令，会显著拖慢性能（每条命令都广播），仅适合临时排查，不可用于生产告警
CONFIG SET notify-keyspace-events 才是真正可用的事件源，但只支持 key 级变更（del、set、expire 等），不包含命令执行、内存增长、慢查询等
想捕获 INFO 中的指标（如 used_memory_peak_human）必须轮询，不能靠事件驱动

如何用 Keyspace Notifications 实现基础告警？

启用 keyspace events 后，Redis 会在 key 发生指定类型操作时，向 Pub/Sub 频道推送消息。这是唯一轻量、原生支持的“事件钩子”。

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

启动前在 redis.conf 加入：notify-keyspace-events Ex（E 表示键事件，x 表示过期事件）；或运行时执行：CONFIG SET notify-keyspace-events Ex
客户端订阅频道：PSUBSCRIBE __keyevent@0__:expired（监听 db 0 的过期事件）
收到消息后，立刻查 TTL 或 GET 判断是否真失效，避免因重复推送误告
注意：EXPIRE 命令本身不会触发 expired 事件，只有实际过期时刻才发；且 AOF 重放期间不发事件

127.0.0.1:6379> PSUBSCRIBE __keyevent@0__:expired
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "__keyevent@0__:expired"
3) (integer) 1
1) "pmessage"
2) "__keyevent@0__:expired"
3) "__keyevent@0__:expired"
4) "session:abc123"

怎么补足 Keyspace Notifications 的短板？

Keyspace Notifications 覆盖面窄，无法响应慢查询、内存飙升、连接数暴增等关键风险。必须组合其他采集方式：

定期执行 INFO 并解析：重点关注 used_memory、connected_clients、instantaneous_ops_per_sec、rejected_connections
开启慢日志：CONFIG SET slowlog-log-slower-than 10000（单位微秒），再用 SLOWLOG GET 10 拉取最近 10 条，识别 KEYS、HGETALL 等危险命令
用 CLIENT LIST 分析连接来源，对 IP+port 频繁新建连接的客户端打标告警
所有采集应走 Unix domain socket 或本地 TCP，避免网络延迟干扰判断时效性

告警逻辑里最容易被忽略的点

告警不是“一触即发”，而是需要上下文过滤和抑制。很多团队踩坑在于：把单次 expired 当成故障，结果发现只是缓存正常淘汰。

对同一 key 的连续过期事件做时间窗口去重（比如 5 秒内只报一次）
内存告警必须结合 mem_allocator 和 maxmemory_policy 判断：如果策略是 noeviction 且内存持续涨，才是真危险
慢查询告警需排除 DEBUG、MONITOR 等运维命令，避免自身监控反成噪音源
所有告警必须带 Redis 实例标识（role、master_host、run_id），否则集群环境下无法定位问题节点