从0到1玩转夜莺监控说起监控系统你脑子里第一个蹦出来的是啥ZabbixPrometheusGrafana还是云厂商自带的那一套说实话这些年我用过不少监控工具直到去年在一家公司接手了一个全新的运维项目需要重新搭建监控体系。当时评估了一大圈最后选择了夜莺Nightingale。用了一年半体验是真的香所以今天想把踩过的坑、填过的坑一股脑儿全倒出来给正在选型或者刚开始用夜莺的朋友一点参考。这玩意儿到底是个啥文档地址https://n9e.github.io/zh/docs/prologue/introduction/夜莺监控听名字挺文艺其实是个硬核的云原生监控分析工具。它的核心理念是All-in-One啥意思呢就是把数据采集、可视化、监控告警、数据分析这些事儿全给你包圆了不用东拼西凑。说起它的出身还挺有来头。最早是滴滴公司开发并开源的2022年5月11日滴滴把它捐赠给了中国计算机学会开源发展委员会CCF ODC成了CCF ODC成立后接受的第一个开源项目 [3]。研发团队都是Open-Falcon那帮老炮儿所以在告警引擎这块的功底你完全可以放心。那它跟GrafanaZabbix这套组合拳有啥区别我个人用下来的感受是Grafana强在可视化夜莺强在告警。Grafana的图表是真的漂亮但告警这块说实话做得一般。夜莺的告警引擎是它的看家本领规则配置灵活、事件管道处理、告警自愈、20多种通知媒介电话、短信、邮件、钉钉、飞书、企业微信这些都内置了用起来是真的顺手 [3]。而且夜莺的定位很有意思——它可以做两件事第一种用法你已经有Prometheus各类Exporter的监控体系了那直接把Prometheus作为数据源接入夜莺夜莺就只管告警这件事可视化你继续用Grafana。第二种用法用夜莺自带的Categraf采集器采集数据然后夜莺作为数据转发网关把数据写入后端时序库Prometheus、VictoriaMetrics等同时承担告警和可视化的角色。我们今天主要讲第二种用法从零开始搭建一套完整的夜莺监控体系。架构这块儿先整明白image-20260714205732798image-20260714205747507在动手部署之前必须得把架构搞清楚不然部署到一半你会懵。夜莺的核心进程叫n9e这个名字来源于夜莺的英文Nightingale的前两位字母 [1]。n9e本身依赖两个存储MySQL存放用户、监控大盘、告警规则这类配置信息Redis存放JWT Token、心跳信息机器的CPU、内存、时间偏移、核数、操作系统、CPU架构这些从v6版本开始夜莺转型成了统一可观测性平台不再只支持时序数据源ES、Loki、Jaeger这些也都能接入了 [1]。部署架构上有两种典型场景场景一中心机房架构适合单机房或者多机房专线稳定的公司n9e部署在中心机房所有机器的Categraf直接上报数据给中心n9en9e把数据转发给后端时序库Prometheus或VictoriaMetrics部署多个n9e实例前面挂Nginx做负载均衡即可实现高可用场景二边缘下沉式混杂架构适合多机房、网络链路不好的公司中心机房部署n9e边缘机房部署n9e-edgen9e-edge不依赖MySQL、Redis只依赖中心端的n9eCategraf在边缘机房把数据上报给n9e-edgen9e-edge再把数据写入边缘机房的时序库中心n9e通过配置数据源的方式去查询边缘机房的时序库我当时公司的情况是中心机房在南京边缘机房在香港之间网络时不时抽风所以两种架构都用上了。下面我会分别讲讲怎么部署。环境准备我这次用的是Rocky Linux 8.5大家用CentOS 7或者Ubuntu 20.04也都没问题差别不大。服务版本说明n9e6.7.2夜莺服务端Categraf0.3.45夜莺客户端MySQL5.7.36存储配置信息Redis6.2.6缓存和心跳Prometheus2.37.0时序数据库这里有个坑要提一下官方其实更推荐VictoriaMetrics作为时序库性能确实比Prometheus好不少单机版就能扛住每秒上百万数据点 [2]。但考虑到我们公司已经有一套Prometheus体系了为了节省成本就直接用了Prometheus。如果你是新环境强烈建议直接上VictoriaMetrics。中心机房架构部署实战MySQL和Redis先跑起来这两个我直接用Docker部署了方便快捷。MySQL和Redis的具体部署过程我就不展开了网上教程一大堆。重点是要建好库和授权。部署完成后导入夜莺的初始化SQLmysql -h 10.206.0.17 -u root -pYourPassword /data/n9e/n9e.sql然后创建监控用户并授权CREATE USER nightingale% IDENTIFIED BY YourStrongPassword;GRANT ALL PRIVILEGES ON n9e_v6.* TO nightingale%;Prometheus的坑你必须知道Prometheus的部署本身不难但有个参数不注意会让人怀疑人生——--enable-featureremote-write-receiver[1]。不加上这个参数启动Prometheus的话夜莺往Prometheus写数据的时候会疯狂报404原因是Prometheus默认没开启/api/v1/write接口的监听。我当时就是没加这个参数排错排了半个小时才反应过来气得我想把键盘摔了。下载Prometheuswget https://github.com/prometheus/prometheus/releases/download/v2.45.2/prometheus-2.45.2.linux-amd64.tar.gztar xf prometheus-2.45.2.linux-amd64.tar.gz -C /data/配置systemd管理cat EOF /etc/systemd/system/prometheus.service[Unit]DescriptionprometheusDocumentationhttps://prometheus.io/Afternetwork.target[Service]TypesimpleExecStart/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-featureremote-write-receiver \ --query.lookback-delta2mRestarton-failureSuccessExitStatus0LimitNOFILE65536StandardOutputsyslogStandardErrorsyslogSyslogIdentifierprometheus[Install]WantedBymulti-user.targetEOFsystemctl daemon-reloadsystemctl enable prometheussystemctl restart prometheus注意这里有个--web.enable-lifecycle参数是为了支持热加载配置用的。--query.lookback-delta2m则是查询时向前看的时间窗口太小会查不到数据。访问http://yourIP:9090/能看到Prometheus的Web界面就说明启动成功了。部署夜莺核心n9en9e建议用二进制方式部署systemd托管后面升级维护也方便 [2]。Docker compose方式虽然简单但社区里很多坑其实都是对Docker compose不熟导致的。Helm方式适合大规模K8s环境但官方其实不太建议把夜莺服务端部署到K8s里——K8s挂了监控就挂了监控系统作为P0级服务依赖其他组件越少越好 [2]。下载安装包去flashcat.cloud/download/nightingale/找最新版本mkdir /data/n9etar xzf n9e-v6.7.2-linux-amd64.tar.gz -C /data/n9e/修改配置文件主要是DB部分cp etc/config.toml etc/config.toml.bakvim 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]]就行。配置systemdcat EOF /etc/systemd/system/n9e.service[Unit]Descriptionn9e.serviceAfternetwork.target[Service]TypesimpleExecStart/data/n9e/n9eWorkingDirectory/data/n9eRestarton-failureSuccessExitStatus0LimitNOFILE65536StandardOutputsyslogStandardErrorsyslogSyslogIdentifiern9e.service[Install]WantedBymulti-user.targetEOFsystemctl daemon-reloadsystemctl start n9e.servicesystemctl enable n9e.serviceimage-20260714210722432n9e默认监听17000端口启动成功后netstat -lntp | grep 17000应该能看到。image-20260714210835426还有一点很重要安装完成后一定要改默认密码默认账号是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 trueurl http://10.206.0.17:17000/v1/n9e/heartbeatCategraf的目录结构是这样的 [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管理Categrafcat EOF /etc/systemd/system/categraf.service[Unit]Descriptioncategraf.serviceAfternetwork.target[Service]TypesimpleExecStart/data/categraf-v0.3.45-linux-amd64/categrafWorkingDirectory/data/categraf-v0.3.45-linux-amd64Restarton-failureSuccessExitStatus0LimitNOFILE65536StandardOutputsyslogStandardErrorsyslogSyslogIdentifiercategraf.service[Install]WantedBymulti-user.targetEOFimage-20260714231048930登录夜莺第一眼该看啥image-20260714234437635服务都起来后浏览器打开http://yourIP:17000用默认账号root/root.2020登录。注意登录后第一件事就是改密码登录进去后你会发现主机列表是空的——别慌因为虽然Categraf已经在上报数据了但主机还没有归组 [1]。这里就得理解夜莺的业务组概念了。业务组可以理解为资源的逻辑分组比如你可以创建web业务组、“db业务组”、“中间件业务组”然后把对应的主机放进去。不同业务组的用户只能看到自己业务组内的资源权限隔离做得挺细。操作流程是这样的创建用户在系统管理-用户管理里创建用户创建团队在权限管理-团队管理里创建团队团队命名有讲究像rab-dev这种带横线的写法是有层级关系的rab是父团队dev是子团队创建业务组在业务组管理里创建业务组把主机归到业务组在主机列表里勾选主机分配业务组把团队绑定到业务组这样团队成员就能看到业务组内的主机了这套权限体系设计得挺合理比直接给用户授权机器要灵活得多。配置数据源让告警能跑起来到这里监控数据已经在采集了但夜莺默认情况下还不知道Prometheus在哪。要让告警引擎能从时序库查询数据需要配置数据源 [1]。操作路径集成中心-数据源管理-新增数据源类型选择PrometheusURL填http://127.0.0.1:9090测试通过后保存。配置完成后告警规则才能查询到对应的指标数据。边缘机房部署跨地域监控的救星说到这里就得提一下我们公司当时的情况了——南京中心机房和香港边缘机房之间网络时不时抽风。如果所有Categraf都直接上报到南京的n9e香港那边网络一抖数据就丢了告警也漏了。边缘下沉式架构就是为了解决这个问题的。核心思想是把时序库下沉部署到边缘机房避免大量时序数据传输到中心机房带来的网络压力 [1]。n9e-edge的配置要点n9e-edge的安装包其实和n9e是同一个解压后里面有n9e-edge这个二进制文件 [1]。mkdir -p /data/n9e-edgetar 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 user001BasicAuthPass ccc26da7b9aba533cbb263a36c07dcc5Timeout 9000BasicAuthUser和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 trueurl http://172.xx.xx.15:19000/v1/n9e/edge/heartbeat引擎名的坑n9e-edge默认的引擎名叫edge中心端n9e的引擎名叫default两个要区分开 [1]。如果你有多个边缘机房每个边缘机房的n9e-edge的引擎名要不一样不然会冲突。修改方法[Alert.Heartbeat]IP Interval 1000EngineName 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-featureremote-write-receiver这个参数一定要加上不然数据写不进去。业务组权限建好用户和团队后一定要把团队关联到业务组不然用户看不到主机。公网暴露夜莺千万别暴露在公网上特别是没改默认密码的情况下 [2]。K8s部署需谨慎不推荐把夜莺服务端部署到K8s里K8s挂了监控就挂了 [2]。写在最后写到这里差不多4000字了从夜莺是什么、怎么部署、怎么用、踩过哪些坑都过了一遍。夜莺这套体系用起来是真的省心特别是告警引擎这一块比我用过的其他监控工具都要顺手。当然工具好不好用最终还是看适不适合你的业务场景。如果你只是在用云厂商的监控夜莺可能不是必需品如果你要自建监控体系又希望告警能力强大、配置灵活夜莺是个不错的选择。