上一篇把夜莺部署完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 205分钟P2内存使用率mem.used_percent 905分钟P2根分区空间disk.used_percent 8510分钟P1系统负载load1 810分钟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%看看告警是否按预期触发、通知是否按预期到达。别等到真出故障了才去验证监控配置那时候你会发现自己对系统运行状态的了解其实没有想象中那么深。演练完记得复盘把配置不合理的规则当场改掉这套监控体系才会越用越顺手。就拿告警演练这件事多啰嗦一句。夜莺说到底是一个工具工具的价值不在于装得多花哨、规则配得多复杂而在于故障发生时它能不能第一秒就告诉你哪里出了问题。以我个人的经验把采集器、告警规则、通知渠道、大盘这几件事踏踏实实跑顺比追求一堆高级功能有用得多。下一篇我会接着聊聊夜莺在多机房场景下的集群部署和性能调优如果你在实际使用中遇到了什么有意思的问题欢迎一起交流。
夜莺监控实战：从采集器接入到告警通知的完整配置指南
上一篇把夜莺部署完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 205分钟P2内存使用率mem.used_percent 905分钟P2根分区空间disk.used_percent 8510分钟P1系统负载load1 810分钟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%看看告警是否按预期触发、通知是否按预期到达。别等到真出故障了才去验证监控配置那时候你会发现自己对系统运行状态的了解其实没有想象中那么深。演练完记得复盘把配置不合理的规则当场改掉这套监控体系才会越用越顺手。就拿告警演练这件事多啰嗦一句。夜莺说到底是一个工具工具的价值不在于装得多花哨、规则配得多复杂而在于故障发生时它能不能第一秒就告诉你哪里出了问题。以我个人的经验把采集器、告警规则、通知渠道、大盘这几件事踏踏实实跑顺比追求一堆高级功能有用得多。下一篇我会接着聊聊夜莺在多机房场景下的集群部署和性能调优如果你在实际使用中遇到了什么有意思的问题欢迎一起交流。