AI 排查服务器故障：从惊艳到失望的 systemd 与 ifa_cacheinfo 溢出经历

奇怪的警报

我正准备结束一天的工作，但你能想象发生了什么。一个与重要服务器相关的警报触发了！又来了……

该服务器是一个有状态集群的一部分，如果长时间缺席可能会导致严重问题。

警报信息很简单。Node-XX is Down

下面的图片是AI生成的

当然，我立刻投入尝试进行故障排除。我尝试通过反向代理ssh进入服务器。失败了！当然，它会失败。我当时到底在想什么？

我决定检查集群状态以了解问题的严重性。超级令人惊讶的是，集群处于健康状态，节点在集群的成员列表中。

什么？？？你在开玩笑吗？这怎么可能？

是时候调查了

我又做了几次检查，完全确认集群是健康的。那一刻我松了一口气，我有充足的时间来调查这个有趣的问题。

首先，我怀疑服务器中的反向ssh代理没有运行之类的。但这说不通！因为来自node-exporter的指标没有被抓取。问题肯定比ssh更广泛。那为什么应用程序能工作且集群是健康的？极度困惑！

获得了服务器的串行控制台访问权限。幸运的是，我能够与服务器交互！服务器实际上并没有宕机。

让我们检查应用程序的状态。它确实在运行！SSH反向代理代理也是健康的。更加困惑了！

让我们检查网络连接和导出器可用性。ip -6 a显示接口已启动并正常工作。curl到导出器在本地和远程都能工作！

这时我完全不知道发生了什么。

AI大神，我需要你的帮助！

绝望中，我决定向AI寻求帮助，但不是编码代理，因为我无法将串行控制台的访问权限提供给像codex这样的代理。甚至复制控制台的输出都不可能。我只能截图！可能看起来疯狂，但为什么不呢！

我打开了一个ChatGPT会话并解释了情况。我要求它排除故障，而我将作为它的工具。它应该一次给我一个命令，我会用截图分享结果。（是的！我有充足的时间！）

有很多命令要运行，而且很耗时。代理真是天赐之物！

在故障排除过程中，根据命令及其输出，我理解了问题。网络接口被不断地移除和重新添加。这就是为什么我之前的手动检查（不）幸运地起作用了！我不知道如何修复这样的问题。在单独的会话中问了ChatGPT几个问题。甚至使用了老朋友谷歌搜索类似问题。但没机会！

我仍在向ChatGPT提供截图，但某个时候它停止要求更多命令，并进行了大量思考和搜索！

它回复了一个指向systemd仓库中github issue的链接。

该问题似乎正是我们的情况。它是由systemd中的一个bug引起的，该bug导致ipv6接口被反复移除和重新添加。ChatGPT总结了该问题，解释了bug并建议将systemd升级到某个版本。

快乐很快消失了！

我很激动，多亏了ChatGPT，我找到了问题和修复方法！现在是时候升级systemd了！

但是等等！集群中所有其他服务器都使用相同版本的systemd。为什么它们没有受到这个问题的影响？在执行任何操作之前，我需要了解确切的根本原因！

我在同一个会话中继续与ChatGPT对话。询问为什么该问题没有影响集群中的其他服务器。这一次讨论似乎不太顺利。经过长时间的来回交流，我找不到任何令人信服的理由。

真是一波三折！半小时前我还惊叹不已，现在却失望了。

作为最后的手段，我询问了一位在这个集群和服务器方面经验最丰富的同事。他开始进行一些检查，与我会话中ChatGPT建议的检查非常相似。 经过一些检查后，他说：

+ 只有这台服务器的运行时间达到了498天。也许是某种整数溢出。我去问问ChatGPT

AI再次调查！

我同事与ChatGPT的对话继续，它发现了一些非常有趣的东西。这似乎就是我们问题的根本原因。 它指出问题是由IFA_CACHEINFO中的溢出引起的。我们完全不知道那是什么。

经过进一步调查，我们发现Linux内核代码中有一个名为ifa_cacheinfo的结构体。它使用一个__u32来存储接口的创建时间，单位是百分之一秒。简单计算一下，很明显它最多只能容纳497.1天！

struct ifa_cacheinfo {
	__u32	ifa_prefered;
	__u32	ifa_valid;
	__u32	cstamp; /* created timestamp, hundredths of seconds */
	__u32	tstamp; /* updated timestamp, hundredths of seconds */
};

找到了！我们的服务器运行时间达到了498天。我们现在可能真的找到了根本原因！ 重启之后问题就消失了！（我们有时候真的是重启工程师😂）

但还有一个小问题！为什么同样使用网络的应用程序没有受到影响？ 因为该应用程序使用dpdk进行网络通信，在这种情况下绕过了Linux内核。一目了然🫠

反思

• 首先，像claude code和codex这样的智能体真是天赐之物！我厌倦了充当现实世界和模型之间的管道，截了那么多图！😁你可能会说，即使有了计算机使用功能，这类情况也能解决。但由于一些有争议的原因，我还没有完全信任到可以授予关键生产工作负载的访问权限！
• 如果我们不了解底层实际发生了什么，AI有时可能会误导我们。在这个特定案例中，将systemd升级到另一个版本（不是AI建议的那个）也能解决问题。但如果问题还没有被systemd解决呢？如果新版本可能带来以前不存在的新的已知/未知问题呢？
• 经验和洞察力仍然重要！至少目前如此！AI有时会陷入某种局部极值。
• 像systemd（有时还有linux）这样的某些软件也可能有意外行为和bug！我大多盲目信任Linux及其基础组件。虽然这种情况很少见，但在排查故障时，始终牢记这一点是好的。