Linux 危机工具
当性能问题导致系统中断时，你一定不想浪费宝贵的时间去安装诊断所需的工具。以下是我建议在 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
a