从0到1玩转夜莺监控：这篇实战指南我写了三天，建议收藏！

说起监控系统，你脑子里第一个蹦出来的是啥？Zabbix？Prometheus？Grafana？还是云厂商自带的那一套？

说实话，这些年我用过不少监控工具，直到去年在一家公司接手了一个全新的运维项目，需要重新搭建监控体系。当时评估了一大圈，最后选择了夜莺（Nightingale）。用了一年半，体验是真的香，所以今天想把踩过的坑、填过的坑，一股脑儿全倒出来，给正在选型或者刚开始用夜莺的朋友一点参考。

这玩意儿到底是个啥？

文档地址：https://n9e.github.io/zh/docs/prologue/introduction/

夜莺监控，听名字挺文艺，其实是个硬核的云原生监控分析工具。它的核心理念是"All-in-One"，啥意思呢？就是把数据采集、可视化、监控告警、数据分析这些事儿全给你包圆了，不用东拼西凑。

说起它的出身还挺有来头。最早是滴滴公司开发并开源的，2022年5月11日，滴滴把它捐赠给了中国计算机学会开源发展委员会（CCF ODC），成了CCF ODC成立后接受的第一个开源项目 [3]。研发团队都是Open-Falcon那帮老炮儿，所以在告警引擎这块的功底，你完全可以放心。

那它跟Grafana+Zabbix这套组合拳有啥区别？我个人用下来的感受是：Grafana强在可视化，夜莺强在告警。Grafana的图表是真的漂亮，但告警这块说实话做得一般。夜莺的告警引擎是它的看家本领，规则配置灵活、事件管道处理、告警自愈、20多种通知媒介（电话、短信、邮件、钉钉、飞书、企业微信这些都内置了），用起来是真的顺手 [3]。

而且夜莺的定位很有意思——它可以做两件事：

第一种用法：你已经有Prometheus+各类Exporter的监控体系了，那直接把Prometheus作为数据源接入夜莺，夜莺就只管告警这件事，可视化你继续用Grafana。

第二种用法：用夜莺自带的Categraf采集器采集数据，然后夜莺作为数据转发网关，把数据写入后端时序库（Prometheus、VictoriaMetrics等），同时承担告警和可视化的角色。

我们今天主要讲第二种用法，从零开始搭建一套完整的夜莺监控体系。

架构这块儿，先整明白

在动手部署之前，必须得把架构搞清楚，不然部署到一半你会懵。

夜莺的核心进程叫n9e，这个名字来源于夜莺的英文Nightingale的前两位字母 [1]。n9e本身依赖两个存储：

MySQL：存放用户、监控大盘、告警规则这类配置信息
Redis：存放JWT Token、心跳信息（机器的CPU、内存、时间偏移、核数、操作系统、CPU架构这些）

从v6版本开始，夜莺转型成了统一可观测性平台，不再只支持时序数据源，ES、Loki、Jaeger这些也都能接入了 [1]。

部署架构上有两种典型场景：

场景一：中心机房架构（适合单机房或者多机房专线稳定的公司）

n9e部署在中心机房
所有机器的Categraf直接上报数据给中心n9e
n9e把数据转发给后端时序库（Prometheus或VictoriaMetrics）
部署多个n9e实例，前面挂Nginx做负载均衡即可实现高可用

场景二：边缘下沉式混杂架构（适合多机房、网络链路不好的公司）

中心机房部署n9e
边缘机房部署n9e-edge
n9e-edge不依赖MySQL、Redis，只依赖中心端的n9e
Categraf在边缘机房把数据上报给n9e-edge
n9e-edge再把数据写入边缘机房的时序库
中心n9e通过配置数据源的方式去查询边缘机房的时序库

我当时公司的情况是中心机房在南京，边缘机房在香港，之间网络时不时抽风，所以两种架构都用上了。下面我会分别讲讲怎么部署。

环境准备

我这次用的是Rocky Linux 8.5，大家用CentOS 7或者Ubuntu 20.04也都没问题，差别不大。

服务	版本	说明
n9e	6.7.2	夜莺服务端
Categraf	0.3.45	夜莺客户端
MySQL	5.7.36	存储配置信息
Redis	6.2.6	缓存和心跳
Prometheus	2.37.0	时序数据库

这里有个坑要提一下，官方其实更推荐VictoriaMetrics作为时序库，性能确实比Prometheus好不少，单机版就能扛住每秒上百万数据点 [2]。但考虑到我们公司已经有一套Prometheus体系了，为了节省成本就直接用了Prometheus。如果你是新环境，强烈建议直接上VictoriaMetrics。

中心机房架构部署实战

MySQL和Redis先跑起来

这两个我直接用Docker部署了，方便快捷。MySQL和Redis的具体部署过程我就不展开了，网上教程一大堆。重点是要建好库和授权。

部署完成后，导入夜莺的初始化SQL：

mysql -h 10.206.0.17 -u root -p'YourPassword' < /data/n9e/n9e.sql

然后创建监控用户并授权：

CREATE USER 'nightingale'@'%' IDENTIFIED BY 'YourStrongPassword';
GRANT ALL PRIVILEGES ON n9e_v6.* TO 'nightingale'@'%';

Prometheus的坑你必须知道

Prometheus的部署本身不难，但有个参数不注意会让人怀疑人生——--enable-feature=remote-write-receiver [1]。

不加上这个参数启动Prometheus的话，夜莺往Prometheus写数据的时候会疯狂报404，原因是Prometheus默认没开启/api/v1/write接口的监听。我当时就是没加这个参数，排错排了半个小时才反应过来，气得我想把键盘摔了。

下载Prometheus：

wget https://github.com/prometheus/prometheus/releases/download/v2.45.2/prometheus-2.45.2.linux-amd64.tar.gz
tar xf prometheus-2.45.2.linux-amd64.tar.gz -C /data/

配置systemd管理：

cat <<EOF >/etc/systemd/system/prometheus.service
[Unit]
Description="prometheus"
Documentation=https://prometheus.io/
After=network.target

[Service]
Type=simple
ExecStart=/data/prometheus-2.45.2.linux-amd64/prometheus \
  --config.file=/data/prometheus-2.45.2.linux-amd64/prometheus.yml \
  --storage.tsdb.path=/data/prometheus-2.45.2.linux-amd64/data \
  --web.enable-lifecycle \
  --enable-feature=remote-write-receiver \
  --query.lookback-delta=2m

Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=prometheus

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable prometheus
systemctl restart prometheus

注意这里有个--web.enable-lifecycle参数，是为了支持热加载配置用的。--query.lookback-delta=2m则是查询时向前看的时间窗口，太小会查不到数据。

访问http://yourIP:9090/能看到Prometheus的Web界面就说明启动成功了。

部署夜莺核心n9e

n9e建议用二进制方式部署，systemd托管，后面升级维护也方便 [2]。Docker compose方式虽然简单，但社区里很多坑其实都是对Docker compose不熟导致的。Helm方式适合大规模K8s环境，但官方其实不太建议把夜莺服务端部署到K8s里——K8s挂了监控就挂了，监控系统作为P0级服务，依赖其他组件越少越好 [2]。

下载安装包（去flashcat.cloud/download/nightingale/找最新版本）：

mkdir /data/n9e
tar xzf n9e-v6.7.2-linux-amd64.tar.gz -C /data/n9e/

修改配置文件，主要是DB部分：

cp etc/config.toml etc/config.toml.bak
vim etc/config.toml

找到[DB]部分，配置MySQL连接信息。然后找到[Pushgw.Writers]，配置时序库的地址：

[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]]
Url = "http://127.0.0.1:9090/api/v1/write"

这个配置的意思是：夜莺接收到Categraf上报的监控数据后，会转发给这个URL。如果你想把数据写入多个时序库，配置多个[[Pushgw.Writers]]就行。

配置systemd：

cat <<EOF >/etc/systemd/system/n9e.service
[Unit]
Description="n9e.service"
After=network.target

[Service]
Type=simple
ExecStart=/data/n9e/n9e
WorkingDirectory=/data/n9e
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=n9e.service
[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl start n9e.service
systemctl enable n9e.service

n9e默认监听17000端口，启动成功后netstat -lntp | grep 17000应该能看到。

还有一点很重要：安装完成后一定要改默认密码！默认账号是root，密码是root.2020 [2]。我看到有公开数据显示，网上有上千个夜莺的公网站点，很多都没改默认密码，这不是明摆着让人白嫖吗？另外config.toml里的SigningKey也建议改成随机字符串，用来加密JWT token。

部署采集器Categraf

夜莺本身不负责数据采集，这事儿得交给agent。官方推荐的是Categraf，当然用telegraf、grafana-agent这些也都能对接 [1]。

Categraf的安装包可以从GitHub的flashcatcloud/categraf仓库下载：

tar xzf categraf-v0.3.45-linux-amd64.tar.gz -C /data/

修改主配置conf/config.toml：

[global]
hostname = ""

[n9e]
url = "http://10.206.0.17:17000"  # n9e服务端地址

[heartbeat]
enable = true
url = "http://10.206.0.17:17000/v1/n9e/heartbeat"

Categraf的目录结构是这样的 [1]：

conf/
├── config.toml        # 主配置
├── logs.toml          # logs-agent配置
├── prometheus.toml    # prometheus agent配置
├── traces.yaml        # trace-agent配置
└── input.*/           # 各种采集插件的配置目录

Categraf的精妙之处在于它"约定优于配置"的设计——以input.开头的目录就是各种采集插件的目录，运行时自动加载。如果某个采集器不想用，把input.xx改成bak.input.xx就行，Categraf会自动忽略 [1]。

基本采集项（CPU、内存、磁盘、磁盘IO、网络）默认就启用了，不用我们额外配置。

systemd管理Categraf：

cat <<EOF >/etc/systemd/system/categraf.service
[Unit]
Description="categraf.service"
After=network.target

[Service]
Type=simple
ExecStart=/data/categraf-v0.3.45-linux-amd64/categraf
WorkingDirectory=/data/categraf-v0.3.45-linux-amd64
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=categraf.service
[Install]
WantedBy=multi-user.target
EOF

登录夜莺，第一眼该看啥

服务都起来后，浏览器打开http://yourIP:17000，用默认账号root/root.2020登录。注意，登录后第一件事就是改密码！

登录进去后你会发现，主机列表是空的——别慌，因为虽然Categraf已经在上报数据了，但主机还没有归组 [1]。

这里就得理解夜莺的"业务组"概念了。业务组可以理解为资源的逻辑分组，比如你可以创建"web业务组"、"db业务组"、"中间件业务组"，然后把对应的主机放进去。不同业务组的用户只能看到自己业务组内的资源，权限隔离做得挺细。

操作流程是这样的：

创建用户：在系统管理-用户管理里创建用户
创建团队：在权限管理-团队管理里创建团队，团队命名有讲究，像rab-dev这种带横线的写法是有层级关系的（rab是父团队，dev是子团队）
创建业务组：在业务组管理里创建业务组
把主机归到业务组：在主机列表里勾选主机，分配业务组
把团队绑定到业务组：这样团队成员就能看到业务组内的主机了

这套权限体系设计得挺合理，比直接给用户授权机器要灵活得多。

配置数据源，让告警能跑起来

到这里监控数据已经在采集了，但夜莺默认情况下还不知道Prometheus在哪。要让告警引擎能从时序库查询数据，需要配置数据源 [1]。

操作路径：集成中心-数据源管理-新增数据源，类型选择Prometheus，URL填http://127.0.0.1:9090，测试通过后保存。

配置完成后，告警规则才能查询到对应的指标数据。

边缘机房部署：跨地域监控的救星

说到这里就得提一下我们公司当时的情况了——南京中心机房和香港边缘机房之间网络时不时抽风。如果所有Categraf都直接上报到南京的n9e，香港那边网络一抖，数据就丢了，告警也漏了。

边缘下沉式架构就是为了解决这个问题的。核心思想是：把时序库下沉部署到边缘机房，避免大量时序数据传输到中心机房带来的网络压力 [1]。

n9e-edge的配置要点

n9e-edge的安装包其实和n9e是同一个，解压后里面有n9e-edge这个二进制文件 [1]。

mkdir -p /data/n9e-edge
tar xzf n9e-v6.7.2-linux-amd64.tar.gz -C /data/n9e-edge/

修改/data/n9e-edge/etc/edge/edge.toml，关键是配置中心端n9e的地址：

[CenterApi]
Addrs = ["http://119.45.140.59:17000"]
BasicAuthUser = "user001"
BasicAuthPass = "ccc26da7b9aba533cbb263a36c07dcc5"
Timeout = 9000

BasicAuthUser和BasicAuthPass对应的是中心端n9e的[HTTP.APIForService.BasicAuth]配置段 [1]。

n9e-edge不依赖MySQL和Redis，只依赖中心端的n9e，所以即使边缘机房和中心机房的网络断了，边缘机房的告警功能还是能正常运转——这个特性在生产环境中是救命级别的。

边缘Categraf的配置区别

边缘机房的Categraf配置和中心机房有两个不同点 [1]：

数据上报地址改为n9e-edge的地址（默认端口19000）
心跳URL要改成/v1/n9e/edge/heartbeat，不能写/v1/n9e/heartbeat

[n9e]
url = "http://172.xx.xx.15:19000"

[heartbeat]
enable = true
url = "http://172.xx.xx.15:19000/v1/n9e/edge/heartbeat"

引擎名的坑

n9e-edge默认的引擎名叫edge，中心端n9e的引擎名叫default，两个要区分开 [1]。

如果你有多个边缘机房，每个边缘机房的n9e-edge的引擎名要不一样，不然会冲突。修改方法：

[Alert.Heartbeat]
IP = ""
Interval = 1000
EngineName = "edge-hk"  # 改成你自己的引擎名

中心n9e添加边缘数据源

在中心n9e的集成中心里，添加边缘机房的Prometheus作为数据源，选择告警引擎的时候要选对应边缘机房的引擎名（比如edge-hk），不能选default [1]。

到这里边缘机房的数据就接入完成了，中心n9e可以直接查询边缘机房的时序库，告警规则也能正常触发。

高可用怎么做？

监控系统要是挂了，那就跟没监控一样糟糕。n9e的高可用其实很简单——多部署几个实例，前面挂Nginx或者LVS做负载均衡就行 [1]。

边缘的n9e-edge同理，同一个edge集群的edge.toml里EngineName要一样，前面搞个负载均衡给agent上报数据用，高可用就完成了。

几个我踩过的坑

时间不同步：社区反馈的很多问题都是机器时间没校准导致的，监控系统对时间很敏感，服务端、时序库、被监控目标、浏览器所在机器的时间都要保持一致 [2]。我曾经因为一台机器时间快了5分钟，看不到监控数据，排错排了一晚上。
Prometheus忘加参数：--enable-feature=remote-write-receiver这个参数一定要加上，不然数据写不进去。
业务组权限：建好用户和团队后一定要把团队关联到业务组，不然用户看不到主机。
公网暴露：夜莺千万别暴露在公网上，特别是没改默认密码的情况下 [2]。
K8s部署需谨慎：不推荐把夜莺服务端部署到K8s里，K8s挂了监控就挂了 [2]。

写在最后

写到这里差不多4000字了，从夜莺是什么、怎么部署、怎么用、踩过哪些坑，都过了一遍。夜莺这套体系用起来是真的省心，特别是告警引擎这一块，比我用过的其他监控工具都要顺手。

当然，工具好不好用，最终还是看适不适合你的业务场景。如果你只是在用云厂商的监控，夜莺可能不是必需品；如果你要自建监控体系，又希望告警能力强大、配置灵活，夜莺是个不错的选择。

如果你觉得这篇文章对你有帮助，欢迎点赞、在看、转发三连，让更多运维兄弟看到！有任何问题欢迎评论区留言交流～

关注公众号：耕云躬行录，获取更多运维实战经验分享！

个人博客：躬行笔记

我们下期见！👋