大促前夜 slab 占了 30%：三次主机巡检

大促前夜 slab 占了 30%：三次主机巡检

OpenAnolis 的 Shiyan Chen 在 2026-09-15 介绍了 STAROps 智能主机巡检。STAROps 是阿里云的智能运维平台。STAR 指四层：Sense 是整体观测，Target 是面向目标的运维，Autonomy 是自主运维，Resilience 是业务韧性。巡检被写成 Resilience 里把事后救火挪到出事之前的那一块。

文章先用一个凌晨场景说明只看告警会停在哪：3 点被叫醒，登录跳板机，在一台台机器上跑 top、dmesg 和 iostat，两小时后才找到一块在丢包的网卡。作者认为多数故障不是突然死的，是慢性问题转成急性：内存连涨三天直到 OOM，conntrack 表快满直到新连接成批失败，日志把盘吃满直到数据库写不进去，光模块老化直到重传涨到十倍。传统监控要等指标顶到天花板才告警。人没法对几百台机器做高频全栈检查。

50 多项检查，对照传统巡检

一次巡检覆盖 CPU、内存、磁盘、网络、GPU、内核和硬件，超过 50 项，而且还在加。对照表把传统巡检写成 5 到 10 项，只看 CPU、内存和磁盘，停在「内存高」。STAROps 要继续问谁在用、为什么高、下一步做什么。内核侧能看见 softlockup、OOM、hungtask。硬件侧在坏掉之前看 CPU、内存、磁盘和网卡的早期迹象。

表里传统输出的例子是「CPU usage: 92%」，对应的诊断例子是 Java 正则回溯把 CPU 打满，要限制回溯深度。这是对照表里的说法，不是单独一次测量的记录。

内核事件里点了四类：softlockup 饿死业务线程，hung task 卡住超过两分钟，RCU stall 预示内核死锁，conntrack 表满了悄悄丢新连接。硬件上：MCE 标出变差的处理器，ECC 警告内存条快坏，SMART 抓住快坏的盘，CRC 在丢包开始前暴露老化的光模块。

深度诊断的例子是「突然都变慢」。传统监控只给「CPU iowait 90%」。STAROps 的证据链是：持续高 iowait，一个 MySQL 进程在猛敲 fsync，根因是 sync_binlog=1 让每次事务提交都等磁盘，然后给出可执行的修复。文章没有写出这次修复后的延迟。

规则来自生产故障，不是教科书。作者写：只有持续、并且符合特定形态的异常才算真问题，用来压误报。每条检查都带故障注入用例，并写成能保证 100% 检出。文章没有给出这些用例的数量，也没有给出误报率。

三起生产故障

大促前夜，巡检发现内核 slab 内存（SReclaimable）已经占到系统内存的 30%。AI 追到日志采集 agent 在遍历 /proc/*/fd，撑出一大片 dentry cache。调整采集策略后收回 8 GB 内核内存，大促当天的 OOM 风险被避开。文章把没有这次巡检的损失写成「可能数百万」，这是估计，不是账单。

微服务集群间歇超时。conntrack 表到了 92%，dmesg 写着 “table full, dropping packet”。判断是 Kubernetes 短连接太多，默认 conntrack_max 不够。调高参数并打开 keepalive 之后，超时不再出现。手工逐台查网络设备要几个小时。文章没有写出调高后的新上限。

慢查询突然变多。磁盘写延迟从 5 毫秒升到 200 毫秒。诊断是 O_SYNC 写入和同机工作负载抢 IOPS。把 WAL 日志盘和数据盘分开后，延迟回到 5 毫秒。在这之前 DBA 花了整整两天调 SQL，病在存储层。

三起都是个案，不是评测集上的平均。

一次演示里的五步

文章用一次演示把自然语言走到分级报告，五步，从头到尾一两分钟。

1. 在对话框输入：/host-inspection — run an inspection on all ECS instances in the current workspace.
2. 智能体读取 Skill，自动填 region、UID、workspace、time_range。
3. 调底层 SLS 异常事件查询，扫整个工作空间。这一次的结果是 3 类 CRITICAL 异常、102 个实例、一共 1,380 个事件。
4. 对关键实例并发做 SysOM 诊断：内存重的用 memgraph，磁盘紧的用 diskanalysis。
5. 收成一份分级报告：马上做的 P0，以及已经恢复但还要看的 P2。

再往下钻，memgraph 的结论是内存利用率过高、有不够用的风险，并锁到一个进程：同一目录里 30 个 32 MB 的分片文件，合计 2.72 GB，怀疑共享内存泄漏。diskanalysis 的结论是磁盘使用率 91.7%，有写满的风险，根因是一个 31.6 GB 的测试填充文件，建议现在删掉。

102、1,380、2.72 GB、91.7% 和 31.6 GB 都来自这一次演示，不是多轮评测的均值。一两分钟也没有拆成每一步的秒数。

三种用法和还没给的数

三种模式：定时巡检按天或按周自动跑，异常才告警；对话式巡检用自然语言描述问题，由 AI 选检查项；API 或 MCP 接进现有运维平台或智能体流程。也可以只说「帮我查这台机器的内存」，它会跑内存全景、OOM 检测和 slab 检查。安全上写了分级 RAM 授权、Human-in-the-Loop 和全量审计。不用单独开通，在 CloudMonitor 2.0 或简单日志服务里点一下。文章没有给出定时巡检的默认频率以外的数字，也没有审计日志的样例条数。

50 多项里没有逐项的检出率和误报率。100% 检出没有样本量。92% 的 CPU 和 90% 的 iowait 是说明用的例子，不是三起故障的测量。页面没有禁止复制的声明。

阿里云，Shiyan Chen（OpenAnolis），STAROps Intelligent Host Inspection: A 24/7 AI Doctor for Your ECS Instances，2026-09-15，https://www.alibabacloud.com/blog/starops-intelligent-host-inspection-a-247-ai-doctor-for-your-ecs-instances_603554