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

前言

天下没有无 bug 的软件，没有不宕机的系统，选择一个好用的、趁手的监控工具，是运维、研发人员 “明哲保身、自证清白” 的必备利器。也有人说监控是运维的眼睛，当然，也是研发的眼睛，生产环境出故障，要尽快发出告警，并提供详实的数据供问题排查，其重要性不言而喻。

本文要介绍的是开源监控工具夜莺监控（Nightingale）。它的定位不是替代所有监控生态组件，而是在 Prometheus、VictoriaMetrics、Thanos、M3、Elasticsearch、Loki 等数据源之上，提供更易管理的告警、仪表盘、多团队权限和复杂机房场景支持。

核心要点

Zabbix 擅长传统设备和操作系统监控，但面对云原生动态对象和多维指标时会吃力。
Prometheus 擅长云原生指标采集与查询，但在规则权限化管理、多集群规则复用、告警事件持久化等方面需要额外工程化。
夜莺监控主打开箱即用、多数据源、告警管理、仪表盘和复杂多机房场景，适合作为统一监控管理入口。
Categraf 可作为配套采集器，也可以与 Telegraf、Grafana Agent、各类 exporter 等生态组件组合。
本文涉及的 star、fork、用户和版本信息来自原文发布时的项目状态，读者落地时应以项目仓库和官方文档为准。

监控的常见痛点

开源的监控系统也不少，目前用的比较广泛的是 Zabbix 和 Prometheus，但没有银弹。Zabbix 擅长设备监控，对各类操作系统、网络设备有较好的兼容适配，但是不擅长微服务和云原生环境的监控，原因如下：

Zabbix 是资产管理式，在云原生环境下，资产是动态变化的，比如 Pod、Service、Deployment 等，Zabbix 不擅长这种动态变化的对象的监控
微服务和云原生环境下，监控指标爆炸性增长，而且指标有不同的维度描述，Zabbix 使用关系型数据库存储时序数据，不擅长处理这种大规模的多维度的指标数据

Prometheus 擅长微服务和云原生环境的监控，基本已经成为 Kubernetes 的标配，在云原生环境下非常流行，但是显然，也有缺点：

设计上偏工具化，使用配置文件来管理规则，缺少权限化管理的 WebUI，如果 IaC 践行的不好的公司（国内大部分公司践行的都不好），要把这个监控能力放开给所有的技术团队，让各个技术团队能够自服务，那就比较困难了
使用 Prometheus 的公司通常会不止一套，比如每个 Kubernetes 一套 Prometheus，多个 Prometheus 可能有很多相同的规则，管理起来比较重复
其他一些小点：告警引擎是单点，告警事件没有持久化；告警规则缺乏一些更为灵活的配置，比如生效时间；存储是单点，当然，现在已经有 VictoriaMetrics、Thanos 等方案了

可以简单理解为：Zabbix 和 Prometheus 都很强，但它们解决问题的出发点不同。很多团队的痛点不在于“没有指标”，而在于指标来源多、规则难管理、团队权限难划分、告警流程难治理。

工具	更擅长的场景	常见短板
Zabbix	传统主机、网络设备、操作系统和资产管理式监控	云原生对象动态变化、多维时序指标规模化处理
Prometheus	Kubernetes、微服务、Exporter 生态和 PromQL 查询	多团队规则管理、权限化 WebUI、告警事件治理和多套 Prometheus 管理
夜莺监控	多数据源统一管理、告警配置、仪表盘、复杂机房和团队协作	需要与后端时序库、日志库或采集器合理组合使用

夜莺介绍

今天要给大家介绍的是“100%国产”的开源监控工具夜莺监控（Nightingale）。夜莺监控最早由滴滴孵化并开源，沉淀的是顶级互联网公司的最佳实践，之后则捐赠给了中国计算机学会进行托管，社区活跃，发展势头迅猛。就在刚刚看到的数据，夜莺监控在GitHub上超过了7000个 star，1200次 fork，相当于每 6 个 star，就有一次 fork，增长曲线非常健康！

夜莺监控-star增长曲线

夜莺最新发布的版本为V6，是一个all-in-one的、开箱即用的监控系统，支持多数据源接入，能够同时对指标、日志、分布式链路追踪数据进行监控和分析。

夜莺监控具有以下 7 大特点：

架构简洁清晰

安装部署简单

支持多数据源

配套有采集器

告警配置灵活

仪表盘美观、性能出众

适应复杂多机房场景

这 7 个特点对应的不是单一功能点，而是一套监控平台落地链路：先把数据接进来，再把规则、权限、仪表盘、告警和多机房架构统一管理起来。

一、架构简洁清晰

夜莺作为一款监控系统，整体设计上非常开放，兼容并包，可以和开源生态上其他软件组合使用，比如采集器可以对接 telegraf、categraf、grafana-agent、datadog-agent、以及各类 exporter；存储可以对接 prometheus、thanos、m3、victoriametrics 等。夜莺的产品架构图如下：

夜莺监控-架构

从依赖上看，就只依赖 mysql 和 redis，这俩存储对于技术人员来说，都是非常熟悉的。夜莺本身就只有一个二进制 + 配置文件，没有其他依赖，所以安装部署都非常容易。

这个架构的好处是边界清楚：采集器、时序库、日志库、链路系统可以继续使用开源生态中成熟的组件，夜莺重点负责监控管理面、告警管理和可视化体验。

二、安装部署简单

最简单的部署方式，是使用 docker-compose，找一个干净的机器环境，然后执行下面的命令即可：

git clone https://github.com/ccfos/nightingale.git
cd nightingale/docker
docker-compose up -d

docker-compose 直接使用 host network，所以没有 bridge，启动之后直接浏览器访问即可，默认端口是 17000，账号 root，密码是 root.2020。

夜莺监控-内置仪表盘

不过，在这里更推荐大家使用二进制方式部署，也是几行命令的事，以 linux x86 环境举例：

# 创建个 n9e 的目录，后面把 n9e 相关的文件解压到这里
mkdir -p /opt/n9e && cd /opt/n9e

# 下载 n9e 发布包，amd64 是 x84 的包，下载站点也提供 arm64 的包，如果需要其他平台的包则要自行编译了
tarball=n9e-v6.1.0-linux-amd64.tar.gz
urlpath=https://download.flashcat.cloud/${tarball}
wget -q $urlpath || exit 1

# 解压缩发布包
tar zxvf ${tarball}

# 解压缩之后，可以看到 n9e.sql 是建表语句，导入数据库
mysql -uroot -p1234 < n9e.sql

# 启动 n9e，先使用 nohup 简单测试，如果需要 systemd 托管，请自行准备 service 文件
nohup ./n9e &> n9e.log &

# 检查 n9e.log 是否有异常日志，检查端口是否在监听，正常应该监听在 17000
ss -tlnp|grep 17000

安装完成后的第一件事，不是立即配置所有业务规则，而是先确认三个基础项：Web 页面能访问，数据库初始化成功，n9e.log 没有明显异常。基础链路稳定后，再接入数据源和采集器。

三、支持多数据源

夜莺最轻量的用法，类似 grafana，直接接入数据源即可，菜单位置：【系统配置】-【数据源】，目前支持的数据源有：prometheus、victoriametrics、thanos、m3、elasticsearch、loki，后续还会支持更多的数据源。

夜莺监控-多数据源支持

数据源接入之后，就可以查看这些数据，做可视化分析，做告警了，夜莺默认提供了一些内置大盘（菜单位置：【仪表盘】-【内置仪表盘】）和内置告警规则（菜单位置：【告警管理】-【内置规则】），导入自己的业务组（是个管理概念，不同的告警规则和仪表盘可以使用不同的业务组分门别类管理+控制权限）即可使用。

多数据源能力的价值在于迁移成本低。团队不需要一次性替换现有 Prometheus、VictoriaMetrics、Thanos、M3 或日志系统，可以先把已有数据源接入夜莺，再逐步治理告警规则和仪表盘。

四、配套有采集器

如果之前没有做过监控数据收集，可以使用夜莺团队提供的采集器 categraf，categraf 是一个单独的开源项目，内置了 OS、SNMP、IPMI、MySQL、Redis、MongoDB、Oracle、Kafka、ElasticSearch、cAdvisor 等多种采集插件，项目地址：https://github.com/flashcatcloud/categraf。当然，也可以使用其他采集器，比如 telegraf、grafana-agent 等，但是 categraf 的对接最为丝滑。

夜莺支持多种数据接入协议，比如 prometheus remote write、OpenTSDB、Datadog 等，接收到数据之后做统一转换，然后转发给后端时序库，具体转发给哪些时序库是在夜莺的配置文件中配置的。

选择采集器时，可以按现状判断：已有成熟采集链路的团队可以继续沿用；从零开始建设基础设施监控的团队，可以优先评估 Categraf，因为它和夜莺的默认使用路径更顺。