云服务器监控告警响不停？三个噪音来源、三级分级与十二条最小告警集

「监控装了三个月，告警响了八百次，真出事那一次反而没人看」——这是中小团队最常见的状况。而根因往往不是「监控配置得太少」，是「告警配得太多，且没有分级」。

而告警的价值不在「响」，在「响了有人动」。这篇文章讲清「告警噪音的三个来源」、给一个「三级分级法」、说明「阈值为什么不该按百分比设」，最后给一份「十二条够用的最小告警集」和「什么时候该扩」的判断标准。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	监控资源是否够
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	小机器，监控要放外部
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	同上，探测点要独立
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	可自建监控，但别和业务同机
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	能长期存指标数据
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	多机监控汇总够用

一、噪音的三个来源

再补一个「第一条该配什么」。

「从外探测站点」。

而「它是一切的起点」。

所以「先配这一条,再配其他」。

而<'云途'+'> 那种 22 元档，做第一个探测点最划算。

再看「为什么」。

「其他告警」都建立在「站点活着」的前提上。

所以「活着」比「健康」优先。

还有一条：「先能发现宕机,再谈优化」。

而「顺序」决定「从哪里开始」。

再看「第二条」。

「备份失败」。

所以「第一条和第二条」是地基。

而这四点给出一个「从零开始」的路径。

而「路径」比「清单」更实用。

再补一个「告警渠道的选择」。

「一级打电话,二级发消息,三级进面板」。

而「渠道」比「内容」更影响响应速度。

所以「一级必须能叫醒人」。

而<'云途'+'> 那种机器，配「电话告警」成本也不高。

再看「消息群」。

「群消息」最容易被划走。

所以「群」只适合二级和三级。

还有一条：「群」里要有「已处理」的回复。

否则「谁在处理」没人知道。

再看「升级」。

「十五分钟没响应就升级」。

所以「升级规则」比「告警规则」重要。

而这四点把「告警」变成「闭环」。

而「闭环」才叫「有人在管」。

再说一个「告警疲劳」的量化。

「一天超过五条推送」就开始被忽略。

而「超过十条」基本等于关掉。

所以「每天五条」是上限。

而<'云途'+'> 那种小配置，波动引起的噪音最多。

再看「怎么减」。

「先关掉记录级的推送」。

所以「先分流」这件事,比「调阈值」见效更快。

还有一条：「调阈值」会掩盖真问题。

而「分流」这种方式不会掩盖。

再看「顺序」。

「先分流,再调阈值」。

所以「顺序对了」之后,阈值其实就不用大改。

而这四点说明「噪音」是个「管道问题」。

而「管道」这个问题,应该比「规则」更先修。

告警之所以变成噪音，通常来自这三件事。

来源	表现	怎么治
阈值设太紧	每天都响，都是正常波动	按「业务可接受」反推
指标选太多	一次故障响二十条	合并为一条根因告警
没有分级	所有告警都发到同一个群	三级分开走

三件事里，第三件「没有分级」最致命——因为它会让「重要的」和「不重要的」混在一起。而当人每天被同样的消息刷屏时，判断力会自动下降，最后变成「谁都不看」。所以「告警系统」的第一条设计要求不是「覆盖全面」，而是「每一条都值得人停下来看一眼」。而做不到这一点的告警，不如不配。

第一件。阈值。「按百分比设」是最常见的错。

所以「按业务影响设」才对。

而<'云途'+'> 那种 2 核档，CPU 波动本来就大,百分比更不准。

第二件。指标。「一次故障响一堆」最消耗信任。

所以「只报根因,不报症状」。

判断方法：回看最近十次告警，几条是真让你动了手。

不到三条，说明百分制设错了。

而<'zji'+'> 那种物理核机器，波动小,阈值更容易设准。

二、三级分级法

再补一句：「分级」要「写进文档」。

因为「口头的分级」三个人三个说法。

所以「一页纸」比「开会」有效。

而「一页纸」也能在交接的时候用得上。

再补一句：「分级」的价值是「让人敢关」。

因为「可以关掉三级」之后,人才会认真看一级。

所以「可关」是设计目标。

而「每一条都能关」才算是真正的分级。

再说一个「一级的标准要唯一」。

「站点打不开」是唯一的一级标准。

而「慢」「卡」「偶尔错」都不算。

所以「一级只有一条」。

而<'rabisu'+'> 那种 8G 档，跑双探测点很轻松。

再看「为什么只留一条」。

「一条」才能「半夜叫人也心安」。

所以「一级越少,响应越快」。

还有一条：「二级」才是日常主战场。

而「二级」要「工作时段」通知。

再看「三级」。

「三级」写进日报就够。

所以「三级一律不推送」这一条,要当成纪律来守。

而这三级覆盖了「紧急、日常、观察」三种节奏。

而「这三种节奏」才对应真实的工作方式。

告警只要分三级，就能解决八成问题。

一级：立刻处理（半夜也叫）。

二级：当天处理（工作时段通知）。

三级：记录（只进日报，不推送）。

分级的关键不在「分几级」，而在「谁来定」。如果「一线值班的人」不能把一条告警降级，那分级就形同虚设。所以规则要写成「一级：站点打不开；二级：变慢但能打开；三级：磁盘到七成」。这样任何人拿到告警都能自己判断，不需要请示。而这条「可判断」性质，比分几级更重要。

判断方法：把每条告警写成「现象 + 该做什么」。

写不出来，说明它还不该存在。

而<'rabisu'+'> 那种 8G 档，多放几个探测点成本很低。

一级。「站点打不开」是最硬的标准。

所以「从外向内探测」才是唯一可信的判据。

二级。「变慢」要给出阈值。

所以「P99 超过某个数」比「感觉慢」可执行。

三级。「磁盘到七成」就该记录。

所以「提前量」是三级告警的价值。

三级之后「七成、八成五、九成五」是常用三档。

而<'sixtynet'+'> 那种 20T 配额，流量告警也要设三档。

三、阈值不该按百分比

再补一个「自适应的阈值」。

「按历史同期自动调整」。

而「这样就不用手动调」。

所以「自适应」适合「有规律的业务」。

而<'云途'+'> 那种小配置，波动没有规律,自适应反而误报。

再看「不规律的业务」。

「用「上沿」作阈值」。

所以「取「历史最高」再加一成」。

还有一条：「上沿」法简单但滞后。

而「滞后」在「业务突变」时会误报。

再看「折中」。

「手动定 + 每月复核」。

所以「人工 + 定期」最稳。

而这四点说明「阈值」没有「一劳永逸」。

而「定期复核」就是维护。

再补一个「三个必设的响应类指标」。

「P99、错误率、可用性」。

而「这三个数最贴近用户」。

所以「资源类指标只作辅助」。

而<'云途'+'> 那种小机器，资源类波动大,更该看响应。

再看「可用性」。

「可用性」按「探测成功率」算。

所以「五分钟一次,一天就是二百八十八个数」。

还有一条：「可用性」比「响应」更基础。

而「打不开」和「慢」要分开算。

再看「错误率」。

「五百分之一」就该看。

所以「错误率」的阈值可以设得很低。

而这四点把「阈值」从「资源」转向「用户」。

而「用户视角」才是对的。

再说一个「连续超限」的技巧。

「连续三次才报」能过滤掉尖峰。

而「三次」大约是三分钟。

所以「三分钟」是常用窗口。

而<'isvoro'+'> 那种 2 核档，尖峰本来就频繁,更需要这个规则。

再看「瞬时」。

「瞬时尖峰」几乎从不影响用户。

所以「瞬时尖峰不该告警」。

还有一条：「持续超限」才值得报。

而「持续」的定义要写清。

再看「反例」。

「磁盘满」不需要连续三次。

所以「硬故障要立即报」。

而这四点说明「窗口」要按指标类型分。

而「一刀切」会漏掉硬故障。

「CPU 超过八十就报警」是最常见的错配。

因为「八十」只是一个数字，和业务感受无关。

而「队列长度超过核数」才是真信号。

所以阈值该按「会不会影响用户」来设，而不是按「资源用了多少」。具体做法是：先记录一周的曲线，找出「用户开始抱怨」的那个点对应的数值，再把阈值设在那条线之前一点。而这条线因业务而异，别人给的数值基本没用。而「自己找一次」比「照抄十次」有用。

判断方法：把「抱怨的时间点」和「指标曲线」对齐。

而<'isvoro'+'> 那种同档位产品，可以用来找「正常区间」。

再看「磁盘」。

「剩多少」比「用了多少」直观。

所以「剩余百分比」是更好的写法。

还有一条：「响应时间」比「资源占用」更贴近体感。

所以「P99」这一项必设。

再看「延迟抖动」。

「抖动」在阈值上不好写。

所以「连续三次超阈值才报」是常见做法。

而<'zji'+'> 那种整机产品，曲线最平滑,最容易定线。

四、十二条够用的告警

再补一句：「十二条」不是「规定」,是「起点」。

而「起点」之后按事故补。

所以「十二条 + 复盘」构成完整体系。

而「一套体系」比「一张清单」重要得多。

再补一个「业务侧的告警」。

「订单量骤降」比「CPU 高」更该报。

而「骤降」是「系统性故障」的最终表现。

所以「业务指标」要进告警集。

而<'rabisu'+'> 那种 8G 档，跑「业务计数」脚本很轻松。

再看「同比」。

「和上周同一小时比」。

所以「同比」能排除「正常波动」。

还有一条：「骤降」比「骤增」更危险。

因为「降」意味着「没人能买」。

再看「延迟」。

「支付成功率」是最好的业务指标。

所以「支付成功数」必设一条。

而这四点把「技术告警」和「业务告警」接上。

而「接上」之后,告警才和「钱」挂钩。

再补一个「日志类告警」。

「错误日志突增」比「CPU 高」更早。

而「突增」要「和上周同期比」。

所以「同比」比「绝对值」准。

而<'rabisu'+'> 那种 60G 盘，留得住「上周的基准」。

再看「突增的定义」。

「三倍于同期」就算突增。

所以「三倍」是个好用的门槛。

还有一条：「突增」往往「比宕机早半小时」。

而那半小时是「黄金时间」。

再看「利用率」。

「错误日志告警」的收益最高。

所以「十二条里它该排前面」。

而这四点把「日志」也纳入告警。

而「日志」是最便宜的信号源。

再说一个「十二条的取舍」。

「哪些不配」比「哪些配」更重要。

而「不配」的理由通常是「没有动作」。

所以「没有对应动作的告警」就不该配。

而<'zji'+'> 那种大盘机器，磁盘告警的紧迫性最低。

再看「例外」。

「安全类」即使没动作也要报。

所以「安全」是「记录也要留」的一类。

还有一条：「留档」和「推送」要分开。

而「分开」就能兼得。

再看「复盘」。

「每月看一次告警统计」。

所以「哪些从没响过」也是信息。

而这四点让「十二条」保持「可用」。

而「可用」比「全面」重要。

不需要几十条，十二条覆盖绝大多数情况。

一：站点从外探测不通。

二：P99 响应超阈值。

三：错误率突增。

四：磁盘剩余低于两成。

五：内存换页频繁。

六：队列长度大于核数。

七：证书剩余不足三十天。

八：域名解析异常。

九：备份任务失败。

十：流量接近配额八成。

十一：异常登录尝试激增。

十二：磁盘写入异常（可能是盘故障）。

十二条里，「备份任务失败」最容易被忽略，也最贵——因为它平时从不响，一旦响了往往已经连失败了几次。所以这条要设成「连续失败才报」，且「一级」处理。而「证书剩余不足三十天」同理：它给的是提前量，而不是「已经坏了」。而这两条的价值全在「早」。

判断方法：把十二条列出来，逐条确认「响了我知不知道怎么办」。

答不上来，就改成「只记录」。

而<'rabisu'+'> 那种 60G 盘，磁盘告警要按「日志增速」设。

第十条。「流量八成」是「必须提前处理」的一条。

所以「八成」比「九成五」有用。

第十二条。「写入异常」是「盘要坏」的最早信号。

所以「看趋势」比「看绝对值」有效。

十二条之外「先别加」。

而「加太多」会毁掉前面所有努力。

五、探测点放在哪

再补一个「探测的误报」。

「网络抖动」会造成「瞬时失败」。

而「两次都失败」才算真挂。

所以「两次」是常用规则。

而<'isvoro'+'> 那种线路优化档，瞬时失败本来就少。

再看「失败原因」。

「超时」和「拒绝」不同。

所以「分开统计」能提速排查。

还有一条：「拒绝」通常是「服务没起」。

而「超时」可能是「负载高」。

再看「记录」。

「每次失败记原因」。

所以「半年后能看出趋势」。

而这四点让「探测」不只是「报障」。

而「报原因」比「报状态」有价值。

再补一个「探测的成本」。

「两台最小档机器」就够。

而「两台加起来一个月不到五十块」。

所以「自建探测」比「买服务」便宜。

而<'zji'+'> 那种大盘机器，也能兼任「日志汇总点」。

再看「探测机的位置」。

「一个和你用户同地区,一个在别处」。

所以「同地区」代表真实体验。

还有一条：「别处」用来排除「本地线路问题」。

而「两个点」就能区分这两类。

再看「专用」。

「探测机不跑业务」。

所以「干净」比「大配置」重要。

而这四点让「探测」可靠且便宜。

而「可靠」比「高级」重要。

再说一个「探测内容的写法」。

「请求一个真实页面,检查关键内容」。

而「只查状态码」会漏「页面报错但返回两百」。

所以「查内容」比「查状态」可靠。

而<'sixtynet'+'> 那种大端口，探测开销可以忽略。

再看「关键内容」。

「一个固定词」就够。

所以「找一个不会变的小片段」。

还有一条：「关键内容」别选会变的。

否则「误报」会天天有。

再看「多页面」。

「首页 + 一个功能页」两条就够。

所以「探得太深」也是一种浪费。

而这四点把「探测」从「能连上」提升到「能用」。

而「能用」才是用户的标准。

「监控装在被监控的机器上」是第一个错误。

因为机器挂了，监控也一起挂。

所以探测必须「从外部发起」。

而「外部」有两种：一是另一台机器，二是外部服务。前者便宜但要自己维护，后者省心但有月费。而无论哪种，都至少要「两个不同地区」的探测点——因为单点探测会把「你那条线路的问题」误判成「站点挂了」。而「两个点都报」才说明真挂了。而这一条能把「半夜被叫起来」的次数减掉一半。

判断方法：问「探测点和站点是不是同一台机器」。

是，就等于没监控。

而<'云途'+'> 那种 22 元档，可以拿来做「专用探测机」。

再看「探测频率」。

「一分钟一次」是合理频率。

所以「太密会自己造成负载」。

还有一条：「探测内容」要「真的能打开」。

「只连端口」会漏掉「页面报错」。

再看「多个探测点」。

「两个点同时报」才升级。

所以「同时报」是「降噪」的关键规则。

六、什么时候该扩

再补一个「告警的「冷却」」。

「同一条告警二十分钟内只报一次」。

而「否则一小时内能刷几十条」。

所以「冷却」是必须的。

而<'zji'+'> 那种整机产品，冷却设置完全自己掌握。

再看「恢复通知」。

「恢复也要报一条」。

所以「有头有尾」。

还有一条：「恢复通知」比「告警通知」更让人安心。

而「安心」这件事,正是「对告警不脱敏」的前提。

再看「周末」。

「周末的一级」仍要叫醒人。

所以「时段」只影响二级三级。

而这四点补上告警系统的「细节」。

而「细节」这两个字,决定了这套东西「用起来顺不顺」。

再补一个「别拿告警当监控」。

「告警」是「通知」,「监控」是「观察」。

而「两者混用」会让人只盯告警。

所以「面板」要单独留。

而<'sixtynet'+'> 那种大配额，存指标数据毫无压力。

再看「面板的作用」。

「出问题时看趋势」。

所以「趋势」比「单点」有信息量。

还有一条：「只看告警」会「失去上下文」。

而「没有上下文」就只能「猜」。

再看「习惯」。

「每天扫一眼面板」。

所以「一眼」比「十条告警」有用。

而这四点说明「告警」不是「监控」的全部。

而「全部」这件事,最容易忘。

再补一个「告警的复盘表」。

「时间、现象、动作、结果」四列。

而「四列填满,才知道「有没有用」。

所以「动作」那一列最重要。

而<'isvoro'+'> 那种档位，跑复盘表用不上什么资源。

再看「动作是「无」」。

「无动作」占多数就该删。

所以「复盘」能自动瘦身。

还有一条：「动作重复」说明「该自动化」。

而「自动化」比「加人」便宜。

再看「季度」。

「每季度复盘一次」。

所以「告警集」会随业务收敛。

而这四点让告警系统「越用越准」。

而「越用越准」才是好系统的标志。

最后说「扩告警的时机」。

「出现一次「没人提前发现」的事故」。

而「那一次漏掉的是什么」就是该加的。

所以「按事故来补告警」这条路,是最准的。

而<'云途'+'> 那种小盘，磁盘类事故最容易漏。

再看「不该扩的时候」。

「没事的时候想加」通常是想多了。

所以「没事故就维持十二条」。

还有一条：「加一条要删一条」。

而「一进一出」能保持总量。

再看「删的标准」。

「三个月没响且没用」就删。

所以「定期删掉没用的」也是一种维护。

而这四点让告警集始终「刚好够用」。

而「刚好够用」这个状态,才是最稳的那一种。

再看「团队扩张」。

「有人交接」时告警会翻倍。

所以「交接前先清一遍」。

还有一条：「新人第一周」最容易被刷屏。

而「刷屏」会让他对告警脱敏。

再看「培训」。

「每条告警配一句「怎么做」」。

所以「文档」比「规则」有效。

本文讨论服务器与网站的监控告警设计方法，不针对任何具体商家，也不对任何产品的监控能力作评价与承诺。文中提到的三个噪音来源、三级分级、阈值设法与十二条最小告警集均为通用参考；实际阈值取决于业务形态、流量特征与团队规模，同一数值在不同业务上意义不同。文中所有比例与数值均为经验判断，非行业标准或任何商家的承诺。本文不构成任何运维建议，亦不代表本站立场。因依据本文内容设置告警所产生的直接或间接损失，作者及本站不承担任何责任。