凌晨两点被电话叫醒一上线用户已经在群里炸了锅——页面转圈、接口超时、登录都卡成幻灯片。我先是下意识敲了uptime、free -h、top然后一路查下去最后定位到系统日志把磁盘 I/O 打满了。事后复盘我最大的感触不是排查技术有多难而是如果我平时能把 Linux 系统监控这套东西真正落到细处那晚根本不用折腾到天亮。这篇文章就是基于这类实战场景写的。我不会只丢给你一串 Linux 常用命令而是把系统监控里最值得关注的指标、我日常排查时用的命令组合、从手动到自动的监控方案以及一次完整的问题定位过程都摊开来说清楚。适合刚接触 Linux 运维的新手、自己跑 VPS 的个人开发者、以及正准备给生产环境搭监控体系的同学。你不需要先把所有工具都学会跟着思路走一遍至少能知道“服务器出问题时下一步该敲什么”。1. 系统监控的核心是这些指标理清它们比记命令更重要很多新手学监控第一件事就是背命令结果遇到问题还是手忙脚乱。原因很简单命令是武器但你要先知道“敌人”是谁。Linux 系统监控的实质是盯住 CPU、内存、磁盘、网络、硬件健康这几类资源的状态并且理解每个指标背后对应的业务影响。1.1 负载均值三个数字别只看大小uptime会输出一个很显眼的数字load average: 3.42, 2.87, 2.61。这三个数分别代表过去 1 分钟、5 分钟、15 分钟的系统平均负载。很多人看到负载超过 1 就紧张其实这个数字要除以 CPU 核心数才有意义。举个例子一台 4 核机器负载 4.0 意味着每个核都刚好跑满负载 2.0 时还有一半算力空闲。反过来如果 1 分钟负载很高但 15 分钟负载很低说明是瞬时冲高可能是定时任务或突发流量如果三个数都持续走高那就要认真对待了。更隐蔽的情况是负载高但 CPU 使用率不高。这往往不是 CPU 不够用而是大量任务阻塞在磁盘 I/O、锁等待或内存换页上。只看负载不看上下文很容易把问题带偏。我自己的习惯是看到负载高第一反应不是加 CPU而是先跑一个vmstat看看到底是r运行队列在涨还是waI/O 等待在涨。1.2 内存free输出里的available才是真正能用的数内存监控最容易犯的错是把free命令里的free列当成剩余内存。Linux 内核有个特点它会尽量用空闲内存做文件缓存buff/cache所以free列数值很小并不代表内存不够。正确的做法是看available列这个值是系统估算出来的“在不触发 swap 的情况下还能分配给新进程的内存”。free -h输出大致是这样total used free shared buff/cache available Mem: 15Gi 2.1Gi 9.3Gi 118Mi 4.1Gi 12Gi Swap: 2.0Gi 0B 2.0Gi假定 total 15Gused 只有 2.1Gfree 有 9.3Gavailable 却显示 12G。这里 buff/cache 占了 4.1G但内核可以在需要时回收它所以 available 比 free 大是正常的。真正危险的信号是 available 持续偏低、swap 开始增长、然后si/so不断有换页动作这种时候业务会明显变卡。1.3 磁盘容量之外I/O 延迟才是业务的隐形杀手监控磁盘只看df -h空间说明你还在第一层。空间满当然重要但线上更常见的问题是磁盘还有大量剩余空间I/O 却已经忙不过来。磁盘 I/O 的核心体现是iostat里的%util、await和aqu-sz。%util接近 100% 说明磁盘设备已经很忙了但要注意对 SSD 来说 100% util 并不一定代表性能到顶很多 SSD 可以并行处理多队列await是平均 I/O 请求处理耗时包括排队和服务时间这个数字超过几十毫秒就要留意了。我遇到过最典型的场景数据库服务器数据盘负载不高但系统盘%util持续 90% 以上后来发现是应用把日志写到了系统盘日志量一大系统盘直接成为瓶颈。所以磁盘监控要分设备看系统盘、数据盘、日志盘单独观察别混在一起。1.4 网络与连接数延迟、丢包和端口耗尽网络监控不仅仅是看带宽跑满没有。对于提供服务的服务器更关键的是连接状态分布和丢包率。ss -s可以快速看到 TCP 连接总数和各状态统计。如果TIME_WAIT连接数量异常多会影响新连接的建立因为每个连接都需要本地端口超过net.ipv4.ip_local_port_range的范围后就会出现Cannot assign requested address。这类问题用ss -s一眼就能看出来。另外延迟和丢包要看ping和mtr。ping看基础的连通性和 RTTmtr能逐跳查看哪一跳在丢包。如果客户端反馈“慢”但服务器本机 CPU、内存、磁盘都正常网络层的排查就必须跟上。1.5 硬件温度性能衰减往往比蓝屏更早出现服务器长期高温不会立刻宕机但 CPU 会主动降频保护自己性能悄悄下滑。这种现象在物理机上很常见尤其是夏季机房制冷不足或风扇积灰。Linux 下用lm-sensors读取温度sudo apt install lm-sensors sudo sensors-detect sensors输出里会包含 CPU 各核心温度、主板温度、风扇转速。如果发现 CPU 温度长期高于 85℃就要检查散热和机房空调了。监控温度不一定非要做成复杂平台定时采样记录日志配合告警也能起到效果。2. 一套命令组合拳覆盖 90% 的日常排查指标理清楚之后命令才能派上用场。下面这套组合是我在实际工作中反复用的几乎每个场景都能覆盖。2.1 top / htop进入任意一台机器的第一件事top是 Linux 运维的基本功。进入交互界面后我建议先记住几个按键P按 CPU 使用率降序排列M按内存使用率降序排列1展开显示每个逻辑 CPU 的使用情况c显示完整命令行默认的按 CPU 排序适合找 CPU 密集进程但如果你想看谁吃内存最多按M更直观。top里还有一个关键信息是zombie僵尸进程如果数量持续增长说明父进程没有正确回收子进程应用代码有问题。htop是top的增强版彩色显示支持鼠标操作F6可以选择排序字段F9直接发信号给进程。我个人在排查时更喜欢htop因为它把 CPU、内存、Swap 的负载条放一起视觉上一眼就能看出资源分布。2.2 vmstat一条命令看到系统整体状态vmstat是我最推荐的第二把武器。用法通常是vmstat 2 10表示每 2 秒采样一次共 10 次。输出关键字段procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 951120 1452 305860 0 0 1 2 1020 2400 8 2 88 2 0排查思路是先看r运行队列是不是大于 CPU 核数如果长期大于核数说明 CPU 饱和再看b阻塞进程数是不是在涨如果 b 高并且wa高基本可以确定 I/O 有瓶颈。si/so是 swap 换入换出一旦持续非零内存很可能不够了。cs是上下文切换过高可能和频繁锁竞争或线程太多有关。2.3 iostat 与 sar把磁盘细节和历史数据盘活iostat -x 1用于监控磁盘 I/O 细节-x展开更多扩展统计Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz %util vda 2.30 12.50 10.5 150.2 0.00 0.00 0.00 0.00 3.20 18.60 0.20 18.4观察r_await/w_await与aqu-sz平均队列长度。如果aqu-sz持续大于设备并发能力说明请求在排队磁盘响应变慢。%util结合队列长度看比单看%util更可靠。sar属于 sysstat 包它能把历史数据落盘以便事后回放。默认采集可能没开启需要确保/etc/cron.d/sysstat里的任务在运行然后通过sar -q看历史负载、sar -r看历史内存、sar -d看历史磁盘。没有历史数据的监控等于只带了手电筒却没有内存卡。2.4 ss、iftop、nload网络排查三件套查端口和连接数用ss而不是旧的netstatss -tulnp # 查看所有监听端口 ss -s # 汇总连接状态 ss -t state established # 查看已建立连接-t看 TCP-u看 UDP-l只看监听-n不做反解-p显示进程。定位“谁在占用 8080 端口”这类问题就用ss -tulnp | grep 8080。实时流量工具iftop可以按连接查看流量iftop -i eth0 -n -P-P会显示端口方便看出具体是哪个服务在消耗流量。nload则更擅长看总入/总出带宽适合判断带宽是否跑满。2.5 dstat 与 perf站在更高维度的补充工具如果你嫌vmstat、iostat分开看麻烦可以试试dstatdstat -cdngy 2一次输出 CPU、磁盘、网络、内存、系统负载。它是 Python 写的很多发行版默认没装apt install dstat或yum install dstat即可。它适合临时把多维度指标同时放到一个屏幕上观察。perf top则是面向性能优化的进阶工具可以直接看到内核和用户态的热点函数。比如 CPU 占用高但找不到是哪个进程或哪个系统调用引起的perf top能告诉你问题发生在copy_page_range还是某个驱动函数上。这个工具对普通运维可能有点深但值得知道它的存在。3. 从命令到平台给服务器装一套能长期看的监控命令适合临时排查但生产环境不能老是靠人肉盯着。于是我们需要监控平台。3.1 先别急着上全家桶评估自己的场景一谈到监控平台很多人直接想到 Prometheus、Zabbix、ELK。但如果你只有两三台服务器直接搭一套完整的 PrometheusGrafanaAlertmanager 其实有点技术债配置项多、组件多、维护成本不小。我个人建议按场景选择场景推荐方案理由个人 VPS / 三四台以内Netdata安装简单自带图表零配置混合环境、需要统一收集Prometheus node_exporter Grafana生态成熟可扩展查询灵活已有复杂 ITIL 流程Zabbix自带告警、报表、模板体系成熟需要收集业务日志并监控Loki / ELK日志和指标分开处理但都可以和 Grafana 结合3.2 Netdata最适合个人和小团队的即时监控Netdata 的安装真的非常无脑curl -Ss https://get.netdata.cloud/kickstart.sh | sh装完后打开http://你的IP:19999能看到 CPU、内存、磁盘、网络、进程等几百张实时图表。它对新人友好在哪它把很多指标换算成了人类能读懂的样子比如 CPU 频率、缓存命中率、上下文切换速率不用你手动敲命令去猜。我用它最舒服的场景是给客户演示“系统当前负载很高”的时候直接打开一个面板指着曲线说“你看这里 I/O 明显上去了”比一堆命令输出直观得多。Netdata 资源占用很低官方说空闲时只占几 MB 内存很适合个人服务器。3.3 Prometheus node_exporter Grafana通用组合的搭建要点这套组合现在是主流但很多人第一次搭时会绕弯。我按最小可用方案来说明。架构上node_exporter负责采集 Linux 系统指标并通过 HTTP 暴露Prometheus 定时去抓取并存储Grafana 负责把 Prometheus 数据画成图表。第一步安装node_exporter它默认监听9100端口wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz cd node_exporter-1.8.2.linux-amd64 ./node_exporter第二步配置 Prometheus修改prometheus.yml的scrape_configsscrape_configs: - job_name: node static_configs: - targets: [192.168.1.10:9100]启动 Prometheus 后可以在http://你的IP:9090/targets里确认 target 是 UP 状态。第三步Grafana 添加 Prometheus 数据源导入官方仪表盘 ID1860适用于 node_exporter就能看到丰富的系统监控面板。这套方案的价值在于数据模型统一。所有机器指标都是带标签的时间序列你可以轻松写 PromQL 做聚合比如“所有 Web 服务器的平均 CPU”一条查询就能完成。3.4 告警配置让监控在出问题时主动找到你监控的意义在于出问题前提醒你。Prometheus 的告警规则和 Alertmanager 配合很常见。比如磁盘使用率超过 90% 时告警groups: - name: node_alerts rules: - alert: DiskUsageHigh expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100 90 for: 5m labels: severity: warning annotations: summary: 磁盘使用率过高 description: 实例 {{ $labels.instance }}当前磁盘使用率超过 90%持续 5 分钟这个规则里for: 5m很关键它表示只有当阈值持续 5 分钟时才触发能过滤掉很多瞬时抖动。Alertmanager 再配置一个 webhook 推到钉钉、企业微信或 Slack告警就算闭环了。告警另一个要点是聚合与去重。别每台机器单独刷屏要按服务、按故障域分组。Alertmanager 里的group_by、group_wait和repeat_interval就是干这个的默认group_wait设置为 30 秒比较合适。4. 一次真实排查响应变慢的服务器监控数据如何一步步定位根因这部分我想完整复盘一次线上事故看命令和指标是如何配合的。4.1 表象负载 5.0但 CPU 使用率只有 20%当时业务反馈上传文件后前端处理速度特别慢。我登上去先执行uptime topuptime显示 load average 4.8机器共 4 核负载已经超过核数。但top里 CPU 的us只有 15%sy5%id却高达 80%。CPU 明明很闲负载却这么高问题几乎不在计算能力。4.2 定位vmstat 里的 wa 和 iostat 的队列长度对上了号我继续跑vmstat 1 5 iostat -x 1 5vmstat中wa平均在 55% 左右b阻塞进程数经常大于 2说明大量进程在等 I/O。iostat显示vdb这块盘的%util到了 99%aqu-sz一直在 8 以上w_await高达 120 毫秒。到这里瓶颈已经锁定在磁盘写入上而且不是系统盘是专门的数据盘。4.3 揪出元凶pidstat 拿到进程号lsof 定位到文件锁定磁盘层后还需要知道是哪个进程在疯狂写盘。此时用pidstat -d 1看每个进程的磁盘读写速率pidstat -d 1 5输出片段14:23:01 PID kB_rd/s kB_wr/s kB_ccwr/s Command 14:23:02 1234 0.00 45000.00 0.00 java一个 Java 进程每秒写 45MB明显不正常。继续用lsof -p 1234 | grep -E \.log|\.out找到它打开的日志文件路径发现是某个中间件把 DEBUG 级日志全部输出并且没有轮转单个日志文件已经涨到几 GB应用每打一条日志都要触发文件系统开销磁盘队列自然就爆了。4.4 处理与复盘降日志、加轮转、查 inode处理分了两步第一保留现场并立刻把日志级别调到 WARN恢复业务第二写日志轮转配置避免单文件无限增大。但复盘时又发现一个潜在风险这台机器/分区的 inode 使用率已经 90% 多因为大量小文件堆积。df -i看到的结果是即使空间还有inode 满了同样无法创建文件。这个隐患平时不显眼一次日志乱写就可能被引爆。那次之后我把磁盘监控分区拆细了系统盘看空间和 inode数据盘关注 I/O 延迟并在监控平台加了一个“日志目录写入速率”的视图防止类似事件再悄悄发生。5. 监控这条路我不想你重复踩的坑最后聊聊我在折腾监控过程中积累的几个教训。5.1 数字采集到了不等于看懂了最典型的例子是load average。如果你只盯着数字超过核数就报警很可能误报。高负载可能来自 I/O、内存换页或锁等待不一定代表 CPU 繁忙。养成“多指标交叉验证”的习惯看到负载高就顺手看一眼 CPU 的us/sy/id/wa、内存 swap、磁盘队列才能得出正确结论。5.2 告警阈值拍脑袋不如先观察基线很多人刚搭好监控平台就急着把所有规则加上然后被一堆噪音告警烦到关掉。更好的做法是先跑两周基线看正常业务的 CPU 均值、峰值、磁盘使用率和网络流量再根据 95 分位加上一定裕量设定阈值。比如业务平时 CPU 是 30%报警阈值设为 75% 就比 50% 更合理避免大促或高峰时误报。5.3 监控系统本身也是需要运维的监控机器一旦挂了你根本不知道系统出了什么问题这是最讽刺的事。我现在会额外在外面放一个探活定时请求监控面板或 Prometheus 的/health接口一旦监控自身不可达也会收到告警。另外Prometheus 的存储不能无限增长要有数据保留策略比如只保留 15 天并在磁盘容量上预留足够余量。还有一个小技巧监控是给人看的不是为了攒数据。每次新加一个仪表盘图先问自己“看到这张图我能做出什么决策”如果答案是不确定这个指标可以不放。不要让几百张图表淹没了真正有用的信息。我平时最依赖的其实就是uptime、vmstat、iostat、ss那几样基本功以及一套能沉淀历史和自动告警的监控平台。系统监控不是一锤子买卖它是在一次次故障复盘里慢慢养出来的。希望这篇内容能让你少走点弯路下次再有人半夜打电话说“服务器卡了”你至少知道从哪几个方向下手而不是干瞪眼。
Linux系统监控实战：从指标到工具，一步步定位服务器性能瓶颈
凌晨两点被电话叫醒一上线用户已经在群里炸了锅——页面转圈、接口超时、登录都卡成幻灯片。我先是下意识敲了uptime、free -h、top然后一路查下去最后定位到系统日志把磁盘 I/O 打满了。事后复盘我最大的感触不是排查技术有多难而是如果我平时能把 Linux 系统监控这套东西真正落到细处那晚根本不用折腾到天亮。这篇文章就是基于这类实战场景写的。我不会只丢给你一串 Linux 常用命令而是把系统监控里最值得关注的指标、我日常排查时用的命令组合、从手动到自动的监控方案以及一次完整的问题定位过程都摊开来说清楚。适合刚接触 Linux 运维的新手、自己跑 VPS 的个人开发者、以及正准备给生产环境搭监控体系的同学。你不需要先把所有工具都学会跟着思路走一遍至少能知道“服务器出问题时下一步该敲什么”。1. 系统监控的核心是这些指标理清它们比记命令更重要很多新手学监控第一件事就是背命令结果遇到问题还是手忙脚乱。原因很简单命令是武器但你要先知道“敌人”是谁。Linux 系统监控的实质是盯住 CPU、内存、磁盘、网络、硬件健康这几类资源的状态并且理解每个指标背后对应的业务影响。1.1 负载均值三个数字别只看大小uptime会输出一个很显眼的数字load average: 3.42, 2.87, 2.61。这三个数分别代表过去 1 分钟、5 分钟、15 分钟的系统平均负载。很多人看到负载超过 1 就紧张其实这个数字要除以 CPU 核心数才有意义。举个例子一台 4 核机器负载 4.0 意味着每个核都刚好跑满负载 2.0 时还有一半算力空闲。反过来如果 1 分钟负载很高但 15 分钟负载很低说明是瞬时冲高可能是定时任务或突发流量如果三个数都持续走高那就要认真对待了。更隐蔽的情况是负载高但 CPU 使用率不高。这往往不是 CPU 不够用而是大量任务阻塞在磁盘 I/O、锁等待或内存换页上。只看负载不看上下文很容易把问题带偏。我自己的习惯是看到负载高第一反应不是加 CPU而是先跑一个vmstat看看到底是r运行队列在涨还是waI/O 等待在涨。1.2 内存free输出里的available才是真正能用的数内存监控最容易犯的错是把free命令里的free列当成剩余内存。Linux 内核有个特点它会尽量用空闲内存做文件缓存buff/cache所以free列数值很小并不代表内存不够。正确的做法是看available列这个值是系统估算出来的“在不触发 swap 的情况下还能分配给新进程的内存”。free -h输出大致是这样total used free shared buff/cache available Mem: 15Gi 2.1Gi 9.3Gi 118Mi 4.1Gi 12Gi Swap: 2.0Gi 0B 2.0Gi假定 total 15Gused 只有 2.1Gfree 有 9.3Gavailable 却显示 12G。这里 buff/cache 占了 4.1G但内核可以在需要时回收它所以 available 比 free 大是正常的。真正危险的信号是 available 持续偏低、swap 开始增长、然后si/so不断有换页动作这种时候业务会明显变卡。1.3 磁盘容量之外I/O 延迟才是业务的隐形杀手监控磁盘只看df -h空间说明你还在第一层。空间满当然重要但线上更常见的问题是磁盘还有大量剩余空间I/O 却已经忙不过来。磁盘 I/O 的核心体现是iostat里的%util、await和aqu-sz。%util接近 100% 说明磁盘设备已经很忙了但要注意对 SSD 来说 100% util 并不一定代表性能到顶很多 SSD 可以并行处理多队列await是平均 I/O 请求处理耗时包括排队和服务时间这个数字超过几十毫秒就要留意了。我遇到过最典型的场景数据库服务器数据盘负载不高但系统盘%util持续 90% 以上后来发现是应用把日志写到了系统盘日志量一大系统盘直接成为瓶颈。所以磁盘监控要分设备看系统盘、数据盘、日志盘单独观察别混在一起。1.4 网络与连接数延迟、丢包和端口耗尽网络监控不仅仅是看带宽跑满没有。对于提供服务的服务器更关键的是连接状态分布和丢包率。ss -s可以快速看到 TCP 连接总数和各状态统计。如果TIME_WAIT连接数量异常多会影响新连接的建立因为每个连接都需要本地端口超过net.ipv4.ip_local_port_range的范围后就会出现Cannot assign requested address。这类问题用ss -s一眼就能看出来。另外延迟和丢包要看ping和mtr。ping看基础的连通性和 RTTmtr能逐跳查看哪一跳在丢包。如果客户端反馈“慢”但服务器本机 CPU、内存、磁盘都正常网络层的排查就必须跟上。1.5 硬件温度性能衰减往往比蓝屏更早出现服务器长期高温不会立刻宕机但 CPU 会主动降频保护自己性能悄悄下滑。这种现象在物理机上很常见尤其是夏季机房制冷不足或风扇积灰。Linux 下用lm-sensors读取温度sudo apt install lm-sensors sudo sensors-detect sensors输出里会包含 CPU 各核心温度、主板温度、风扇转速。如果发现 CPU 温度长期高于 85℃就要检查散热和机房空调了。监控温度不一定非要做成复杂平台定时采样记录日志配合告警也能起到效果。2. 一套命令组合拳覆盖 90% 的日常排查指标理清楚之后命令才能派上用场。下面这套组合是我在实际工作中反复用的几乎每个场景都能覆盖。2.1 top / htop进入任意一台机器的第一件事top是 Linux 运维的基本功。进入交互界面后我建议先记住几个按键P按 CPU 使用率降序排列M按内存使用率降序排列1展开显示每个逻辑 CPU 的使用情况c显示完整命令行默认的按 CPU 排序适合找 CPU 密集进程但如果你想看谁吃内存最多按M更直观。top里还有一个关键信息是zombie僵尸进程如果数量持续增长说明父进程没有正确回收子进程应用代码有问题。htop是top的增强版彩色显示支持鼠标操作F6可以选择排序字段F9直接发信号给进程。我个人在排查时更喜欢htop因为它把 CPU、内存、Swap 的负载条放一起视觉上一眼就能看出资源分布。2.2 vmstat一条命令看到系统整体状态vmstat是我最推荐的第二把武器。用法通常是vmstat 2 10表示每 2 秒采样一次共 10 次。输出关键字段procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 951120 1452 305860 0 0 1 2 1020 2400 8 2 88 2 0排查思路是先看r运行队列是不是大于 CPU 核数如果长期大于核数说明 CPU 饱和再看b阻塞进程数是不是在涨如果 b 高并且wa高基本可以确定 I/O 有瓶颈。si/so是 swap 换入换出一旦持续非零内存很可能不够了。cs是上下文切换过高可能和频繁锁竞争或线程太多有关。2.3 iostat 与 sar把磁盘细节和历史数据盘活iostat -x 1用于监控磁盘 I/O 细节-x展开更多扩展统计Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz %util vda 2.30 12.50 10.5 150.2 0.00 0.00 0.00 0.00 3.20 18.60 0.20 18.4观察r_await/w_await与aqu-sz平均队列长度。如果aqu-sz持续大于设备并发能力说明请求在排队磁盘响应变慢。%util结合队列长度看比单看%util更可靠。sar属于 sysstat 包它能把历史数据落盘以便事后回放。默认采集可能没开启需要确保/etc/cron.d/sysstat里的任务在运行然后通过sar -q看历史负载、sar -r看历史内存、sar -d看历史磁盘。没有历史数据的监控等于只带了手电筒却没有内存卡。2.4 ss、iftop、nload网络排查三件套查端口和连接数用ss而不是旧的netstatss -tulnp # 查看所有监听端口 ss -s # 汇总连接状态 ss -t state established # 查看已建立连接-t看 TCP-u看 UDP-l只看监听-n不做反解-p显示进程。定位“谁在占用 8080 端口”这类问题就用ss -tulnp | grep 8080。实时流量工具iftop可以按连接查看流量iftop -i eth0 -n -P-P会显示端口方便看出具体是哪个服务在消耗流量。nload则更擅长看总入/总出带宽适合判断带宽是否跑满。2.5 dstat 与 perf站在更高维度的补充工具如果你嫌vmstat、iostat分开看麻烦可以试试dstatdstat -cdngy 2一次输出 CPU、磁盘、网络、内存、系统负载。它是 Python 写的很多发行版默认没装apt install dstat或yum install dstat即可。它适合临时把多维度指标同时放到一个屏幕上观察。perf top则是面向性能优化的进阶工具可以直接看到内核和用户态的热点函数。比如 CPU 占用高但找不到是哪个进程或哪个系统调用引起的perf top能告诉你问题发生在copy_page_range还是某个驱动函数上。这个工具对普通运维可能有点深但值得知道它的存在。3. 从命令到平台给服务器装一套能长期看的监控命令适合临时排查但生产环境不能老是靠人肉盯着。于是我们需要监控平台。3.1 先别急着上全家桶评估自己的场景一谈到监控平台很多人直接想到 Prometheus、Zabbix、ELK。但如果你只有两三台服务器直接搭一套完整的 PrometheusGrafanaAlertmanager 其实有点技术债配置项多、组件多、维护成本不小。我个人建议按场景选择场景推荐方案理由个人 VPS / 三四台以内Netdata安装简单自带图表零配置混合环境、需要统一收集Prometheus node_exporter Grafana生态成熟可扩展查询灵活已有复杂 ITIL 流程Zabbix自带告警、报表、模板体系成熟需要收集业务日志并监控Loki / ELK日志和指标分开处理但都可以和 Grafana 结合3.2 Netdata最适合个人和小团队的即时监控Netdata 的安装真的非常无脑curl -Ss https://get.netdata.cloud/kickstart.sh | sh装完后打开http://你的IP:19999能看到 CPU、内存、磁盘、网络、进程等几百张实时图表。它对新人友好在哪它把很多指标换算成了人类能读懂的样子比如 CPU 频率、缓存命中率、上下文切换速率不用你手动敲命令去猜。我用它最舒服的场景是给客户演示“系统当前负载很高”的时候直接打开一个面板指着曲线说“你看这里 I/O 明显上去了”比一堆命令输出直观得多。Netdata 资源占用很低官方说空闲时只占几 MB 内存很适合个人服务器。3.3 Prometheus node_exporter Grafana通用组合的搭建要点这套组合现在是主流但很多人第一次搭时会绕弯。我按最小可用方案来说明。架构上node_exporter负责采集 Linux 系统指标并通过 HTTP 暴露Prometheus 定时去抓取并存储Grafana 负责把 Prometheus 数据画成图表。第一步安装node_exporter它默认监听9100端口wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz cd node_exporter-1.8.2.linux-amd64 ./node_exporter第二步配置 Prometheus修改prometheus.yml的scrape_configsscrape_configs: - job_name: node static_configs: - targets: [192.168.1.10:9100]启动 Prometheus 后可以在http://你的IP:9090/targets里确认 target 是 UP 状态。第三步Grafana 添加 Prometheus 数据源导入官方仪表盘 ID1860适用于 node_exporter就能看到丰富的系统监控面板。这套方案的价值在于数据模型统一。所有机器指标都是带标签的时间序列你可以轻松写 PromQL 做聚合比如“所有 Web 服务器的平均 CPU”一条查询就能完成。3.4 告警配置让监控在出问题时主动找到你监控的意义在于出问题前提醒你。Prometheus 的告警规则和 Alertmanager 配合很常见。比如磁盘使用率超过 90% 时告警groups: - name: node_alerts rules: - alert: DiskUsageHigh expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100 90 for: 5m labels: severity: warning annotations: summary: 磁盘使用率过高 description: 实例 {{ $labels.instance }}当前磁盘使用率超过 90%持续 5 分钟这个规则里for: 5m很关键它表示只有当阈值持续 5 分钟时才触发能过滤掉很多瞬时抖动。Alertmanager 再配置一个 webhook 推到钉钉、企业微信或 Slack告警就算闭环了。告警另一个要点是聚合与去重。别每台机器单独刷屏要按服务、按故障域分组。Alertmanager 里的group_by、group_wait和repeat_interval就是干这个的默认group_wait设置为 30 秒比较合适。4. 一次真实排查响应变慢的服务器监控数据如何一步步定位根因这部分我想完整复盘一次线上事故看命令和指标是如何配合的。4.1 表象负载 5.0但 CPU 使用率只有 20%当时业务反馈上传文件后前端处理速度特别慢。我登上去先执行uptime topuptime显示 load average 4.8机器共 4 核负载已经超过核数。但top里 CPU 的us只有 15%sy5%id却高达 80%。CPU 明明很闲负载却这么高问题几乎不在计算能力。4.2 定位vmstat 里的 wa 和 iostat 的队列长度对上了号我继续跑vmstat 1 5 iostat -x 1 5vmstat中wa平均在 55% 左右b阻塞进程数经常大于 2说明大量进程在等 I/O。iostat显示vdb这块盘的%util到了 99%aqu-sz一直在 8 以上w_await高达 120 毫秒。到这里瓶颈已经锁定在磁盘写入上而且不是系统盘是专门的数据盘。4.3 揪出元凶pidstat 拿到进程号lsof 定位到文件锁定磁盘层后还需要知道是哪个进程在疯狂写盘。此时用pidstat -d 1看每个进程的磁盘读写速率pidstat -d 1 5输出片段14:23:01 PID kB_rd/s kB_wr/s kB_ccwr/s Command 14:23:02 1234 0.00 45000.00 0.00 java一个 Java 进程每秒写 45MB明显不正常。继续用lsof -p 1234 | grep -E \.log|\.out找到它打开的日志文件路径发现是某个中间件把 DEBUG 级日志全部输出并且没有轮转单个日志文件已经涨到几 GB应用每打一条日志都要触发文件系统开销磁盘队列自然就爆了。4.4 处理与复盘降日志、加轮转、查 inode处理分了两步第一保留现场并立刻把日志级别调到 WARN恢复业务第二写日志轮转配置避免单文件无限增大。但复盘时又发现一个潜在风险这台机器/分区的 inode 使用率已经 90% 多因为大量小文件堆积。df -i看到的结果是即使空间还有inode 满了同样无法创建文件。这个隐患平时不显眼一次日志乱写就可能被引爆。那次之后我把磁盘监控分区拆细了系统盘看空间和 inode数据盘关注 I/O 延迟并在监控平台加了一个“日志目录写入速率”的视图防止类似事件再悄悄发生。5. 监控这条路我不想你重复踩的坑最后聊聊我在折腾监控过程中积累的几个教训。5.1 数字采集到了不等于看懂了最典型的例子是load average。如果你只盯着数字超过核数就报警很可能误报。高负载可能来自 I/O、内存换页或锁等待不一定代表 CPU 繁忙。养成“多指标交叉验证”的习惯看到负载高就顺手看一眼 CPU 的us/sy/id/wa、内存 swap、磁盘队列才能得出正确结论。5.2 告警阈值拍脑袋不如先观察基线很多人刚搭好监控平台就急着把所有规则加上然后被一堆噪音告警烦到关掉。更好的做法是先跑两周基线看正常业务的 CPU 均值、峰值、磁盘使用率和网络流量再根据 95 分位加上一定裕量设定阈值。比如业务平时 CPU 是 30%报警阈值设为 75% 就比 50% 更合理避免大促或高峰时误报。5.3 监控系统本身也是需要运维的监控机器一旦挂了你根本不知道系统出了什么问题这是最讽刺的事。我现在会额外在外面放一个探活定时请求监控面板或 Prometheus 的/health接口一旦监控自身不可达也会收到告警。另外Prometheus 的存储不能无限增长要有数据保留策略比如只保留 15 天并在磁盘容量上预留足够余量。还有一个小技巧监控是给人看的不是为了攒数据。每次新加一个仪表盘图先问自己“看到这张图我能做出什么决策”如果答案是不确定这个指标可以不放。不要让几百张图表淹没了真正有用的信息。我平时最依赖的其实就是uptime、vmstat、iostat、ss那几样基本功以及一套能沉淀历史和自动告警的监控平台。系统监控不是一锤子买卖它是在一次次故障复盘里慢慢养出来的。希望这篇内容能让你少走点弯路下次再有人半夜打电话说“服务器卡了”你至少知道从哪几个方向下手而不是干瞪眼。
