监控 Redis 消息队列长度直接用 LLEN 命令即可，但消费延迟没有内置单一指标，需要结合队列长度趋势、服务器延迟命令以及业务层时间戳计算来综合判断。

命令速用版

以下命令可在 redis-cli 中直接执行，用于快速查看基础状态：

1. 查看队列长度
LLEN your_queue_key

2. 查看服务器瞬时延迟（注意：部分云托管 Redis 可能禁用此命令）
LATENCY LATEST

3. 查看慢查询日志
SLOWLOG GET 10

4. 查看每秒处理命令数
INFO stats | grep instantaneous_ops_per_sec

5. 启动 Redis Exporter（修正后的 Docker 命令）
docker run -d `--name` redis_exporter -p 9121:9121 oliver006/redis_exporter `--redis`.addr redis://<host>:<port>

为什么会这样

Redis 本身是键值存储，队列通常是基于 List 或 Stream 结构模拟实现的。Redis 原生提供了内存、吞吐量、运行时信息和延时的监控能力，但“消费延迟”属于业务逻辑层面的指标，Redis 服务端无法直接感知消息被消费者处理花了多久。

公开资料中没有看到可靠的量化数据表明单一命令能完全替代业务监控。因此，我们需要分两层看：一是 Redis 服务端是否响应慢（影响消费速度），二是消息在队列里停留了多久（业务延迟）。

分步处理

1. 监控队列长度

使用 LLEN 命令获取列表长度。如果是生产环境，不要人工轮询，应通过 exporter 暴露指标。

2. 监控服务端延迟

Redis 2.8.13 引入了 Latency Monitoring 功能。可以通过 LATENCY 命令排查服务端是否有阻塞事件。同时配置慢查询日志，记录执行时间超过阈值的命令。

配置示例：
slowlog-log-slower-than 10000
slowlog-max-len 128

3. 监控业务消费延迟（代码实战）

在消息生产者写入队列时，将当前时间戳写入消息体或关联 key。消费者取出消息后，计算当前时间与消息时间戳的差值。这个差值才是真正的“消费延迟”。

Python 示例：

import redis, json, time

r = redis.Redis(host='localhost', port=6379)

# 生产者：写入带时间戳的消息
msg = {'data': 'test', 'ts': time.time()}
r.lpush('queue', json.dumps(msg))

# 消费者：计算延迟
msg = json.loads(r.brpop('queue')[1])
delay = time.time() - msg['ts']
print(f"Consumption delay: {delay}s")

4. 搭建可视化监控（Prometheus 配置）

使用 Prometheus 配合 Redis Exporter 抓取指标，并在 Grafana 中展示。Redis Exporter 可以导出队列长度、连接数、内存等指标。

prometheus.yml 配置示例：

scrape_configs:
  - job_name: 'redis_exporter'
    static_configs:
      - targets: ['localhost:9121']

Grafana 面板建议导入 Redis Exporter 官方模板（Dashboard ID: 763），重点关注 redis_key_size 指标。

5. 告警规则示例

在 Prometheus Alertmanager 中配置队列堆积告警：

- alert: RedisQueueBacklog
  expr: redis_key_size{key="your_queue_key"} > 1000
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Redis queue backlog detected"

怎么验证是否生效

1. 长度验证：手动 LLEN 命令结果应与 Grafana 面板显示的队列长度趋势一致。

2. 延迟验证：在 Grafana 中观察 latency 相关面板，当系统负载高时，LATENCY LATEST 应能捕捉到峰值（若命令可用）。

3. 业务验证：打印消费者计算出的延迟日志，确认数值在合理范围内，无异常堆积。

常见坑

1. 慎用 MONITOR 命令：MONITOR 会实时打印所有请求，对性能有一定影响，生产环境谨慎使用，仅适合调试。高负载下可能导致性能雪崩。

2. 发布订阅不是队列：Redis 的发布订阅模式是广播模式，消息不持久，消费者下线会丢失消息，不适合可靠队列场景。

3. 过期监听不稳定：监听 Key 过期事件实现延迟队列存在不稳定情况，坑较多，建议使用 Redisson 等成熟客户端库实现的延迟队列功能。

4. 碎片率关注：监控内存时注意 mem_fragmentation_ratio，过高可能影响性能。

5. 云厂商限制：部分云托管 Redis 实例可能禁用 LATENCY 等高危命令，需依赖 exporter 指标或控制台监控。

参考来源

• Redis Official Documentation: https://redis.io/documentation
• Redis Exporter GitHub: https://github.com/oliver006/redis_exporter
• Prometheus Official Documentation: https://prometheus.io/docs