监控 Redis：Zabbix 和 Nightingale 生态对比

巴辉特 2024-11-08 11:27:40

Zabbix 监控 Redis 和 Nightingale 监控进程的原理是一样的，但是产品体验很不相同，本文对两个方案分别加以说明方便大家选型对比。

监控 Redis 的原理

监控 Redis 的原理比较简单，就是通过 TCP 连到 Redis 实例上，执行 info 之类的命令获取输出并解析，然后把解析出来的数据推给监控系统，MySQL、MongoDB 的监控原理也都是类似的。虽然要弄懂这些指标的具体含义并不容易，但是仅从采集端来看，相关的采集逻辑并不麻烦。

下面是我的环境里通过 info 命令拿到的输出，给你一个直观的认识：

$ redis-cli
127.0.0.1:6379> info
# Server
redis_version:6.2.16
redis_git_sha1:00000000
redis_git_dirty:0
...

# Memory
used_memory:963376
used_memory_human:940.80K
used_memory_rss:8712192
used_memory_rss_human:8.31M
used_memory_peak:1021480

上面的内容只是截取了一部分，不过也很能说明问题了，info 命令的输出是分 section 的，每个 section 里有很多 key-value 对，这些 key-value 对就是我们要监控的指标。

Zabbix 监控 Redis

Zabbix 老版本监控 Redis 就是靠自行编写采集脚本，这种方式有点过于麻烦了，从 Zabbix agent2 开始，使用 go 重写 agent，支持了更多新的采集能力，其中就包括了 Redis 的监控数据采集。

在 Zabbix 中采集监控数据，首先要指定使用哪个 agent 所在的机器作为探针，然后给这个探针下发采集任务，agent 会去执行任务，然后把采集到的数据推给 Zabbix server。Zabbix server 则会把收到的数据存储到数据库中，然后根据用户配置的告警规则，触发告警。

一般来讲，为了稳定可靠的采集，都是直接把采集任务下发给 Redis 实例所在的机器上的 agent，这样 agent 直接通过 127.0.0.1:6379 连接本地的 Redis 实例，采集数据的时候不会受网络影响。

Zabbix 绑定 Redis 模板

上例中，我给这个机器绑定了 Redis by Zabbix agent 2 这个模板，这个模板默认连的是 tcp://localhost:6379。之后就可以采集到数据了，比如 redis.clients.connected 这个 Key 表示的是当前连接到 Redis 的客户端数量。

Nightingale 监控 Redis

Nightingale 本身无法采集数据，可以使用 categraf 作为采集器（当然，你也可以使用其他你习惯的采集器），下面是 categraf 采集 redis 的相关配置文件：

[[instances]]
address = "localhost:6379"
labels = { instance="n9e-10.2.3.4:6379" }

上例中我采集数据的时候给这个数据附加了一个 instance 标签，后面就可以根据 instance 这个标签来区分不同的 Redis 实例了。这个配置比较简单，核心就是配置 address 的地址，如果你的 Redis 有密码，还需要配置 password。

categraf redis dashboard

上例是使用 categraf 采集了数据之后推给夜莺，在夜莺里导入了 redis 的内置仪表盘看到的样子。

Zabbix 和 Nightingale 对比

整体来看，二者差别好像不大。实际上还是有巨大差别的，主要体现在：

数据结构上。Zabbix 使用 Key 来表示监控指标，Nightingale 复用 OpenTSDB、Prometheus 生态的标签+指标的方式，更加灵活。尤其是在聚合计算的时候。
存储容量上。如果你只有少量 Redis 实例要监控，感受不深，如果你有大量 Redis 实例要高频率监控的时候，就会明显感受到 RDBMS 存储时序数据的瓶颈。而 Zabbix 在这个点上就比较吃力。其实 Redis 实例的指标不多，整体还好，如果你要采集 ElasticSearch 的指标就会发现，如果要完备的采集，随随便便一个实例就有几万个指标，这么大量的指标，还是建议使用专门的时序库来存储。

总结

如果是使用第一代 Zabbix-agent，我是不建议用 Zabbix 监控 Redis 以及各类数据库、中间件的，后面 Zabbix 发布的 agent 2 会更好一些，可以用，但是因为 Zabbix 的历史包袱，也不建议用。在笔者看来，Zabbix 适合监控网络设备，而数据库、中间件、Kubernetes、微服务这些监控需求，交由 Prometheus 生态来搞更合适。

Prometheus 生态的采集器很多，除了文中介绍的 categraf，还可以使用 Telegraf、Prometheus Exporter 等，这些采集器都是开源的，可以根据自己的需求来选择。

Nightingale 在 Prometheus 生态里扮演的是高可用、UI 易用的告警引擎，可以同时对接多套 Prometheus，用一套告警规则生效到多套 Prometheus，而且有权限管控，给全公司各个团队用的时候比较方便。后面 Nightingale 会开放 ElasticSearch、ClickHouse 的告警引擎能力，届时就更加强大了。