【一个人的SOC】(07) 数据可靠性——源健康/同步死信/对账差异三层聚合

上一篇 (06) 资产对账我们学了 F1.3——它能告诉你"台账和实际数据差在哪"，三类差异清清楚楚列出来。但你跑 F1.3 时一定会撞上一个新问题：

“为什么今天突然有 50 条 shadow？是新增了 50 台新设备吗？还是 5 条新设备，剩下 45 条其实早就在，只是昨天没跑对账？”

更让人头疼的是——你分不清数据流在哪个环节坏了：

• 采集器没收到数据？ → 那你看到的"差异"其实是"看不见的真实"
• 采集器收到了但同步失败？ → 那你看到的"差异"是"看见但没写进来"
• 同步成功但台账没对账？ → 那你看到的"差异"是"该算的没算"

这是三个不同问题，解法也完全不同。

本篇解的就是当数据"看起来不对"时，怎么 30 秒内定位是哪一层坏了——靠的是把"源健康 + 同步死信 + 对账差异"三层信号聚到一个看板上。

为什么 SOC 也需要"数据可靠性"？

直说原因——F1.3 的输出严重依赖它前面两层的健康：

如果 Loki 断了 1 小时，F1.3 跑的时候拿到的就是"1 小时前的数据"——它依然会输出’无差异’，而你以为是’今天没问题’。

错。是你没看到今天的问题。

这就是 06 篇里那条硬约束——“源不新鲜时禁止静默给无差异结论”——的来源。数据可靠性是把那条约束从一句口号，变成一个有数字有事实的看板。

这一篇的实质是：让你不再"被自己骗"。

三层健康聚合：一张图说清"数据流哪一层坏了"

这三层是从左到右的因果链：

采集器 → 同步管道 → 对账引擎 → 你看到的"差异"
  ①        ②          ③
  ↓         ↓           ↓
源健康  同步死信    对账差异

关键洞察：一个源头出问题，会同时让三层都变红——但只有识别出"哪一层先变红"，才能知道根因。

🎯 实战判断：

• 只有 ③ 变红 + ①② 都绿 → 业务层问题（设备变动、IP 飘了）
• ①②③ 全红 → 先修①（源头都没数据，下游不可能对）
• ① 绿 + ②③ 红 → 先修②（数据有了但写不进去）
• ①② 绿 + ③ 特别红 → F1.3 配置/基线问题，不是数据问题

这就是"30 秒定位"的根因。

实战：看一次健康看板

控制台 → “数据健康” 页就是你刚才看的那张图的全貌。

第一次打开这个页面会看到什么？根据你的网络规模不同，大致是：

• 源健康：3 个采集器（Wazuh/TP-Link/Nmap）状态灯——online/offline/stale（数据 24h 没更新）
• 同步死信：失败记录数（新手一般 0；网络抖动时偶尔 1-2 条）
• 对账差异：shadow / offline / mismatch 三类数字

重点看趋势小图——某一条线突然陡增 = 出事了。

各源健康状态：采集器健康度红黄绿三色

⚠️ 关键约束（06 篇里也讲过，这里再强调一次）：任何一个源 24 小时没成功同步，状态灯必须变红。看到红灯别先怪系统——那是设计行为，提醒你"这个源已经断了一阵"。

死信队列：失败的记录去哪了？

你可能想问：“源健康失效"和"同步死信"听起来都像"失败了”——区别是什么？

源健康失效 = 采集器没拉到数据（网络问题、采集器宕机、凭据过期）； 同步死信 = 采集器拉到了但写不进库（schema 不匹配、字段越界、关联约束冲突）。

两者的处理路径完全不同。来看看一条数据"从采集器到 SOC"会走哪条路：

关键设计（这是 F1.3 同源思想）：单条失败不阻断整批。Wazuh 推 100 条来，1 条 schema 不对 → 其他 99 条正常入库，那 1 条单独进死信。你随时可以从死信页查到它、修好它、让它重放。

死信计数提示：资产对账页顶部的「X 条死信待处理」一行

💡 为什么"失败不阻断整批"很重要？ 因为网络抖动、字段变更、版本升级都太常见了——让 99% 的好数据进得来，比让 1% 的坏数据卡住整批更划算。

处置死信：3 个动作

当死信出现时，你绝大多数时候只有 3 个选择：

💡 典型场景：

• 8 月 23 日我们做了一次代码更新，旧 schema 的数据进死信了——重放一次就解决了；
• 路由器固件升级后 IP 格式变了，3 条死信——改完解析代码后重放；
• 测试期间主动 push 的一些奇怪格式的 payload——直接标记已解决，永远不重试。

常见问题

Q：源健康红 + 死信 0 + 对账差异爆增——什么情况？

A：这是经典"采集器长时间不工作"模式：数据没进 → 看不到死信（因为没东西进失败）→ 但台账与实际差距越来越大。根因在源头，先修采集器（网络/凭据/容器）。

Q：源健康绿 + 死信 100 + 对账差异只增不减——什么情况？

A：典型"schema 升级但代码没跟上"模式：数据在进，但写不进去。根因在管道，看死信详情里的错误码，大部分会是字段类型/约束。

Q：什么时候该重放 vs 跳过？

A：看错误码。重放 = 你修了什么，预期这次会成功（代码改完、字段加完）。跳过 = 你承认这条数据永远不该进来（测试数据、过期格式、已知设备下线）。

Q：F1.3 报"shadow 50 条"，先看 07 的看板还是先处理？

A：先看 07 的看板。如果 ① 源健康有红灯，shadow 可能是"采集器突然回了"或"突然没回"造成的假信号——修了源头再看，不然处理到一半发现是"数据本身不准"。

收尾：07 在系列中的位置

到本篇为止，你的 SOC 不只是"看见"和"看清"——还多了一层**“自我诊断”**：

接下来 08 篇会进一步把"多源数据不一致时信哪个"——身份可信度评分解决最后一个"真"的问题。

老李上周发现一个诡异现象：F1.3 突然报 30 多条 shadow。 他慌了 5 分钟，然后点开 07 看板——所有源状态绿 + 死信 0。 5 分钟后他意识到：不是有人搞事，是上周换了办公楼、所有人手机重新连了 5GHz 而不是 2.4GHz，路由器把新 MAC 都报给采集器了。 看完看板、知道根因后，他点"一键纳管"批量处理了 30 多条。

没有 07 的看板，他会花两小时翻日志找"是不是被攻击了"。

老李的看板救了他一晚上睡眠时间。你的呢？

【系列导航】《一个人的SOC》总目录（持续更新）

【上一篇】(06) 资产对账——影子/离线/不匹配三类差异稽核

【系列开篇】(00) 中小企业为什么需要自己的安全运营中心

【项目地址】AI-miniSOC - GitHub · MIT 开源，欢迎 Star ⭐ **【Gitee 镜像】**https://gitee.com/xiejava/AI-miniSOC

【交流】 看板上看到 3 个源都变红怎么办？别慌——把死信列表的截图发 Issue，我帮你按"先源头、再管道、最后对账"的顺序诊断。

下一篇：[待 08 完成后补充链接]

作者博客：http://xiejava.ishareread.com/