前言

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

监控的常见痛点

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

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

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

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

夜莺介绍

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

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

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

1. 架构简洁清晰
2. 安装部署简单
3. 支持多数据源
4. 配套有采集器
5. 告警配置灵活
6. 仪表盘美观、性能出众
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

三、支持多数据源

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

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

四、配套有采集器

如果之前没有做过监控数据收集，可以使用夜莺团队提供的采集器 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 等，接收到数据之后做统一转换，然后转发给后端时序库，具体转发给哪些时序库是在夜莺的配置文件中配置的。

五、告警配置灵活

夜莺的告警配置比较灵活，可以用一套规则生效到多个数据源，支持级别抑制、生效时间配置、告警屏蔽、告警订阅、告警自愈等等，告警规则的配置界面如下：

六、仪表盘美观、性能出众

夜莺的仪表盘，全部采用自研的可视化引擎。展示效果美观、性能出众、功能丰富（虽然还没有 grafana 全面，但基本可以作为grafana的国产化对标了）。夜莺的仪表盘支持暗黑主题，一个小样例效果如下：

七、适应复杂多机房场景

很多公司都有很多机房，如果网络链路相互之间不太好，此时通常会在不同的机房下沉部署时序库，但是告警规则又想在一个中心管理，夜莺也支持这种部署方案，即：把告警引擎下沉跟随时序库部署，告警规则的管理和可视化还是放在中心，架构图如下：

使用国外的开源监控项目，最担心的就是没有技术支持，夜莺作为“100%国产”开源项目，有两种技术支持方式，一种是社区支持，一种是商业支持，有预算的可以寻求快猫星云团队的技术支持，响应更加及时。社区技术支持渠道，主要是论坛和GitHub issue，相关地址如下：

• 夜莺仓库：https://github.com/ccfos/nightingale
• 夜莺文档：https://n9e.github.io/
• 论坛地址：https://answer.flashcat.cloud/

夜莺的企业用户有上千家，比如移动、联通、电信、米哈游、莉莉丝、途游、悠星、高济、益丰、大参林、方正证券、国泰君安、海底捞、海康、搜狐、新浪等，分布在各行各业。夜莺开源项目的背后有商业公司在持续运作支持，而且托管在基金会，发展具有可持续性，推荐大家在日常工作中使用。