abbix、Prometheus、Grafana、Nightingale,四个监控如何选型?

研监控系统的时候,通常会看到这四个产品:Prometheus、Grafana、Zabbix、Nightingale,对新手而言,是个选型难题。本文尝试分别解释其适用场景和优缺点,当然了,每个人的认知都有局限,仅供大家参考。

Zabbix

Zabbix 是老牌监控产品,主要用于资产设备 监控,比如监控网络设备、服务器,Zabbix 要求用户在 UI 上主动添加设备,填写连接地址、认证信息。是典型的资产式管理逻辑。

Zabbix 也可以监控 MySQL、Redis、Postgres、Kubernetes 等各类开源组件,但这不是它的长处,采集的指标偏少、海量指标不方便检索。

对于微服务指标监控,Zabbix 就更加不擅长了,这是 Prometheus 生态的天下。

Zabbix 产品经过多年打磨,产品完成度极高,体现在:

  • 沉淀了大量的模板,可以开箱即用监控各类网络设备
  • 数据采集时的 ETL 处理很完备,因为 SNMP 数据很不规整,促使 Zabbix 沉淀了很多预处理器
  • 告警事件的发送链路也有不错的抽象,多种媒介的适配、灵活的消息模板
  • 对各类老旧设备的兼容性很好,比如 AIX

Zabbix 仍然服役于大量企业,主要是解决设备监控的场景。

Prometheus

Prometheus 是模仿 Borgmon 诞生的,可谓师出名门,专门为时序数据研发了 TSDB(Time series database),简洁的查询语法、时序数据定义方式,已然成为业内事实标准。

Prometheus 社区有非常多的 Exporter,就是监控采集器,可以采集机器、数据库、中间件等各类监控数据,不同的 Exporter 通常是不同的社区贡献者维护的,所以实际使用时是要部署很多二进制。

可视化方面,Prometheus 仅提供实时 Ad-hoc 查询探索,不提供仪表盘能力,Prometheus 通常和 Grafana 配合使用,由 Grafana 提供仪表盘能力。

告警方面,Prometheus 提供的是 Yaml 文件方式来配置告警规则,没有提供 UI。Prometheus 是单点架构,进程里内置告警引擎,周期性查询自身的监控数据,产生告警事件,告警事件推给 Alertmanager 做后续的去重、静默、抑制、路由、发送。

Prometheus 生态非常开放,吸引了广大贡献者,Prometheus 是当前世界上最流行的监控生态。

实际在落地的时候,如果你们担心单点架构不可靠,或者你们数据量比较大,更建议使用 VictoriaMetrics,VictoriaMetrics 和 Prometheus 接口、协议兼容,姑且可以看作是分布式的 Prometheus。

Prometheus 社区也提供了 SNMP Exporter,也可以监控网络设备,不过相比 Zabbix 的开箱即用,要折腾得多,如果追求统一化平台,可以用 Prometheus 这套体系监控所有数据,如果想追求设备监控的开箱即用,可以两个产品配合使用。

Grafana

Grafana 的用户量是监控、可观测性领域最大的,因为它是可视化领域的老大。虽然 AI 发展迅猛,但是 AI 更擅长的是实时分析、推理,Grafana 不会被 AI 替代,Grafana 相当于是承接了 AI 生成的可视化数据。

Grafana 可以对接多种数据源,最丝滑的是 Prometheus、Mimir、VictoriaMetrics、Tempo、Loki,即:跟自己的产品对接最为丝滑。

Grafana 除了可以对接 Prometheus 查看数据,实际也可以对接 Zabbix 查看,有些人不喜欢 Zabbix 上个时代的 UI 风格,觉得 Grafana 更好看,实际从功能体验来看,我感觉 Zabbix 自身的数据就在 Zabbix 里看图就足够了。

Grafana 实际也可以做告警引擎,对不同的数据源配置告警规则,优点是可以联动多种数据源,缺点是对事件的 Pipeline 处理支持有限,国内使用 Grafana Alerting 的公司比较少。

Nightingale

夜莺项目(Nightingale)类似 Grafana 可以对接多种数据源,不过侧重在告警。如果你们有多套 Prometheus、多套 ElasticSearch,还有 ClickHouse、Loki 的数据需要做告警,还想使用 UI 管理告警规则,那夜莺是合适的。

如果你们只有少量 Prometheus,也能接受使用 Yaml 管理告警规则,那夜莺就有点重了。

夜莺提供了事件 Pipeline 的能力要着力说一下,这个能力可以对告警事件做一系列处理,并且可以对接自己的系统,比如告警产生之后,想要调用自己的系统补充上一些关键字段(Enrichment),或者调用自己的 AI 做个 Summary,或者把符合某类条件的告警 Drop 掉,或者做一下 Relabel,都可以使用 Pipeline 机制。

夜莺社区提供了一个采集器叫 Categraf,姑且可以理解为是把各类 Exporter 整合成了一个二进制,如果你不想部署这么多 Exporter,想用一个进程打天下,Categraf 是可以考虑的。

相关推荐
qq_452396231 天前
第十二篇:《数据采集:Grafana Alloy、Fluent Bit、Vector 的选型与配置》
java·贪心算法·grafana
2601_962097361 天前
可观测性实战:Prometheus+Grafana+OTel构建监控
grafana·prometheus·微服务架构·可观测性·opentelemetry
Joker-Full-stack1 天前
higress Grafana生产事故复盘:Loki 2.9 WAL 竞态 Bug 导致 5 天审计日志消失
bug·grafana·higress
IT界的老黄牛1 天前
Jenkins 监控一条龙:接入、看板 9964、11 条告警规则直接抄走
jenkins·grafana·prometheus·监控·ci-cd·告警规则
陈皮糖..2 天前
基于 Keepalived 的传统 Web 高可用架构的容器化改造与可观测性升级
运维·docker·性能优化·架构·云计算·prometheus
heimeiyingwang2 天前
【Prometheus·部署篇】存储与容量规划:本地存储、远程存储与长期保存
prometheus
heimeiyingwang2 天前
【Prometheus·可视化篇】Grafana 集成:数据源配置与 Dashboard 设计原则
grafana·prometheus
IT界的老黄牛2 天前
Jenkins 构建卡了 23 天,abort 按钮点了没用
jenkins·maven·prometheus·告警·排查·ci-cd
2601_962097363 天前
GraphQL,Grafana和Dash
python·grafana·数据可视化·graphql·dash
heimeiyingwang4 天前
【Prometheus·告警篇】告警规则:Recording Rules 与 Alerting Rules 最佳实践
prometheus