上一篇把夜莺部署完，web界面也打开了，很多人觉得这一步就意味着"装好了"。但说句实在话，从"安装成功"到"真正用起来"，中间还隔着一大截。这段时间后台收到最多的留言就两类：一类是"装完了，然后呢？"，另一类是"我配了告警，但根本不触发啊"。所以这一篇我准备把夜莺从"装好"到"跑起来"这条路上最容易卡壳的地方，一个一个说清楚。重点讲采集器接入、告警规则配置、通知渠道打通、可视化大盘搭建，以及我在实际使用中踩过的一些坑。
适合看这篇的人，是那种已经把夜莺服务端跑起来、正准备把服务器和业务接进去的运维、开发，以及自己折腾服务器监控的站长。如果你还在部署阶段卡着，建议先把上一篇的部署流程走完再回来，不然下面很多配置你会看得一头雾水。
1. 使用夜莺前先想清楚：监控对象与采集链路
1.1 夜莺的核心组件与工作流程
先花两分钟把夜莺的底层架构说清楚，不然后面配告警你一定会懵。夜莺这个监控平台，拆开来看其实是四个角色分头干活：采集器负责从机器上拿数据，时序数据库负责把数据存下来，服务端负责算告警、接通知，Web端负责让你看到数据、改配置。
这个关系不妨打个比方：采集器是你的眼睛，时序库是记忆力，服务端是大脑，WebAPI是手，MySQL这类关系库则是记事本。眼睛看到东西，手记录，大脑判断，最后你通过记事本去查。理解了这套流程，后面所有配置都是在指挥这几个角色协作。
所以排查问题时方向就很清晰：数据没上图，先看采集器有没有上报；告警没触发，先看时序库里有没有数据、规则有没有生效；通知没收到，再看渠道配没配对。很多朋友一上来就改一堆配置，结果越改越乱，就是因为没先想清楚现在到底卡在哪一环。
1.2 让主机真正"开口说话"：采集器的接入与配置
服务端装好之后，第一步就是把采集器部署到要监控的机器上。夜莺官方的采集器叫collector，不同版本名字可能略有不同，但使用思路一致，这里以我用的夜莺 v6 版本为例说明。
建议用主动模式接入，也就是采集器主动上报到服务端。这样部署更简单，也能避免服务端被防火墙挡着拉不到数据的问题。需要改的地方主要是配置文件里的服务端地址，类似下面这段：
heartbeat: enable: true urls: - http://192.168.2.10:7000改完后启动collector，去夜莺的"机器列表"页面刷新一下，如果看到这台机器上线了，说明通路已经打通。我第一次接机器时有个小插曲：服务端明明在跑，但机器迟迟不上线。后来发现是心跳URL写成了Web页面的端口，而心跳对接的是服务端的内网端口，两个端口不一样。坑很小，但足够让人怀疑人生。
接下来就是打标签和分组。干过运维的人应该都有这种经验：机器一多，光靠IP根本没法管理。我建议接入时就按"业务线/环境/角色"三个维度打标签，比如backend-prod-01、mysql-test-02这种。后面建告警规则、搭大盘，用标签来圈定机器，会比单纯选IP灵活得多，也方便以后扩容新机器。
另外还要提醒一句：时序库的选型也得提前定好。夜莺后端可以对接Prometheus、VictoriaMetrics、M3DB等时序库。如果你的机器量不大，Prometheus单机就够了；如果后续有上万台机器的规模，建议直接上VictoriaMetrics，性能余量会宽裕很多。我这边前期图省事直接用了Prometheus，后来机器规模涨上来之后，查询性能明显吃力，才又迁到了VictoriaMetrics。迁移倒不复杂，但一开始就选对能省掉很多折腾。
2. 告警规则配置：从阈值到触达的完整链路
2.1 告警规则的核心要素拆解
夜莺的告警规则配置，核心就是把四件事说清楚：查什么数据、达到什么条件、持续多久开始告警、告警发给谁。看起来简单，但每条规则里的每个字段都有讲究。
拿我最常用的一条规则举例，监控CPU使用率。新建告警规则时，查询语句大概长这样：
cpu.usage_idle < 20这个表达式不用理解得太复杂，你可以把它读成"这台机器的空闲CPU已经不到20%了"。后面还要配上"持续时间"，比如持续5分钟才告警，这样能过滤掉短时间的CPU抖动。我有次把持续时间设成1分钟，结果业务高峰期几乎每十分钟就要收一批CPU告警，那几天手机基本不敢静音。后来改成5分钟，清净多了。
除了查询条件和持续时间，告警还要区分"当前值"型和"趋势"型。当前值型适合磁盘空间、内存占用这类指标，趋势型适合判断"磁盘是不是在快被写满"这种有变化规律的情况。我第一次用夜莺时只盯着当前值配置，导致一条磁盘告警在阈值上下反复横跳，一会儿恢复一会儿告警。后来加了连续N次的判断条件，才算是把这种抖动压下去。
2.2 通知渠道接入：邮件、钉钉、企业微信与通用Webhook
告警规则有了，还得让告警真正"出声"。夜莺支持的通知渠道有邮件、钉钉、企业微信、飞书、Webhook等。我的习惯是邮件作为留痕渠道，IM机器人做实时触达，邮件有存档价值，IM消息则是值班同学第一时间看到的。
以邮件为例，在夜莺的系统配置里找到SMTP设置，填上邮件服务器地址、发件人、认证密码。这里要注意，很多邮件服务商对发件频率有限制，告警风暴的时候容易出现邮件发不出去的情况，所以我的习惯是在邮件渠道后面再加一个Webhook渠道，把告警转发到自建的通知群里。
Webhook配置也不复杂，就是给夜莺一个接收地址，它会把告警内容以JSON形式POST过来。下面是我这边收到的一条告警消息示例：
{ "event_name": "CPU使用率过高", "severity": 2, "metric": "cpu.usage_idle", "value": "8.3", "threshold": "20", "duration": "5m", "target": "backend-prod-01", "time": "2024-12-15 14:23:10" }如果你的企业有自己的告警平台，完全可以在Webhook里把这套JSON转成自己的格式。我在公司就是这么接的，夜莺负责计算告警，企业平台负责聚合和推送，两边各干各的活，非常顺手。
2.3 告警升级与静默：减少无效打扰的实战策略
告警配多了以后你会发现，真正头疼的不是"告警漏掉"，而是"告警太吵"。夜莺的静默功能，用来在特定时间段、特定机器上屏蔽告警，非常实用。比如凌晨的例行备份任务，持续半小时，这段时间磁盘、CPU指标会有明显波动，如果不做静默，值班同学后半夜会被一连串告警吵醒，第二天还得向所有人解释这些都不是故障。
所以我给的建议是：正式上生产之前，把静默窗口、告警升级策略都提前想好。告警升级适合那种长时间不恢复的故障，比如某台机器内存持续高占用，可以先给一个普通告警，如果连续30分钟没恢复，再升级成严重告警并通知到主管。夜莺里能配置不同级别的告警升级策略，按业务特点去调就行，不用追求一步到位，后期根据实际告警频率校准就好。
3. 监控大盘与视图体系
3.1 内置大盘与导入模板
告警搞定之后，下一步就是让数据变成能看的图表。夜莺自带了一些监控大盘，安装部署完成之后，进入"仪表盘"页面就能看到。系统默认的十几个大盘覆盖了主机基础监控、网络监控这类的通用场景，对于刚起步的团队来说，完全可以直接拿来用。
如果你想要更丰富的展示，夜莺也支持导入JSON格式的大盘，网上可以找到很多开源的模板。但我不太建议一上来就塞一堆模板，因为模板里的指标命名、变量名跟你的环境不一定对得上，导入之后一大批"无数据"，反而打击信心。先用自带大盘跑几天，等熟悉了字段，再按自己的需求修改，这样会顺很多。
3.2 自定义大盘的搭建思路
自定义大盘其实没有多神秘，核心就两件事：选指标、定布局。
选指标这一步，你需要知道夜莺库里到底存了哪些指标。最简单的办法是用"即时查询"功能，输入关键字比如cpu、mem，就能看到匹配到的指标名和当前值。确认指标名存在，再去大盘里画图，就不会出现"曲线不显示"的问题。我刚开始用的时候经常犯这个错误，照着网上的配置把指标名抄过来，结果本地的采集器根本没采集这个指标，图自然就是空的。
布局方面，我建议新手先从"单机总览"开始做起。摆四五个图表，CPU、内存、磁盘、网络流量，再放一个文本面板显示机器名。一个主机一个总览盘，确保每台机器至少能被一个总览盘覆盖。等机器数量多了，再用变量下拉框把"选择主机"做成一个筛选器，实现一个大盘看所有机器，维护成本能低很多。
3.3 告警事件与数据检索的使用技巧
最后说说告警事件查询。夜莺会把每条告警的产生过程记录在"历史事件"里，包括触发时间、恢复时间、当时的指标值。这个东西在复盘故障的时候特别有用。
比如有次线上服务响应变慢，我通过历史事件发现告警规则失效了几个小时，原因是当时指标名被采集器升级改掉了，告警规则还在用旧的指标名，导致查询结果一直为空。如果你不看事件记录，光靠猜，可能半天定位不到这个原因。所以我的习惯是每周刷一遍历史事件，看看哪些规则频繁触发、哪些规则好久没触发，顺便清理掉一批价值不大的规则，让告警体系一直保持干净的状态。
4. 真实业务场景下的监控配置案例
4.1 场景一：一台标准Linux服务器的完整监控
把理论知识落到实际，最典型的就是对一台Linux服务器做完整监控。以我这边某台后端服务器为例，我会关注四类指标：CPU、内存、磁盘、网络。下面这套是我日常在用的告警参数，可以直接抄作业：
| 监控项 | 指标表达式 | 触发条件 | 持续时长 | 告警级别 |
|---|---|---|---|---|
| CPU使用率 | cpu.usage_idle | < 20 | 5分钟 | P2 |
| 内存使用率 | mem.used_percent | > 90 | 5分钟 | P2 |
| 根分区空间 | disk.used_percent | > 85 | 10分钟 | P1 |
| 系统负载 | load1 | > 8 | 10分钟 | P1 |
注意表里的load1要结合CPU核数来看，8核机器和32核机器的承载能力完全不一样，阈值需要根据实际核数调整。我是按load1除以核数超过0.7来估的，系统真的出现性能瓶颈时再微调。
那磁盘空间为什么把持续时长设成10分钟？因为磁盘空间不会像CPU那样秒级波动，短时间判断意义不大，拉长一点还可以避免临时大文件造成的误报。这思路也适用于其它"慢变量"，像磁盘剩余量、文件句柄数，都可以把持续时间调长一些。
4.2 场景二：MySQL实例监控配置
除了看机器，业务层面最常见的监控对象就是数据库了。MySQL的监控，我比较关注三个指标：连接数、慢查询数、主从延迟。
连接数的告警规则可以这么设：当前连接数除以最大连接数大于0.85，持续5分钟，说明连接快满了。慢查询数按天做趋势告警，一天内慢查询超过某个数量就提醒，适合发现SQL性能劣化。主从延迟尤其重要，延迟一旦拉开，主备切换时就有丢数据的风险。我这边设的是主从延迟超过60秒持续3分钟触发P0告警，宁可严格一点，也不能等出问题再补救。
MySQL状态的采集，夜莺有两种方式：一种是通过collector自带插件直接连接MySQL获取，另一种是从mysqld-exporter拉数据，再通过remote write写入夜莺。我推荐前期先用自带插件，简单省事，等功能复杂了再换exporter方案，迁移成本也不高。
4.3 场景三：Web站点可用性监控
最后一个场景，适合没有专业拨测系统的团队。用夜莺做Web站点可用性监控，本质上是利用"HTTP拨测"的方式去请求你的URL，根据返回状态码判断网站是否正常。
做法是在目标服务器上配置一个HTTP拨测任务，比如每60秒请求一次你给前端服务准备的健康检查地址，如果返回码不是200，或者响应时间超过3秒，就触发告警。夜莺的指标库里会记录对应的状态码和响应耗时，把它们拿出来配置告警规则就行。
这个场景真心建议所有对外提供服务的网站都配上。我踩过的坑是，拨测脚本直接请求首页，结果首页包含太多动态内容，偶尔响应慢一点就误报。后来我改成请求一个专门的轻量健康检查接口，把动态页面排除在拨测范围外，误报率立刻降下来了。记住，监控的目的是发现"站真的挂了"，而不是发现"首页变慢了"，这两件事要分清。
5. 使用夜莺这段时间遇到的高频问题与排查思路
5.1 告警不触发的排查清单
告警不触发是所有监控系统使用过程中最让人挠头的问题。我自己整理了一个排查清单，顺序很重要，照着走能省不少时间：
- 先看数据在"即时查询"里能不能查到。查不到数据，后面都不用看了，问题出在采集或存储环节。
- 再看告警规则是否绑定了正确的机器和标签。很多漏告警其实是规则里的标签过滤条件和机器实际标签不匹配。
- 确认持续时间是不是太长。如果指标只是很短时间内超过阈值，没达到持续时长要求，自然不触发。
- 检查告警规则的启用状态和生效时间。别一不小心把它设成静默，或者还没到生效时间。
- 最后查一下历史事件里有没有"规则匹配到0条数据"这样的记录，有就说明是查询语句写错了，查不到数。
这块我特别想强调第一点。我遇过几次告警不触发，排查到最后，发现是采集器升级之后指标名变了，旧的指标不再产生数据，规则查出来永远是空。所以规则里只要出现查询结果为空的情况，多半是指标名、标签不匹配，先把数据确认好，再谈告警。
5.2 告警触发后收不到通知的几类原因
告警明明触发了，但通知没到，这类问题也挺常见。我遇到过的原因大致有三种：通知渠道配置错误、告警事件被静默、接收人设置没生效。
先说渠道配置错误。比如Webhook地址填的时候写成了http，服务端发请求时被网络策略拦掉，或者IM机器人的关键字没有匹配上夜莺推送的标题，消息直接被机器人过滤。这一类的解决思路很简单：先用一个测试告警去验证渠道，看服务端日志里有没有推送成功的记录。夜莺在系统日志里会记录每个通知任务的发送状态，排查起来比想象中要快。
再就是静默规则误伤。夜莺的静默可以按机器、标签、时间范围去匹配，有时候规则写得太宽，把本来需要收到的告警也挡掉了。所以一定要在告警规则列表里顺便检查一遍关联的静默策略，确保它们不会互相冲突。接收人设置这个就更常见了，尤其是新接手的团队，告警规则配好了，但通知组里还是空的，或者成员有效期过期了，通知自然送不出去。
5.3 数据断点与采集延迟的处理
大盘上突然出现一段空白，图表曲线空了，说明这个时间段没有数据落到时序库。数据断点的原因通常有这几种：采集器进程挂了、网络不通、服务端时序库存储空间满了、采集器本地时间跳变。
排查方法也很常规：去采集器那台机器上看进程状态和日志。夜莺的采集器日志会明确写下"heartbeat failed"或者"write data failed"之类的关键词，看到哪个报错就处理哪个。如果确认采集器一直在跑，但服务端还是查不到数据，就要检查时序库的存储空间了。我遇到过连续几天采集正常、大盘曲线突然断掉的情况，最后发现是时序库所在磁盘满了，后端进程虽然没死，但写不进去数据。
再补充一个关于时间跳变的坑。有些云服务器如果开启了时间同步，偶尔会出现时间跳变，采集器上报的时间戳如果比服务端当前时间晚，数据会直接被认为无效而丢弃。这个情况比较隐蔽，单看数据面板什么异常都看不到，但曲线就是缺一段。处理方式也简单，确认采集器所在机器的时间同步正常就行。
5.4 一些只有踩过坑才知道的经验
到这里，再分享几个我用夜莺这段时间总结出来的经验，不一定写在哪本手册里，但确实管用。
第一，标签命名要克制。我曾经给机器打了非常详细的标签，什么环境、角色、机房、负责人全都塞进去，结果标签维度越多，写查询语句越容易出错。现在我只保留三个固定标签：业务线、环境、角色，其他信息放在备注里。标签的用途是定位和筛选，不是做资产管理，别把两件事混在一起。
第二，告警规则要定期做减法。夜莺用久了，规则会越攒越多，很多历史规则可能在项目结束之后就没意义了。我的习惯是每个月清理一次，把触发次数极低和好几个月没触发过的规则拿出来重新验证，该删就删。规则库保持精简，告警信号才有价值，否则全是一堆条件写错的历史遗留规则，很容易把真正重要的告警淹没掉。
第三，周期性地做"告警演练"。比如故意把一台测试机的CPU打到100%，看看告警是否按预期触发、通知是否按预期到达。别等到真出故障了才去验证监控配置，那时候你会发现自己对系统运行状态的了解，其实没有想象中那么深。演练完记得复盘，把配置不合理的规则当场改掉，这套监控体系才会越用越顺手。
就拿告警演练这件事多啰嗦一句。夜莺说到底是一个工具，工具的价值不在于装得多花哨、规则配得多复杂，而在于故障发生时，它能不能第一秒就告诉你哪里出了问题。以我个人的经验，把采集器、告警规则、通知渠道、大盘这几件事踏踏实实跑顺，比追求一堆高级功能有用得多。下一篇我会接着聊聊夜莺在多机房场景下的集群部署和性能调优，如果你在实际使用中遇到了什么有意思的问题，欢迎一起交流。
：用 TaoToken 统一 Key 管理 HTML/CSS/JS 调试配置)
