云服务器可观测性：监控、告警与故障排查的实战手册
正文
出事时最怕的不是故障，是不知道故障在哪
凌晨两点，一个客户的 API 突然大面积超时，值班的同事被电话叫醒，登录控制台看了一圈，机器在线、CPU 不高、磁盘也没满，一切"看起来正常"。等我们赶到，登录机器一条一条命令试，才发现是数据库里一条没走索引的慢查询把连接池占满了。从接到电话到定位到根因，整整花了四十多分钟。真正让人难受的不是这次故障本身，而是这四十分钟里，没有任何一个地方告诉他们"问题在哪"。
故障是运维的常态，机器不会因为你的谨慎就永远不出问题。真正决定损失大小的，是你从"知道出事了"到"知道哪里坏了"这段定位时间有多短。 可观测性要解决的就是这件事：它不是为了画一堆好看的图表，而是让你在被叫醒的那一刻，能用最短的路径回答三个问题——哪里坏了、严重到什么程度、接下来该做什么。
顺带说一句搜索习惯的事。不少人是搜"ESC 云服务器运维"进来的，其实"ESC"是一处常见的拼写或记混，大家真正想找的是"弹性云服务器"。在腾讯云，这个产品的正式名字是 CVM，也就是云服务器；本文讲的所有监控与排查方法，针对的就是 CVM 这套体系，命令和思路换到别的平台也通用。
可观测性的三层：指标、日志、链路
业界把可观测性拆成三个支柱，我习惯按"发现—定位—追根"的顺序来理解它们。
指标。指标是时序数据，采样频率高、存储开销低，适合看趋势和做告警。腾讯云的产品是云监控，自带基础监控，覆盖 CVM 的 CPU、内存、磁盘、网络等基础项；你还可以用自定义监控上报业务指标，比如订单量、队列积压深度。指标的优势是便宜、快、能画曲线，缺点是它只告诉你"某个数字不对劲"，不告诉你"为什么"。
日志。日志是细节，是事后取证的地方。系统日志、应用日志、访问日志，记录了每一个请求、每一条报错。腾讯云对应的产品是日志服务 CLS，能做采集、检索、统计和告警。指标的曲线会告诉你"错误率涨了"，日志则会告诉你"错误率涨的是哪个接口、报的什么错、堆栈在哪一行"。没有日志的告警，等于让你猜；有了日志，定位才有落点。
链路。链路追踪解决的是分布式系统的调用问题。一个请求经过网关、若干微服务、缓存、数据库，到底是哪一跳慢了，靠指标看不出，靠单机日志也拼不起来，要靠 Trace：一个请求 ID 串起完整调用链，哪一步耗时最长一目了然。腾讯云侧可用应用性能监控类的产品来采集。
三层的配合方式是固定的：指标负责发现异常并告警，日志负责把异常落到具体的错误和代码，链路负责在分布式场景里找到拖后腿的那一跳。先把指标做全，再补日志，最后上链路，这个顺序不要反。
必须盯住的指标清单
监控项不是越多越好，而是一定要覆盖"会直接导致用户感知故障"的那几类。下面这张表是我给客户做巡检时最常用的一份底线清单。
监控指标 建议阈值参考 常见根因 处置动作
CPU 使用率 持续超过八成为预警，拉满五分钟为紧急 死循环、慢查询、流量突增、挖矿程序 top 定位进程后限流或扩容
内存使用率 超过八成五且无明显回收 内存泄漏、缓存无上限、并发过高 看进程 RSS 与 swap 后重启或调参
磁盘使用率 超过八成为预警，超过九成为紧急 日志堆积、核心转储、上传目录膨胀 du 逐层定位大目录后清理或扩容
inode 使用率 超过八成需关注 海量小文件，如会话与缓存碎片 df -i 查看后清理临时文件
磁盘 IO 等待 平均 await 长期偏高 机械盘随机读、数据库热点写入 iostat 定位后用 SSD 或优化读写
公网出带宽 达到所购峰值的八成 被刷、盗链、爬虫、被转载 iftop 定位来源后套 CDN 并限速
TCP 连接数 接近连接上限或突然激增 连接泄漏、SYN 攻击、超时未回收 ss 统计连接状态后调内核参数
TCP 重传率 明显偏高且持续 网络抖动、丢包、跨地域链路差 mtr 定位丢包段后换线路或可用区
这八项不一定每台机器都全设，但一个对外提供服务的 CVM，CPU、内存、磁盘三项是底线，网络两项面向公网业务是底线。阈值不要照搬别人的数字，要结合你自己业务的正常水位来定，别人八成才算高，你的业务可能四成就该看一看了。
告警策略怎么设计才不会被静音
告警最大的敌人不是漏报，是误报太多之后被人为静音。一旦团队养成"这个告警不用管"的习惯，真正的故障来的时候也就没人看了。让告警有效，有几条原则。
分级。把告警分成 P0、P1、P2 三级。P0 是用户已经在受影响的问题，走电话加短信；P1 走短信或企业微信；P2 走邮件或群消息。不要所有告警都往同一个渠道推，否则等于没有分级。
阈值加持续时间。单点瞬时飙高不算故障，要设置"持续 N 分钟"才触发。比如 CPU 超过八成并持续五分钟才告警，这样能过滤掉大量抖动带来的噪音。
组合条件。多个指标同时越界才告警，比单指标更容易命中真故障。例如"CPU 高且错误率同步上升"，就有很强的问题指向性。
收敛与静默期。一个根因往往引发一片告警，要设置收敛规则和静默窗口，避免告警风暴把值班人的手机打爆。但静默要有期限、要有记录，不能变成永久性忽略。
有行动项的告警。每条告警的描述里要写清"接到后第一步做什么"。一条只写"CPU 高"的告警，值班人还得自己想，等于把定位时间又拉了回来。
定期复盘告警质量。误报率高的规则应该被改，而不是被静音。 每季度回看一次告警记录，把长期无人处理的规则要么修阈值、要么删掉，让告警列表始终"每一条都值得看"。
高频故障排查手册：CPU 飙高、磁盘写满、网络丢包
先记住一条原则：上机器之前，先在云监控里看时间线，确认是什么时候开始异常的、哪个指标先动。对着时间线排查，比一上来就重启机器高效得多，也安全得多。
CPU 飙高。第一步 top 或 htop，按 P 排序，看是谁在吃 CPU。重点看几个数字：us 是用户态、sy 是内核态、wa 是 IO 等待、si 是软中断。如果 wa 很高，那根本不是 CPU 忙，是磁盘 IO 卡住了，去查 iostat；如果 sy 很高，可能是系统调用或中断异常，比如网络被打；如果 us 高且是某个应用进程，再进一层看是慢查询还是死循环。pidstat 能按进程看 CPU 明细，配合 journalctl 看应用日志。找到根因之前别急着重启，重启只是把症状藏起来。
磁盘写满。先 df -h 看是哪个分区满了，再 df -i 看 inode 是不是爆了——inode 满和空间满是两回事，表现都是"写不进去"，但解法完全不同。定位大文件用 du -sh 逐层往下钻。有一个坑很多人踩过：删了日志，df 看空间却没释放。那是因为文件被进程打开着，删除的只是目录项，进程不退出空间就不回收。用 lsof 加上查找已删除文件的参数就能找到这种"幽灵文件"，重启对应进程即可释放。
内存异常。free -h 看物理内存和 swap，ps aux 按内存排序看谁是消耗大户。重点关注 RSS 持续增长、swap 被频繁使用的情况，这通常是内存泄漏或者缓存没设上限。
网络丢包。先用 ping 看有没有丢包和延迟，再用 mtr 或 traceroute 看丢在路径的哪一段——是本地出口、骨干还是对端。iftop 看是谁在占带宽，ss 看连接状态分布，统计各种状态的连接数量，大量 TIME_WAIT 或 SYN_RECV 都说明有问题。ip -s link 能看网卡自身的丢包计数。如果是应用层偶发超时，别只看网络，去看应用和数据库的慢查询日志：很多"网络问题"最后都被证明是一条走错索引的 SQL。
自动化运维：从人工重启到自愈
排障能力再强，也是在人肉救火。运维的进化路径大致是这样几级：人肉发现、人肉处理，到脚本化处理，到定时任务，再到事件驱动的自愈。
腾讯云上可用的抓手不少。云监控负责发现异常，自动化助手可以远程批量下发命令，弹性伸缩组能在负载升高时自动扩容，负载均衡的健康检查会把不健康的实例自动摘掉。把这些串起来，就能实现一些简单的自愈：磁盘水位超过阈值自动清理临时文件；服务进程假死自动重启；实例健康检查失败自动替换；流量突增自动扩容。
但自愈一定要有护栏。我见过最糟的情况是自愈脚本本身出了问题，把整个集群反复重启，故障范围比原故障还大。所以自愈动作要有频率上限、要能一键停用、每一次动作都要有可审计的记录。还有一条铁律：先做好可观测，再做自愈。没有监控的自愈不是自动化，是瞎重启。
一次完整的故障复盘（时间线写法）
复盘的价值在时间线。下面用一次典型的数据库慢查询导致 API 故障来演示怎么写。
T+0，监控发现 API 平均响应时间从正常水位抬升，P95 延迟告警触发。
T+3 分钟，值班人确认告警，登录云监控看时间线，发现 CPU 与数据库连接数同步上涨。
T+8 分钟，登录机器执行 top，看到数据库进程 CPU 偏高，连接数接近上限。
T+12 分钟，查数据库当前运行语句，定位到一条缺少索引的查询，在流量高峰被反复执行。
T+18 分钟，临时为该查询加上索引，连接池逐步回落。
T+25 分钟，响应时间回到正常水位，告警解除。
T+40 分钟，确认无数据异常，事件关闭。
复盘要写清四样东西：影响面（影响了多久、多少用户）、根因（那条 SQL 为什么突然变慢）、处置过程（每一步做了什么）、改进项（谁负责、什么时候完成）。改进项通常包括：给同类查询补索引、给慢查询设专门告警、给数据库连接数设独立阈值、把慢查询日志纳入日常巡检。复盘不是追责会，它的目的是补上这次暴露出的监控盲区，让下次同类问题能被更早发现。
FAQ
Q：腾讯云自带的云监控够用吗，还需要装 Agent 吗？
A：基础监控能覆盖 CPU、网络、磁盘等主机级指标，日常够用。但如果你要看内存细节、进程级指标、业务自定义指标，通常需要装监控 Agent。折中做法是先用基础监控兜底，缺哪块补哪块，不必一上来就全量上 Agent。
Q：云监控告警为什么没有发出来？
A：先按顺序排查四件事：告警规则是不是被停用或处于静默期；阈值是否设置了"持续时长"导致还没到时；通知渠道和接收人是否配置正确、是否被退订；触发条件是不是组合条件导致单指标越界也没报。多数"告警没发"最后都落在这四条上。
Q：搜"ESC 云服务器"和腾讯云 CVM 是同一个东西吗？
A：本质上是一回事，"ESC"多是拼写或记混，指的是弹性云服务器，腾讯云的正式产品名是 CVM。你在别处看到的 ESC 相关运维方法，核心思路可以直接迁移到 CVM 上，命令和指标体系基本通用。
Q：删了日志，磁盘空间却没释放怎么办？
A：多半是文件被进程打开着。删除只移除了目录项，进程不退出，空间就不会回收。用 lsof 查找处于已删除状态但被占用的文件，定位到对应进程后重启它，空间即刻释放。更规范的做法是让日志按大小滚动并定期清理，而不是靠手动删。
结语
可观测性的本质，是让你在故障面前不靠猜。给你三条能马上做的：第一，今天就去云监控里把 CPU、内存、磁盘和公网出带宽的告警配起来，阈值结合自己的正常水位定，并加上持续时间过滤抖动。第二，把日志接进日志服务，保证任何一个错误都能被检索到，而不是散落在各台机器上。第三，用一周时间做一次故障演练，故意制造一次人为的异常，看你的告警多久能发现、定位要多快，把暴露出来的盲区补上。
如果你手上服务一多、告警一乱，把当前的监控项和告警记录整理一份交给服务商复盘，往往能一次性砍掉一半没用的告警，也顺手补上真正该有的那几条。
如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。