Linux故障排查神器atop：从安装配置到日志回放的全方位实战指南

如果你负责过一台跑业务的 Linux 实例，大概率经历过这种尴尬：白天一切正常，一到凌晨就有一台机器 CPU 飙到 100%，等你 SSH 上去的时候负载已经自己降下来了。top 看一秒、htop 看十秒，都看不到十分钟之前发生了什么。这个场景里，真正能帮你把案发现场找回来的工具，不是 top，不是 htop，而是 atop。

atop 是 Linux 下一个非常老牌的系统与进程监控工具，它最大的特点不是“实时看”，而是“持续记录”。它会在后台按固定间隔把 CPU、内存、磁盘、网络以及每个进程的 CPU 消耗、内存增长等细节全部写进压缩二进制日志。等实例出问题时，你只要回放对应的日志文件，就能知道故障前那一刻系统里究竟在发生什么。这篇内容就围绕火山引擎 Linux 实例上搭建 atop 的完整路径来写：怎么安装、怎么配置守护进程、交互界面怎么读、CPU 飙高/内存泄漏/磁盘打满这类高频故障怎么用它定位，以及部署后必须避开的几个坑。

如果你平时的工作就是维护云上实例、排查线上性能问题，或者正在为团队搭建一套轻量的“事故留痕”机制，这篇文章可以直接当作操作手册来用。

1. 为什么在云实例上排查性能问题，我首选 atop 而不是 top

很多人的习惯是：实例一卡，第一反应就是敲 top。top 确实能告诉你“此刻”谁在吃 CPU、谁占内存，但它只给你一扇极窄的窗户。等你能登录上去的时候，负载可能早就恢复了，top 看到的一切都是“风平浪静”，而故障证据已经全部丢失。

1.1 top 的“当下视角”与 atop 的“历史视角”

top 默认的刷新周期是 3 秒左右，它展示的是当前采样点的瞬时快照。实例负载降低之后，你最多只能从监控平台的曲线图上看到一个大致的尖峰，但无法回答下面这些问题：

• 尖峰期间是哪个进程把 CPU 吃满的？
• 内存是从哪个时间点开始持续上涨的？
• 磁盘 IO 满的时候，到底是随机小 IO 还是顺序大流量？
• 系统失去响应前，进程列表最后变成了什么样？

atop 的设计目标就是解决这些。它启动后会按照固定的采样间隔（默认 600 秒）采集一次系统全貌，并把每次采样追加到当天的日志文件里。这个文件里面不仅有汇总数据，还有完整的进程级明细。你之后可以用atop -r打开任意一天的日志，像翻监控录像一样把故障窗口内的每个采样点翻出来看。

1.2 和 sar、htop 放在一起比，atop 的独特点

有人会问：sar 也能记录历史数据，htop 展示的信息更丰富，为什么偏偏是 atop？我把这四类工具放在一起做了个对比，差别其实很清晰：

sar 要事先配置好 sysstat 的 cron 任务，没配置的机器等于没有任何历史数据。而 atop 在很多发行版里装上之后就会自动以守护进程方式运行，天然自带“监控录像”。htop 的交互体验确实好，但它和 top 一样不落盘，依然解决不了“事后查证”的问题。

所以我的结论很直接：实时看 load 用 top 够了，但凡是需要“出事故之后还原现场”的场合，atop 是更合适的底座。

2. 火山引擎 Linux 实例上的安装与守护进程配置

atop 的安装不复杂，真正容易被忽略的是“装完之后有没有在后台记录”。下面按火山引擎控制台常见的镜像体系分别给出安装命令，并说明如何验证守护进程真的在写日志。

2.1 不同镜像体系下的一行安装命令

登录实例后，先确认一下系统版本和 atop 是否已经存在：

cat /etc/os-release command -v atop

CentOS 7/8、以及使用 yum 体系的 openEuler 这类镜像，可以直接安装：

yum install -y atop systemctl enable --now atop

如果yum install提示找不到 atop 包，多半是默认源里没有，需要先启用 EPEL：

yum install -y epel-release yum update -y yum install -y atop systemctl enable --now atop

Ubuntu、Debian 镜像使用 apt 体系：

apt-get update apt-get install -y atop systemctl enable --now atop

安装完成后建议顺手看一下版本，确认不是老掉牙的远古版本：

atop -V

提示：火山引擎控制台上创建的实例，只要安全组放行了 SSH，安装命令通常不会遇到网络问题。如果实例处于私有网络且没有 NAT 网关，需要先保证 yum/apt 源可达，否则包管理器会一直超时。

2.2 确认守护进程真的在写日志

很多人在安装完 atop 后直接敲atop进入交互界面，看到系统信息就以为完事了。实际上，交互界面只是 atop 的“前台模式”，真正的历史记录功能要靠后台守护进程。你得确认日志文件正在生成：

systemctl status atop ls -lh /var/log/atop/

正常情况下/var/log/atop/目录下会出现类似atop_20240115这样的当天文件。刚启动时文件可能很小，但它的存在本身就说明守护进程正在工作。如果没有这个文件，排查思路是：

1. 确认服务状态是否为 running；
2. 看journalctl -u atop有没有报错；
3. 确认配置里的LOGPATH指向的目录可写。

2.3 三个关键配置变量：LOGOPTS、LOGINTERVAL、LOGPATH

atop 守护进程的配置因发行版位置略有不同：

• RHEL/CentOS 系：/etc/sysconfig/atop
• Ubuntu/Debian 系：/etc/default/atop

核心配置变量就三个：

LOGOPTS="-wR" LOGINTERVAL=600 LOGPATH=/var/log/atop/

• LOGOPTS：-w表示把数据写入原始日志文件，-R表示让 atop 自己处理日志文件的按天切换和保留；
• LOGINTERVAL：采样间隔，单位秒，默认 600 秒就是每 10 分钟记录一次；
• LOGPATH：原始日志文件的存放目录。

修改配置后需要重启服务：

systemctl restart atop systemctl status atop

我见过不少机器日志文件一直不增长，最后发现是用户手动敲atop -w起了个临时进程，而不是通过 systemd 管理守护进程。这种临时进程一旦终端断开就被杀了，数据自然也就丢了。

3. atop 工作的底层模型：采样周期、原始日志文件与磁盘占用的账

要真正用好 atop，得理解它背后的数据模型。这不是理论问题，而是直接关系到你以后能不能在正确的位置找到正确的时间点。

3.1 一个采样点里装了什么

atop 的每个采样点不是只记几个 load 数字，而是一整套系统快照：

• CPU 层面的总体使用率、每个 CPU 核的使用率、中断占比；
• 负载均值、当前系统上进程与线程的总数；
• 物理内存总量、已用、缓存、交换分区使用情况；
• 所有磁盘设备的读写速率、busy 占比；
• 网卡的收发速率、TCP/UDP 包统计；
• 每个进程的 CPU 时间、虚拟内存/常驻内存、内存增长量、磁盘读写字节数。

这些数据合在一起，基本就是一台实例在一瞬间的完整“体检报告”。因为日志文件是压缩二进制格式，普通文本阅读工具打不开，必须用 atop 自己来读。这也是很多人不知道它价值的原因——你不会没事去翻一个二进制文件。

3.2 一天的日志文件到底占多大

很多人在部署前最关心的一个问题：日志会不会把磁盘撑爆？这个问题其实很好估算。

先看采样次数：默认 600 秒间隔，一天是 1440 分钟，也就是 144 个采样点。再估算每个采样点的大小：一台 300 个进程左右的常规业务实例，一个采样点包含所有进程明细，压缩后大概在 1KB 到 3KB 之间。一天的日志量差不多就是这个数量级：

注意，这只是个估算量级。真正的影响因素有两个：一是实例上的进程/线程总数，线程也会被记录；二是采样频率，把间隔从 600 秒改成 60 秒，日志体积大约放大 10 倍。对大多数实例来说，默认配置跑一个月，日志总量基本不会超过一两百 MB，这点开销相对于排障价值是完全可以接受的。

日志的保留策略由LOGOPTS里的-R、发行版自带的 logrotate 配置共同控制。默认情况下原始日志会保留若干天，超出保留窗口的旧文件会被清理。官方的默认值通常已经够用，但如果你希望保留更长时间做月度复盘，就要自己调整保留天数，同时算好磁盘空间，避免把根分区写满。

4. 交互界面速查：那些按键到底在切换什么视图

装好服务之后，直接在终端里敲atop就能进入实时交互界面。第一次用的人往往会觉得信息密度太大，不知道看哪里，也不知道按什么键。这里把我平时最常用的按键和字段讲一遍。

4.1 十个最高频按键

先记按键，再记字段。下面这个表是你在 atop 里最高频会用到的操作：

t和T是最值得记住的两个键。用atop -r回放历史文件时，屏幕每次显示一个采样点，通过t往时间轴后面翻、T往前面翻，就能像看幻灯片一样观察系统的变化过程。

4.2 顶部系统区块怎么读：CPU、CPL、MEM、SWP、DSK、NET

atop 的顶部是系统级汇总，一般分成几块，每一块都对应一类资源：

• CPU 区：显示所有核的总体 CPU 占用，以及 user、sys、irq、idle 的细分。如果 sys 的占比明显偏高，说明系统调用、内核态处理成了瓶颈；
• CPL 区：显示最近 1/5/15 分钟的负载均值，以及当前进程数、线程数。这里的进程数如果异常膨胀，往往意味着有频繁创建进程的行为；
• MEM 区：物理内存的总量、空闲量、缓存占用；
• SWP 区：交换分区使用情况，一旦开始有换页活动，内存压力就已经不小了；
• DSK 区：每个磁盘设备的 busy 百分比、读/写速率。busy 高且读写速率低，通常是随机小 IO 导致；
• NET 区：网卡的每秒收发速率，以及 TCP/UDP 包数量。

这六个区块基本覆盖了一台实例的所有资源维度。排查时先扫一遍顶部，就能大概知道故障属于哪一类，然后再下沉到进程层去定位具体对象。

4.3 进程列表字段逐列拆解：从累计值看懂增长趋势

顶部往下就是进程列表。atop 的进程字段和 top 略有不同，它更强调“从启动到现在的累计值”，所以能看出趋势：

我最常用的两个判断技巧：看 CPU 瓶颈，就按 USRCPU 排序，找出燃烧 CPU 最凶的进程；看内存泄漏，就盯 RSIZE 和 RGROW。一个进程如果 RSIZE 只增不减，并且每次采样都在上涨，那它基本就是内存泄漏的嫌疑对象。RDCHAR、WRCHAR 单独看意义不大，要配合 DSK 区块的 busy 百分比一起判断是谁在制造磁盘压力。

5. 三个高频故障场景的完整排查实操

工具学会了，最终还是要落到故障上。这里挑三个我遇到最多的场景，把从“接到告警”到“定位真凶”的完整路径走一遍。

5.1 场景一：CPU 飙高但登录后已经回落

这是最典型的“事后查证”场景。监控曲线显示凌晨 2 点到 2 点 10 分 CPU 跑满，等你登录上去负载已经恢复正常。此时 top 没有任何参考价值，直接回放日志：

atop -r /var/log/atop/atop_20240115 -b 02:00 -e 02:15

进入回放界面后，先看 CPL 区的负载均值，确认尖峰对应的采样点；然后用t和T在采样点之间移动，观察 CPU 区块的 user/sys 占比变化。如果某一段 sys 占比特别高，说明问题出在内核态，比如频繁的系统调用、上下文切换、中断风暴；如果 user 占比高，则更可能是业务进程或脚本在计算。

接着对进程列表按 CPU 排序，找到 USRCPU 增量最大的进程。这里有一个细节：进程列的 SYSCPU/USRCPU 是累计值，所以要看的是两次采样之间的差值，而不是绝对值。你只要用t切换到尖峰开始的采样点，记住当时的 USRCPU，再切到尖峰结束的采样点，两个值一减，就知道这段时间里谁消耗的 CPU 时间最多。

5.2 场景二：内存只增不减，疑似泄漏

内存泄漏的特点是一条缓慢向上、从不回落的曲线。遇到这类问题，建议直接看内存累计统计视图：

atop -r /var/log/atop/atop_20240115 -b 08:00 -e 20:00

进入回放后按M切换到内存累计视图，关注 RSIZE 和 RGROW。RGROW 表示进程自启动以来常驻内存的增长量，如果一个进程的 RGROW 持续增长，而它的业务逻辑并不需要缓存那么多数据，泄漏的可能性就非常大了。

实际排查中还有个常见干扰项：很多语言的运行时（比如 JVM、Node.js 的堆内存管理）会预留大量虚拟内存，VSIZE 虚高不代表真的用了物理内存，所以重点要看 RSIZE 和 RGROW，不要被 VSIZE 吓到。定位到具体进程后，再去结合它的日志、部署时间、近期发布记录做交叉验证，基本就能锁定是哪一次变更引入的泄漏。

5.3 场景三：磁盘 IO 使用率达到 100%，但进程列表看不出谁在写

磁盘打满时如果只盯着进程列表的 CPU 和内存，往往找不到头绪，因为大量等待 IO 的进程 CPU 占用可能很低。正确的打开方式是先看 DSK 区块：

• busy 接近 100%，但读写速率只有几十 MB/s：说明是随机小 IO 把设备拖垮了，比如大量零散的读写请求；
• busy 高，读写速率也很高：说明是吞吐型压力，比如日志大量落盘、文件拷贝、数据库备份。

确定压力类型后，再回到进程列表，看 RDCHAR 和 WRCHAR 两列。排序之后，写字符数最高的进程就是最可疑的写入方。进程的 RDCHAR/WRCHAR 是累计值，同样要用两个采样点的差值来判断它在故障窗口内的实际写入量。

另外要注意火山引擎这类云平台上的实例，云盘本身有 IOPS 和吞吐上限。如果 atop 显示磁盘 busy 100% 但读写速率并没有突破物理磁盘能力，很可能是打到了云盘的规格上限。这时候该做的是评估是否需要升级云盘规格，或者把业务拆到多个实例/多块盘上，而不是在系统层面死磕。

如果想顺便排查网络流量异常，按n切到网络视图，对比网卡收发速率与 NET 区块的包统计。找出那个时段流量突增的采样点，再结合业务日志，就能区分是正常业务高峰还是外部的扫描/攻击流量。

6. 日志回放与事故复盘：实例失去响应之后怎么还原现场

如果故障已经严重到实例失去响应，SSH 都登不进去，这时候 atop 的历史日志就成了第一手证据。前提是你之前已经把守护进程开起来了，而且日志文件没有被清掉。

6.1 回放原始日志的正确打开方式

回放命令的完整形态是：

atop -r /var/log/atop/atop_20240115 -b 02:00 -e 02:15

-r指定原始日志文件，-b和-e指定起始和结束时间。回放模式下 atop 不会实时刷新，而是停留在指定时间窗口内的第一个采样点，你可以用t和T在采样点之间移动。

时间窗口的设置越精确越好。比如告警是凌晨 2 点 10 分触发的，那就把窗口开到 2:00 到 2:20，前后各留一点余量，既能看清故障发生前的“正常状态”，也能看到故障发生后的“恶化过程”。对比正常采样点和异常采样点，往往一眼就能看出变化拐点。

如果实例的/var/log/atop/目录因为磁盘问题已经写不进去了，也可以尝试把磁盘挂载到另一台实例上，再对原始文件做回放。云平台上的实例如果已经销毁，只要提前把日志同步到别的存储位置，数据就不会丢。

6.2 非交互模式的批量输出和 atopsar

在某些场景下，你不想来回按键翻采样点，而是想一次性把一段时间内的所有数据打印出来。atop 提供了非交互输出模式：

atop -r /var/log/atop/atop_20240115 -P CPU,MEM,DSK,NET -b 10:00 -e 10:30

这条命令会把 10:00 到 10:30 之间每个采样点的 CPU、内存、磁盘、网络摘要按行打印出来，方便配合脚本做后续分析，或者直接把输出重定向到文件里留存。

如果习惯 sar 那种报告格式，atop 还附带一个工具叫atopsar。它可以基于原始日志生成 CPU、内存、磁盘、网络等维度的历史报告：

atopsar -r /var/log/atop/atop_20240115 -c -m -d -n

-c是 CPU、-m是内存、-d是磁盘、-n是网络，按需组合即可。对需要周期性出报告或做长期趋势分析的团队来说，atopsar 能省掉不少手工处理的时间。

6.3 组合排障：atop 日志 + 内核日志 + 监控平台的时间线对齐

atop 能告诉你“系统里发生了什么”，但有些故障的根因在系统之外。比如实例突然被 OOM Killer 杀掉进程、内核出现 panic、云平台的底层宿主机发生抖动，这些在 atop 的进程数据里不一定能直接看到结论，需要和其他证据串起来看。

我习惯的做法是拉三条时间线做对齐：

1. atop 原始日志：系统资源和进程行为的明细变化；
2. 内核日志：journalctl -k或dmesg，重点看 OOM、hung_task、软锁死等关键事件；
3. 云监控平台的指标：实例 CPU、内存、网络、磁盘的分钟级曲线。

举个例子，atop 显示某进程 RSIZE 在故障前持续上涨，内存耗尽后内核日志里出现 OOM Killer 记录，监控平台同时显示内存使用率冲到接近 100%，三条线在时间上完全吻合，结论就非常扎实：内存耗尽触发 OOM，业务进程被杀，实例表现为服务不可用。

7. 部署后需要立刻调整的参数与踩坑清单

atop 默认配置能用，但“能用”和“好用”之间还差几个关键调整。下面这些是我在每台新实例上都会做的收尾动作，也是踩过坑之后总结出来的。

7.1 默认 600 秒采样太粗，改成多少合适

默认的LOGINTERVAL=600意味着每 10 分钟才记录一次。如果一次故障只持续了两三分钟，很可能完全落在两次采样之间，回放日志时只能看到故障前和故障后的状态，中间的“现场”是空白的。

我的建议是把采样间隔至少缩到 60 秒：

# /etc/sysconfig/atop 或 /etc/default/atop LOGINTERVAL=60

60 秒的采样密度能覆盖绝大多数故障场景，日志体积放大 10 倍也完全可以接受。如果实例规格比较小、磁盘空间紧张，可以折中设成 120 秒。设置完后记得重启服务并确认日志文件正常增长，否则配置改了等于没改。

7.2 日志保留和落盘位置的安全边界

日志如果和根分区放在一起，万一实例本身因为磁盘写满出问题，atop 日志就成了压死骆驼的最后一根稻草。建议确认一下/var/log所在分区的容量，如果实例数据盘足够大，也可以把LOGPATH改到独立的数据盘目录下，避免日志和系统盘互相影响。

保留天数的调整要看发行版的具体机制。有些版本靠 atop 自己的-R参数控制保留窗口，有些版本靠 logrotate 配置（比如/etc/logrotate.d/atop）做每日轮转。无论哪种机制，我建议至少保留 7 到 14 天，太短会导致“事后想查却发现日志已经被清掉”的尴尬。

7.3 三个容易踩的坑：进程级网络、容器内采样、时区对齐

很多用户以为 atop 能直接看到每个进程的网络流量，实际上系统级的网络统计是默认采集的，但进程级的网络流量统计依赖额外的内核模块（netatop），默认不加载。所以别指望通过 atop 精确到“哪个进程在大量发包”，至少在没有安装对应内核模块的机器上做不到。

容器环境里用 atop 要特别小心。在宿主机上，atop 看到的是宿主机全部进程，包括容器内进程，可以用于定位容器导致的资源消耗；但在容器内直接跑 atop，通常只能看到容器自己的 PID 命名空间内有限的进程信息，而且如果没有足够的权限，资源数据还会被隔离机制过滤，参考价值很有限。

时区也是个容易翻车的地方。atop 日志默认按系统本地时间记录，如果实例设置了 UTC，而云监控曲线和同事的排查记录用的是北京时间，回放窗口就会整体错位。动手排查前先date确认一下当前时区，再把-b和-e的时间换算成系统本地时间。

7.4 我在每台新实例上的收尾动作

每次在火山引擎上开通新的 Linux 实例，我固定会做这么几件事：装 atop、把采样间隔改成 60 秒、确认systemctl enable atop开机自启、然后看一眼/var/log/atop/目录下确实生成了当天文件。整套动作不超过两分钟，但收益是长期的——以后再遇到“凌晨三点 CPU 飙高但没人看见现场”这类问题，至少手里有一份能回放的原始记录。

最后再分享一个我自己觉得很有用的习惯：不只是生产环境，开发机和测试机的 atop 我也一律开着。很多时候“预发环境复现不了，一上线就出问题”，问题的苗头其实早就出现在测试环境的历史日志里，只是当时没人去看。atop 这类工具的价值，不在于它功能有多花哨，而在于它总能在你意识到需要证据的那一刻，让证据已经安安静静地躺在那里等你。