夜莺这套服务器监控软件我之前在《服务器监控软件夜莺使用一》里把安装部署的过程捋了一遍服务端跑起来了页面也能正常登录很多朋友这时候通常会有一个共同的感受事情好像做完了又好像没做完。因为监控系统真正开始有价值恰恰是从“接入真实机器、配置告警、搭建看板”这一刻开始的前面的部署只是热身。这篇文章就聚焦在“夜莺监控系统安装部署完成之后”该怎么往下走。我会按照自己实际接一台生产服务器的完整路径来写先理清楚夜莺在监控链路里的分工然后讲采集端 categraf 的接入和验证接着是告警规则、通知渠道、可视化看板最后把我在现场踩过的一些坑和排查思路整理成速查清单。适合已经装好夜莺、准备用它盯机器的运维朋友也适合还在调研“服务器监控软件到底怎么选”的人参考。全文以夜莺 v7 版本为例老版本部分菜单名称可能不同但整体思路通用。1. 先理清楚夜莺在这条监控链路里到底扮演什么角色很多刚接触夜莺的人会有一个误区觉得装好夜莺就等于拥有一切包括数据采集、存储、告警、展示。实际上夜莺是“管控大脑”它自己并不负责把监控数据完整地存下来更不会像传统监控软件那样自带一套厚重的数据采集体系。这里的核心分工你必须在动手配置前就搞清楚否则后面排查问题会非常痛苦。1.1 夜莺的架构分工server、采集器与时序库夜莺的整个链路大概是这样的采集器 categraf 负责在每台被监控机器上收集 CPU、内存、磁盘、网络这些指标然后通过 HTTP 接口推送给夜莺服务端n9e-servern9e-server 收到数据后先把数据写入你部署时指定的时序数据库比如 Prometheus、VictoriaMetrics 或者 Mimir你需要查看指标或者配置告警时夜莺再从时序库里把数据查出来展示。这个“夜莺本身不存数据数据在时序库里”的设计一开始会让习惯了 Zabbix 的人不太适应。我举个类比夜莺更像是一个调度中心和告警平台时序库是它的仓库categraf 则是散布在各个机房的“眼线”。三者的职责非常清晰你排查问题时首先要确认“眼线”是否在正常上报然后去“仓库”里看数据到底有没有进来最后才轮到夜莺这个“大脑”去处理和展示。1.2 部署完之后先确认这几个页面没问题按照上一篇的部署文档安装完成后我建议你先不要急着接机器先把几个基础页面过一遍确认服务端确实是健康的。首先是“仪表盘”页面正常打开后里面会有一批内置看板比如主机监控、CPU 相关等说明系统自带的模板已经初始化成功。其次是“告警规则”页面v7 版本里默认会带一些内置规则模板像“机器失联”“CPU 使用率过高”这些你应该能看到它们处于未启用状态。再一个是“主机列表”页面此时还没有任何机器接入列表大概率是空的这属于正常现象。最后去确认一下“通知配置”里的联系方式有没有初始化这一步很多人会漏掉导致后面告警规则配好了告警却一个都发不出去。我习惯把这一步称为“上线前的仪表盘自检”花不了两分钟但能避免你后面在错误的方向上浪费时间。确认完这些我们再正式开始接入第一台机器。2. 接入第一台服务器categraf 采集端配置与数据验证接入被监控机器这件事在夜莺体系里比传统监控软件要简单不少。你不用像用 Zabbix 那样在服务端创建主机、关联模板、配置宏夜莺的设计哲学是“只要采集器把数据发上来机器就会自动出现在列表里”。这种自动发现机制让大批量接入机器变得非常省事我第一次用的时候甚至有点不太习惯。2.1 categraf 配置最小可用的 agentcategraf 是夜莺官方推荐的采集器使用 Go 编写部署非常简单。把安装包解压到目标机器后需要改两个关键的配置文件一个是config.toml负责全局配置和上报地址另一个是conf/目录下的采集插件配置。先看全局配置。config.toml里最核心的是[global]和[[writers]]这两个部分[global] hostname web-01 omit_hostname false [[writers]] url http://192.168.1.100:17000/prometheus/v1/write basic_auth_user 用户名 basic_auth_pass 密码hostname这个字段决定了这台机器在夜莺里的标识也就是 ident。如果不设置categraf 会默认采用机器的系统主机名。我建议在批量部署时统一规划 hostname 的命名规则比如web-01、redis-02、mysql-prod-03这种后面看告警、查指标会非常直观。url就是夜莺服务端的接收地址把 IP 换成你实际部署的地址即可。如果你的夜莺开启了认证basic_auth_user和basic_auth_pass也要对应填好。改完全局配置后还需要检查采集插件。conf/目录下默认包含了非常多的采集插件配置比如conf/input.cpu/、conf/input.mem/、conf/input.disk/、conf/input.net/等每个目录里都有一个config.toml。categraf 的机制是插件目录存在并且配置有效这个采集器就会启用。所以一般不需要你手动创建大量配置只需要确认需要的插件目录没有被删掉即可。我常用的最小集是这些插件目录采集内容备注input.cpuCPU 使用率、各核指标默认采集即可input.mem内存使用量、使用率默认采集即可input.disk磁盘分区使用率、inode注意按需过滤挂载点input.net网卡流量、包量、错误计数默认采集全部网卡input.proc进程存活状态需要额外配置目标进程启动 categraf 也很简单直接执行./categraf --test可以先跑一次看看有没有报错确认没问题后再用nohup ./categraf 或者 systemd 方式后台运行。这里有一个实际经验--test模式不只是测试配置语法它还会真的执行一次采集并打印输出你可以借此直接看到采集到的指标名和值这对后面写 PromQL 表达式帮助特别大。2.2 数据上报验证从页面和 API 两条路确认categraf 起来之后数据并不是立刻就能在页面上看到。因为夜莺的写入链路是“categraf - n9e-server - 时序库”中间任何一环出问题都会导致数据丢失。我通常会按顺序做三步验证。第一步去“主机列表”页面刷新一下看目标机器是否已经出现。夜莺默认根据 categraf 上报的时间戳来识别机器在线状态机器一出现说明采集器到服务端的链路是通的。如果机器没出现优先检查 categraf 进程是否还活着以及writers.url是否能通。第二步因为“主机列表”只代表心跳上来了不代表时序数据一定写入了还需要去“指标分析”页面有的版本叫“即时查询”里搜一下指标比如输入cpu_usage_active选择正确的时间范围看能不能查到数据。这里我要强调一下这个页面就是夜莺的 PromQL 查询入口后面配告警规则之前我建议你都先到这里验证一下表达式能不能查到数据能查到再去做规则能省下后面大量排错时间。第三步如果你熟悉时序库还可以直接到 VictoriaMetrics 或 Prometheus 的查询页面里验证。这一步相对进阶一些但也是最能确认问题环点的方式。如果页面和 API 都查不到数据但主机列表又显示在线那大概率是写入时序库的过程出了问题要去看 n9e-server 的日志。2.3 常用插件与指标说明接入完第一台机器后你需要认识几个最常见的指标因为后面写告警规则全靠它们。以 categraf 默认采集的指标为例这几个是重点cpu_usage_activeCPU 整体使用率数值范围 0-100是一个即时值。cpu_usage_idleCPU 空闲率100 减去它就是使用率。mem_used_percent内存使用百分比。disk_used_percent磁盘分区使用百分比注意这个指标带mount标签比如/、/data写规则时要按实际情况过滤。net_bytes_recv和net_bytes_sent网卡接收和发送的字节数这个是计数器用的时候通常需要配合rate()函数计算速率。我在实际使用中发现一个很容易踩的坑很多人拿到cpu_usage_active后直接套rate()函数结果算出来的值完全不对。因为cpu_usage_active本身已经是一个“使用率”的百分数值不是计数器不需要再对它做速率计算。categraf 里真正需要rate()的是cpu_usage_guest这类计数器指标以及网络流量这类累计值。写表达式之前先确认指标类型是 gauge 还是 counter这个习惯能帮你少走很多弯路。另外categraf 的指标在时序库里默认会带上ident标签这个标签的值就是你在config.toml里配置的hostname。所有 PromQL 表达式里都可以通过ident机器名来精确过滤某台机器也可以不写ident直接对所有机器生效。理解了这个标签体系后面写告警规则、做看板的时候就会顺畅很多。3. 把数据变成告警规则引擎的三种玩法夜莺的告警能力是它区别于很多开源监控软件的核心优势。它不是简单地“设置一个阈值超过就报警”而是提供了告警规则、屏蔽规则、订阅规则这三个层级分别解决“什么时候报警”“什么时候不报警”以及“报警之后通知谁”的问题。这一节我把这三个层级的用法分别拆开讲。3.1 告警规则配置的完整参数说明进入“告警规则”页面创建一条新的规则你会看到几个核心字段每一个我都说一下实际配置时怎么理解。规则名称就不多说了关键是“查询”这一部分。规则配置框里的 PromQL 表达式比如 CPU 使用率超过 85% 的表达式可以这样写cpu_usage_active{identweb-01} 85这个表达式表示机器 web-01 的 CPU 使用率大于 85 时触发告警。如果你想对一批机器生效比如所有 ident 以 web 开头的机器可以这样写cpu_usage_active{ident~web-.*} 85夜莺支持完整的 PromQL 语法所以聚合、分组这些操作都能用。表达式写好后下面是“持续周期”和“执行频率”这两个参数。执行频率决定夜莺每多久去查一次数据默认 15 秒左右即可持续周期则是一个缓冲机制它表示“表达式条件必须连续满足多少次才算触发告警”。这里我要多说一句持续周期是防止告警风暴最重要的参数我见过不少新手把持续时间设成 1 个周期结果半夜被瞬时 CPU 尖峰唤醒好几次实际上服务根本没出问题。建议 CPU、内存这类波动大的指标持续时间至少设置 5 个周期以上磁盘使用率这类增长缓慢的指标可以设短一些甚至立即触发都行。还有一个重要的字段是“告警等级”夜莺里通常分为 1、2、3 级分别对应紧急、重要、提醒。等级的设计不只是为了在页面上显示颜色更重要的是配合后面的通知路由让不同级别的告警走不同渠道。比如 P0 级发电话或短信P1 级发企业微信群P2 级发邮件这是生产环境非常实用的做法。配置完成后建议先点击“测试”按钮夜莺会读取当前时序库的数据判断这个表达式在当前时刻是否触发了告警条件。如果测试界面直接显示“已触发”那就说明表达式和阈值没有问题如果显示“未触发”你需要确认是机器数据没采集到还是阈值设高了或是 ident 标签没对上避免把一条根本不会触发的规则留到生产环境。3.2 屏蔽规则做维护窗口的正确姿势运维工作中最常见的告警干扰场景就是明明在做计划内维护告警却一条接一条。比如凌晨 2 点对数据库做迁移CPU 和 IO 磁盘使用率都飙升如果你没有处理机制监控系统就会把这当成故障疯狂通知。夜莺的屏蔽规则就是专门解决这个问题的。创建屏蔽规则时需要指定三段信息屏蔽的时间范围、屏蔽的标签条件、屏蔽的告警级别。时间范围可以是一次性时间段也可以是周期性时间段比如每周六凌晨 2 点到 6 点自动屏蔽备份任务带来的告警。标签条件则可以精确到机器比如identdb-01也可以匹配一组机器比如ident~redis-.*灵活性很强。我特别想提醒一个细节屏蔽规则尽量把条件写精确不要图省事直接屏蔽整个服务。因为屏蔽规则的匹配范围太大会把真正需要关注的故障也一起屏蔽掉导致告警盲区。我在实际工作中见过有人为了省事屏蔽了全部告警结果第二天业务挂了没人发现这个教训非常惨痛。合理的使用方式是只屏蔽你知道的、计划内的变化而不是把所有噪音都遮住。3.3 订阅规则把告警分给对的人订阅规则是用来做告警分发的。默认情况下一条告警触发后所有配置了接收通知的联系人都会收到消息这在只有一个业务团队时没问题但当监控的机器多了、团队分工细了以后就会变得很混乱。举个例子你同时监控了应用服务器和数据库服务器应用团队的同事其实并不关心数据库的磁盘告警而 DBA 也不希望被应用进程的告警刷屏。订阅规则就是用来做路由分发的一条订阅规则大致包含三部分事件过滤条件匹配哪些告警例如按标签ident~db-.*匹配所有数据库机器。通知目标过滤出来的告警该发给谁可以是一个组也可以是一个具体的联系人。通知渠道比如只发企业微信或者只发邮件。这样一来“数据库告警只发给 DBA”“应用告警只发给应用团队”这类需求就能非常干净地实现不再需要为不同机器重复创建一堆规则。我搭建这套分派体系之后告警的处理效率提升非常明显因为每个人接收到的消息都是和自己相关的不会因为长期被无关告警打扰而产生“告警麻木”。4. 告警送到人手里通知渠道这样配告警规则配置得再完美如果通知发不出去一切都等于零。夜莺原生的通知渠道覆盖面非常广常见的邮件、企业微信、钉钉、飞书、Webhook 都是开箱即用的。这一节我拿最通用的 webhook 模式为例讲一下完整配置过程以及我在对接过程中的一些体会。4.1 通知渠道与告警级别怎么配合在配置通知之前建议你先花点时间设计一下“告警级别到通知渠道”的映射关系。我自己在用的策略是紧急级别走 webhook 对接内部值班系统触发电话/短信重要级别推到企业微信群提醒级别只发邮件留底。这样设置的好处是越严重的告警越能通过强打扰的方式触达而低级别的告警不会频繁打扰人。这个策略落实到夜莺里其实就是给不同级别的告警关联不同的通知规则。夜莺的告警规则可以按级别触发不同通知渠道比如在同一条告警规则里把紧急级别的通知方式设为 webhook把提醒级别的通知方式设为邮件。配置的时候不用创建多条规则只需要在告警规则的“通知设置”里分别指定即可。4.2 以 webhook 为例的完整配置过程在夜莺页面里找到“通知配置”你可以看到系统支持多种通知方式其中“Webhook 回调”是最灵活的一种。它的原理很简单告警触发时夜莺会向你在配置里填写的 URL 发一个 HTTP POST 请求请求体里携带告警的详细信息。你只要提供一个能够接收这个请求的接口比如自研的告警接收服务、企业微信/钉钉机器人的自定义 webhook就能实现对通知内容的完全定制。我以对接一个钉钉机器人为例夜莺侧需要填写的参数如下回调 URL填机器人提供的 webhook 地址。请求方式POST。请求头通常要添加Content-Type: application/json。为了让告警内容更易读夜莺的通知配置里还支持用模板字符串来拼装内容。这里我放一个简单的模板示例它的作用是把告警事件里的机器名和告警详情拼进消息体{ msgtype: text, text: { content: 【告警】机器: {{$labels.ident}}\n详情: {{$annotations.summary}}\n时间: {{$evalMatches.timestamp}} } }不同版本的模板语法可能略有差异但思路是一致的你可以在消息体里引用告警事件的各种字段。我建议第一次配置时先在页面上点击“测试”按钮发送一条模拟告警看看对方接收到的消息格式是否符合预期再微调模板内容。配置完后我还养成了一个习惯每配完一条通知方式就故意触发一条低级别告警确认所有环节都正常后再清掉测试告警。这个动作看起来很简单但能避免那种“直到真出故障才发现通知没配好”的悲剧。5. 可视化看板不只会用还得能自己造夜莺的看板功能在日常使用中地位可能比告警还高。告警只是被动地告诉你“出事了”看板则是你主动观察系统状态、分析容量趋势、判断业务高峰的主要工具。夜莺看板的设计和 Grafana 非常像有过 Grafana 使用经验的人几乎可以无缝上手。5.1 导入官方仪表盘模板如果你不想从零开始画看板最快的路径是使用夜莺官方提供的内置仪表盘模板。在“仪表盘”页面你会看到系统已经预置了一些模板比如“主机监控”这类基础看板。如果预置模板不能满足需求夜莺也支持通过 JSON 文件导入来自社区的仪表盘模板。你可以在夜莺监控官网以及相关社区仓库找到不少现成的模板下载后导入即可。导入模板我一般建议按团队维度去组织比如建一套“基础设施总览”的文件夹再建一个“业务应用监控”的文件夹文件夹里再按照不同业务模块去创建看板。这样导航层级清晰日常切换效率很高。如果一开始就把所有看板平铺在一个根目录下等看板数量多起来后找起来会非常费劲。5.2 手写一个 CPU 与内存看板内置模板可以满足大部分展示需求但真实世界里总有一些“监控指标需要按团队自定义”的场景这时候你还是得学会自己画图。夜莺建一个画板面板的流程非常直观进入某个仪表盘后点击“添加 Panel”然后在查询区域输入 PromQL 表达式并选择展示方式即可。以创建一个“CPU 使用率趋势图”为例查询表达式可以写100 - avg(rate(cpu_usage_idle{identweb-01}[2m])) * 100这个表达式的意思是取 web-01 这台机器的 CPU 空闲率计算最近 2 分钟的速率再用 100 减去它得到 CPU 使用率。如果你不想写这么长直接用cpu_usage_active{identweb-01}这个即时值指标也可以看板展示效果差别不大。面板类型建议选择“折线图”左侧 Y 轴的单位设置为“percent”保留两位小数这样坐标轴会显示成百分比格式。如果一台机器上有多个 CPU 核categraf 默认采集的指标会带上cpucpu0、cpucpu1这样的标签此时直接用avg聚合掉cpu标签即可避免每个核都画成一条线。内存面板的表达式比较简单mem_used_percent{identweb-01}如果你希望在不同机器之间做对比可以在表达式里去掉ident过滤条件并且添加legend展示格式夜莺会自动按机器名分组在图例里显示每台机器的使用率曲线。这种对比视图对定位“哪台机器内存异常”特别有用我在处理集群内存问题时经常挂着这样一个看板观察。6. 排错复盘那些年我踩过的夜莺的坑这一节把我使用夜莺过程中遇到过的典型问题整理成一个排查清单每一个问题都附上了排查思路和解决方案。这些都是我在真实环境里踩过的坑不是从文档里搬来的知识。6.1 最常遇到的三类故障与排查思路第一类主机列表里看不到机器。这类问题 90% 出在采集端。先用ps -ef | grep categraf确认进程活着再用curl确认 categraf 所在机器能访问夜莺的写入接口。如果进程和网络都没问题去看 categraf 的日志里面通常会直接打出上报失败的原因。还有一个小概率情况是hostname配置了重复值导致多台机器用同一个 ident 互相挤下线这种情况务必在批量部署时规划好命名。第二类看板或告警查询不到指标数据。这要先区分是“完全没有数据”还是“部分时间段没有数据”。完全没有数据大概率是 categraf 没采集到或者写入时序库失败部分时间段没有数据则可能是时序库做了留存策略数据已经被清理。我遇到过一个小概率但很坑的情况服务器时间不准导致数据点被时序库当成“未来数据”丢弃最后通过同步 NTP 时间才解决。第三类告警规则看起来没问题但不触发。我遇到最多的是 ident 标签书写错误。PromQL 对标签值的大小写和完全匹配非常严格web-01和Web-01是两个完全不同的值。另外建议把规则表达式先拿到“指标分析”页面手动跑一遍确认当前数据是否满足触发条件。如果测试页面显示“已触发”但告警一直没有消息那问题就出在通知环节需要去排查通知配置和联系人设置。6.2 几个现场经验与参数调优建议最后分享几个我在使用夜莺过程中觉得很有价值的实际经验不涉及具体公司业务都是一些通用的工程实践。关于告警的持续时间前面我提到过要防止瞬时抖动这里我再补充一个“告警分级”的应用场景同一类指标可以配置成两条规则一条是“提醒级”持续时间短目的是感知波动另一条是“紧急级”持续时间长目的是确认故障。这样既不会漏掉真故障又不会被小波动吵得分心。关于指标的长期保存我建议根据不同指标的重要性设置不同的保存时长。比如用于容量规划的磁盘、内存指标保存时间长一些而用于短期排障的瞬时高精度指标可以保存短一些。夜莺对接的时序库如 VictoriaMetrics 支持按指标配置保存策略这个能力用好了能显著降低存储成本。关于看板组织我坚持“看板跟着业务走”的原则。不要只做“按机器分组”的看板因为机器会变、会迁移但业务模块是相对稳定的。把看板内容用标签维度来组织比如按apporder-service、envprod这样的方式组织在基础设施频繁变动的场景下维护成本会低很多。我自己用夜莺这一年多下来最大的体会是一套服务器监控软件真正好不好用不完全取决于它有多少炫酷的功能而在于你能不能把它和自身的运维流程磨合好。告警规则怎么定、通知分派怎么设计、看板怎么组织这些都需要结合自己的业务场景反复调整。夜莺提供了一个非常灵活的底座剩下的就看你愿意花多少精力去雕琢了。希望这篇“使用二”的经验整理能帮你把夜莺真正用起来让它成为你日常运维里一个可靠的工具。