用阿里云 ChatOps Agent 找回消失的日志：内核漏洞修复换盘后的 SLS 采集断流排查

本文是一次真实的线上排查记录，也是《内核漏洞修复》的续篇。一套运维 API 服务的日志突然查不到了，而且全程没有任何告警。我们先回溯"从什么时间开始没的"，发现断流起点正好落在之前那次内核漏洞修复换盘的时间点上；随后把现象、实例信息和 SLS 的 project / logstore 一并丢给阿里云控制台的 ChatOps Agent------它自己查出 Logtail 压根没装、用户自定义标识也没配，然后把这两样一并补齐、验证心跳恢复。

背景：运维 API 服务的日志，突然查不到了

出问题的是一套运维 API 服务，部署在杭州地域两台同标签、同角色的 ECS 实例上，日志通过 SLS Logtail 采集入库。

某天需要查这个服务的一段调用日志时，我们发现日志库里是空的 ------不是少了某几条，而是这个服务的日志整体断了。更让人后背发凉的是：全程没有任何告警。日志断流不像 CPU 打满、进程退出那样会触发报警，它就那么静静地停在那里，直到有人真的要去查日志才暴露。

而这套服务，不久前刚做过一次内核漏洞修复。

第一步：先搞清楚"从什么时间开始没的"

发现日志没了，第一反应不该是急着修，而是先把断流起点定下来------只有知道"从哪一刻开始没的"，才能去对这段时间里发生过什么变更。

在 SLS 里按实例维度过滤，翻出最后一条日志的时间戳，再拿这个时间点去对近期的变更记录，结果非常干净地对上了：

事实	观察结果
断流起点	正好落在内核漏洞修复替换系统盘的时间点上
换过盘的那台（实例 B）	换盘之后再没写过一条日志
未换盘的同角色实例（实例 A）	日志一直正常入库

上一篇《内核漏洞修复》记录的正是那次换盘：为修复 Linux 内核本地提权漏洞，我们直接更换了系统盘，容器服务当时也已恢复正常------验收通过了，但没人回头看日志。

至此能确定的是：断流和那次换盘是同一时刻发生的。至于换盘具体抹掉了什么------是 Logtail 没装，还是机器组标识没配，或者两者都是------站在日志库这一侧是看不出来的，得往实例里查。

换盘会打断采集链路的哪一环？

Logtail 是阿里云 SLS（日志服务）的数据采集 Agent。它要把日志送进 Logstore，得同时满足几层条件，而这几样东西全都放在系统盘上：

Logtail 装没装：可执行文件和启动脚本在换盘后可能压根不存在；
机器组标识配没配 ：机器组通常按两种方式之一纳管机器------
- IP 模式：机器组里写明实例私网 IP，Logtail 启动后按 IP 上报心跳；
- 用户自定义标识（user_defined_id）模式 ：在 /etc/ilogtail/user_defined_id 里写入固定标识（如 opsapi-online），机器组按该标识匹配；
进程跑没跑：装好、配好之后，Logtail 还得真正启动并持续上报心跳。

换盘会把这几层一起清零。但具体断在哪一层，光看 SLS 控制台是分辨不出来的------控制台只会告诉你"这台机器心跳异常"，不会告诉你是没装、没配、还是没起。人工排查到这里就卡住了：我们能确定"跟换盘有关"，但要往下定位到具体缺哪一项，就得登录实例逐项翻。

而这个问题的隐蔽性，来自两头都不吭声：

内核修复的验收标准里没有"日志采集"这一项：容器起来了、进程健康了、端口通了，就认为修复完成了；
SLS 侧也不会主动告诉你原因：控制台只显示机器心跳异常，不会提示"这台机器刚换过系统盘"。

如果按传统方式把这条链路查通、修好，需要：

登录 SLS 控制台，逐个 Logstore 检查采集状态、定位断流时间点；
找到对应的机器组，确认它是 IP 模式还是标识模式、期望值是什么；
登录 ECS 实例，检查 Logtail 是否安装、进程是否在跑、标识文件内容对不对；
缺什么补什么，重启 Logtail；
回到 SLS 控制台验证心跳，再回到日志库确认数据真的开始入库。

跨 SLS 和 ECS 两个控制台、外加一次实例登录。所以定位到"是换盘导致的"之后，具体断在哪一环、怎么补回去，我们直接交给了 ChatOps Agent。

交给 ChatOps：把现象、实例和 project / logstore 一起丢过去

我们登录阿里云控制台，进入 ChatOps 对话框，先让 Agent 把两台实例捞出来：

用户：查看杭州地域带有这两个标签的 ecs 实例（附带标签截图）

Agent 调用资源查询工具后，返回两台实例信息：

实例 ID	私网 IP	角色
`i-bp17rn************dla`	`10.10.0.116`	线上 OPS 实例 A
`i-bp17rn************dl9`	`10.5.0.230`	线上 OPS 实例 B

接着把三样东西一次性交给它------现象、实例信息、日志落在哪个 project / logstore：

用户：其中一台刚做完内核漏洞修复、换了系统盘，从那之后 SLS 日志就采集不上了。日志在 oos-online-hangzhou 这个 project 下，帮忙查一下是什么原因。

把 project / logstore 一并给足这一步很关键：Agent 只有知道日志该落在哪，才能反查到对应的机器组和采集配置。拿到这些信息后，Agent 把问题归类为 SLS Logtail 采集异常，并自动创建了一个排查计划：

计划名称：排查 SLS Logtail 采集异常
目标：确认这两台实例中哪一台的 Logtail 采集链路断了、断在哪一项
步骤 1：查询 SLS 项目下的机器组列表
步骤 2：检查机器组的纳管方式与机器标识，对比两台实例，定位缺失项

计划初始只有两个诊断步骤；定位到根因后，Agent 又把"修复配置"和"验证心跳"追加为新的子任务------整个计划是可以边执行边长出来的，也可以随时回看。

ChatOps Agent 处理流程

1. 查询 Logtail 机器组列表

Agent 通过 SLS API 查询到该 SLS 项目下的机器组：

text 复制代码

oos-engine-online
oos-openapi-online
oos-ops-online

结合业务角色，与 OPS 相关的机器组是 oos-ops-online。Agent 将第一步结论记录到计划中：

SLS 项目下共有 3 个机器组，与 ops 相关的是 oos-ops-online。

2. 定位到底断在哪一环

Agent 继续调用 SLS API 查看 oos-ops-online 机器组：它采用的是 user_defined_id 模式，期望标识为 opsapi-online。再对比机器组当前成员和两台实例的实际状态：

实例 A（10.10.0.116）：Logtail 正常，标识为 opsapi-online，心跳持续上报；
实例 B（10.5.0.230）：不在机器组中，无心跳。

顺着实例 B 往下查，Agent 定位到断的不是一环，而是两环：

Logtail 压根没装------换盘后的新系统盘上没有 ilogtail；
用户自定义标识也没配 ------/etc/ilogtail/user_defined_id 不存在，机器组自然认不出它。

这就解释了它为什么会从机器组里彻底消失：不是标识写错了，而是采集端整个不见了。而这两项，恰恰是我们站在 SLS 控制台那一侧无论如何也看不到的。

3. Agent 把缺的两样一并补齐

定位到根因后，Agent 并没有停在"给你一段命令、自己上去执行"，而是先摊开修复方案和将要执行的命令，等我们在会话里确认后，通过云助手通道直接在实例 B 上执行：

bash 复制代码

# 1. 重新安装 Logtail（安装脚本按 project 所在地域取，SLS 控制台的机器组接入指引里可直接复制）
sudo ./logtail.sh install cn-hangzhou

# 2. 写入机器组期望的用户自定义标识
sudo mkdir -p /etc/ilogtail
echo "opsapi-online" | sudo tee /etc/ilogtail/user_defined_id

# 3. 启动 / 重启 Logtail 使配置生效
sudo /etc/init.d/ilogtaild restart

整个过程我们没有 SSH 登录实例：命令由 Agent 下发，执行结果直接回流到会话里，能逐条看到哪一步成功、哪一步失败。如果实例用的是较新的 systemd 管理版本，最后一步会自动换成 systemctl restart ilogtaild。

注意：如果机器组采用的是 IP 模式，第 2 步就换成确保实例私网 IP 已加入机器组列表------该走哪条路径，同样由 Agent 根据机器组的纳管方式自己判断。

4. 验证恢复

修完不算完，Agent 接着自己复查了一遍机器组成员：

bash 复制代码

aliyun sls ListMachines \
  --region cn-hangzhou \
  --project oos-online-hangzhou \
  --machineGroup oos-ops-online

输出显示两台实例均已上报心跳：

json 复制代码

{
  "machines": [
    { "ip": "10.10.0.116", "userdefined-id": "opsapi-online" },
    { "ip": "10.5.0.230",  "userdefined-id": "opsapi-online" }
  ]
}

同时，SLS Logstore 中实例 B 的日志重新开始入库，采集延迟逐步回落至正常范围。至此，从"发现日志库空了"到"采集恢复"，我们一步都没有离开 ChatOps 会话窗口。

检查项	修复前	修复后
实例 B 上的 Logtail	❌ 未安装	✅ 已安装并运行
实例 B 的 `user_defined_id`	❌ 不存在	✅ `opsapi-online`
机器组 `oos-ops-online` 成员数	1	2
实例 B 心跳	❌ 无	✅ 正常
实例 B 日志入库	❌ 中断	✅ 恢复

根因复盘：真正的问题不是配置丢了，而是"丢了没人知道"

配置丢失本身只是个小故障------写一个文件、重启一个进程就能修好。这次值得复盘的是它为什么能静默存在这么久：

断流没有告警：日志库空了不会触发任何报警，SLS 侧只显示机器心跳异常，也不会主动关联"这台机器刚换过盘"。
变更验收不含采集侧：内核修复的验收清单里有容器、进程、端口，唯独没有"日志还在不在入库"。
换盘天然是"采集端清零"操作 ：这次断的不止一环------Logtail 本身没装，/etc/ilogtail/user_defined_id 也不存在。这些东西全在系统盘上，换盘等于把采集端整个抹掉；机器组按固定标识匹配时，新盘必须重装 Logtail 并重新声明标识，才能被重新纳管。
发现问题靠的是"刚好要用日志"：如果不是这次正好要查一段调用日志，断流还会继续静默下去。

所以真正的教训有两条：一是内核修复（换盘）的收尾 checklist 必须补上采集侧 ------检查 Logtail 是否安装、user_defined_id / IP 是否匹配机器组、验证心跳、验证日志真的开始入库；二是给关键 Logstore 配上"日志入库量跌零"告警，别把发现问题的时机交给"刚好有人要查日志"。

ChatOps Agent 在此场景中的关键能力

这次排查体现了阿里云 ChatOps Agent 作为 AIOps 入口的几项关键能力：

1. 自然语言定位资源

我们只需要说"查看杭州地域带有这两个标签的 ecs 实例"并贴上标签截图，Agent 就能自动调用资源查询工具，返回实例 ID、私网 IP 等关键信息，无需手工翻控制台。

2. 结构化计划与分步执行

Agent 没有一次性执行所有操作，而是先创建可检查的排查计划，把"查机器组 → 查成员 → 定位缺失 → 修复 → 验证"拆成可追踪的子任务。每一步的结论都会回写到计划，便于审计。

3. 既能查 API，也能下命令

通过 CommonAPICaller 等工具，Agent 可以直接调用 SLS API 查询机器组和机器心跳，比人工在多个控制台页面间跳转更快、更准；确认根因后，它又能通过云助手把修复命令下发到实例上执行------查、判、修、验在同一条会话里闭环，这是本次最省时间的地方。

4. 有副作用的操作，先确认再执行

对"写入标识文件""重启 Logtail"这类会改变实例状态的操作，Agent 会先把方案和将要执行的命令摊开，等我们在会话里确认后才真正下发。这样既省掉了人工登录敲命令的动作，也没有把"要不要改"的决定权交出去。

5. 变更前后量化对比

修复完成后，Agent 会再查一次机器组和实例状态，用表格形式呈现"Logtail 是否安装、标识是否写入、成员数、心跳、日志入库"的前后对比，方便确认问题是不是真正解决了、而不是"看着像好了"。

推广价值：沉淀成两条可复用的动作

这次案例可以拆成两条 SOP，分别对应"已经出事了怎么查"和"下次怎么不出事"。

A、日志断流的定位动作（发现侧）

发现日志缺失，先按实例维度过滤，定位最后一条日志的时间戳；
拿这个时间点去对近期变更记录（换盘、重装、克隆、扩缩容）；
时间点对上，基本就能锁定是"本地采集环境被重置"，不必再从零猜；
带着这个结论找 ChatOps Agent，连同现象、实例信息、project / logstore 一起给它，让它定位到具体断在哪一环并修复。

B、内核漏洞修复（换盘）后的收尾动作（预防侧）

换盘并确认业务恢复后，立即检查 SLS 机器组心跳；
若心跳丢失，先确认 Logtail 还在不在（换盘后大概率已经没了），不在就重新安装；
再检查 /etc/ilogtail/user_defined_id 是否存在、是否与机器组期望值一致；
重启 Logtail，验证心跳恢复；
回到日志库确认真的有新数据入库；
给关键 Logstore 配一条"入库量跌零"告警；
将本次修复路径记录到 Agent 记忆中，后续同类变更可自动提示。

对运维团队的价值：

把"猜"变成"对时间点"：断流起点 + 变更记录，是定位这类问题最短的路径。
补上安全修复的最后一公里：内核漏洞修完了，但可观测性不能跟着一起"修没"------否则下一次故障就是盲查。
缩短 MTTR：从"发现日志缺失 → 登录排查 → 手工修复"压缩为"一句话描述 → Agent 定位 → Agent 执行修复"。
沉淀审计记录：每次排查计划、API 调用、修复命令都可追溯。
经验可复用：同一批做内核修复的其他实例出现类似问题时，Agent 可直接复用本次修复路径。

适用场景与边界

ChatOps Agent 在这类场景中特别适合：

内核漏洞修复换盘、镜像重装、实例克隆后的采集恢复检查；
已经定位到断流时间点后，快速确认到底断在哪一环（没装 / 没配 / 没起）；
机器组 IP 或 user_defined_id 变更后的成员核对；
多实例场景下快速定位哪一台采集异常；
需要跨 ECS、SLS 两个产品联动排查的运维任务。

但以下情况仍需要人工介入：

断流起点与变更的关联判断：Agent 能查出最后一条日志的时间，但"这个时间点对应哪次变更、当时为什么这么改"仍需要人来确认；
日志缺失是因为业务进程本身未启动，而非 Logtail 问题；
需要修改机器组所属账号、RAM 权限等安全相关配置；
涉及 Logtail 版本兼容性、自定义插件等深度问题；
需要在生产环境执行可能影响业务的批量变更。

结语

日志断流最危险的地方不在于"没日志"，而在于它安静得可怕：没有告警、没有报错、业务照常跑，直到某天你需要它的时候，才发现最关键的那几天是空的。

这次的排查路径其实很朴素------先定位断流起点，再对变更记录 ，一下就撞上了之前那次内核修复换盘。但"跟换盘有关"只是个方向，真正费事的是往下定位：到底断在哪一环。这部分交给 ChatOps Agent 之后，它拿着我们给的现象、实例和 project / logstore，自己制定排查计划、调用 SLS API 对比两台实例、查出Logtail 压根没装、用户自定义标识也没配 这两处断点，并在我们确认后直接把 Logtail 装上、标识补齐、复查心跳恢复。从把问题丢进对话框到采集恢复，全程没有登录一次实例，也没有在两个控制台之间来回切换。

人机分工在这次排查里分得很清楚：人负责把现象变成线索 （断流起点 → 关联到换盘），Agent 负责把线索变成结果（查出断在哪一环 → 补齐 → 验证）。结合上一篇的内核漏洞修复，这套组合已经能覆盖"安全修复 → 业务恢复 → 可观测性恢复"的完整链路。

如果说有什么值得立刻去做的，那就是给关键 Logstore 加一条"入库量跌零"告警------别让下一次断流，又是靠"刚好有人要查日志"才发现。

相关文章：

前篇：阿里云 ChatOps Agent 让非标准化环境可修复：内核漏洞换盘后的容器恢复
阿里云 ChatOps Agent 辅助告警响应：ECS 磁盘使用率从 80% 降到 34% 的排查与修复