ECS智能巡检实战：从传统监控到AI诊断的运维升级

1. 从半夜被告警叫醒说起ECS 巡检到底难在哪做运维的同行大概都有过这种体验凌晨两点手机响了监控告警说某台 ECS 的 CPU 飙到 95%你迷迷糊糊爬起来连上去看发现是个日志轮转脚本卡住了又或者某台机器磁盘悄悄写满等到业务报错才发现一查是某个临时目录堆了几个 G 的 core dump。这类问题的共同点是——它们都不是突然发生的而是有一个缓慢恶化的过程只是没人盯着等它爆出来的时候已经晚了。传统做法无非两条路。一条是靠人肉巡检写个 checklist每天上班挨个登机器敲df -h、top、free -m看一圈心里踏实。这套方法在机器数量个位数的时候还能撑住一旦上了几十上百台人力根本覆盖不过来而且人是有惰性的今天忙了就跳过明天忘了又跳过巡检记录形同虚设。另一条路是堆监控Zabbix、Prometheus 加一堆 exporter阈值告警配一大堆。监控确实能解决指标越界的问题但它解决不了综合判断的问题——CPU 高不一定有事磁盘 80% 不一定危险真正要命的是多个指标叠加出来的隐性风险而阈值告警是单点的、割裂的。STAROps 主机智能巡检想干的就是把这两条路的短板补上。它给每台 ECS 配一个24 小时在线的 AI 医生这个医生不是简单地读几个指标然后跟阈值比大小而是像老运维一样把一台机器的 CPU、内存、磁盘、网络、进程、日志、内核参数、系统配置综合起来看给出这台机器现在健不健康、哪里有问题、建议怎么处理的判断。关键词里的 SysOM 是这套体系的底层支撑它负责把主机层面的可观测数据采集上来STAROps 则在上层做智能分析和巡检编排。这篇文章适合谁看如果你是负责几十到上千台 ECS 的运维或 SRE每天被琐碎的机器问题消耗精力那这套思路值得你花时间研究如果你是刚接触主机运维的新人想搞清楚一次专业的巡检到底该看什么这里面的检查项清单和判断逻辑也能直接拿来用。我不打算把它写成产品说明书而是按一个真实运维的视角把巡检这件事拆开讲透——为什么要这么设计、每个环节的坑在哪、实际落地时怎么调。2. 智能巡检和传统监控的本质区别从报警器到诊断医生很多人第一次听到智能巡检会下意识觉得不就是监控加个 AI 吗这个理解偏差挺大的也是落地时最容易走弯路的地方。我先把这两者的定位掰扯清楚后面讲具体实现你才不会迷糊。2.1 监控是越界报警巡检是综合体检监控的核心逻辑是阈值比对。你设一个规则CPU 使用率超过 90% 持续 5 分钟就告警。这套逻辑简单、实时、可靠但它有个天然缺陷——它只回答某个指标有没有越界不回答这台机器整体怎么样。举个特别典型的例子。一台跑数据库的 ECSCPU 长期在 70% 左右内存用了 85%磁盘 IO wait 有点高。单看每个指标都没触发告警阈值监控面板一片绿。但实际上这台机器已经处于亚健康状态内存 85% 意味着 page cache 回收压力大IO wait 高说明磁盘快成瓶颈了这时候如果业务量再涨一点很可能直接雪崩。监控不会告诉你这些因为它只看单点。巡检的逻辑完全不同。它模拟的是一个有经验的运维登机器后的思考过程先看整体负载再看资源分布然后看有没有异常进程、有没有错误日志、关键配置有没有被改过。它输出的是一个体检报告而不是一堆孤立的数字。STAROps 的智能巡检就是把这个思考过程产品化了而且用 AI 把经验判断这部分做得更细。2.2 为什么AI 医生这个比喻是贴切的我一开始也觉得AI 医生有点营销味但用下来发现这个比喻其实挺准。医生看病分几步问诊采集症状、检查量指标、诊断综合判断、开方给建议。智能巡检的流程几乎一模一样。采集阶段对应问诊和检查SysOM 负责把主机上的各类数据拉上来包括但不限于 CPU 各维度使用率、内存分布、磁盘容量和 IO、网络连接状态、进程列表、系统日志、内核参数。诊断阶段对应综合判断这是 AI 真正发挥作用的地方——它不是简单跑规则而是能识别出这几个指标的组合意味着什么。比如内存使用率高 swap 使用率上升 大量进程处于 D 状态这个组合指向的是内存压力导致的 IO 阻塞而不是单纯的内存不够。开方阶段就是给出可执行的建议比如建议清理 /var/log 下超过 30 天的日志或者建议检查某进程是否存在内存泄漏。2.3 巡检频率和监控频率不是一回事这里有个实操中很容易踩的坑有人把巡检任务配成每分钟跑一次结果把机器自己拖垮了。巡检和监控的采集频率逻辑完全不同。监控采集是轻量的读几个/proc下的文件开销极小秒级甚至亚秒级都没问题。但巡检要做的事情重得多——它可能要遍历进程树、扫描日志文件、检查大量配置文件、做综合分析。这种操作如果高频跑本身就是一种负载。我的经验是常规巡检一天一到两次足够比如凌晨业务低峰期跑一次全量体检。对于核心业务机器可以加一次白天的高峰期巡检重点看资源水位和异常进程。真正需要秒级响应的还是交给监控告警巡检负责的是定期深度体检和发现慢性问题两者是互补关系不是替代关系。3. SysOM 在底层做了什么数据采集这一环决定巡检质量智能巡检的上限取决于底层数据采集的质量。如果采集上来的数据本身就不全、不准、不及时上层的 AI 再聪明也是垃圾进垃圾出。SysOM 在这套体系里的角色就是数据底座我把它干的事拆成几块讲。3.1 主机可观测数据的几个层次一台 Linux 主机能采集的数据粗略分可以分成四层从浅到深层次典型数据采集方式巡检价值资源层CPU、内存、磁盘、网络/proc、/sys判断整体水位进程层进程列表、线程、句柄、状态/proc/[pid]定位异常进程配置层内核参数、系统配置、服务状态sysctl、systemd发现配置漂移日志层系统日志、应用日志、内核日志journald、文件发现隐性错误资源层的数据大家最熟top、free、df这些命令看的就是这一层。但真正能体现巡检价值的往往是下面三层。进程层能告诉你是谁在吃资源配置层能告诉你机器有没有被人偷偷改过日志层能告诉你有没有反复出现的错误被忽略了。SysOM 的价值在于它把这四层数据都标准化采集了而且是在不侵入业务的前提下。它通过内核模块和用户态 agent 配合把主机层面的可观测性做深这是普通 exporter 做不到的。比如它能拿到更细的进程级 IO 统计、更准的内存分布包括 slab、page cache 的细分这些数据对诊断内存到底被谁吃了这种经典难题特别有用。3.2 采集开销控制别让医生把病人累着采集本身是有成本的这个成本必须控制住否则巡检就成了新的负载源。SysOM 在这方面做了几件事值得说。第一是采样而非全量。比如进程列表不是每次都把几千个进程的完整信息拉一遍而是按需采样重点关注资源占用靠前的进程和状态异常的进程。第二是聚合而非原始。很多指标在采集端就做了聚合比如 CPU 使用率是按时间窗口算好的而不是把原始 tick 数传上去让上层算。第三是分级采集。常规巡检用轻量采集深度诊断时才开启全量采集避免平时就背着高开销。提示如果你自己搭类似的采集体系一定要在测试环境压测采集 agent 的开销。我见过采集 agent 自己吃掉 10% CPU 的案例那就本末倒置了。3.3 数据的时间维度巡检要看趋势不只是快照单次快照能发现现在有问题但发现不了正在变坏。智能巡检的一个关键能力是看趋势。比如磁盘使用率今天 60%昨天 55%上周 50%这个缓慢上升的趋势比现在 60%更值得警惕——按这个速度两周后就满了。SysOM 采集的数据带时间戳STAROps 在做分析时会把历史数据拉出来做趋势判断。这就要求数据得存得住、查得快。实操中我建议至少保留 30 天的巡检数据核心指标保留 90 天这样趋势分析才有意义。存储成本其实不高因为巡检数据是聚合后的不是原始流水。4. 一次完整的智能巡检跑下来AI 到底在判断什么这部分是核心。我把一次巡检从触发到出报告的过程拆开重点讲 AI 在每个环节的判断逻辑以及这些逻辑背后的运维经验。4.1 巡检项编排不是检查项越多越好新手做巡检容易犯的错是贪多恨不得把能查的都查一遍结果报告几十页没人看得完。真正有效的巡检是有重点的STAROps 的巡检项编排思路我比较认同它把检查项分成几类。第一类是必查项也就是任何机器都该看的CPU 负载、内存水位、磁盘容量、关键进程存活、系统日志错误。这些是底线出问题直接影响业务。第二类是场景项根据机器角色动态加载。比如数据库机器要重点看 IO 和连接数Web 服务器要重点看网络连接和文件句柄大数据节点要重点看磁盘和内存。第三类是安全项检查有没有异常登录、有没有可疑进程、关键文件权限有没有被改。这种分类的好处是报告有层次运维一眼能看出哪些是必须马上处理的哪些是了解一下就行。我在实际用的时候会把必查项的告警直接推到值班群场景项和安全项汇总成日报避免信息过载。4.2 异常识别的三种模式AI 在巡检里识别异常主要靠三种模式理解这三种模式你就能明白它为什么比阈值告警聪明。第一种是静态阈值这个和传统监控一样超过某个值就标记。但巡检里的阈值可以更宽松因为它不是实时告警而是体检标记。比如磁盘 85% 在监控里可能不告警但巡检会标记为需要关注因为体检的目的是提前发现。第二种是动态基线。这是 AI 发挥作用的地方。同一类机器在相似业务量下指标应该在一个范围内波动。如果某台机器的指标明显偏离了同类机器的基线即使没超阈值也会被标记。比如十台 Web 服务器九台的连接数都在 2000 左右有一台常年 8000这就值得查——可能是负载均衡配置有问题也可能是这台机器上有异常连接。第三种是关联分析。这是最能体现医生思维的部分。单个指标正常但组合起来异常AI 会识别这种模式。我整理了几个常见的关联模式关联模式涉及指标可能的根因内存压力型内存使用率高 swap 上升 D 状态进程多内存不足导致 IO 阻塞IO 瓶颈型IO wait 高 磁盘队列长 应用响应慢磁盘成为瓶颈连接泄漏型文件句柄数持续上升 连接数高 内存缓涨连接未释放配置漂移型内核参数与基线不符 近期无变更记录配置被误改这种关联分析靠人工写规则很难穷举AI 的优势在于它能从大量历史数据里学到什么样的组合通常意味着什么问题而且能持续更新。4.3 从发现问题到给出建议的最后一公里巡检报告最没用的形态是列出一堆问题但不告诉你怎么办。STAROps 在建议生成这块做得比较实在它的建议是分级的而且尽量可执行。我举几个实际报告里的建议例子你感受一下颗粒度磁盘/var/log使用率 88%建议清理 30 天前的日志预估可释放 12GB命令参考find /var/log -name *.log -mtime 30 -delete执行前请确认日志已归档。某进程内存占用持续增长7 天内从 500MB 涨到 2.3GB疑似内存泄漏建议排查该进程的堆内存使用必要时重启并观察。系统net.core.somaxconn当前值 128低于同类机器基线 1024建议评估后调整调整命令sysctl -w net.core.somaxconn1024。这种建议的价值在于它把发现问题和解决问题之间的鸿沟填上了。运维不需要再去查资料、算影响直接照着做或者评估一下就能处理。当然建议只是建议涉及重启、改配置这种操作还是得走变更流程不能无脑执行。5. 落地实操把智能巡检接进你的日常运维流程前面讲的都是原理和设计这部分讲怎么真正用起来。我按从零到跑通的顺序把关键步骤和坑都列出来。5.1 接入前的准备先搞清楚你的机器画像在配巡检之前先花半天时间把机器盘一遍做个体检。要搞清楚几件事机器总数和分布哪些是核心业务、哪些是边缘、每类机器的角色Web、DB、缓存、大数据等、每类机器的正常水位大概是多少。这一步很多人跳过结果巡检配出来全是误报。比如你给一台本来就跑满 CPU 的压测机配了 CPU 告警那它天天告警你就麻木了。机器画像清楚了巡检项和阈值才能配得准。我一般会做一个简单的表格把机器按角色分组每组记录正常情况下的 CPU、内存、磁盘水位范围。这个表格后面配巡检基线的时候直接能用。5.2 巡检策略配置频率、范围、通知怎么定配置巡检策略核心就三个问题多久跑一次、跑哪些机器、结果发给谁。频率前面说过常规一天一到两次核心机器可以加一次。范围建议分批接入先拿几台非核心机器试跑一周看看报告质量和误报率调好了再铺开。通知这块要克制必查项的问题实时推其他项汇总成日报别什么都往值班群推否则就是新的告警疲劳。注意巡检任务本身要错峰。如果你有 500 台机器别让它们在同一分钟全部开始巡检那会对采集端和存储端造成瞬时压力。建议按机器分组每组间隔几分钟错开跑。5.3 报告解读怎么从一堆检查项里抓重点巡检报告出来了怎么快速抓重点我的习惯是先看红黄绿的整体评级红色项优先处理黄色项排期处理绿色项扫一眼确认没有异常趋势就行。然后重点看两类内容一类是新增问题也就是这次巡检新出现的这类往往是最近变更引入的处理优先级高另一类是持续恶化项比如磁盘使用率连续几次巡检都在涨这类是慢性病得治根。报告里如果有趋势图一定要看趋势单次快照容易骗人。5.4 和现有监控、工单系统的配合智能巡检不是孤立的它得和现有体系配合。我的做法是巡检发现的紧急问题自动生成工单派给对应负责人巡检发现的趋势性问题进周会讨论巡检报告作为月度健康度评估的输入。和监控的配合是互补监控负责实时告警巡检负责定期体检。监控告警触发后可以手动触发一次该机器的深度巡检帮助快速定位。这个联动用起来很顺手相当于告警之后自动叫了个专家会诊。6. 踩过的坑和攒下的经验这些细节文档里不会写这部分是我自己用下来最有价值的沉淀都是文档里不会写、但实际会遇到的。6.1 误报是最大的敌人没有之一智能巡检落地失败的头号原因就是误报太多运维看几次就不看了。误报来源主要有几个阈值配得太紧、基线没考虑业务波动、关联规则太敏感。我的应对办法是先松后紧。刚接入的时候阈值放宽宁可漏报不可误报等积累了一段时间数据摸清了正常波动范围再逐步收紧。另外一定要给巡检项加白名单机制比如某些机器就是 CPU 高那就把它排除在 CPU 告警之外别硬套统一规则。6.2 采集 agent 的版本管理容易被忽略SysOM 的采集 agent 是要升级的升级过程中如果管理不当会出现部分机器新版本、部分老版本的混乱导致数据格式不一致上层分析出错。我吃过这个亏后来定了规矩agent 升级必须分批灰度先升 5% 观察一天没问题再全量而且升级窗口避开业务高峰。6.3 巡检数据的安全和权限巡检数据里包含进程列表、配置信息、日志片段这些是有敏感性的。权限管理必须做好谁能看哪些机器的巡检报告、谁能触发巡检、谁能修改巡检策略都要有明确划分。我建议巡检数据的访问权限和机器本身的访问权限对齐能登这台机器的人才能看这台机器的巡检报告避免越权。6.4 AI 建议要参考不要照做AI 给的修复建议尤其是涉及改配置、重启服务、删文件的一定要人工评估后再执行。AI 是基于通用经验给的判断它不知道你这台机器的特殊业务逻辑。我见过有人直接照着建议删了日志结果删掉的是正在被审计用的日志惹了麻烦。记住AI 是助手决策权在人。7. 智能巡检还能往哪走几个我实际在试的扩展方向最后聊几个我正在实践、觉得有价值的扩展方向给想深入的人一点参考。第一个方向是巡检即代码。把巡检策略、阈值、白名单都用配置文件管理起来纳入版本控制。这样策略变更可追溯、可回滚团队协作也方便。我现在把巡检配置和业务代码放一个仓库改巡检策略走 PR 流程规范多了。第二个方向是根因定位的自动化。现在巡检能发现问题但定位根因还得人工。我在尝试把巡检数据和变更记录、发布记录关联起来如果某台机器巡检异常且近期有发布就自动提示可能与某次发布相关能省不少排查时间。第三个方向是容量预测。基于历史巡检数据做趋势外推预测磁盘什么时候满、内存什么时候不够提前扩容。这个对资源规划特别有用比等到告警了再扩容从容得多。第四个方向是巡检知识库沉淀。每次处理完一个巡检发现的问题把根因和解决方案记下来慢慢就形成了一个团队自己的知识库。下次遇到类似问题AI 可以参考历史案例给建议越用越准。这套东西说到底核心不是 AI 有多神而是把老运维脑子里的经验固化成可复用的流程和数据。机器多了人脑记不住、看不过来就得靠系统。STAROps 加 SysOM 这套组合本质上是给运维团队配了个不知疲倦的助手把重复的、琐碎的巡检工作接过去让人能腾出手来做更有价值的事。我在实际用下来最大的感受是巡检报告看多了对机器的手感反而更好了因为系统帮你把平时注意不到的细节都摆出来了。