7.1 Redis 监控指标

7.1 Redis 监控指标

7. Redis 监控与优化：7.1 Redis 监控指标详解

为什么监控 Redis 指标至关重要？

• 性能诊断与优化： 监控指标能够揭示 Redis 的性能瓶颈，例如慢查询、内存瓶颈、网络瓶颈等，从而有针对性地进行优化。

• 故障预警与快速响应： 通过监控关键指标，可以及时发现异常情况，例如连接数突增、内存使用率过高、主从同步延迟等，实现故障的提前预警和快速响应，降低业务风险。

• 容量规划与资源管理： 监控指标能够帮助评估 Redis 的资源使用情况，例如内存、CPU、网络带宽等，为容量规划和资源合理分配提供数据支持。

• 长期趋势分析与性能基线建立： 长期监控指标的变化趋势，可以帮助建立 Redis 性能基线，预测未来的资源需求，并及时发现性能退化。

7.1 Redis 监控指标详解

Redis 提供了丰富的监控指标，主要可以通过以下几种方式获取：

• INFO 命令： 最常用且全面的监控命令，返回 Redis 服务器的各种信息，包括服务器状态、客户端连接、内存使用、持久化、复制、统计信息等。

• redis-cli --stat 选项： 实时监控 Redis 服务器状态的命令行工具，以秒为单位刷新显示关键指标。

• SLOWLOG 命令： 用于记录执行时间超过阈值的慢查询命令，帮助分析性能瓶颈。

• CLIENT LIST 命令： 列出当前连接到 Redis 服务器的客户端信息，包括客户端地址、连接时长、命令执行情况等。

• MONITOR 命令 (谨慎使用)： 实时输出 Redis 服务器接收到的所有命令，用于调试和分析，但会显著影响性能，生产环境谨慎使用。

• 第三方监控工具： 例如 Prometheus + Grafana、RedisInsight、云服务商提供的监控套件等，提供更丰富的功能和可视化界面。

下面我们将分类详细介绍 Redis 的关键监控指标，并结合代码示例进行说明。

7.1.1 基础信息类指标

这类指标主要反映 Redis 服务器的基础状态信息。

• uptime_in_seconds (服务器运行时间): 表示 Redis 服务器已经运行了多少秒。

  • 重要性： 了解服务器运行时间，判断服务器是否重启过，用于排查一些与重启相关的故障。

  • 获取方式： redis-cli info server | grep uptime_in_seconds

  • 代码示例 (redis-cli):

    redis-cli info server | grep uptime_in_seconds
    # 输出示例：uptime_in_seconds:3600
    ​

  • 详解： 输出的数字表示 Redis 服务器已经运行的秒数。例如，uptime_in_seconds:3600 表示服务器已运行 1 小时。

• connected_clients (已连接客户端数量): 表示当前连接到 Redis 服务器的客户端数量。

  • 重要性： 监控客户端连接数，防止连接数过高导致服务器压力过大。

  • 获取方式： redis-cli info clients | grep connected_clients

  • 代码示例 (redis-cli):

    redis-cli info clients | grep connected_clients
    # 输出示例：connected_clients:10
    ​

  • 详解： 输出的数字表示当前连接到 Redis 服务器的客户端数量。连接数过高可能意味着客户端连接管理不当或遭受恶意连接攻击。

• used_memory_human (已使用内存): 以人类可读的方式显示 Redis 已使用的内存大小。

  • 重要性： 监控 Redis 内存使用情况，防止内存溢出 (OOM)。

  • 获取方式： redis-cli info memory | grep used_memory_human

  • 代码示例 (redis-cli):

    redis-cli info memory | grep used_memory_human
    # 输出示例：used_memory_human:1.23M
    ​

  • 详解： 输出以 M (兆字节)、G (吉字节) 等人类可读的单位显示 Redis 已使用的内存大小。需要密切关注 used_memory_human 的增长趋势，并设置合理的内存使用率阈值。

• role (服务器角色): 显示 Redis 服务器的角色，例如 master (主节点)、slave (从节点) 或 sentinel (哨兵)。

  • 重要性： 在 Redis 集群或主从复制架构中，了解服务器角色至关重要，用于判断节点状态和拓扑结构。

  • 获取方式： redis-cli info replication | grep role 或 redis-cli role (Redis 5.0+ 版本)

  • 代码示例 (redis-cli):

    redis-cli info replication | grep role
    # 输出示例：role:master
    redis-cli role  # Redis 5.0+
    # 输出示例：master
    #           127.0.0.1
    #           6379
    #           1
    ​

  • 详解： role 指标显示服务器的角色。在主从复制架构中，需要确保主节点为 master，从节点为 slave。在 Redis 集群中，角色会更加复杂，需要结合集群状态信息进行判断。

7.1.2 性能指标类指标

这类指标直接反映 Redis 服务器的性能表现。

• instantaneous_ops_per_sec (瞬时每秒操作数): 表示 Redis 服务器当前每秒处理的命令数量。

  • 重要性： 衡量 Redis 的吞吐能力，反映服务器的繁忙程度。

  • 获取方式： redis-cli info stats | grep instantaneous_ops_per_sec

  • 代码示例 (redis-cli):

    redis-cli info stats | grep instantaneous_ops_per_sec
    # 输出示例：instantaneous_ops_per_sec:1234
    ​

  • 详解： 输出的数字表示 Redis 当前每秒处理的命令数量。 instantaneous_ops_per_sec 会随着负载波动，需要结合历史数据进行分析，判断是否存在性能瓶颈。

• total_commands_processed (处理的总命令数): 表示 Redis 服务器启动以来处理的总命令数量。

  • 重要性： 统计 Redis 的工作负载，长期趋势分析。

  • 获取方式： redis-cli info stats | grep total_commands_processed

  • 代码示例 (redis-cli):

    redis-cli info stats | grep total_commands_processed
    # 输出示例：total_commands_processed:123456789
    ​

  • 详解： 输出的数字表示 Redis 服务器启动以来处理的总命令数量。可以用于计算平均每秒处理的命令数 (TPS)。

• keyspace_hits (键命中次数): 表示在 Redis 中成功找到键的次数。

• keyspace_misses (键未命中次数): 表示在 Redis 中未能找到键的次数。

  • 重要性： 衡量缓存命中率，高命中率是 Redis 作为缓存的关键指标。

  • 获取方式： redis-cli info stats | grep keyspace_

  • 代码示例 (redis-cli):

    redis-cli info stats | grep keyspace_
    # 输出示例：keyspace_hits:10000
    #           keyspace_misses:1000
    ​

  • 详解： keyspace_hits 和 keyspace_misses 反映了缓存的命中和未命中情况。缓存命中率计算公式为： keyspace_hits / (keyspace_hits + keyspace_misses)。 通常情况下，高缓存命中率 (例如 90% 以上) 是比较理想的。低命中率可能意味着缓存设计不合理或缓存容量不足。

• latency_ms (命令延迟): 虽然 INFO 命令本身不直接提供命令延迟的指标，但可以通过 SLOWLOG 命令和 Redis 7 新增的延迟监控功能来获取命令延迟信息。

  • 重要性： 命令延迟是衡量 Redis 性能的关键指标，高延迟会导致应用响应变慢。

  • 获取方式：

    • SLOWLOG GET： 查看慢查询日志，分析慢查询命令和延迟。

    • Redis 7 延迟监控： 使用 LATENCY HISTOGRAM 等命令查看延迟统计信息 (更高级的延迟监控功能，超出本文基础监控指标范围，可以另行深入研究)。

  • 代码示例 (redis-cli - SLOWLOG):

    redis-cli slowlog get 10  # 获取最近 10 条慢查询日志
    # 输出示例：
    # 1) 1678886400
    #    10000  # 延迟毫秒数
    #    127.0.0.1:54321
    #    GET mykey
    ​

  • 详解： SLOWLOG 记录了执行时间超过配置阈值 (默认 10 毫秒) 的命令。通过分析慢查询日志，可以找出导致延迟高的命令类型和键，并进行优化。 Redis 7 引入了更强大的延迟监控功能，可以更精细地分析延迟分布和瓶颈。

7.1.3 内存指标类指标

这类指标反映 Redis 服务器的内存使用情况。

• used_memory (已使用内存字节数): 以字节为单位显示 Redis 已使用的内存大小。

• used_memory_rss (Redis 进程实际占用的物理内存): 表示 Redis 进程实际占用的物理内存大小 (Resident Set Size)。

• mem_fragmentation_ratio (内存碎片率): 表示 Redis 内存碎片化的程度，计算公式为 used_memory_rss / used_memory。

  • 重要性： 监控内存使用情况，防止内存溢出，并关注内存碎片率，过高的碎片率会降低内存利用率。

  • 获取方式： redis-cli info memory | grep used_memory , redis-cli info memory | grep used_memory_rss, redis-cli info memory | grep mem_fragmentation_ratio

  • 代码示例 (redis-cli):

    redis-cli info memory | grep used_memory
    # 输出示例：used_memory:1234567
    redis-cli info memory | grep used_memory_rss
    # 输出示例：used_memory_rss:2345678
    redis-cli info memory | grep mem_fragmentation_ratio
    # 输出示例：mem_fragmentation_ratio:1.89
    ​

  • 详解：

    • used_memory 是 Redis 内部统计的已使用内存，包括数据、索引、缓存等。

    • used_memory_rss 是操作系统层面看到的 Redis 进程实际占用的物理内存。通常 used_memory_rss 会大于 used_memory，因为存在内存碎片、进程管理开销等。

    • mem_fragmentation_ratio 理想情况下接近 1，但通常会大于 1。 过高的碎片率 (例如大于 1.5) 可能意味着内存分配和释放策略有问题，需要关注。 Redis 会尝试进行内存碎片整理，但效果有限。

• maxmemory (最大可用内存): 表示 Redis 配置的最大可用内存限制。

• maxmemory_policy (最大内存淘汰策略): 表示当内存达到 maxmemory 限制时，Redis 采用的内存淘汰策略，例如 noeviction、allkeys-lru、volatile-lru 等。

  • 重要性： 了解内存限制和淘汰策略，确保 Redis 在内存不足时能够按照预期进行数据淘汰，防止 OOM 或数据丢失。

  • 获取方式： redis-cli config get maxmemory, redis-cli config get maxmemory-policy

  • 代码示例 (redis-cli):

    redis-cli config get maxmemory
    # 输出示例：1) "maxmemory"
    #           2) "0"  # 0 表示没有限制
    redis-cli config get maxmemory-policy
    # 输出示例：1) "maxmemory-policy"
    #           2) "noeviction"
    ​

  • 详解：

    • maxmemory 配置了 Redis 可以使用的最大内存。如果设置为 0，则表示没有限制 (不推荐在生产环境中使用)。

    • maxmemory-policy 定义了内存淘汰策略。常见的策略包括：

      • noeviction: 内存满时，拒绝写入操作，返回错误。

      • allkeys-lru: 淘汰所有键空间中最久未使用的键 (Least Recently Used)。

      • volatile-lru: 只淘汰设置了过期时间的键空间中最久未使用的键。

      • 其他策略，例如 allkeys-random、volatile-random、volatile-ttl 等。

    根据业务场景选择合适的淘汰策略非常重要。

7.1.4 持久化指标类指标

这类指标反映 Redis 持久化 (RDB 和 AOF) 的状态。

• rdb_last_save_time (上次 RDB 持久化时间戳): 表示上次成功执行 RDB 持久化的 Unix 时间戳。

• rdb_bgsave_in_progress (RDB 后台持久化是否正在进行): 表示 RDB 后台持久化进程是否正在运行，0 表示未运行，1 表示正在运行。

• aof_enabled (AOF 是否启用): 表示 AOF 持久化是否已启用，0 表示未启用，1 表示已启用。

• aof_last_rewrite_time_sec (上次 AOF 重写耗时): 表示上次 AOF 重写操作耗时 (秒)。

• aof_pending_bio_fsync (AOF 等待后台 fsync 完成的数量): 表示 AOF 持久化等待后台 fsync 操作完成的数量。

  • 重要性： 监控持久化状态，确保数据安全，并关注持久化性能。

  • 获取方式： redis-cli info persistence | grep rdb_, redis-cli info persistence | grep aof_

  • 代码示例 (redis-cli):

    redis-cli info persistence | grep rdb_last_save_time
    # 输出示例：rdb_last_save_time:1678886400
    redis-cli info persistence | grep rdb_bgsave_in_progress
    # 输出示例：rdb_bgsave_in_progress:0
    redis-cli info persistence | grep aof_enabled
    # 输出示例：aof_enabled:1
    redis-cli info persistence | grep aof_pending_bio_fsync
    # 输出示例：aof_pending_bio_fsync:0
    ​

  • 详解：

    • rdb_last_save_time 用于判断 RDB 持久化是否正常执行。如果时间戳长时间没有更新，可能意味着 RDB 持久化配置有问题或执行失败。

    • rdb_bgsave_in_progress 监控 RDB 后台持久化进程状态，长时间处于 1 可能意味着持久化进程遇到问题或服务器负载过高。

    • aof_enabled 确认 AOF 持久化是否已启用。

    • aof_last_rewrite_time_sec 和 aof_pending_bio_fsync 反映 AOF 重写和 fsync 操作的性能。 aof_pending_bio_fsync 数值过高可能意味着磁盘 I/O 瓶颈。

7.1.5 复制指标类指标 (主从复制)

这类指标反映 Redis 主从复制的状态。

• connected_slaves (已连接从节点数量): 主节点上显示的已连接从节点数量。

• master_link_up (主从连接状态): 从节点上显示的主从连接状态，up 表示连接正常，down 表示连接断开。

• master_link_down_since_seconds (主从连接断开时长): 从节点上显示的主从连接断开时长 (秒)。

• slave_repl_offset (从节点复制偏移量): 从节点已复制的数据偏移量。

• master_repl_offset (主节点复制偏移量): 主节点当前的复制偏移量。

• slave_lag (复制延迟): 主节点复制偏移量减去从节点复制偏移量，表示主从节点数据同步的延迟 (秒)。

  • 重要性： 监控主从复制状态，确保数据同步正常，并关注复制延迟，过高的延迟可能导致数据不一致或故障切换时数据丢失。

  • 获取方式： 主节点: redis-cli info replication | grep connected_slaves , 从节点: redis-cli info replication | grep master_ , 从节点: 计算 master_repl_offset - slave_repl_offset

  • 代码示例 (redis-cli - 主节点):

    redis-cli info replication | grep connected_slaves
    # 输出示例：connected_slaves:2
    ​

  • 代码示例 (redis-cli - 从节点):

    redis-cli info replication | grep master_link_up
    # 输出示例：master_link_up:up
    redis-cli info replication | grep master_link_down_since_seconds
    # 输出示例：master_link_down_since_seconds:-1  # -1 表示连接正常
    redis-cli info replication | grep slave_repl_offset
    # 输出示例：slave_repl_offset:12345678
    redis-cli info replication | grep master_repl_offset
    # 输出示例 (需要在主节点上获取)：master_repl_offset:12345680
    # 计算 slave_lag (需要在从节点上获取 master_repl_offset)
    master_offset=$(redis-cli -h <master_ip> -p <master_port> info replication | grep master_repl_offset | awk -F ':' '{print $2}')
    slave_offset=$(redis-cli info replication | grep slave_repl_offset | awk -F ':' '{print $2}')
    slave_lag=$((master_offset - slave_offset))
    echo "Slave Lag: $slave_lag"
    # 输出示例：Slave Lag: 2
    ​

  • 详解：

    • connected_slaves 在主节点上显示已连接的从节点数量。

    • master_link_up 和 master_link_down_since_seconds 在从节点上显示主从连接状态和断开时长。

    • slave_repl_offset 和 master_repl_offset 是复制偏移量，用于计算 slave_lag。

    • slave_lag 表示主从节点数据同步的延迟，单位通常是字节或命令数量。可以使用偏移量差值估算延迟大小。 理想情况下，slave_lag 应该很小。 过高的 slave_lag 可能意味着网络延迟、主节点负载过高或从节点处理能力不足。

7.1.6 错误和警告类指标

这类指标反映 Redis 服务器的错误和警告信息。

• rejected_connections (拒绝的连接数): 表示由于达到 maxclients 限制而被拒绝的客户端连接数量。

  • 重要性： 监控被拒绝的连接数，如果持续增长，可能意味着 maxclients 配置过小或遭受恶意连接攻击。

  • 获取方式： redis-cli info stats | grep rejected_connections

  • 代码示例 (redis-cli):

    redis-cli info stats | grep rejected_connections
    # 输出示例：rejected_connections:100
    ​

  • 详解： rejected_connections 表示由于达到 maxclients 配置限制而被拒绝的连接数。如果这个指标持续增长，需要检查 maxclients 配置是否合理，或者是否存在连接泄漏或恶意连接攻击。

• oom_instantaneous_lru (最近一次 LRU 淘汰时是否发生 OOM): 表示最近一次 LRU 淘汰操作是否因为内存不足而触发 OOM (Out Of Memory) 错误。

  • 重要性： 监控 OOM 错误，防止 Redis 崩溃或数据丢失。

  • 获取方式： redis-cli info stats | grep oom_instantaneous_lru

  • 代码示例 (redis-cli):

    redis-cli info stats | grep oom_instantaneous_lru
    # 输出示例：oom_instantaneous_lru:0  # 0 表示未发生 OOM
    #           oom_instantaneous_lru:1  # 1 表示发生 OOM
    ​

  • 详解： oom_instantaneous_lru 指标为 1 表示最近一次 LRU 淘汰操作因为内存不足而触发了 OOM 错误。 这通常是严重的错误，需要立即排查内存问题，例如增加 maxmemory 配置、优化内存使用、检查是否存在内存泄漏等。

• warning (警告信息): INFO 命令返回的 Warnings 部分可能包含一些警告信息，例如关于内存使用、持久化、复制等方面的警告。

  • 重要性： 关注警告信息，及时处理潜在问题。

  • 获取方式： redis-cli info | grep Warning 或 查看 INFO 命令的完整输出。

  • 代码示例 (redis-cli):

    redis-cli info | grep Warning
    # 输出示例 (可能没有警告)：# Warning
    # 如果存在警告，例如：
    # # Warning
    # # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    ​

  • 详解： INFO 命令的 Warnings 部分会显示 Redis 服务器的警告信息。需要仔细阅读警告信息，了解警告的具体内容，并根据提示进行相应的处理。例如，上述示例中警告 TCP backlog 设置过小，可能需要调整系统内核参数。

7.1.7 键空间指标类指标

这类指标反映 Redis 键空间 (数据库) 的信息。

• db<dbnum> (数据库信息): INFO 命令返回的 Keyspace 部分包含每个数据库 (db0, db1, ...) 的键数量 (keys) 和过期键数量 (expires) 信息。

  • 重要性： 了解每个数据库的键数量和过期键情况，用于分析数据分布和过期策略。

  • 获取方式： redis-cli info keyspace

  • 代码示例 (redis-cli):

    redis-cli info keyspace
    # 输出示例：
    # db0:keys=1234,expires=100
    # db1:keys=5678,expires=50
    ​

  • 详解： db<dbnum> 部分显示每个数据库的键数量 (keys) 和设置了过期时间的键数量 (expires)。 可以根据这些信息了解每个数据库的数据规模和过期键的比例。

7.2 Redis 监控指标实践代码示例 (Python)

除了使用 redis-cli 命令行工具，还可以使用编程语言 (例如 Python) 结合 Redis 客户端库 (例如 redis-py) 来获取和处理监控指标。

import redis
import time
# 连接 Redis
r = redis.Redis(host='localhost', port=6379)
def get_redis_info():
    """获取 Redis INFO 命令返回的信息"""
    return r.info()
def monitor_redis_metrics():
    """实时监控 Redis 关键指标并输出"""
    while True:
        info = get_redis_info()
        uptime = info['uptime_in_seconds']
        connected_clients = info['connected_clients']
        used_memory_human = info['used_memory_human']
        ops_per_sec = info['instantaneous_ops_per_sec']
        keyspace_hits = info['keyspace_hits']
        keyspace_misses = info['keyspace_misses']
        mem_fragmentation_ratio = info['mem_fragmentation_ratio']
        role = info['role']
        hit_ratio = 0
        if keyspace_hits + keyspace_misses > 0:
            hit_ratio = keyspace_hits / (keyspace_hits + keyspace_misses) * 100
        print(f"--- Redis Monitoring --- {time.strftime('%Y-%m-%d %H:%M:%S')}")
        print(f"Uptime: {uptime} seconds")
        print(f"Connected Clients: {connected_clients}")
        print(f"Used Memory: {used_memory_human}")
        print(f"Ops/sec: {ops_per_sec}")
        print(f"Cache Hit Ratio: {hit_ratio:.2f}%")
        print(f"Memory Fragmentation Ratio: {mem_fragmentation_ratio:.2f}")
        print(f"Role: {role}")
        print("-" * 20)
        time.sleep(1)  # 每秒刷新一次
if __name__ == "__main__":
    monitor_redis_metrics()
​

代码详解:

1. 导入库: 导入 redis 客户端库和 time 库。

2. 连接 Redis: 使用 redis.Redis() 方法连接 Redis 服务器。

3. get_redis_info() 函数: 封装了获取 INFO 命令返回信息的逻辑。

4. monitor_redis_metrics() 函数:

   • 循环获取 INFO 信息。

   • 提取关键指标 (uptime, connected_clients, used_memory_human, ops_per_sec, keyspace_hits, keyspace_misses, mem_fragmentation_ratio, role)。

   • 计算缓存命中率。

   • 格式化输出监控指标。

   • 使用 time.sleep(1) 每秒刷新一次。

5. if __name__ == "__main__":: 主程序入口，调用 monitor_redis_metrics() 函数开始监控。

运行代码:

1. 确保已安装 redis-py 库: pip install redis

2. 运行 Python 脚本: python your_script_name.py

运行后，脚本会实时输出 Redis 的关键监控指标到控制台。您可以根据需要扩展代码，例如将监控数据存储到数据库、集成到监控系统 (例如 Prometheus) 等。

7.3 总结与最佳实践

• 选择合适的监控指标: 根据业务需求和关注点，选择关键的监控指标进行重点监控。例如，对于缓存场景，缓存命中率、内存使用率、延迟是关键指标；对于持久化场景，持久化状态、延迟是关键指标；对于主从复制场景，复制延迟、主从连接状态是关键指标。