开源运维监控系统-Nightingale（夜莺）应用实践

一、前言

  某业务系统因OS改造，原先的Zabbix监控系统推倒后未重建，本来计划用外部企业内其他监控系统接入，后又通知需要自建才能对接，考虑之前zabbix的一些不便，本次计划采用一个类Prometheus的监控系统，经调研后发现Nightingale兼容Prometheus，又有一些其他功能增强，又在一些大的企业经过较大规模部署实践，故本次采用Nightingale作为监控系统来进行重建。

  Nightingale（夜莺） 是由滴滴开源，基于Open-source Apache-2.0 Licensed，捐赠给中国计算机学会开源发展委员会（CCF ODC）的， 它是在 Open-Falcon 的基础上，结合滴滴内部的最佳实践，在性能、可维护性、易用性方面做了大量的改进，逐渐成熟为滴滴集团统一的监控解决方案，支撑了滴滴内部数十亿监控指标，覆盖了从OS、容器、到应用等各层面的监控需求，周活跃用户数千。（Nightingale）作为一个企业级云原生监控解决方案，旨在满足云原生时代企业级的监控需求，侧重云原生，同上兼顾云原生和裸金属，支持应用监控和系统监控，插件机制灵活，插件丰富完善，具有高度的灵活性和可扩展性。它可满足不同规模用户的场景，小到几台服务，大到数十万都可以完美支撑。官网号称：它具备All-in-One部署和开箱即用（Out of the box）特性，集合了 Prometheus 和 Grafana 的优点，集成了数据收集、可视化指标和监控警报三大主要功能，还可以对分布在多个 Region 的指标、日志、链路追踪数据进行统一的可视化和分析。

通过上述系统，我们需要解决如下问题：

• 当环境中主机系统出现问题后 , 能及时感知，并告警通知，有方便的告警配置方式和多样的通知方式
• 可通过历史数据了解当前环境运行趋势，预测未来可能出问题，为服务扩缩容提供数据支撑
• 配置简单，功能完善，文档丰富，有成熟的结构可参考
• 支持多种指标检测，尤其可及时感知业务异常，并支持一定的告警自我恢复

相关资源：官网、官方手册、nightingale Gitee、官方文档、部署指导、社区问答、Bug报告、open-falcon、Netdata、TSDB、最新版下载、教程

二、产品特性及架构

2.1、产品特性

夜莺于 2020 年 3 月 20 日，在 github 上发布 v1 版本，已累计迭代 100 多个版本。目前官方最新版是6.7.3版本。从 v6 版本开始，夜莺尝试转型为统一可观测性平台，n9e 不再仅支持接入时序数据源(Prometheus、Victoriametrics、M3DB、Thanos)，也可以接入日志类数据源（Elasticsearch，Loki【预】），链路追踪数据源（Jaeger）。

1）开箱即用：Nightingale支持Docker、Helm Chart和云服务等多种部署方式，它将数据收集、监控和警报集成到了一个系统中，并配有各种监控面板、快速视图和警报规则模板，这大大降低了云原生监控系统的建设成本、学习成本和使用成本，从 v6 版本开始，支持接入 ElasticSearch、Jaeger 数据源，实现日志、链路、指标多维度的统一可观测，更好的UI界面也让用户使用更简单，更加友好。

2）专业的告警管理：它可提供可视化警报配置和管理，支持各种警报规则，提供配置静默和订阅规则的功能，支持多个警报传递通道（多种告警方式），并具有警报自我修复和事件管理等功能。支持对接 Prometheus、VictoriaMetrics、Thanos、Mimir、M3DB 等多种时序库，可实现统的一告警管理。另外它无缝搭配 Flashduty，实现了告警聚合收敛、认领、升级、排班、IM集成，确保告警处理不遗漏，减少打扰，更好协同。

3）云原生支持：实现了通过“交钥匙”即交付的方式来快速构建企业级云原生监控系统，支持大多常见采集器Categraf、Telegraf和Grafana-agent、datadog-agent、各种 exporter 等多个采集器，支持Prometheus、VictoriaMetrics、M3DB、ElasticSearch和Jaeger等多个数据源，并兼容导入Grafana仪表盘，与云原生生态系统无缝集成，采用 Apache-2.0 license开源授权。

4）高性能及高可用：由于 Nightingale的多数据源引擎及其出色的架构设计，它可充分利用高性能的时序数据库，可以处理数十亿时序数据的数据收集、存储和警报分析场景，节省了大量成本。它的组件可以在没有单点故障的情况下进行水平扩展。它已经部署在数千家企业中，并在苛刻的生产实践中进行了测试。许多领先的互联网公司已经将Nightingale用于具有数百个节点的集群机器，处理数十亿个时间序列数据。

5）弹性扩展和集中管理：Nightingale可以部署在单核1G的云主机上，也可以部署在数百台机器的集群中，或在Kubernetes中运行。还可以作为时间序列数据库、警报引擎和可以分散到各数据中心和区域的其他组件，它综合考虑到平衡边缘部署和集中管理，解决了数据碎片化和缺乏统一视图的问题。

6）开放式社区支持： 收到多家公司和近千名社区开发人员支持，持续为Nightingale开源社区的健康长久发展发力，保证了社区活跃而专业，同时也在不断沉淀产品中提供了越来越多的最佳实践。Nightingale可以与开源社区中的常见收集器进行交互，如categraf、telegif、datadog agent、grafana agent，以及开源社区中常见的时间序列数据库，如Prometheus、VictoriaMetrics、Thanos，以及日志存储，如：ElasticSearch、Loki，以及常见的通知中间件，如：Slack、mm、Dingtalk、Wecom。Nightingale支持类似Kibana的查询探索，允许您通过关键字和过滤器过滤日志。

2.2、项目架构

上图中，中间的飞鸟代表夜莺的核心进程 n9e，对于 n9e 来说，它本身依赖的存储：Mysql和Redis，前者用于 存放配置类别信息，如用户，监控大盘，告警规则等；Redis用于存放访问令牌(JWT Token)，心跳信息，如：机器列表中CPU、内存、时间偏移、核数、操作系统、CPU架构等。左侧为 n9e 的数据源，n9e 可以支持多种采集器 （agent），默认使用Categraf，当然如上文所述，它支持常见的几乎所有采集器，比如我们这里计划保持使用Prometheus的Node-Exporter或其他exporter；另外对于日志可考虑接入Elasticsearch，链路追踪数据源Jaeger。
Nightingale的数据流大概如下：这里以时序指标数据的采集为例，agent 会把采集到的数据推送给 n9e （端口:17000），然后经由 n9e 加工（自动添加附加标签）转发给对应的时序数据库保存。另外在 n9e 把数据的转发给时序数据库之前，会先从监控数据中提取出 ident 标签写入 mysql 的 target 表（机器列表）中，同时如果 agent 用的是 Categraf 并且配置了心跳(heartbeat=true)，则会把心跳上报的 metadata 存入 Redis（就是目标主机的核数、操作系统、CPU架构等）。

如果想采用集群方式，只需要在多节点扩展n9e服务即可，或者多实例，集群中多个 n9e 实例会均分告警规则，分片处理，从而可以处理更大量的告警规则。官方建议在在 n9e 前面架设负载均衡，可以是 4/7 层的，让 agent 通过负载均衡上报监控数据，上层访问 n9e 也通过负载均衡，这样 n9e 任何一个实例挂掉，不会影响到整个服务可用性，从而做到高可用。关于采集器部署，如果目标网络与n9e服务侧良好的情况下，目标机器只需部署 Categraf，直连中心节点（n9e服务集群）即可，否则建议将告警引擎（n9e-alert：它是 n9e 的一个只保留告警引擎模块的独立可执行程序）和时序数据库一起下沉部署到目标主机上，考虑大多数情况下是内网场景，故后者这种干扰多的因素影响有限。如下图所示，从 v6.0.0.ga.9 开始，合并了 n9e-alert、n9e-pushgw 模块为 n9e-edge，因此必要情况下秩序部署一个n9e-edge组件即可，配置也简单，只需在 edge.toml 配置文件里，配置中心端 n9e 的地址即可。注意的是， 目标主机上n9e-edge 默认的引擎名字是 edge，与中心端 n9e 的引擎名字（default）便于区分。这就要求，目标网络域/机房的时序库在夜莺里添加数据源的时候，要选择该网络域对应的告警引擎（edge）。如果有多个时，注意它们之间的 n9e-edge 的引擎名字要不一样。如下图中的两个区域，官网推荐使用 Categraf + n9e-edge 的方式来采集数据，即region01 所示：当 Categraf 采集的数据上报给 n9e-edge 后，n9e-edge 就可以从监控数据中解析出机器信息，然后通过中心端的 n9e 写入数据库 target 表，这样就可以在页面上看到机器列表了。就可以使用机器分组，自定义标签，告警自愈之类的功能。

下图中仅使用夜莺作为告警引擎，这时Nightingale就类似 Grafana（Grafana 侧重看图，夜莺侧重告警），可以接入多种不同的数据源，比如 Prometheus、VictoriaMetrics、M3DB、ElasticSearch、Loki、TDEngine 等，在夜莺中配置管理告警规则，夜莺周期性去查询各个存储，判定异常数据，产生告警事件，然后把告警事件通过钉钉、企微、邮件等方式发出，或直接推给 FlashDuty，做告警聚合降噪之后再由 FlashDuty 做后续分发。这种架构中，Nightingale把各种监控数据源的告警规则集中管理，统一告警事件的分发，而监控数据的采集、传输，夜莺均无需介入。

本次监控系统构建计划采用： Prometheus + node_exporter+ + Grafana+Nightingale（n9e），必要时还可集成Netdata（Netdata是一个高效、高度模块化的度量管理引擎。它的无锁定设计使其非常适合对度量进行并发操作）；本例中，Nightingale仅用作为告警引擎用来统一管理告警、看图，莺类似 Grafana，是一个服务端组件，可以接入不同的数据源，之后只需要把 Prometheus 作为数据源配置与Nightingale对接即可，改善Prometheus 使用配置文件的告警规则管理方式的不方便，支持更为灵活的告警策略配置，比如控制生效时间、一套规则生效多个集群，它还支持告警自愈；夜Nightingale相比 Grafana（agpl 协议），它的看图能力稍差一些，前者图形为自研，和 Grafana 没法 100% 兼容，但夜莺支持导入 Grafana 的仪表盘 JSON，基础的图表都是兼容的。

如上图所示，Nightingale采用树状节点导航，又称之为对象树。这就便于对监控对象的分组管理机制，方便查找和查看监控对象，以及对监控对象设置监控策略等管理动作。另外有继承关系，当监控策略应用到某个节点后，该节点下的所有子节点挂载的所有的机器都会应用这个策略，任何一台机器触发相关阈值都会产生告警。

三、环境部署

部署方式：我们采用二进制方式

1、推荐二进制部署：稳，升级也方便
2、Docker compose 方式：一般仅用于简单测试，不推荐在生产环境使用 Docker compose，升级起来挺麻烦的，需要对 Docker compose 熟悉
3、Helm 方式：公司大规模使用了 Kubernetes，可以选择 Helm 方式；但监控系统作为 P0 级服务，最好是尽量少的依赖其他组件，故不推荐把夜莺服务端部署到 Kubernetes 中，因为 Kubernetes 一旦挂了监控就挂了。

3.1、资源需求

1）硬件环境

最小要求	推荐配置
1c 2G 40G	2g 4G 100G

2）软件环境

• 时序存储数据库：新环境选型建议使用 VictoriaMetrics，单机版 VictoriaMetrics 就可以抗住每秒上百万数据点，性能很好，CPU、内存的占用都比 Prometheus 少，而且，完全兼容 Prometheus 的查询接口；VictoriaMetrics 还有集群版本，对大部分公司，单机版就足够用了。但本次由于是兼容性优先，且监控量并不大，故还是采用Prometheus内置的TSDB作为时序数据库。
• 严格时间一致性：监控系统对时间很敏感，请各位先把机器时间校准一致，让服务端的机器、时序库的机器、要监控的目标机器、浏览器所在的 PC 时间，都保持一致。
• 基础存储：夜莺依赖 mysql 存储各类用户配置类数据，比如告警规则、屏蔽规则、仪表盘；依赖 redis 存储 jwt token 和机器心跳上报的 metadata，除此之外，没有别的依赖，需先准备好mysql和redis环境。如果是集群部署，则可在多个机器上的部署n9e ，这些进程读写同一个 MySQL 和 Redis；
• 数据采集：组合使用了各种 agent 和 exporter，比如 Datadog-Agent，Telegraf，Grafana-Agent，OpenTSDB agent，Node-Exporter，vmagent 都可以对接，不过最推荐的还是 Categraf；因Categraf 和夜莺的整合最为丝滑，夜莺内置的告警规则、仪表盘大都是针对 Categraf 定制的，n9e 中机器列表页面的心跳信息都是 Categraf 才会去采集并上报的，所以采集器选 Categraf为最佳推荐。
• 告警引擎：使用夜莺，内置了一些规则开箱即用，告警规则的配置比较灵活
• 看图可视化：使用 Grafana，图表更为炫酷，社区非常庞大

3.2、环境部署

1）基础依赖环境部署：mysql 5.7.44 +redis

#mysql部署：https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/；https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/binary-installation.html
#mysql YUM源
vim /etc/yum.repos.d/mysql-community.repo
[mysql57-community]
name=MySQL 5.7 Community Server
baseurl=http://repo.mysql.com/yum/mysql-5.7-community/el/7/$basearch/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql

yum install mysql-community-server -y
systemctl start mysqld.service
#或者二进制包解压缩运行也可
wget --no-check-certificate https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.35-linux-glibc2.28-x86_64.tar.gz  #MD5: 03396cdc844dba798e881224b09550f0
#或
tar -xf mysql-8.0.35-linux-glibc2.28-x86_64.tar.xz
#或
xz -dc  mysql-8.0.35-linux-glibc2.28-x86_64.tar.xz | tar x
mv mysql-8.0.35-linux-glibc2.28-x86_64 mysql-8.0.35
cd mysql-8.0.35/
#配置mysql环境变量
export PATH=/usr/local/project/mysql-8.0.35/bin:$PATH
mysql -V
#配置
useradd -r -g mysql -s /bin/false mysql
mkdir mysql-files
chown mysql:mysql mysql-files  #mysqlfiles目录提供了一个方便的位置，可以用作secure_file_priv系统变量的值，该变量将导入和导出操作限制在特定目录中
./bin/mysqld --user=mysql --basedir=/usr/local/project/mysql-8.0.35 --datadir=/usr/local/project/mysql-8.0.35/data --initialize  #数据库新安镇初始化
ls ./data/
 auto.cnf     client-cert.pem     '#ib_16384_1.dblwr'  '#innodb_redo'   mysql.ibd            public_key.pem    sys
 ca-key.pem   client-key.pem       ib_buffer_pool      '#innodb_temp'   performance_schema   server-cert.pem   undo_001
 ca.pem      '#ib_16384_0.dblwr'   ibdata1              mysql           private_key.pem      server-key.pem    undo_002   #初始化的临时密码在日志文件里
#查看密码
tail -10000 ./mysqld.log|grep " A temporary password"
bin/mysqld_safe --user=mysql &  #命令启动，https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysqld-safe.html
#重置密码
mysql> ALTER USER 'root'@'localhost' IDENTIFIED WITH MYSQL_NATIVE_PASSWORD BY 'Pro#1210GT';

#配置自启动服务
vim /lib/systemd/system/mysqld.service
[Unit]
Description=MySQL - automatically !
After=mysqld.service start success !

[Service]
Type=forking
ExecStart=/usr/bin/bash service mysqld start
ExecReload=/usr/bin/bash service mysqld restart
ExecStop=/usr/bin/bash service mysqld stop
PrivateTmp=true

[Install]
WantedBy=multi-user.target

#或
cp -pr ./support-files/mysql.server /etc/init.d/mysqld
chkconfig --add mysqld
systemctl enable mysqld  #输出
mysqld.service is not a native service, redirecting to systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable mysqld

systemctl daemon-reload
#或简单安装
yum -y install mariadb*
systemctl enable mariadb
systemctl restart mariadb
#mysql启动报错：
[ERROR] [MY-011011] [Server] Failed to find valid data directory.
[ERROR] [MY-010020] [Server