1. 从一台半夜告警的 ECS 说起凌晨两点十七分手机在床头柜上震了一下。我眯着眼摸过来一看是监控群里的一条告警某台 ECS 的 CPU 使用率连续五分钟超过 90%。爬起来开电脑登上机器top一看一个日志采集进程因为磁盘写满卡死了连带把 CPU 也拖了上去。清理日志、重启进程、加监控项前后折腾了四十分钟。第二天顶着黑眼圈上班的时候我就在想这种活儿能不能让机器自己干这就是 STAROps 主机智能巡检这套东西要解决的问题。它不是那种装个 Agent 采几个指标就完事的传统监控而是把 AI 能力真正嵌进运维巡检的链路里让 ECS 从“出了问题告警”进化到“还没出问题就告诉你哪里不对劲”。你可以把它理解成给每台 ECS 配了一个 24 小时不睡觉的 AI 医生平时做体检、看指标、写报告真出了毛病还能帮你做初步诊断、给处置建议。这篇文章适合谁看如果你是运维工程师、SRE、DevOps或者手头管着几台到几百台 ECS 的开发同学这套思路和实操细节都能直接拿去用。哪怕你现在只有一台测试机看完也能明白智能巡检到底怎么落地、哪些坑要提前避开。我会从整体设计思路讲到具体配置再到实际跑起来之后遇到的问题和排查方法尽量把每一步的“为什么”都说清楚。2. 主机智能巡检到底在巡检什么2.1 传统监控和智能巡检的本质区别很多人一听到“巡检”两个字脑子里浮现的就是定时跑个脚本把 CPU、内存、磁盘、网络几个指标拉出来跟阈值比一比超了就发邮件。这套东西不是没用但它有个致命问题阈值是死的业务是活的。举个例子一台跑批处理任务的 ECS每天凌晨两点到四点 CPU 跑到 80% 是正常业务行为你设个 75% 的阈值它天天半夜告警运维人员慢慢就麻木了真出事的时候反而没人看。反过来一台平时 CPU 只有 5% 的机器突然涨到 40%虽然绝对值不高但相对它自己的基线来说已经是异常了传统阈值监控根本不会报。智能巡检的核心差异就在这里它不只看绝对值更看趋势、看基线、看关联。STAROps 这套东西在采集层之上加了一层 AI 分析引擎它会做几件事基线学习每台 ECS 的指标都有自己独特的“作息规律”AI 会在一段时间内学习这个规律形成动态基线。上面那台跑批的机器它的 CPU 基线在凌晨就是高的白天就是低的AI 学完之后不会在凌晨瞎告警。趋势预测磁盘使用率从 60% 涨到 65% 可能没人注意但 AI 会算斜率告诉你“按当前增长速度7 天后磁盘会满”。这就是从“当下有没有问题”变成“未来会不会有问题”。关联分析单看 CPU 高可能只是业务繁忙但如果 CPU 高 磁盘 IO 等待高 网络重传率高同时出现那大概率是某个服务出了问题。AI 会把多个指标放在一起看给出综合判断。异常检测用统计方法和机器学习模型识别那些“说不上哪里不对但就是不对”的模式比如某个进程的内存缓慢泄漏、某个端口的连接数异常波动。注意智能巡检不是要取代传统阈值监控两者是互补关系。阈值监控负责兜底保证硬性红线不被突破智能巡检负责提前发现软性问题把故障扼杀在萌芽阶段。2.2 一套完整的巡检体系包含哪些模块STAROps 主机智能巡检这套体系拆开来看大概是这么几层层级模块核心职责采集层SysOM Agent采集 CPU、内存、磁盘、网络、进程等基础指标采集层日志采集器收集系统日志、应用日志、内核日志分析层基线引擎学习每台机器的指标基线生成动态阈值分析层异常检测模型识别偏离基线的异常模式分析层关联规则引擎多指标联合判断减少误报应用层巡检报告生成定期输出健康报告含评分和建议应用层告警与通知异常时触发告警支持多种通知渠道应用层处置建议针对常见问题给出修复建议和操作指引这里面最核心的是分析层。采集层的东西市面上方案很多SysOM 本身也是开源可用的但真正让“智能”两个字落地的是基线引擎和异常检测模型。没有这两块就只是个数据采集工具谈不上智能。2.3 为什么选择在 ECS 上做智能巡检有人可能会问现在云厂商自己就带监控和告警为什么还要自己搭一套智能巡检我自己的体会是三个原因第一云厂商的监控是通用型的它不知道你的业务特点。同样是 CPU 高跑数据库的机器和跑 Web 服务的机器含义完全不一样。智能巡检可以针对每台机器的角色做定制化分析。第二云厂商的告警阈值配置起来很麻烦机器多了之后根本管不过来。智能巡检的基线学习是自动的新机器加进来跑几天就自动形成基线不需要人工一台台配阈值。第三也是最重要的一点智能巡检能给出“怎么办”的建议而不只是“出问题了”。传统告警告诉你 CPU 高了智能巡检会告诉你“CPU 高是因为某个进程在疯狂写日志建议检查该进程的日志轮转配置”。这个差别在半夜被叫醒的时候特别明显。3. 核心细节拆解AI 是怎么给主机看病的3.1 基线学习让每台机器都有自己的“正常值”基线学习是整个智能巡检的地基。没有准确的基线后面的异常检测全是空中楼阁。STAROps 的基线引擎大概是这样工作的首先它会为每台 ECS 的每个核心指标CPU 使用率、内存使用率、磁盘使用率、磁盘 IO、网络流量等建立一个时间序列模型。这个模型不是简单的平均值而是考虑了周期性天周期、周周期和趋势性的。具体来说它会把一天分成若干个时间窗口比如每 5 分钟一个点一天就是 288 个点。然后对每个时间点统计过去 N 天默认 14 天同一时间点的数据分布计算出均值、标准差、分位数等统计量。这样每个时间点都有一个独立的基线区间。举个例子某台 Web 服务器每天上午 9 点到 11 点是访问高峰CPU 基线可能在 40%-60% 之间波动而凌晨 3 点到 5 点是低谷基线可能只有 5%-10%。如果某天凌晨 4 点 CPU 突然跑到 50%虽然绝对值不高但远超该时间点的基线上限AI 就会判定为异常。基线学习需要一段“冷启动”时间。根据我的实测至少需要 7 天的数据才能形成比较可靠的基线14 天以上效果更好。新机器刚接入的前几天建议先观察不告警等基线稳定后再开启异常检测。提示如果业务有明显的季节性变化比如电商大促、月末结算基线学习周期要相应拉长或者手动标记特殊时段避免把正常业务高峰误判为异常。3.2 异常检测三种武器各管一摊基线建好之后异常检测就是拿实时数据和基线做比对。STAROps 用了三种方法来覆盖不同类型的异常第一种统计偏离检测。这是最基础的方法就是看当前值是否超出了基线的置信区间。通常用 3-sigma 原则即超出均值 ±3 倍标准差就判定为异常。这个方法简单快速适合检测突发性的尖峰。但 3-sigma 有个问题它对小幅度但持续性的偏移不敏感。比如内存使用率每天涨 1%一周下来涨了 7%单看每一天都不算异常但累积起来就是大问题。所以还需要第二种方法。第二种趋势检测。这个方法不看单点值而是看一段时间内的变化趋势。它会计算指标的斜率如果斜率持续为正且超过某个阈值就判定为“趋势异常”。磁盘使用率是最典型的场景每天涨一点AI 会算出“预计 X 天后达到 100%”提前发出预警。第三种模式检测。这个方法用机器学习模型来识别复杂的异常模式。比如某个进程的内存使用呈现“阶梯式上升-突然下降-再上升”的锯齿模式这通常是内存泄漏的典型特征。统计方法和趋势检测都很难捕捉这种模式但模式检测可以。三种方法各有侧重实际运行时会综合三者的结果给出最终判定。这样既能抓住突发异常也能发现慢性问题还能识别复杂模式。3.3 关联分析避免“狼来了”的关键做过运维的人都知道告警疲劳是个大问题。如果一天发几百条告警大部分都是误报那真正重要的告警也会被忽略。智能巡检如果只是把单指标异常简单叠加告警量会比传统监控还大。STAROps 的关联分析引擎就是来解决这个问题的。它的核心思路是单个指标异常可能是噪声多个相关指标同时异常才更可能是真问题。具体实现上它维护了一张“指标关联图”。比如CPU 使用率高 磁盘 IO 等待高 → 可能是 IO 密集型任务内存使用率高 Swap 使用率高 → 可能是内存不足网络流量高 网络重传率高 → 可能是网络质量问题磁盘使用率高 日志文件增长快 → 可能是日志未轮转当多个关联指标同时出现异常时系统会提升告警级别如果只有单个指标异常且没有关联指标佐证则会降低级别或先观察一段时间再决定是否告警。这个机制在实际使用中效果非常明显。我负责的一批 ECS 接入智能巡检后告警量从每天几十条降到了每天两三条但真正的问题一个都没漏掉。3.4 巡检报告把数据变成人能看懂的建议智能巡检的最终产出是一份巡检报告。这份报告不是简单地把指标数据罗列出来而是要用自然语言告诉运维人员你的机器现在健康状况如何有哪些潜在风险建议做什么操作。一份典型的巡检报告包含这几个部分健康评分给每台 ECS 打一个 0-100 分的健康分方便快速筛选有问题的机器。异常摘要列出当前存在的异常项按严重程度排序。趋势预警列出未来可能出问题的指标比如“磁盘预计 5 天后写满”。处置建议针对每个异常项给出具体的修复建议尽量细化到可执行的命令或配置修改。历史对比和上周、上月的健康情况做对比看整体趋势是变好还是变差。报告支持定时生成比如每天早上 9 点发到邮箱和按需生成在控制台点击“立即巡检”。对于运维团队来说每天早上花五分钟扫一眼巡检报告就能对全部机器的健康状况心里有数。4. 实操落地从零搭建一套智能巡检4.1 环境准备与 Agent 部署假设你手头有一批 ECS操作系统以 CentOS 7/8 或 Alibaba Cloud Linux 为主现在要接入 STAROps 智能巡检。第一步是部署采集 Agent。SysOM Agent 的安装方式比较简单官方提供了一键安装脚本。但在生产环境批量部署时有几个细节要注意# 下载安装脚本示例实际地址以官方文档为准 wget https://example.com/sysom-agent-install.sh # 赋予执行权限 chmod x sysom-agent-install.sh # 执行安装指定服务端地址 ./sysom-agent-install.sh --server http://your-starops-server:8080安装完成后Agent 会以 systemd 服务的形式运行可以用systemctl status sysom-agent检查状态。批量部署时我建议用 Ansible 或类似的配置管理工具来做而不是手动一台台装。下面是一个 Ansible playbook 的片段示例- hosts: ecs_servers become: yes tasks: - name: Copy install script copy: src: files/sysom-agent-install.sh dest: /tmp/sysom-agent-install.sh mode: 0755 - name: Run install script shell: /tmp/sysom-agent-install.sh --server http://your-starops-server:8080 args: creates: /etc/sysom/agent.confcreates参数的作用是幂等性保证如果/etc/sysom/agent.conf已经存在说明 Agent 已经装过了跳过执行。这在批量运维中很重要避免重复安装导致配置被覆盖。注意Agent 部署前要确认 ECS 的安全组规则允许 Agent 访问服务端的端口。如果服务端在内网确保 ECS 和服务端网络互通如果服务端在公网建议走内网通道或加白名单不要直接把管理端口暴露在公网。4.2 基线配置与冷启动策略Agent 装好之后数据就开始往服务端传了。但这时候先别急着开告警让基线引擎先跑一段时间。在 STAROps 控制台里每台 ECS 都有一个“基线状态”标识通常有这几种学习中数据积累不足基线尚未形成此时不产生异常告警。已就绪基线已形成可以开启异常检测。需更新业务发生重大变化如扩容、迁移基线需要重新学习。冷启动期间我建议做这几件事第一检查数据采集是否完整。在控制台的“数据质量”页面可以看到每台机器的指标上报情况。如果有指标缺失或断点要先排查 Agent 状态和网络连通性。第二手动标记特殊时段。如果知道某台机器在特定时间有特殊任务比如每周日凌晨的备份可以在控制台里标记为“维护窗口”这段时间的异常不告警。第三设置合理的告警灵敏度。STAROps 通常提供“宽松”“标准”“严格”三档灵敏度。冷启动结束后建议先用“宽松”档跑一周观察告警情况再根据实际需要调整。根据我的经验基线学习 7 天后大部分机器的基线已经比较准确了。但有些业务波动大的机器可能需要 14 天甚至更久。不要为了赶进度提前开启告警否则前期误报太多团队会对这套系统失去信任。4.3 告警规则与通知渠道配置基线就绪后就可以配置告警规则了。STAROps 的告警配置大概分这几个维度告警级别通常分“提示”“警告”“严重”三级。提示级别只记录不通知警告级别发通知但不电话严重级别才触发电话告警。合理分配级别可以避免半夜被无关紧要的告警吵醒。告警聚合同一台机器的多个告警可以聚合为一条通知避免告警风暴。比如一台机器同时出现 CPU 高、内存高、磁盘高可以聚合成一条“主机综合异常”通知。通知渠道支持邮件、Webhook、钉钉/企业微信机器人等。我一般配置成提示级别只进控制台警告级别发到运维群严重级别才打电话。静默规则支持按时间段静默比如维护窗口内不告警。也支持按指标静默比如某个已知的长期异常可以暂时屏蔽。配置告警规则时有个技巧先宽后严。刚开始把阈值放宽一点观察一段时间看看哪些告警是真正需要关注的再逐步收紧。一上来就设得很严只会导致告警疲劳。4.4 巡检报告的定时生成与分发巡检报告是这套系统里使用频率最高的功能之一。配置起来也不复杂在控制台的“巡检报告”页面新建一个报告任务设置报告范围可以选择全部 ECS也可以按标签、按分组选择。生成频率支持每天、每周、每月。我一般设每天早 8 点生成日报每周一生成周报。报告内容可以选择包含健康评分、异常摘要、趋势预警、处置建议等模块。分发方式支持邮件、Webhook 推送到群机器人。报告生成后会以 HTML 或 PDF 格式发送。我习惯把日报发到运维群周报发到技术负责人邮箱。这样不同角色关注不同粒度的信息各取所需。提示如果 ECS 数量很多比如超过 100 台日报可能会很长。建议按业务分组分别生成报告或者只把有异常的机器列入报告健康的机器只给一个汇总数字。5. 常见问题与排查技巧实录5.1 Agent 数据上报异常怎么查Agent 装好了但数据不上报这是最常见的问题。排查思路按顺序来第一步检查 Agent 进程状态。systemctl status sysom-agent看进程是否在运行。如果没运行看日志journalctl -u sysom-agent -n 100找报错信息。第二步检查网络连通性。从 ECS 上curl一下服务端地址看能不能通。如果不通检查安全组、防火墙、DNS 解析。第三步检查配置文件。/etc/sysom/agent.conf里的服务端地址、端口、认证信息是否正确。有时候批量部署时配置文件里的地址写错了导致所有机器都上报失败。第四步检查磁盘空间。Agent 本地会缓存数据如果磁盘满了缓存写不进去上报也会失败。df -h看一下/var/lib/sysom目录所在分区的使用率。第五步检查时间同步。如果 ECS 的时间和服务端差太多数据可能会被服务端拒绝。date看一下时间必要时用chronyd或ntpd同步。这五步走下来大部分上报问题都能定位。5.2 误报太多怎么调智能巡检刚上线时误报是难免的。关键是怎么快速把误报降下来。我的经验是分三步走第一步分析误报模式。把最近一周的误报导出来看看主要集中在哪些指标、哪些机器、哪些时间段。如果集中在某几台机器可能是这些机器的业务特殊需要单独调整基线。第二步调整基线灵敏度。对于业务波动大的机器可以把基线区间放宽或者改用更鲁棒的统计方法比如用中位数代替均值用四分位距代替标准差。第三步增加关联条件。如果某个单指标告警经常误报可以给它加关联条件比如“CPU 高”必须同时满足“磁盘 IO 等待高”才告警。这样虽然可能漏掉一些单指标异常但能大幅降低误报。注意调低误报的同时要小心别把真异常也过滤掉了。每次调整后建议观察几天确认没有漏报重要问题。5.3 基线学习不准确怎么办基线不准通常有几个原因数据量不够。新机器接入不到 7 天基线还没学稳。这种情况等就行了别急着调。业务变化太频繁。如果一台机器每天的业务模式都不一样基线很难学准。这种情况可以考虑按业务类型分组同类机器共享基线而不是每台机器独立学。数据质量问题。如果采集的数据有缺失、跳变、重复基线学习会受干扰。检查 Agent 日志看有没有采集异常。周期性不明显。有些机器的负载没有明显的日周期或周周期基线引擎可能学不到规律。这种情况可以改用滑动窗口基线即用最近 N 小时的数据动态计算基线而不是用历史同期数据。5.4 智能巡检和现有监控体系怎么融合很多团队已经有了一套监控体系比如 Prometheus Grafana Alertmanager再引入智能巡检会不会重复建设我的做法是智能巡检作为现有监控的补充而不是替代。具体来说基础指标采集可以复用现有监控的数据源不必重复部署 Agent。智能巡检的异常检测结果可以通过 Webhook 推送到现有告警平台统一管理告警。巡检报告可以作为现有监控的补充视图提供更高层的健康评估。这样既利用了现有投资又增加了智能分析能力运维团队不需要切换多个平台。5.5 常见问题速查表问题现象可能原因排查方法解决措施Agent 不上报数据进程未运行systemctl status sysom-agent启动进程检查日志Agent 不上报数据网络不通curl服务端地址检查安全组、防火墙Agent 不上报数据配置错误检查 agent.conf修正服务端地址和端口误报频繁基线未学稳查看基线状态延长学习期调低灵敏度误报频繁业务波动大分析误报模式放宽基线或增加关联条件漏报重要异常灵敏度太低回顾历史异常适当提高灵敏度巡检报告为空报告范围配置错误检查报告任务配置修正 ECS 选择范围告警不通知通知渠道配置错误测试通知渠道重新配置 Webhook 或邮箱6. 我踩过的坑和总结的经验说几个实际落地过程中踩过的坑都是文档里不会写的。第一个坑Agent 资源占用。SysOM Agent 本身资源占用不大但如果采集频率设得太高比如每秒采集一次在高负载机器上会明显增加系统负担。我一般把采集间隔设为 15 秒到 60 秒对绝大多数场景够用了。如果确实需要秒级精度建议只对关键指标开高频率采集。第二个坑基线学习期间业务变更。有台机器在基线学习期间做了扩容CPU 和内存都变了结果基线学出来的是一半旧配置一半新配置的混合体完全不准确。后来我养成了习惯任何业务变更后都手动重置该机器的基线让它重新学习。第三个坑告警风暴。有一次机房网络抖动几十台机器同时上报网络异常告警平台瞬间被刷屏。后来配置了告警聚合和抑制规则同一类型的告警在 5 分钟内只发一条汇总网络类告警如果超过 10 台机器同时触发自动升级为机房级告警。第四个坑报告太长没人看。一开始日报把所有机器都列进去100 多台机器的报告几十页根本没人看。后来改成只列异常机器健康的只给一个数字报告缩短到一页以内阅读率明显提高。第五个坑过度依赖 AI。智能巡检确实能发现很多人发现不了的问题但它不是万能的。有些问题需要结合业务上下文才能判断AI 给的建议只能作为参考最终决策还是要靠人。我一般把 AI 的建议当作“线索”而不是“结论”。最后分享一个我觉得特别有用的技巧把智能巡检的异常检测结果和变更管理系统打通。每次有变更操作发布、扩容、配置修改时自动在巡检系统里标记时间点这样当异常发生时可以快速关联到最近的变更排查效率会高很多。这个联动机制看起来简单但在实际故障排查中能省下大量时间。这套东西我用了大半年最大的感受是它不能让你完全不用管机器但能让你在管机器的时候更有方向。以前是出了问题到处翻日志现在是每天早上看一眼报告心里有数该处理的处理该观察的观察。对于手头机器多、人手少的团队来说这种效率提升是实打实的。 
长河君 · 2026/10/31 9:20:47 · 阅读 1.2k STAROps主机智能巡检：AI如何让ECS运维从告警走向预测
1. 从一台半夜告警的 ECS 说起凌晨两点十七分手机在床头柜上震了一下。我眯着眼摸过来一看是监控群里的一条告警某台 ECS 的 CPU 使用率连续五分钟超过 90%。爬起来开电脑登上机器top一看一个日志采集进程因为磁盘写满卡死了连带把 CPU 也拖了上去。清理日志、重启进程、加监控项前后折腾了四十分钟。第二天顶着黑眼圈上班的时候我就在想这种活儿能不能让机器自己干这就是 STAROps 主机智能巡检这套东西要解决的问题。它不是那种装个 Agent 采几个指标就完事的传统监控而是把 AI 能力真正嵌进运维巡检的链路里让 ECS 从“出了问题告警”进化到“还没出问题就告诉你哪里不对劲”。你可以把它理解成给每台 ECS 配了一个 24 小时不睡觉的 AI 医生平时做体检、看指标、写报告真出了毛病还能帮你做初步诊断、给处置建议。这篇文章适合谁看如果你是运维工程师、SRE、DevOps或者手头管着几台到几百台 ECS 的开发同学这套思路和实操细节都能直接拿去用。哪怕你现在只有一台测试机看完也能明白智能巡检到底怎么落地、哪些坑要提前避开。我会从整体设计思路讲到具体配置再到实际跑起来之后遇到的问题和排查方法尽量把每一步的“为什么”都说清楚。2. 主机智能巡检到底在巡检什么2.1 传统监控和智能巡检的本质区别很多人一听到“巡检”两个字脑子里浮现的就是定时跑个脚本把 CPU、内存、磁盘、网络几个指标拉出来跟阈值比一比超了就发邮件。这套东西不是没用但它有个致命问题阈值是死的业务是活的。举个例子一台跑批处理任务的 ECS每天凌晨两点到四点 CPU 跑到 80% 是正常业务行为你设个 75% 的阈值它天天半夜告警运维人员慢慢就麻木了真出事的时候反而没人看。反过来一台平时 CPU 只有 5% 的机器突然涨到 40%虽然绝对值不高但相对它自己的基线来说已经是异常了传统阈值监控根本不会报。智能巡检的核心差异就在这里它不只看绝对值更看趋势、看基线、看关联。STAROps 这套东西在采集层之上加了一层 AI 分析引擎它会做几件事基线学习每台 ECS 的指标都有自己独特的“作息规律”AI 会在一段时间内学习这个规律形成动态基线。上面那台跑批的机器它的 CPU 基线在凌晨就是高的白天就是低的AI 学完之后不会在凌晨瞎告警。趋势预测磁盘使用率从 60% 涨到 65% 可能没人注意但 AI 会算斜率告诉你“按当前增长速度7 天后磁盘会满”。这就是从“当下有没有问题”变成“未来会不会有问题”。关联分析单看 CPU 高可能只是业务繁忙但如果 CPU 高 磁盘 IO 等待高 网络重传率高同时出现那大概率是某个服务出了问题。AI 会把多个指标放在一起看给出综合判断。异常检测用统计方法和机器学习模型识别那些“说不上哪里不对但就是不对”的模式比如某个进程的内存缓慢泄漏、某个端口的连接数异常波动。注意智能巡检不是要取代传统阈值监控两者是互补关系。阈值监控负责兜底保证硬性红线不被突破智能巡检负责提前发现软性问题把故障扼杀在萌芽阶段。2.2 一套完整的巡检体系包含哪些模块STAROps 主机智能巡检这套体系拆开来看大概是这么几层层级模块核心职责采集层SysOM Agent采集 CPU、内存、磁盘、网络、进程等基础指标采集层日志采集器收集系统日志、应用日志、内核日志分析层基线引擎学习每台机器的指标基线生成动态阈值分析层异常检测模型识别偏离基线的异常模式分析层关联规则引擎多指标联合判断减少误报应用层巡检报告生成定期输出健康报告含评分和建议应用层告警与通知异常时触发告警支持多种通知渠道应用层处置建议针对常见问题给出修复建议和操作指引这里面最核心的是分析层。采集层的东西市面上方案很多SysOM 本身也是开源可用的但真正让“智能”两个字落地的是基线引擎和异常检测模型。没有这两块就只是个数据采集工具谈不上智能。2.3 为什么选择在 ECS 上做智能巡检有人可能会问现在云厂商自己就带监控和告警为什么还要自己搭一套智能巡检我自己的体会是三个原因第一云厂商的监控是通用型的它不知道你的业务特点。同样是 CPU 高跑数据库的机器和跑 Web 服务的机器含义完全不一样。智能巡检可以针对每台机器的角色做定制化分析。第二云厂商的告警阈值配置起来很麻烦机器多了之后根本管不过来。智能巡检的基线学习是自动的新机器加进来跑几天就自动形成基线不需要人工一台台配阈值。第三也是最重要的一点智能巡检能给出“怎么办”的建议而不只是“出问题了”。传统告警告诉你 CPU 高了智能巡检会告诉你“CPU 高是因为某个进程在疯狂写日志建议检查该进程的日志轮转配置”。这个差别在半夜被叫醒的时候特别明显。3. 核心细节拆解AI 是怎么给主机看病的3.1 基线学习让每台机器都有自己的“正常值”基线学习是整个智能巡检的地基。没有准确的基线后面的异常检测全是空中楼阁。STAROps 的基线引擎大概是这样工作的首先它会为每台 ECS 的每个核心指标CPU 使用率、内存使用率、磁盘使用率、磁盘 IO、网络流量等建立一个时间序列模型。这个模型不是简单的平均值而是考虑了周期性天周期、周周期和趋势性的。具体来说它会把一天分成若干个时间窗口比如每 5 分钟一个点一天就是 288 个点。然后对每个时间点统计过去 N 天默认 14 天同一时间点的数据分布计算出均值、标准差、分位数等统计量。这样每个时间点都有一个独立的基线区间。举个例子某台 Web 服务器每天上午 9 点到 11 点是访问高峰CPU 基线可能在 40%-60% 之间波动而凌晨 3 点到 5 点是低谷基线可能只有 5%-10%。如果某天凌晨 4 点 CPU 突然跑到 50%虽然绝对值不高但远超该时间点的基线上限AI 就会判定为异常。基线学习需要一段“冷启动”时间。根据我的实测至少需要 7 天的数据才能形成比较可靠的基线14 天以上效果更好。新机器刚接入的前几天建议先观察不告警等基线稳定后再开启异常检测。提示如果业务有明显的季节性变化比如电商大促、月末结算基线学习周期要相应拉长或者手动标记特殊时段避免把正常业务高峰误判为异常。3.2 异常检测三种武器各管一摊基线建好之后异常检测就是拿实时数据和基线做比对。STAROps 用了三种方法来覆盖不同类型的异常第一种统计偏离检测。这是最基础的方法就是看当前值是否超出了基线的置信区间。通常用 3-sigma 原则即超出均值 ±3 倍标准差就判定为异常。这个方法简单快速适合检测突发性的尖峰。但 3-sigma 有个问题它对小幅度但持续性的偏移不敏感。比如内存使用率每天涨 1%一周下来涨了 7%单看每一天都不算异常但累积起来就是大问题。所以还需要第二种方法。第二种趋势检测。这个方法不看单点值而是看一段时间内的变化趋势。它会计算指标的斜率如果斜率持续为正且超过某个阈值就判定为“趋势异常”。磁盘使用率是最典型的场景每天涨一点AI 会算出“预计 X 天后达到 100%”提前发出预警。第三种模式检测。这个方法用机器学习模型来识别复杂的异常模式。比如某个进程的内存使用呈现“阶梯式上升-突然下降-再上升”的锯齿模式这通常是内存泄漏的典型特征。统计方法和趋势检测都很难捕捉这种模式但模式检测可以。三种方法各有侧重实际运行时会综合三者的结果给出最终判定。这样既能抓住突发异常也能发现慢性问题还能识别复杂模式。3.3 关联分析避免“狼来了”的关键做过运维的人都知道告警疲劳是个大问题。如果一天发几百条告警大部分都是误报那真正重要的告警也会被忽略。智能巡检如果只是把单指标异常简单叠加告警量会比传统监控还大。STAROps 的关联分析引擎就是来解决这个问题的。它的核心思路是单个指标异常可能是噪声多个相关指标同时异常才更可能是真问题。具体实现上它维护了一张“指标关联图”。比如CPU 使用率高 磁盘 IO 等待高 → 可能是 IO 密集型任务内存使用率高 Swap 使用率高 → 可能是内存不足网络流量高 网络重传率高 → 可能是网络质量问题磁盘使用率高 日志文件增长快 → 可能是日志未轮转当多个关联指标同时出现异常时系统会提升告警级别如果只有单个指标异常且没有关联指标佐证则会降低级别或先观察一段时间再决定是否告警。这个机制在实际使用中效果非常明显。我负责的一批 ECS 接入智能巡检后告警量从每天几十条降到了每天两三条但真正的问题一个都没漏掉。3.4 巡检报告把数据变成人能看懂的建议智能巡检的最终产出是一份巡检报告。这份报告不是简单地把指标数据罗列出来而是要用自然语言告诉运维人员你的机器现在健康状况如何有哪些潜在风险建议做什么操作。一份典型的巡检报告包含这几个部分健康评分给每台 ECS 打一个 0-100 分的健康分方便快速筛选有问题的机器。异常摘要列出当前存在的异常项按严重程度排序。趋势预警列出未来可能出问题的指标比如“磁盘预计 5 天后写满”。处置建议针对每个异常项给出具体的修复建议尽量细化到可执行的命令或配置修改。历史对比和上周、上月的健康情况做对比看整体趋势是变好还是变差。报告支持定时生成比如每天早上 9 点发到邮箱和按需生成在控制台点击“立即巡检”。对于运维团队来说每天早上花五分钟扫一眼巡检报告就能对全部机器的健康状况心里有数。4. 实操落地从零搭建一套智能巡检4.1 环境准备与 Agent 部署假设你手头有一批 ECS操作系统以 CentOS 7/8 或 Alibaba Cloud Linux 为主现在要接入 STAROps 智能巡检。第一步是部署采集 Agent。SysOM Agent 的安装方式比较简单官方提供了一键安装脚本。但在生产环境批量部署时有几个细节要注意# 下载安装脚本示例实际地址以官方文档为准 wget https://example.com/sysom-agent-install.sh # 赋予执行权限 chmod x sysom-agent-install.sh # 执行安装指定服务端地址 ./sysom-agent-install.sh --server http://your-starops-server:8080安装完成后Agent 会以 systemd 服务的形式运行可以用systemctl status sysom-agent检查状态。批量部署时我建议用 Ansible 或类似的配置管理工具来做而不是手动一台台装。下面是一个 Ansible playbook 的片段示例- hosts: ecs_servers become: yes tasks: - name: Copy install script copy: src: files/sysom-agent-install.sh dest: /tmp/sysom-agent-install.sh mode: 0755 - name: Run install script shell: /tmp/sysom-agent-install.sh --server http://your-starops-server:8080 args: creates: /etc/sysom/agent.confcreates参数的作用是幂等性保证如果/etc/sysom/agent.conf已经存在说明 Agent 已经装过了跳过执行。这在批量运维中很重要避免重复安装导致配置被覆盖。注意Agent 部署前要确认 ECS 的安全组规则允许 Agent 访问服务端的端口。如果服务端在内网确保 ECS 和服务端网络互通如果服务端在公网建议走内网通道或加白名单不要直接把管理端口暴露在公网。4.2 基线配置与冷启动策略Agent 装好之后数据就开始往服务端传了。但这时候先别急着开告警让基线引擎先跑一段时间。在 STAROps 控制台里每台 ECS 都有一个“基线状态”标识通常有这几种学习中数据积累不足基线尚未形成此时不产生异常告警。已就绪基线已形成可以开启异常检测。需更新业务发生重大变化如扩容、迁移基线需要重新学习。冷启动期间我建议做这几件事第一检查数据采集是否完整。在控制台的“数据质量”页面可以看到每台机器的指标上报情况。如果有指标缺失或断点要先排查 Agent 状态和网络连通性。第二手动标记特殊时段。如果知道某台机器在特定时间有特殊任务比如每周日凌晨的备份可以在控制台里标记为“维护窗口”这段时间的异常不告警。第三设置合理的告警灵敏度。STAROps 通常提供“宽松”“标准”“严格”三档灵敏度。冷启动结束后建议先用“宽松”档跑一周观察告警情况再根据实际需要调整。根据我的经验基线学习 7 天后大部分机器的基线已经比较准确了。但有些业务波动大的机器可能需要 14 天甚至更久。不要为了赶进度提前开启告警否则前期误报太多团队会对这套系统失去信任。4.3 告警规则与通知渠道配置基线就绪后就可以配置告警规则了。STAROps 的告警配置大概分这几个维度告警级别通常分“提示”“警告”“严重”三级。提示级别只记录不通知警告级别发通知但不电话严重级别才触发电话告警。合理分配级别可以避免半夜被无关紧要的告警吵醒。告警聚合同一台机器的多个告警可以聚合为一条通知避免告警风暴。比如一台机器同时出现 CPU 高、内存高、磁盘高可以聚合成一条“主机综合异常”通知。通知渠道支持邮件、Webhook、钉钉/企业微信机器人等。我一般配置成提示级别只进控制台警告级别发到运维群严重级别才打电话。静默规则支持按时间段静默比如维护窗口内不告警。也支持按指标静默比如某个已知的长期异常可以暂时屏蔽。配置告警规则时有个技巧先宽后严。刚开始把阈值放宽一点观察一段时间看看哪些告警是真正需要关注的再逐步收紧。一上来就设得很严只会导致告警疲劳。4.4 巡检报告的定时生成与分发巡检报告是这套系统里使用频率最高的功能之一。配置起来也不复杂在控制台的“巡检报告”页面新建一个报告任务设置报告范围可以选择全部 ECS也可以按标签、按分组选择。生成频率支持每天、每周、每月。我一般设每天早 8 点生成日报每周一生成周报。报告内容可以选择包含健康评分、异常摘要、趋势预警、处置建议等模块。分发方式支持邮件、Webhook 推送到群机器人。报告生成后会以 HTML 或 PDF 格式发送。我习惯把日报发到运维群周报发到技术负责人邮箱。这样不同角色关注不同粒度的信息各取所需。提示如果 ECS 数量很多比如超过 100 台日报可能会很长。建议按业务分组分别生成报告或者只把有异常的机器列入报告健康的机器只给一个汇总数字。5. 常见问题与排查技巧实录5.1 Agent 数据上报异常怎么查Agent 装好了但数据不上报这是最常见的问题。排查思路按顺序来第一步检查 Agent 进程状态。systemctl status sysom-agent看进程是否在运行。如果没运行看日志journalctl -u sysom-agent -n 100找报错信息。第二步检查网络连通性。从 ECS 上curl一下服务端地址看能不能通。如果不通检查安全组、防火墙、DNS 解析。第三步检查配置文件。/etc/sysom/agent.conf里的服务端地址、端口、认证信息是否正确。有时候批量部署时配置文件里的地址写错了导致所有机器都上报失败。第四步检查磁盘空间。Agent 本地会缓存数据如果磁盘满了缓存写不进去上报也会失败。df -h看一下/var/lib/sysom目录所在分区的使用率。第五步检查时间同步。如果 ECS 的时间和服务端差太多数据可能会被服务端拒绝。date看一下时间必要时用chronyd或ntpd同步。这五步走下来大部分上报问题都能定位。5.2 误报太多怎么调智能巡检刚上线时误报是难免的。关键是怎么快速把误报降下来。我的经验是分三步走第一步分析误报模式。把最近一周的误报导出来看看主要集中在哪些指标、哪些机器、哪些时间段。如果集中在某几台机器可能是这些机器的业务特殊需要单独调整基线。第二步调整基线灵敏度。对于业务波动大的机器可以把基线区间放宽或者改用更鲁棒的统计方法比如用中位数代替均值用四分位距代替标准差。第三步增加关联条件。如果某个单指标告警经常误报可以给它加关联条件比如“CPU 高”必须同时满足“磁盘 IO 等待高”才告警。这样虽然可能漏掉一些单指标异常但能大幅降低误报。注意调低误报的同时要小心别把真异常也过滤掉了。每次调整后建议观察几天确认没有漏报重要问题。5.3 基线学习不准确怎么办基线不准通常有几个原因数据量不够。新机器接入不到 7 天基线还没学稳。这种情况等就行了别急着调。业务变化太频繁。如果一台机器每天的业务模式都不一样基线很难学准。这种情况可以考虑按业务类型分组同类机器共享基线而不是每台机器独立学。数据质量问题。如果采集的数据有缺失、跳变、重复基线学习会受干扰。检查 Agent 日志看有没有采集异常。周期性不明显。有些机器的负载没有明显的日周期或周周期基线引擎可能学不到规律。这种情况可以改用滑动窗口基线即用最近 N 小时的数据动态计算基线而不是用历史同期数据。5.4 智能巡检和现有监控体系怎么融合很多团队已经有了一套监控体系比如 Prometheus Grafana Alertmanager再引入智能巡检会不会重复建设我的做法是智能巡检作为现有监控的补充而不是替代。具体来说基础指标采集可以复用现有监控的数据源不必重复部署 Agent。智能巡检的异常检测结果可以通过 Webhook 推送到现有告警平台统一管理告警。巡检报告可以作为现有监控的补充视图提供更高层的健康评估。这样既利用了现有投资又增加了智能分析能力运维团队不需要切换多个平台。5.5 常见问题速查表问题现象可能原因排查方法解决措施Agent 不上报数据进程未运行systemctl status sysom-agent启动进程检查日志Agent 不上报数据网络不通curl服务端地址检查安全组、防火墙Agent 不上报数据配置错误检查 agent.conf修正服务端地址和端口误报频繁基线未学稳查看基线状态延长学习期调低灵敏度误报频繁业务波动大分析误报模式放宽基线或增加关联条件漏报重要异常灵敏度太低回顾历史异常适当提高灵敏度巡检报告为空报告范围配置错误检查报告任务配置修正 ECS 选择范围告警不通知通知渠道配置错误测试通知渠道重新配置 Webhook 或邮箱6. 我踩过的坑和总结的经验说几个实际落地过程中踩过的坑都是文档里不会写的。第一个坑Agent 资源占用。SysOM Agent 本身资源占用不大但如果采集频率设得太高比如每秒采集一次在高负载机器上会明显增加系统负担。我一般把采集间隔设为 15 秒到 60 秒对绝大多数场景够用了。如果确实需要秒级精度建议只对关键指标开高频率采集。第二个坑基线学习期间业务变更。有台机器在基线学习期间做了扩容CPU 和内存都变了结果基线学出来的是一半旧配置一半新配置的混合体完全不准确。后来我养成了习惯任何业务变更后都手动重置该机器的基线让它重新学习。第三个坑告警风暴。有一次机房网络抖动几十台机器同时上报网络异常告警平台瞬间被刷屏。后来配置了告警聚合和抑制规则同一类型的告警在 5 分钟内只发一条汇总网络类告警如果超过 10 台机器同时触发自动升级为机房级告警。第四个坑报告太长没人看。一开始日报把所有机器都列进去100 多台机器的报告几十页根本没人看。后来改成只列异常机器健康的只给一个数字报告缩短到一页以内阅读率明显提高。第五个坑过度依赖 AI。智能巡检确实能发现很多人发现不了的问题但它不是万能的。有些问题需要结合业务上下文才能判断AI 给的建议只能作为参考最终决策还是要靠人。我一般把 AI 的建议当作“线索”而不是“结论”。最后分享一个我觉得特别有用的技巧把智能巡检的异常检测结果和变更管理系统打通。每次有变更操作发布、扩容、配置修改时自动在巡检系统里标记时间点这样当异常发生时可以快速关联到最近的变更排查效率会高很多。这个联动机制看起来简单但在实际故障排查中能省下大量时间。这套东西我用了大半年最大的感受是它不能让你完全不用管机器但能让你在管机器的时候更有方向。以前是出了问题到处翻日志现在是每天早上看一眼报告心里有数该处理的处理该观察的观察。对于手头机器多、人手少的团队来说这种效率提升是实打实的。