9k star 监控系统，100% 国产，推荐了解

前言

监控系统的重要性不言而喻，国内用的最多的应该是 Zabbix 和 Prometheus，其优缺点：

• Zabbix 是资产管理式，监控数据存在数据库中，擅长设备监控，不擅长微服务和云原生环境的监控；推出时间较早，社区活跃度较高
• Prometheus 是云原生环境的监控利器，支持多维度的指标数据，自研存储引擎，但是告警引擎是单点，使用配置文件管理规则，缺少权限化管理的 WebUI，如果把监控能力开放给公司所有团队，让各个团队自服务，就比较困难

随着云的发展，Zabbix 感觉是依托于存量市场，而 Prometheus 是未来的大势所趋。那 Prometheus 的缺点应该如何解决呢？推荐大家了解一下夜莺（Nightingale）开源项目。

夜莺介绍

夜莺项目 github 地址是 https://github.com/ccfos/nightingale 。其中 ccfos 是哪家公司？其实，ccfos 不是家公司，ccf 是中国计算机学会的缩写，os 是 open source 的缩写，ccfos 是中国计算机学会开源项目的统一地址。夜莺项目最初由滴滴开源，后来捐赠给中国计算机学会进行托管了。

目前，夜莺项目的 github star 数量在 9300 多，fork 数量在 1300 多，相当于每 7 个 star，就有一次 fork，docker pull 的数量 178000，增长曲线非常健康。

夜莺产品架构

夜莺核心是做一个高可用的告警引擎，支持多数据源接入，很多公司都有多个 Prometheus、VictoriaMetrics、Thanos，希望统一管理告警规则，于是，夜莺的产品架构图如下：

用户配置的告警规则，可以同时生效到多个时序库，不需要为每个时序库分别配置告警规则。另外，对于有些公司有多个机房，网络链路不太好，时序库可能分散在多个机房，夜莺支持把告警引擎下沉部署到各个机房，即便和中心机房的网络链路中断，也不影响边缘机房的告警。架构图如下：

下面我们介绍一下夜莺的优势和劣势。

夜莺优势1：灵活的告警规则

夜莺主要是告警引擎这块做得最方便，告警规则的配置也较为灵活，告警规则支持级别抑制、生效时间配置、事件 relabel、告警屏蔽、告警订阅、告警自愈等等。告警规则的配置界面如下：

• 数据源支持配置多个，也可以选择全部，即：一条告警规则生效到多个数据源
• 告警规则支持多条，可以启用级别抑制，编写 promql 时可以调出内置指标，方便编写
• 事件 relabel 是对告警事件的二次处理，比如 drop 掉一些不想要的标签
• 生效时间用于配置告警规则的生效时间，比如只在工作日生效，周末不生效，或者只在白天生效，晚上不生效，或者不同时段不同阈值
• 告警自愈是告警触发之后，自动执行一些脚本，串联一些固定止损操作
• 回调地址是告警触发之后，调用第三方接口，比如钉钉、飞书等，进行告警通知，也可以对接各个公司自定义的接口

夜莺优势2：内置很多最佳实践

夜莺除了对接时序库，还可以对接各类采集器 agent，比如 telegraf、categraf、datadog-agent、各类 exporter 等，不同的数据库、中间件都有提供一些现成的仪表盘、告警规则，这样可以快速上手，省心不少。下面是夜莺内置的模板中心：

很多朋友不会写 promql，但是 promql 在 Prometheus 生态里又极为重要，那能否让一些资深工程师提前写好，沉淀下来，普通工程师直接用呢？夜莺支持的指标视图就是干这个事的，目前已经内置沉淀了几百个 promql，开箱即用。

夜莺的劣势1：仪表盘不如 grafana

虽然已经内置了不少仪表盘了，但是还是不如 grafana 那么丰富，grafana 在看图这块确实无出其右，夜莺内置的那些仪表盘，如果你觉得够用了，就用，如果觉得不够用，建议还是上 grafana，下图是夜莺内置的一个仪表盘样例：

夜莺的劣势2：告警降噪能力不够

夜莺侧重在多数据源告警、告警规则统一管理，支持邮件、企微、飞书、钉钉等通知媒介，通过自定义通知脚本，也可以实现电话、短信通知，即常用的通知媒介都是支持的，不支持的写个脚本也可以支持。但是告警收敛降噪、排班、认领、升级、和 IM 深度打通等功能，还是不够（可能我想要的太多