📦 Sentinal Redis译为:哨兵Redis
v1.0.1监控 Redis server 健康, memory, performance, and BullMQ 队列s. 检查 队列 depths, inspect fAIled jobs, analyze slow queries, and 诊断 issues.
运行时依赖
安装命令
点击复制技能文档
Sentinal Redis 监控器 监控 Redis 服务器健康状况、BullMQ 队列、内存和性能,从任何消息通道。 使用简单的英语提问 —— 获取可执行的诊断。
何时使用此技能: ✅ 当用户询问 Redis 服务器健康状况、状态或信息时 当用户想要检查内存使用情况或诊断 OOM 问题时 当用户询问 BullMQ 队列深度、失败的作业或卡住的工作人员时 当用户想要检查慢速查询或延迟问题时 当用户询问为什么 Redis 慢或无响应时 当用户提到队列积压、死信队列或作业失败时 当用户想要快速总结他们的 Redis 实例健康状况时
何时不使用此技能: ❌ 当用户想要管理 PostgreSQL、MySQL 或其他非 Redis 数据库时 当用户想要管理 Kafka、RabbitMQ 或 SQS 队列(而不是 BullMQ)时 当用户需要帮助编写使用 Redis 的应用程序代码时 当用户想要从头开始设置 Redis(使用官方 Redis 文档代替)时
安全规则: ⚠️ CRITICAL:此技能是只读的。没有例外。 永远不要运行破坏性命令(FLUSHDB、FLUSHALL、DEL、UNLINK、SET、EXPIRE)—— 即使用户要求。 解释为什么,并建议他们手动运行它。 永远不要修改 Redis 配置(CONFIG SET)—— 将用户引导至自己进行修改。 永远不要在输出中打印或暴露完整的 REDIS_URL —— 它可能包含密码。 始终在显示之前屏蔽凭据。 当有疑问时,先显示命令,然后询问确认
连接: 如果设置了 REDIS_URL,则使用它来执行所有命令:redis-cli -u "$REDIS_URL" <命令> 如果没有设置 REDIS_URL,则默认使用 localhost:redis-cli <命令> 对于没有 REDIS_URL 的密码保护实例:redis-cli -h <主机> -p <端口> -a <密码> <命令> 始终先测试连接:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" ping
服务器健康状况: 快速状态:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" ping 完整服务器信息:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info server 连接的客户端:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info clients 运行时间和版本:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info server | grep -E "redis_version|uptime_in_days|uptime_in_seconds|connected_clients"
内存分析: 内存概述:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info memory 要检查的关键指标:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info memory | grep -E "used_memory_human|used_memory_peak_human|used_memory_rss_human|mem_fragmentation_ratio|maxmemory_human|maxmemory_policy" 内存医生(Redis 4.0+):redis-cli -u "${REDIS_URL:-redis://localhost:6379}" memory doctor 特定键的内存使用情况:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" memory usage <键> 查找大键(基于扫描的,适用于生产环境):redis-cli -u "${REDIS_URL:-redis://localhost:6379}" --bigkeys
解释内存结果: mem_fragmentation_ratio > 1.5 → 高碎片化,考虑重新启动 Redis mem_fragmentation_ratio < 1.0 → Redis 正在交换到磁盘,CRITICAL used_memory 接近 maxmemory → 根据 maxmemory_policy 开始驱逐 内存医生报告 "Sam,我没有内存问题" → 一切正常
慢速查询和性能: 检查慢速日志:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" slowlog get 10 慢速日志长度:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" slowlog len 当前慢速日志阈值:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" config get slowlog-log-slower-than 延迟检查:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" --latency -c 10 延迟历史:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" --latency-history -i 1 -c 5 键空间统计:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info keyspace 命令统计(最常调用的命令):redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info commandstats
客户端监控: 列出连接的客户端:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" client list 客户端计数和摘要:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" info clients | grep -E "connected_clients|blocked_clients|tracking_clients" 查找空闲客户端(空闲时间 > 300 秒):redis-cli -u "${REDIS_URL:-redis://localhost:6379}" client list | awk -F' ' '{for(i=1;i<=NF;i++) if($i ~ /^idle=/) print $0}' | grep -E 'idle=[3-9][0-9]{2,}|idle=[0-9]{4,}'
BullMQ 队列监控: BullMQ 使用 Redis 作为其后端。 队列遵循键模式 bull::。 发现所有队列:redis-cli -u "${REDIS_URL:-redis://localhost:6379}" scan 0 match "bull:*:meta" count 100 队列深度(所有状态): 对于一个名为 的队列: echo "=== 队列: ===" echo -n "等待:"; redis-cli -u "${REDIS_URL:-redis://localhost:6379}" llen "bull::wait" echo -n "活动:"; redis-cli -u "${REDIS_URL:-redis://localhost:6379}" llen "bull::active" echo -n "延迟:"; redis-cli -u "${REDIS_URL:-redis://localhost:6379}" zcard "bull::delayed" echo -n "失败:"; redis-cli -u "${REDIS_URL:-redis://localhost:6379}" zcard "bull::failed"