如果你负责过一台跑业务的 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我把这四类工具放在一起做了个对比差别其实很清晰工具实时交互历史记录进程级明细故障复盘友好度top有无只显示当前存活进程低htop有彩色易读无当前进程信息更丰富低sar/sysstat无偏报告有依赖 cron配置进程级有限中atop有快捷键多有默认开启每个采样点都有完整进程表高sar 要事先配置好 sysstat 的 cron 任务没配置的机器等于没有任何历史数据。而 atop 在很多发行版里装上之后就会自动以守护进程方式运行天然自带“监控录像”。htop 的交互体验确实好但它和 top 一样不落盘依然解决不了“事后查证”的问题。所以我的结论很直接实时看 load 用 top 够了但凡是需要“出事故之后还原现场”的场合atop 是更合适的底座。2. 火山引擎 Linux 实例上的安装与守护进程配置atop 的安装不复杂真正容易被忽略的是“装完之后有没有在后台记录”。下面按火山引擎控制台常见的镜像体系分别给出安装命令并说明如何验证守护进程真的在写日志。2.1 不同镜像体系下的一行安装命令登录实例后先确认一下系统版本和 atop 是否已经存在cat /etc/os-release command -v atopCentOS 7/8、以及使用 yum 体系的 openEuler 这类镜像可以直接安装yum install -y atop systemctl enable --now atop如果yum install提示找不到 atop 包多半是默认源里没有需要先启用 EPELyum install -y epel-release yum update -y yum install -y atop systemctl enable --now atopUbuntu、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这样的当天文件。刚启动时文件可能很小但它的存在本身就说明守护进程正在工作。如果没有这个文件排查思路是确认服务状态是否为 running看journalctl -u atop有没有报错确认配置里的LOGPATH指向的目录可写。2.3 三个关键配置变量LOGOPTS、LOGINTERVAL、LOGPATHatop 守护进程的配置因发行版位置略有不同RHEL/CentOS 系/etc/sysconfig/atopUbuntu/Debian 系/etc/default/atop核心配置变量就三个LOGOPTS-wR LOGINTERVAL600 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 秒间隔144 次/天60 秒间隔1440 次/天约 100 个进程0.5MB 上下5MB 上下约 300 个进程1MB 到 3MB10MB 到 30MB上千进程/线程5MB 以上50MB 以上注意这只是个估算量级。真正的影响因素有两个一是实例上的进程/线程总数线程也会被记录二是采样频率把间隔从 600 秒改成 60 秒日志体积大约放大 10 倍。对大多数实例来说默认配置跑一个月日志总量基本不会超过一两百 MB这点开销相对于排障价值是完全可以接受的。日志的保留策略由LOGOPTS里的-R、发行版自带的 logrotate 配置共同控制。默认情况下原始日志会保留若干天超出保留窗口的旧文件会被清理。官方的默认值通常已经够用但如果你希望保留更长时间做月度复盘就要自己调整保留天数同时算好磁盘空间避免把根分区写满。4. 交互界面速查那些按键到底在切换什么视图装好服务之后直接在终端里敲atop就能进入实时交互界面。第一次用的人往往会觉得信息密度太大不知道看哪里也不知道按什么键。这里把我平时最常用的按键和字段讲一遍。4.1 十个最高频按键先记按键再记字段。下面这个表是你在 atop 里最高频会用到的操作按键作用t/T向后 / 向前翻动一个采样点回放历史日志时非常关键1展开或收起每个 CPU 核的单独状态d/D切换磁盘读写视图 / 磁盘累计统计视图m/M切换内存视图 / 内存累计统计视图n/N切换网络视图 / 网络累计统计视图c/p/u切换为命令行视图 / 程序名视图 / 用户名视图r查看进程的资源限制v进入更详细的变量视图能看到更多字段/按当前资源指标正向 / 反向排序q退出t和T是最值得记住的两个键。用atop -r回放历史文件时屏幕每次显示一个采样点通过t往时间轴后面翻、T往前面翻就能像看幻灯片一样观察系统的变化过程。4.2 顶部系统区块怎么读CPU、CPL、MEM、SWP、DSK、NETatop 的顶部是系统级汇总一般分成几块每一块都对应一类资源CPU 区显示所有核的总体 CPU 占用以及 user、sys、irq、idle 的细分。如果 sys 的占比明显偏高说明系统调用、内核态处理成了瓶颈CPL 区显示最近 1/5/15 分钟的负载均值以及当前进程数、线程数。这里的进程数如果异常膨胀往往意味着有频繁创建进程的行为MEM 区物理内存的总量、空闲量、缓存占用SWP 区交换分区使用情况一旦开始有换页活动内存压力就已经不小了DSK 区每个磁盘设备的 busy 百分比、读/写速率。busy 高且读写速率低通常是随机小 IO 导致NET 区网卡的每秒收发速率以及 TCP/UDP 包数量。这六个区块基本覆盖了一台实例的所有资源维度。排查时先扫一遍顶部就能大概知道故障属于哪一类然后再下沉到进程层去定位具体对象。4.3 进程列表字段逐列拆解从累计值看懂增长趋势顶部往下就是进程列表。atop 的进程字段和 top 略有不同它更强调“从启动到现在的累计值”所以能看出趋势字段含义PID进程号SYSCPU / USRCPU进程累计消耗的内核态 / 用户态 CPU 时间单位秒VSIZE / RSIZE虚拟内存 / 常驻物理内存单位 KBVGROW / RGROW进程启动以来虚拟内存 / 常驻内存的增长量单位 KBRDCHAR / WRCHAR进程累计读 / 写的字符数与磁盘 IO 强相关MEM进程常驻内存占物理内存的百分比CMD进程对应的命令我最常用的两个判断技巧看 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 的进程数据里不一定能直接看到结论需要和其他证据串起来看。我习惯的做法是拉三条时间线做对齐atop 原始日志系统资源和进程行为的明细变化内核日志journalctl -k或dmesg重点看 OOM、hung_task、软锁死等关键事件云监控平台的指标实例 CPU、内存、网络、磁盘的分钟级曲线。举个例子atop 显示某进程 RSIZE 在故障前持续上涨内存耗尽后内核日志里出现 OOM Killer 记录监控平台同时显示内存使用率冲到接近 100%三条线在时间上完全吻合结论就非常扎实内存耗尽触发 OOM业务进程被杀实例表现为服务不可用。7. 部署后需要立刻调整的参数与踩坑清单atop 默认配置能用但“能用”和“好用”之间还差几个关键调整。下面这些是我在每台新实例上都会做的收尾动作也是踩过坑之后总结出来的。7.1 默认 600 秒采样太粗改成多少合适默认的LOGINTERVAL600意味着每 10 分钟才记录一次。如果一次故障只持续了两三分钟很可能完全落在两次采样之间回放日志时只能看到故障前和故障后的状态中间的“现场”是空白的。我的建议是把采样间隔至少缩到 60 秒# /etc/sysconfig/atop 或 /etc/default/atop LOGINTERVAL6060 秒的采样密度能覆盖绝大多数故障场景日志体积放大 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 这类工具的价值不在于它功能有多花哨而在于它总能在你意识到需要证据的那一刻让证据已经安安静静地躺在那里等你。