Linux 危机工具

linux| 2024-03-25

当性能问题导致系统中断时，你一定不想浪费宝贵的时间去安装诊断所需的工具。以下是我建议在 Linux 服务器上默认安装的 “危机工具 “列表（如果尚未安装），以及它们的（Ubuntu）软件包名称：

Package	Provides	Notes
procps	ps(1), vmstat(8), uptime(1), top(1)	basic stats
util-linux	dmesg(1), lsblk(1), lscpu(1)	system log, device info
sysstat	iostat(1), mpstat(1), pidstat(1), sar(1)	device stats
iproute2	ip(8), ss(8), nstat(8), tc(8)	preferred net tools
numactl	numastat(8)	NUMA stats
tcpdump	tcpdump(8)	Network sniffer
linux-tools-common linux-tools-$(uname -r)	perf(1), turbostat(8)	profiler and PMU stats
bpfcc-tools (bcc)	opensnoop(8), execsnoop(8), runqlat(8), softirqs(8), hardirqs(8), ext4slower(8), ext4dist(8), biotop(8), biosnoop(8), biolatency(8), tcptop(8), tcplife(8), trace(8), argdist(8), funccount(8), profile(8), etc.	canned eBPF tools[1]
bpftrace	bpftrace, basic versions of opensnoop(8), execsnoop(8), runqlat(8), biosnoop(8), etc.	eBPF scripting[1]
trace-cmd	trace-cmd(1)	Ftrace CLI
nicstat	nicstat(1)	net device stats
ethtool	ethtool(8)	net device info
tiptop	tiptop(1)	PMU/PMC top
cpuid	cpuid(1)	CPU details
msr-tools	rdmsr(8), wrmsr(8)	CPU digging

一些较长的说明：[1] bcc 和 bpftrace 有很多重叠的工具：bcc 的工具功能更强（例如 CLI 选项），而 bpftrace 的工具可以即时编辑。但这并不是说其中一个比另一个更好或更快：它们发出的 BPF 字节码是一样的，运行起来也一样快。还要注意的是，bcc 正在从 Python 向 libbpf C（带 CO-RE 和 BTF）演进和迁移工具，但我们还没有重新制作软件包。未来，”bpfcc-tools “应该会被更小的 “libbpf-tools “包取代，后者只是工具二进制文件。

此列表只是最低要求。有些服务器有加速器，你还需要安装它们的分析工具：例如，在英特尔 GPU 服务器上，需要安装 intel-gpu-tools 软件包；在英伟达服务器上，需要安装 nvidia-smi。调试工具（如 gdb(1)）也可以预先安装，以便在危机时立即使用。

像这样的基本分析工具不会经常更换，因此这份列表可能只需要每隔几年更新一次。如果你认为我遗漏了当今重要的软件包，请告诉我（例如在评论中）。

添加这些软件包的主要缺点是它们在磁盘上的大小。在云实例上，向基本服务器镜像添加 Mbytes 会增加实例部署时间，甚至是几分之一秒。幸运的是，我列出的软件包大多很小（而且 bcc 也会越来越小），因此花费的大小和时间都很少。我曾见过因体积问题而无法在默认情况下包含 debuginfo（总计约 1 Gbyte）的情况。

我能不能在需要时再安装吗？

在生产环境出现危机期间尝试安装软件可能会出现许多问题。下面我将通过一个虚构的例子，结合我在实践中总结出的一些经验：

下午 4:00：警报！你公司的网站瘫痪了。不，有人说还在运行。还在吗？正常，但速度太慢，无法使用。
下午 4:01：您查看监控仪表板，发现一组后端服务器出现异常。是磁盘 I/O 高吗？是什么原因造成的？
下午 4:02：您通过 SSH 连接到一台服务器以深入研究，但 SSH 登录需要很长时间。
下午 4：03：出现登录提示，输入 “iostat -xz 1 “开始查看基本磁盘统计数据。停顿了很久，最后提示 “未找到命令’iostat’…请尝试：sudo apt install sysstat”。唉。鉴于系统运行速度很慢，安装这个软件包可能需要几分钟。运行安装命令。
下午 4:07：软件包安装失败，因为无法解析软件源。/etc/apt 配置出了问题。由于服务器所有者现在正在 SRE 聊天室帮助处理故障，您问道：”你们是如何安装系统软件包的？他们回答：”我们从不安装。我们只更新应用程序。唉。你找到另一台服务器，将其正常运行的 /etc/apt 配置复制过来。
下午 4:10：你需要先用固定配置运行 “apt-get update”，但速度慢得要命。
下午 4:12：……真的要花这么长时间吗？
下午 4:13: apt 返回 “失败：连接超时”。也许这个系统的性能问题太慢了？还是无法连接到 repos？你开始进行网络调试，并询问服务器团队：”你们用防火墙吗？”他们说不知道，要问网络安全团队。
下午 4：17：网络安全团队回复：是的，他们已经阻止了任何意外流量，包括 HTTP/HTTPS/FTP 的出站 apt 请求。嘎嘎。”你能马上编辑规则吗？”没那么容易”那完全关闭防火墙呢？””紧急情况下，当然可以”
下午 4:20：防火墙被禁用。你再次运行 apt-get update。虽然很慢，但还是成功了！然后运行 apt-get install，结果……权限错误。什么？我是 root，这根本没道理。你在 SRE 聊天室分享了你的错误，有人指出了你的错误：平台安全团队不是让系统不可变了吗？
下午 4:24：平台安全团队现在在 SRE 聊天室解释说，文件系统的某些部分可以写入，但其他部分，尤其是可执行二进制文件，则被阻止。嘎嘎！”我们怎么才能禁用这个功能？”不行，这就是问题所在。你必须创建新的服务器镜像，并禁用它。”
下午 4:27：此时，SRE 团队已宣布发生重大故障，并通知了执行团队，他们要求定期更新状态，并告知何时修复。状态：还没做什么。
下午 4:30：你开始运行 “cat /proc/diskstats”，作为最基本的 iostat(1)，但必须花时间阅读 Linux 源代码（admin-guide/iostats.rst）才能理解它。它只是确认磁盘是否繁忙，而你从监控仪表板上已经知道了这一点。你确实需要磁盘和文件系统跟踪工具，如 biosnoop(8)，但你也无法安装它们。除非你也能黑进最基本的跟踪工具……你可以 “cd /sys/kernel/debug/tracing”，然后开始查找 FTrace 文档。
下午 4:55：新的服务器镜像终于启动，所有文件系统均可写入。你登录后，”apt-get install sysstat”。你还没来得及运行 iostat，聊天室里就传来了消息：”网站已恢复！谢谢！你们做了什么？”我们重新启动了服务器，但还没有修复任何问题。你有一种感觉，今晚你睡着后 10 分钟，断电就会再次出现。
凌晨 12:50：Ping！我就知道会这样。你从床上爬起来，打开工作用的笔记本电脑。网站瘫痪了–被黑客攻击了–有人禁用了防火墙和文件系统安全。

幸运的是，我没有经历过凌晨 12:50 的事件，但其他事件都是基于真实世界的经验。在我之前的工作中，这个顺序经常会发生变化：”流量团队 “可能会在 15 分钟左右启动云区域故障转移，因此我最终会安装 iostat，但随后这些系统就会闲置。

默认安装

上述情况说明了为什么理想情况下需要预先安装危机处理工具，以便在停机期间迅速开始调试生产问题。有些公司已经这样做了，他们的操作系统团队会创建包含所有内容的自定义服务器镜像。但有许多仍在运行默认 Linux 版本的网站在这方面学得很辛苦。我建议 Linux 发行版将这些危机处理工具添加到它们的企业 Linux 变体中，这样，无论公司大小，都能在发生性能中断时立即投入运行。

本文文字及图片出自 Linux Crisis Tools