夜莺这个项目我从 v5 一直用到 v6中间经历过不少部署完、页面能打开、但就是没数据的阶段。很多人下载完夜莺监控系统安装部署包看到登录页、看到默认面板就以为已经搞定了其实真正的工作才刚刚开始。这篇服务器监控软件夜莺使用二不打算重复讲安装包怎么解压、服务怎么启动而是聚焦在一个更实际的问题部署完成之后怎么把一台真实的服务器接进夜莺让它的 CPU、内存、磁盘、端口、进程都变成可观测的数据再让这些数据在异常时主动通知你。不管你是刚装完夜莺正在对着空面板发呆还是已经接了几台机器准备做告警策略这篇内容应该都能给你一些能直接照做的经验。1. 先搞清楚夜莺部署完成之后到底有哪些东西在跑很多文章会把安装过程写得特别简单比如一条命令启动所有组件。这没毛病但如果你不知道后台有哪些组件后面遇到问题会非常被动。夜莺监控系统安装部署完成之后实际是一个小的组件集群而不是单个进程。1.1 组件全景每个进程是干什么的以最常见的 Docker Compose 或二进制方式部署为例一个完整的夜莺环境里通常会有这么几类角色组件作用类比n9e-server夜莺核心服务端处理告警规则、通知、权限、API大脑 调度中心nginx前端静态资源、反向代理门卫MySQL / MariaDB存储用户、告警规则、屏蔽策略、审计日志档案室Redis缓存、告警去重、集群信息便签本Prometheus / VictoriaMetrics时序数据库存监控指标数据仓库带时间轴categraf / telegraf部署在被监控机上的采集器情报员其中最容易被人忽略的是时序数据库。夜莺本身不是一个完整的时序存储方案它默认对接 Prometheus 或 VictoriaMetrics负责接收采集器上报的指标并存储。也就是说哪怕你夜莺的 Web 界面开着数据库和 Redis 都正常一旦时序库没配好页面上照样什么都看不到。1.2 你的场景适合用哪个时序库新版本夜莺支持多种时序库实际部署中最常见的是 Prometheus 和 VictoriaMetrics 两种。我个人的建议是单机监控数量在几百台以内用内置的 Prometheus 就够了机器数量多、写入量大的场景优先上 VictoriaMetrics因为它的磁盘占用和查询性能都要好不少。补充一个细节如果你用的是【夜莺监控官网】提供的一键部署脚本它默认拉起的时序库多半是 Prometheus。生产环境里我更倾向于单独部署 VictoriaMetrics然后修改 n9e-server 配置文件中时序库相关地址。原因很简单——Prometheus 的本地存储是单机的数据目录一旦损坏恢复起来非常麻烦而 VictoriaMetrics 在这方面容错性好很多。1.3 数据流转一条指标是怎么从服务器走到页面上的理解数据流是排查一切没数据问题的基础用文字描述一下完整链路categraf 在被监控机上采集 CPU 使用率、内存、磁盘等指标。categraf 通过 remote write 协议把指标 POST 到 n9e-server 的/prometheus/v1/write接口或者是直接写到时序库。n9e-server 做一层写入转发把数据落到 Prometheus / VictoriaMetrics。前端页面查询数据时调 n9e-server 的查询接口n9e-server 再去时序库拉数据。告警引擎周期性读取告警规则从时序库查询指标数据判断是否触发告警。这套链路里任何一环断了表象都是页面看不到数据或者告警不响。所以后面所有问题排查基本都围绕这条链路逐段检查。2. 第一批服务器接入categraf 采集器配置实测夜莺的官方采集器是 categraf它前身是 Telegraf 的一个分支但针对夜莺做了大量优化。第一次用的时候不要贪多先把一台机器完整接进来确认数据通路是通的再批量铺开。2.1 下载安装 categraf 的正确姿势categraf 通过二进制单文件运行不依赖 Java 之类的运行时环境。去官方 GitHub Releases 页面下载对应架构的压缩包即可。服务器是 amd64 就用categraf-vx.x.x-linux-amd64.tar.gzARM 架构的服务器不要下错否则会直接提示exec format error。下载完解压之后目录结构大概是这样的categraf/ ├── categraf # 主程序 ├── conf/ │ ├── config.toml # 全局配置 │ └── input.*/ # 各种采集插件的配置目录 └── README.md先看conf/config.toml最核心的几个配置项如下[global] hostname # 留空会自动取机器 hostname建议显式写成有意义的名称 omit_hostname false [writer_opt] batch 2000 chan_size 10000 [[writers]] url http://192.168.1.10:17000/prometheus/v1/write # 夜莺服务端写入接口 basic_auth_user basic_auth_pass 这里面[[writers]]的 url 是最重要的必须指向夜莺服务端的写入地址。很多人以为要直接写时序库的地址其实不对应该写 n9e-server 的 HTTP 端口默认 17000下的/prometheus/v1/write。写错地址之后categraf 日志里会频繁报错但页面没有任何提示容易让人一头雾水。2.2 启动并验证数据是否上报在 categraf 目录下直接执行./categraf --test这个命令会检查配置语法并尝试连接写入端。没问题的话再用 systemd 方式管理/etc/systemd/system/categraf.service内容参考[Unit] Descriptioncategraf Afternetwork.target [Service] WorkingDirectory/opt/categraf ExecStart/opt/categraf/categraf Restartalways RestartSec10 [Install] WantedBymulti-user.target启动之后去夜莺的机器列表页面看有没有多出一台主机。如果机器列表里出现了新主机说明心跳和标签上报已经通了。如果机器列表没出现但指标页有数据往往是 categraf 的 hostname 和ident配置不一致导致的后面会细说。2.3 默认采集了哪些指标刚启动的 categraf 会默认启用一批系统采集插件包括 cpu、mem、disk、net、kernel、system 等。这些指标覆盖了最初级的服务器监控需求可以先把这些数据看明白再去扩展额外插件。我一般在生产环境里会调整几个插件的配置避免无效指标太多conf/input.system/下可以关闭负载均值的部分采集项云服务器上/proc/loadavg的负载含义和在物理机上不一样容易误判。conf/input.disk/默认会有mount_points和fs_types过滤建议把临时文件系统如tmpfs、overlay排除不然磁盘分区列表会被一堆 Docker overlay 目录刷屏。conf/input.net/建议打开interfaces [eth0, ens33]白名单避免统计到docker0、veth*这类虚拟网卡。这些配置改完之后记得重启 categrafsystemctl restart categraf数据会在下一轮采集周期生效默认采集间隔是 15 秒等一下就能在夜莺页面看到。2.4 自定义监控端口和进程服务器监控不可能永远只看系统指标MySQL、Redis、Nginx 这些中间件和自定义进程才是业务血条。categraf 里提供了丰富的采集插件比如redis、mysql、nginx但很多场景下你只是想确认端口还活着或者进程还在不在不需要拉一堆中间件指标。这时候有两个轻量做法第一种在conf/input.net_response/里配置 TCP 端口探测[[instances]] targets [ 127.0.0.1:3306, 127.0.0.1:6379, ] protocol tcp timeout 1s第二种在conf/input.procstat/里按进程名匹配[[instances]] search mysqld pattern mysqld这种方式会在每台机器上产生procstat_lookup和进程存活相关指标告警规则直接针对这些指标写即可。它比单纯端口探测更可靠因为有些服务端口虽然还在监听但进程已经处于半死状态了。3. 告警规则配置从能收到到收得准接入数据只是第一步夜莺真正值钱的是告警引擎。这个引擎的灵活度非常高但灵活也是有代价的就是初学时容易搞混规则、指标、通知三者之间的关系。3.1 告警规则在夜莺里的模型夜莺的告警体系涉及几个核心概念数据源告警规则去哪个时序库查数据默认是你配置的那个 Prometheus/VictoriaMetrics。告警规则定义 PromQL 查询语句、持续时长、告警级别、通知模板。通知媒介内置支持邮件、钉钉、企业微信、Webhook 等。告警屏蔽在维护窗口内不触发告警比如凌晨发布变更时可以提前屏蔽。这个模型和大部分监控系统类似区别在于夜莺的规则可以做到非常细可以一条规则批量匹配所有机器也可以精确到某台机器的某个指标。它用的是 PromQL 来写查询条件所以不懂 PromQL 的人上手会有一点门槛。3.2 一个完整的 MySQL 端口监控告警案例假设你要监控一批 MySQL 服务器的 3306 端口同时想把端口挂了这件事立刻通知到钉钉群。操作步骤如下先在【告警管理】-【告警规则】里新建一条规则规则名称MySQL端口探测失败查询语句PromQLnet_response_response_code{port3306} ! 0实际上 categraf 的 net_response 插件在探测失败时net_response_response_code会等于 1 或者直接缺省。更稳妥的写法是判断net_response_result_code 1或者用up语义的指标具体要看上报的字段名。持续时长建议 30 秒避免端口单次抖动就报警。告警级别P1紧急或 P2重要按业务对 MySQL 的依赖程度来定。通知媒介选择钉钉 Webhook配置好加签密钥。这里要专门提醒一个新手容易犯的错误不要用 0来判断端口存活。因为当采集器自己挂了、网络不通的时候指标会直接消失 0的表达式结果会变成无数据夜莺默认不会因为无数据触发告警于是机器彻底挂了反而没反应。更好的方式是采用对端不可达才算故障的表达式比如net_response_result_code 1这条条件下端口能连上时返回 0连不上时返回 1指标存在并且等于 1 才告警。如果 categraf 进程都挂了指标消失这条规则不触发但你会有另外的agent 心跳异常规则兜底。3.3 告警风暴是怎么来的怎么避免第一次配告警规则的人通常会遇到一告警就是一大片的情况。比如你写了一条磁盘使用率大于 90% 的规则结果同一批机器全部触发钉钉群瞬间被刷屏。这时候需要做好两件事一是合理设置持续时长。磁盘使用率超过阈值之后不一定会立刻导致故障持续 5 分钟以上再告警能过滤掉大量瞬时抖动。当然像磁盘只读这种高优先级场景持续时长应该设短一些。二是善用告警升级和收敛。夜莺的告警规则里可以配置静默时间指的是同一个规则、同一个告警对象在一次告警之后隔多久才能再次触发。比如 MySQL 端口挂了一次恢复之前不需要每隔 15 秒就再告警一次把静默时间设置为 300 秒或者更长能有效避免告警风暴。另外一个实用技巧是标签分组。PromQL 返回的指标可以带不同的 instance 标签夜莺默认按标签分组产生独立告警事件。如果你希望任何一台机器磁盘满合并成一条通知发出来而不是每个机器一条可以通过分组配置来实现。这里不展开写具体界面了因为不同小版本的字段位置略有差异但逻辑是通用的。4. 监控看板和巡检数据不只是用来告警的很多人的服务器监控实践到最后变成了只有告警才打开页面这其实很可惜。夜莺的看板功能虽然不如 Grafana 花样多但覆盖日常巡检足够。4.1 用内置看板快速掌握机器状态夜莺自带了一些内置大盘比如主机基础监控大盘能展示 CPU 使用率、内存使用率、磁盘 IO、网络流量等。机器列表里打开某一台机器的详情就能看到这些图。我个人的习惯是会把每类业务机器单独分一个业务组然后在看板里按业务组过滤而不是所有机器混在一起看。比如电商服务的机器组单独一个筛选条件businessshop这样告警记录、看板数据都对得上号。需要看更炫的图夜莺也支持与 Grafana 对接。可以把夜莺作为数据源然后在 Grafana 里做更灵活的仪表盘。具体操作是在 Grafana 中新增 Prometheus 类型数据源地址填夜莺的查询接口剩下的就和用 Prometheus 一样了。这个功能比较适合那些公司本来就在用 Grafana 的团队。4.2 定时巡检报告夜莺在较新的版本里提供了内置大盘和报表相关能力。比如可以配置每日或每周的巡检报告把服务器 CPU、内存、磁盘、网络的关键指标汇总成一份 PDF 或图片定时发到邮箱或群里。这个功能对没有专职运维的团队非常有用。领导不需要天天去翻监控页面每天定点收到一份你的服务器还健康的报告心里有底。配置方式一般是在报表管理里新建报表选择大盘、选择接收人、设置时间计划即可。有一点要注意如果服务器组数量多报表里的图表数量也会很多生成的报告体积会很大。建议在报表里勾选关键指标和自己最关心的几台机器不要一次性把所有主机全塞进去不然 PDF 打开慢也没人愿意看。5. 夜莺部署使用中的常见问题与排障记录这部分是我个人运维夜莺以来踩坑最多的区域。每个问题背后基本都有一条清晰的原因链路搞清楚之后再遇到就不会慌了。5.1 部署和页面都能打开但机器列表和指标都是空的这是装机后最高频的问题。排查链路如下先看 categraf 进程有没有起来ps -ef | grep categraf再看 categraf 日志journalctl -u categraf -f如果日志里出现write ... failed或者connection refused说明写入端地址不对或者夜莺服务端没起来。如果日志里没有任何报错但夜莺页面还是空的去夜莺服务端手动验证一下写入接口curl -v http://127.0.0.1:17000/prometheus/v1/write正常会返回 405 或 400 之类的响应但连接是通的。如果 curl 直接 timeout说明 n9e-server 没有监听这个端口得去查看服务端进程和防火墙。还有一个容易被忽略的点是 categraf 的hostname和夜莺里的机器标识不一致。夜莺默认用ident字段标识一台机器而 categraf 上报时会带上hostname字段。如果 categraf 配置里手动写了 hostname但机器列表里搜索的是系统主机名就会看到机器离线或者干脆搜不到。5.2 告警触发正常但恢复通知一直收不到夜莺的告警恢复机制和 Prometheus Alertmanager 有点类似一个告警在持续时间内不再匹配触发条件才会进入恢复流程。如果你发现告警恢复了但没收到恢复通知多数情况是恢复通知的媒介没启用或者通知规则里只勾选了触发告警时而没有勾选恢复时。另外如果告警规则里配置了静默时间恢复之后短时间内相同告警再次触发可能不会立刻发通知。这个是正常行为不是故障。5.3 指标数据出现断档数据断档通常分两种一种是个别机器断档一种是全部机器断档。个别机器断档先去被监控机上看 categraf 日志大概率是采集插件 panic 重启了或者系统时间被改动过。categraf 对系统时间比较敏感时间跳变会导致 remote write 的数据时间戳异常时序库可能拒绝写入或者写入后查询不到。全部机器断档优先查时序库的存储和磁盘空间。Prometheus 在数据目录所在磁盘写满时会停止所有写入表现就是夜莺页面上曲线同时消失。这种问题尤其在 Docker 部署方式下经常出现因为容器日志、临时文件都可能落在系统盘系统盘一满监控先挂。5.4 数据存储的清理与容量规划夜莺接的机器多了之后时序库的磁盘占用会涨得很快尤其是你开启了大量中间件采集插件时。规划容量时我习惯按每天新增数据量 × 保留天数来估算。Prometheus 的保留时间可以通过启动参数--storage.tsdb.retention.time控制比如保留 15 天--storage.tsdb.retention.time15dVictoriaMetrics 则用-retentionPeriod参数。时间太长意义不大服务器监控数据一个月内的价值最高更早的基本没人查。如果公司有合规要求非要留半年建议把数据落到单独的归档存储而不是无限堆在时序库里。另外对夜莺上报的数据也可以在 categraf 这一层做裁剪。比如conf/config.toml里的[global]有hostname、labels配置而各 input 插件也可以配置interval和instances。不要让所有插件都在捞数据没用的一律禁用。磁盘、CPU、内存这些基础指标必须采集而像 net 下的几十个计数器很多环境里根本用不上关掉能省不少存储。6. 我的一些使用习惯和后续建议如果你正准备把夜莺铺到整个机房我的建议是先别急着追求大而全。先把十台以内的机器接好把系统指标、端口探测、统一告警消息这三件事跑顺再逐步加中间件监控和自定义脚本采集。在后续使用中我比较推荐把夜莺的一些扩展能力用起来告警自愈夜莺支持通过回调 Webhook 对接自愈平台但把自愈动作接到监控上之前一定要先小范围灰度。我第一次用告警回调时因为表达式写反差点把生产环境的 Nginx 全部重启了一遍这教训比较深刻。自定义采集脚本categraf 支持 exec 插件可以定期执行一个脚本并采集输出。这个能力适合做业务层监控比如统计某个接口的响应时间、数据库连接池剩余数。脚本输出格式要按 categraf 的要求写成一行一条指标否则采集不上来。多云环境统一监控夜莺的机器列表里可以通过用户标签区分云厂商和业务线比如cloudaliyun、businessweb。这样在多云环境下告警规则可以按标签批量套用非常方便。最后分享一个我实际使用中发现的小技巧夜莺的告警规则编辑页面里有一个测试按钮可以手动输入 PromQL 并查看当前返回的指标数据。写告警规则的时候不要凭感觉先把查询语句贴进去看看返回的指标名称、标签值对不对再保存规则。这能省下大把调试时间。夜莺这套系统如果只是轻轻用可能感觉它就是又一个监控面板。但真正用起来之后你会发现它的价值集中在告警收敛和批量管理能力上。把基础数据接好、告警规则调准后面再扩容只是重复操作而已不会再有学习成本了。希望这篇内容能帮到你正在做的监控部署少走点弯路。