服务器半夜宕机怎么第一时间知道

凌晨两点站点打不开，早上七点才发现，这种经历不少人有过一次。机器没挂的时候各项指标看着都正常，真出问题又没人第一时间知道，问题往往不在服务器本身，而在有没有人盯着它。监控要装哪几层、指标盯哪几个、告警怎么设才不被当成噪音、预算只有三百多能不能做，这篇按动手的顺序说一遍。

宕机是怎么被发现的

发现自己站点挂掉，通常只有三条路：用户跑来投诉、自己随手打开看看、监控主动发消息。前两条靠运气，等到用户开口，流量已经白白流走一段；自己随手打开更是碰巧。真正能把损失压住的只有第三条，所以别把监控当成装完就完的事。

监控要分两层来做。外层是探活，从别的机器往站点发请求，看首页能不能拿到 200、耗时多少；内层是指标采集，看处理器、内存、磁盘、网络、关键进程是否健在。只做外层，机器已经满载但页面还能打开时看不出苗头；只做内层，网络或线路断了又完全不知情。

探活的发起位置最容易做错。有人写个脚本在本机请求自己的域名，机器一重启、网卡一断，脚本跟着消失，等于没监控。探测点要放在另一台机器上，最好放在别的机房甚至别的城市，哪怕是一台最便宜的小机器也够用。请求的内容也要挑，只测首页会漏掉登录页、商品页、支付回调这些真正要紧的路径。

内层指标里，比处理器百分比更值得盯的是四件事：磁盘剩余空间、可用内存、并发连接数、关键进程是否存在。盘写满、内存被吃光、进程被挤掉，这三种故障在真实站点里出现的频率远高于处理器跑满，而且多数是慢慢积累出来的，不看曲线根本发现不了。

每次探测的结果都落一份记录，写清时间、响应码、耗时、失败原因。只看当下的提示灯没有意义，翻一周的记录才知道是偶发抖动还是持续恶化，排障时这份记录比任何截图都管用，也能在事后证明问题从什么时候开始的，跟服务商沟通时这份记录往往比口头描述更有分量，也能帮你判断该换机器还是该改程序。

该监控哪几个指标

可用性层面看三样：首页的响应码与耗时、关键内页的响应码、静态资源能不能取到。首页正常但图片和样式取不到，用户看到的仍然是一个残破页面，这类故障只测首页永远发现不了，把关键路径逐条挂上探测才有意义。探测间隔和超时时间也要定好，间隔太短容易误报，太长又会发现得太晚；同一条路径连测三次都失败才报警，能过滤掉大部分抖动。

机器层面看磁盘剩余、可用内存、交换分区占用、平均负载、并发连接数、带宽进出。阈值别照抄别人的百分之八十，按自己的业务曲线定，一个白天流量翻三倍的站和一个夜间跑批的站，合理的警戒线完全不一样。看曲线比看瞬时值更有用，趋势能提前几天把容量问题提醒出来，短时尖峰单独设一条线看。

应用层面看数据库连接数、慢查询条数、缓存命中率、队列堆积量、错误日志的增长速度。错误日志一天涨十倍，往往比任何硬件指标都更早发现问题，把它做成一条曲线，比事后翻文件高效得多。把这几条指标和系统曲线放在同一屏，交叉着看才看得出因果。指标项别贪多，超过二十条的大盘没人会每天打开看，只留能直接下结论的几条，剩下的需要时再查。每条指标后面写一句\"看到什么值该做什么\"，新人也能照着处理，值班交接时少解释一遍，也少一次互相猜。

告警通道怎么设才叫得醒人

告警先分级。站点打不开、磁盘超过九成这类属于致命，要能直接把人叫醒；负载偏高、慢查询增多属于警告，走普通消息；磁盘到七成、证书快到期属于提示，每天汇总一次发出来就够。级别错了，要么被无视，要么被烦到关掉。

通道至少留两条。一条走手机上的通知，一条走聊天工具或邮件，两条互为备份。只挂一种通道，遇到消息被折叠、通知权限被系统收走、网络临时不通，就整晚没人知道，事后翻记录只能看到一条没人读的提醒。

别把所有事都设成致命。天天半夜响的告警等于没有告警，人会自动过滤。真正该半夜叫人的只有业务不可用和数据可能丢失这两类，其余放到白天处理，判断标准写清楚，值班的人照着执行就行。

提醒的内容要写全：哪个站点、哪个指标、当前值多少、阈值是多少、从几点开始异常、先去执行哪条命令看什么。只发一句\"磁盘告警\"，收到的人还得自己从头查一遍，等于把时间又浪费一次。

设置静默和重复间隔。同一个故障十分钟内只发一次，不要每轮探测都推一条；恢复时补一条恢复通知，让人知道不用再看了。故障期间有人正在处理，可以手动静默一小时，避免消息把处理的人自己也淹没。

值班要有人真的看。机器能发消息，但没人盯着屏幕依然是零。两个人轮值，或者给自己定一条最低承诺，比如收到致命告警十五分钟内必须打开看一眼，做不到就把告警级别降下来重新设计。

定期演练一次。手动停掉一个服务，看告警多久到、内容对不对、按提示能不能查到原因、恢复通知有没有发出来。演练里暴露的问题比真故障便宜得多，一年做两三次足够，改完再练一遍确认有效。

便宜档也能做监控

三百多块的入门档能不能当监控机，答案是能。探活和指标采集本身不吃资源，六核十二线程配三十二 G 内存这类机型跑一套外部探活加日志收集绰绰有余，硬盘容量放半个月的指标数据也没压力。云途香港独服的入门档就属于这一类，拿来当专职监控机不算浪费，反而比把业务全压上去更耐用，出故障时也不会连着业务一起停。

比配置更重要的是位置。监控机千万别和被监控的机器放在同一台宿主机、同一个机柜，机房断电、交换机故障、上游线路抖动都会一起完蛋。放到另一个机房，成本几乎不变，抗风险能力完全不同。预算再紧，这一条也别省，同机房的监控等于自己给自己作证。

八百块那一档适合反过来用，二十四核四十八线程配三十二 G 内存和八百 G 固态，两 G 端口加四十 T 月流量，拿来跑业务才是它的位置，用来专职做监控属于错配。同系列的中档机型可以留一台作备用机，主站出事时顶上去，平时拿来跑测试和备份也说得过去，不白占一份钱。

算一笔账。一台入门机一个月的支出，大约等于一次小故障带来的订单损失，更别说被搜索引擎降权之后的恢复周期。监控不是额外开销，是把不可预期的损失换成固定的小额支出，这笔账怎么算都划算，尤其是对接单和转化直接挂钩的站点，一次深夜故障抵得上好几年的监控开销。

出事后怎么复盘

顺序永远是先恢复再分析。故障还在的时候翻日志找理论，用户还在打不开页面，时间全耗在推理上。手上要有能立刻生效的动作，重启服务、切备用机、回滚上一次变更，先把业务拉回来再说。

把时间线记下来。告警几点到、人几点介入、几点定位到原因、几点恢复，这四个数字决定这次到底算不算处理得快。凭印象回忆的时间线通常会美化自己，写在纸上的才靠得住。

找根因用排除法。是容量不够、是代码有 bug、是配置改错、是外部攻击，四类各自有对应证据。八成故障和最近一次改动有关，所以每次上线的记录都要留，时间、改了什么、谁改的，排查时第一时间对照。

复盘必须产出可执行的三样东西：改什么、谁负责改、什么时候改完。没有责任人和日期的复盘只是聊了一场天，下次同类问题照样发生，而且没人记得当初说过要修。

同类风险横向查一遍。这次是磁盘写满，就把所有机器的磁盘增长曲线都拉出来看；这次是内存被打满，就把所有跑着同样程序的服务都查一遍。故障暴露的往往不是单点问题，而是一类共通的设计缺陷，顺手改掉能省下后面几次同样的夜班。

把结论写进文档，放在下次有人值班时能看到的位置。文档不用长，一页写清现象、原因、处置、改进项和验证方法，比散落在聊天记录里的讨论有用得多。

监控本身别拖垮机器

采集频率别贪高。十五秒一次对绝大多数站点已经足够，一秒一次除了让数据库和磁盘多写几十倍数据，对发现问题几乎没有帮助。频次越高越容易把监控自己变成负载源，这个坑踩过的人不少，采集频率和业务负载之间要留出余量。

存储要做轮转。原始指标留十五天，按小时或按天聚合后的数据留一年，超期自动清理。见过监控数据把磁盘写满、然后业务跟着挂掉的案例，起因只是没设保留策略。清理任务要自动化，别指望有人记得手动删。

监控进程自己限资源。处理器份额、内存上限都设住，别让它和业务抢。真出现高峰时，宁可让监控掉几帧，也不能让前台页面变慢，主次关系要提前想清楚，资源上限写进配置文件，别留给默认值，默认值通常是给开发环境准备的。

探活脚本要轻。只发 HEAD 或者只取首页头部，别每次把全页和图片都拉一遍。探测点多了以后，这种浪费是成倍放大的，一个月能凭空多出几百 G 流量，额度紧的机型尤其要留意这一点，探活请求攒一个月也能抵掉一晚上的正常访问配额。

监控自己也要被监控。用一个完全独立的外部探活盯着监控服务本身，两边互相看着，才不至于出现监控挂了三天、所有人都以为一切正常的情况。两个探活点分属不同机房，才是真的互不牵连，成本加起来还不到一顿饭钱。