1. 项目概述为什么我们需要时刻关注系统资源在Ubuntu服务器或者日常桌面环境中无论你是开发者、运维工程师还是普通用户系统卡顿、应用无响应、服务异常往往是第一道警报。这些警报的背后通常指向了三个核心资源CPU、内存和网络。CPU是大脑决定了计算速度内存是工作台决定了能同时处理多少任务网络是高速公路决定了数据进出的效率。当任何一个环节出现瓶颈整个系统的体验就会直线下降。“Ubuntu 查看系统资源占用”这个需求看似基础实则是系统管理和性能调优的基石。它不仅仅是敲几个命令看看数字更是理解系统运行状态、诊断问题根源、进行容量规划的第一步。很多新手在面对top命令里跳动的数字时会感到困惑而老手则能从中一眼看出是哪个进程在“作妖”是内存泄漏还是CPU被某个脚本“死循环”吃满或者是网络连接数爆表导致服务不可用。本文将从一个资深运维和开发者的视角带你系统性地掌握在Ubuntu上监控CPU、内存和网络资源的全套方法论。我们不只讲命令更会深入讲解每个命令输出字段的含义、不同工具的应用场景以及如何将这些零散的信息串联起来形成一套完整的问题诊断逻辑。你会发现从基础的top到强大的htop从查看瞬间状态的free、vmstat到进行实时流量分析的iftop、nethogs每一款工具都是你洞察系统内部的“眼睛”。2. 核心监控工具全景与选型逻辑面对琳琅满目的系统监控命令新手最容易犯的错误就是“一把抓”或者只记住一两个命令。实际上不同的工具设计初衷不同提供的信息维度和实时性也各异。一个高效的排查流程往往是从宏观到微观从整体到局部。下面这张表梳理了最核心的工具及其定位你可以把它当作你的“武器库”索引工具类别工具名称核心用途特点与适用场景综合概览top/htop实时查看进程级别的CPU、内存使用率进程列表。top是基础所有系统都有htop是其增强版界面友好支持鼠标操作、树状视图、颜色高亮强烈推荐日常使用。内存专项free查看系统整体内存和交换空间Swap的使用情况。快速了解内存总量、已用、空闲、缓存/缓冲以及Swap是否被启用。vmstat报告虚拟内存统计信息包括进程、内存、分页、块IO、陷阱和CPU活动。侧重系统整体性能能查看内存的si换入、so换出情况判断是否发生内存交换。CPU专项mpstat查看每个CPU核心的详细利用率统计。在多核CPU系统中分析负载是否均匀分布在各核心还是某个核心被独占。pidstat监控进程及其子线程的CPU、内存、IO等资源消耗。可以按进程或线程细化监控是top的补充常用于定位具体进程的详细资源消耗。网络专项iftop实时显示网络接口的带宽使用情况类似top的网络版。可视化的流量看板能快速定位哪个IP或端口占用了大量带宽。nethogs按进程实时统计网络带宽使用情况。杀手级工具。当iftop告诉你某个IP流量大时nethogs能直接告诉你这个流量是哪个进程产生的。ss/netstat查看网络连接、监听端口、路由表、接口统计等信息。netstat较老ss是其更快速、更现代的替代品。用于查看连接数、状态如TIME_WAIT过多等。nload实时监控网络流量和带宽使用情况图形化显示。界面简洁直观显示每个网卡的流入流出速率曲线。磁盘IOiotop实时监控磁盘I/O使用情况并按进程排序。当系统卡顿但CPU内存不高时很可能是磁盘IO瓶颈用它来定位“IO大户”。系统快照glances跨平台的综合系统监控工具通过Web或命令行提供丰富信息。集大成者在一个界面里展示CPU、内存、网络、磁盘、进程等几乎所有信息适合快速总览。选型心得我的习惯是快速健康检查用htop或glances怀疑内存问题先用free -h看整体再用vmstat 2 5每2秒采样一次共5次看交换情况怀疑网络流量异常先用nload看哪个网卡异常再用iftop看具体IP最后用nethogs定位进程。这个组合拳几乎能覆盖90%的日常问题。3. CPU资源监控从整体负载到进程级剖析CPU是系统繁忙程度最直观的指标。监控CPU不仅要看整体使用率更要理解“负载均衡”、“I/O等待”这些深层状态。3.1 核心工具实战top/htop 深度解读top命令是入门必修课。直接输入top后你会看到两部分系统概要信息和进程列表。系统概要区解读前5行top - 14:30:01 up 10 days, 3:15, 1 user, load average: 0.05, 0.10, 0.15 Tasks: 250 total, 1 running, 249 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.3 us, 0.7 sy, 0.0 ni, 96.8 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 15925.8 total, 1024.5 free, 8192.3 used, 6709.0 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 7410.2 avail Mem负载平均值load average:0.05, 0.10, 0.15分别代表过去1分钟、5分钟、15分钟的系统平均负载。对于单核CPU1.00表示刚好满负荷。这个值如果持续高于CPU核心数说明系统过载。例如4核CPU负载长期高于4就需要警惕。CPU行%Cpu(s): 这是关键中的关键。ususer: 用户空间进程占用CPU百分比。你的应用程序如Python、Java程序消耗的CPU就在这里。sysystem: 内核空间进程占用CPU百分比。系统调用、内核线程如网络、磁盘驱动的消耗。ididle: CPU空闲百分比。这个值高是好事。waI/O wait:重要指标CPU等待I/O通常是磁盘或网络完成的时间百分比。如果这个值持续很高比如5%说明磁盘或网络可能是瓶颈CPU在“空等”即使ussy不高系统也会感觉卡顿。ststeal: 在虚拟化环境中如云服务器被宿主机“偷走”的CPU时间。如果这个值高说明你的虚拟机所在的物理主机资源竞争激烈。进程列表区操作在top界面中你可以按以下键进行排序快速定位问题进程P(大写): 按CPU使用率降序排序默认。M: 按内存使用RES降序排序。T: 按累计CPU时间排序。1: 展开显示所有CPU核心的单独统计。htop——更强大的替代品htop需要安装(sudo apt install htop)它提供了彩色界面、横向柱状图、鼠标点击支持、树状视图按F5显示进程父子关系以及更便捷的搜索、过滤和杀死进程功能。在htop中你可以一眼看出CPU各核心的负载是否均衡内存使用情况也更直观。3.2 进阶诊断mpstat 与 pidstat当top显示整体CPU使用率很高时我们需要更细粒度的分析。mpstat洞察多核CPU的负载分布运行mpstat -P ALL 2它会每2秒报告一次所有CPU核心的统计信息。Linux 5.15.0-91-generic (ubuntu-server) 03/15/2024 _x86_64_ (4 CPU) 14:32:01 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 14:32:03 all 2.12 0.00 0.75 0.12 0.00 0.06 0.00 0.00 0.00 96.94 14:32:03 0 3.03 0.00 1.01 0.00 0.00 0.00 0.00 0.00 0.00 95.96 14:32:03 1 1.52 0.00 0.51 0.51 0.00 0.00 0.00 0.00 0.00 97.47 14:32:03 2 2.02 0.00 1.01 0.00 0.00 0.00 0.00 0.00 0.00 96.97 14:32:03 3 1.98 0.00 0.50 0.00 0.00 0.25 0.00 0.00 0.00 97.28这里可以清晰看到4个核心CPU0-3各自的利用率。如果发现某个核心的%usr或%sys持续接近100%而其他核心很闲可能意味着某个单线程应用或内核任务出现了瓶颈没有充分利用多核。pidstat追踪特定进程的详细消耗pidstat是sysstat工具包的一部分需安装(sudo apt install sysstat)。它非常擅长追踪进程随时间变化的资源使用。pidstat 2 5 -u: 每2秒采样一次共5次报告所有进程的CPU使用情况。pidstat -p PID 2 5 -u: 监控特定进程的CPU使用。pidstat -t -p PID 2 5:-t参数可以显示该进程下的各个线程的CPU使用情况对于诊断多线程应用如Java、Nginx的性能问题极为有用。实操心得遇到CPU飙升我的标准流程是1)htop按P排序找到最耗CPU的进程PID。2) 用pidstat -t -p PID 2 5查看该进程下哪个线程最活跃。3) 结合jstackJava或gdb等工具获取该线程的堆栈信息定位到具体代码行。这个组合能解决大部分CPU热点问题。4. 内存资源监控理解真正的“已用”与“可用”内存监控的误区比CPU更多。很多人看到free命令里used很大就慌了其实在Linux中内存管理哲学是“不用白不用”它会用空闲内存来缓存Cache和缓冲Buffer以提升磁盘读写性能。4.1 free 命令正确解读内存状态运行free -h-h表示人类可读格式total used free shared buff/cache available Mem: 15Gi 5.2Gi 1.1Gi 345Mi 8.9Gi 9.5Gi Swap: 2.0Gi 0.0Gi 2.0Gitotal: 物理内存总量。used: 已使用的内存包括应用程序使用的和缓存/缓冲。free: 完全空闲、未被使用的内存。buff/cache: 被内核用于缓存Cache存储读取过的文件和缓冲Buffer存储待写入磁盘的数据的内存。这部分内存在应用程序需要时可以被立刻释放所以它并不是“被占用”的。available:这是最关键的数字估算的、可供启动新应用程序而无需交换Swap的内存数量。它等于free buff/cache中可回收的部分。只要这个值还比较大系统内存就是健康的。Swap: 交换分区使用情况。如果used持续增长说明物理内存不足系统开始使用硬盘作为虚拟内存这将导致性能严重下降。所以看内存压力首要关注available列而不是free列。一个free很小但available很大的系统运行效率可能非常高。4.2 vmstat洞察内存交换与系统瓶颈vmstat是一个强大的系统性能综合监控工具对于内存它提供了两个关键指标siswap in和soswap out。 运行vmstat 2 5每2秒一次共5次procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1234567 987654 4567890 0 0 12 25 345 1234 2 1 97 0 0swpd: 已使用的虚拟内存Swap大小。如果大于0需结合si/so看。si(swap in): 每秒从磁盘Swap读入到内存的数据量KB。如果持续大于0说明系统正在从Swap恢复数据之前发生过内存紧张。so(swap out): 每秒从内存写入到磁盘Swap的数据量KB。如果这个值持续大于0是内存不足的明确警报系统正在把不活跃的内存页换出到硬盘性能会急剧恶化。memory部分的free/buff/cache与free命令含义一致。procs部分的b处于不可中断睡眠状态的进程数通常是等待I/O。如果这个值持续较高也暗示可能存在I/O瓶颈。4.3 定位内存泄漏与“内存大户”在htop中按M键可以按内存使用排序。这里主要关注两列RES (RSS - Resident Set Size): 进程实际使用的物理内存大小不含共享库。这是衡量一个进程占用多少物理内存的主要指标。%MEM: RES占系统总物理内存的百分比。如果发现某个进程的RES持续增长且不释放比如一个Java应用RES从1G慢慢涨到8G就很可能是内存泄漏。对于容器环境如Docker还需要注意/proc/meminfo中的Slab和KernelStack等内核内存占用有时内核对象泄漏也会导致“内存消失”。避坑技巧有时候free显示available内存很少但top里所有进程的RES加起来远小于总内存。这可能是内核的slab内存sudo slabtop查看或内存碎片导致。另一个常见原因是透明大页Transparent Huge Pages在某些数据库如Redis、MongoDB场景下会导致性能问题甚至内存占用异常可以通过cat /sys/kernel/mm/transparent_hugepage/enabled检查并根据数据库官方建议决定是否禁用。5. 网络资源监控从带宽到连接的全链路分析网络问题往往更复杂它可能表现为服务响应慢、下载上传卡顿、网络错误等。我们需要从带宽使用、连接状态、进程关联三个层面来监控。5.1 带宽监控iftop, nload, nethogsnload最直观的流量仪表盘安装sudo apt install nload。运行nload它会分上下两部分显示每个网络接口的实时流入Incoming和流出Outgoing流量曲线、速率、总量。一眼就能看出哪个网卡如eth0, ens33在活动流量是否异常。按左右方向键可以切换网卡。iftop查看“谁”在通信安装sudo apt install iftop。运行sudo iftop -i eth0指定网卡。它的界面类似top会动态列出当前主机与其他IP之间的流量连接按流量排序。你可以看到是哪个远程IP在和你通信占用多少带宽。按p键可以切换显示端口号这对于找出哪个服务如80端口流量大很有帮助。nethogs终极杀手——关联进程与网络流量安装sudo apt install nethogs。这是我最爱的工具之一。运行sudo nethogs eth0它会列出每个进程实时的网络带宽使用KB/s。当服务器带宽被打满而你用iftop只看到一堆IP时nethogs能直接告诉你罪魁祸首是/usr/bin/python3还是/usr/sbin/nginx。这对于排查异常流量、挖矿木马、错误配置的定时任务等场景无比高效。5.2 连接状态监控ss 命令深度使用netstat已经过时sssocket statistics是它的现代替代品速度更快信息更全。查看所有连接ss -tunap-t: TCP连接-u: UDP连接-n: 以数字形式显示地址和端口不解析域名和服务名-a: 显示所有监听和非监听-p: 显示使用此套接字的进程 这个命令组合会列出所有TCP/UDP连接并显示对应的进程PID和名称。输出中LISTEN表示监听状态ESTAB表示已建立连接。统计各种状态的连接数ss -s。这个命令会输出一个总结对于诊断连接数过多的问题非常有用比如查看TIME-WAIT状态连接是否堆积。Total: 345 (kernel 456) TCP: 234 (estab 123, closed 34, orphaned 0, synrecv 0, timewait 30/0), ports 0 ...如果TIME-WAIT或CLOSE-WAIT状态连接异常多可能意味着应用程序没有正确关闭连接需要调整内核参数或检查程序代码。查看指定端口的连接ss -tunap | grep :80。快速查看谁在连接你的80端口。5.3 网络性能基准测试iperf3监控是发现异常测试是验证能力。iperf3用于测量网络带宽和性能。在一台服务器上启动服务端iperf3 -s在另一台客户端上测试到服务端的带宽iperf3 -c 服务端IP这会输出带宽、抖动、丢包率等关键指标。在部署新服务或怀疑网络带宽不足时这是一个标准的验证手段。网络问题排查流程1)nload看整体流量是否异常。2)iftop -i eth0看具体是哪个外部IP流量大。3)sudo nethogs eth0定位到产生该流量的进程。4)ss -tunap | grep 目标IP或端口查看该进程建立的连接详情。5) 结合进程信息ps aux | grep PID和日志最终确定问题根源。6. 一体化监控与自动化告警入门以上都是命令行下的实时或快照式监控。对于需要长期运行的服务我们需要更持续、更自动化的方案。6.1 glances一站式的综合监控面板glances是一个用Python写的跨平台监控工具信息呈现非常友好。 安装sudo apt install glances或pip install glances。 运行glances你会得到一个包含几乎所有信息的单屏显示CPU、内存、交换空间、负载、网络IO分每个网卡、磁盘IO分每个分区、最耗资源的进程列表、文件系统使用率等等。它还可以运行在服务器模式glances -s然后通过浏览器http://服务器IP:61208来访问这个监控面板非常适合快速检查多台服务器。6.2 配置简单的日志监控脚本虽然像PrometheusGrafanaAlertmanager是专业的监控告警方案但我们可以从简单的Shell脚本开始实现核心监控。 下面是一个示例脚本check_resource.sh它检查CPU负载、内存可用性和磁盘空间并在超过阈值时发送通知这里以打印日志为例实际可替换为邮件、钉钉、企业微信等通知#!/bin/bash # 阈值配置 LOAD_THRESHOLD5.0 # 1分钟平均负载阈值根据CPU核心数调整 MEM_AVAIL_THRESHOLD1024 # 可用内存阈值(MB) DISK_USAGE_THRESHOLD90 # 根分区使用率百分比阈值 # 获取数据 LOAD1$(uptime | awk -Fload average: {print $2} | cut -d, -f1 | sed s/ //g) MEM_AVAIL$(free -m | awk /^Mem:/{print $7}) DISK_USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) # 判断并告警 CURRENT_TIME$(date %Y-%m-%d %H:%M:%S) WARNING_MSG if (( $(echo $LOAD1 $LOAD_THRESHOLD | bc -l) )); then WARNING_MSG[${CURRENT_TIME}] 警告: 1分钟平均负载过高: ${LOAD1} (阈值: ${LOAD_THRESHOLD})\n fi if [ $MEM_AVAIL -lt $MEM_AVAIL_THRESHOLD ]; then WARNING_MSG[${CURRENT_TIME}] 警告: 可用内存过低: ${MEM_AVAIL}MB (阈值: ${MEM_AVAIL_THRESHOLD}MB)\n fi if [ $DISK_USAGE -gt $DISK_USAGE_THRESHOLD ]; then WARNING_MSG[${CURRENT_TIME}] 警告: 根分区使用率过高: ${DISK_USAGE}% (阈值: ${DISK_USAGE_THRESHOLD}%)\n fi # 如果有告警信息则处理这里输出到文件实际可发送通知 if [ -n $WARNING_MSG ]; then echo -e $WARNING_MSG /var/log/system_health.log # 此处可以添加发送邮件或Webhook的代码例如 # curl -X POST -H Content-Type: application/json -d {\msg\: \$WARNING_MSG\} 你的通知机器人URL fi可以将这个脚本加入crontab每分钟执行一次实现基本的自动化监控。6.3 核心指标监控要点总结长期监控时建议重点关注以下指标并为它们设置合理的告警阈值CPU:监控点1分钟/5分钟平均负载需结合CPU核心数判断。监控点%waI/O等待百分比持续高于5%需警惕。监控点单个核心或整体%us%sy持续高于80%。内存:监控点available内存而非free低于总内存的10%。监控点Swap分区的si/so有持续非零值。监控点单个进程的RES内存持续增长可能泄漏。网络:监控点网卡带宽使用率持续超过80%。监控点特定状态如TIME-WAIT的连接数异常增多。监控点网络错误包ifconfig或ip -s link中的errors,dropped计数器持续增长。磁盘:监控点磁盘空间使用率df -h。监控点磁盘I/O等待时间%utilviaiostat或awaitiotop或iostat过高。掌握从快速命令检查到自动化脚本监控的方法你就能从被动救火转向主动运维在用户抱怨之前就发现并解决潜在的系统资源瓶颈。这些技能是任何在Linux环境下工作的人员的宝贵财富无论是管理一台个人开发机还是维护一个庞大的服务器集群其核心思路都是相通的。