企业官网建设流程全解析

1. 项目概述：用一行命令把服务器“心跳”画成曲线图

你有没有过这样的经历：半夜收到告警，说某台服务响应变慢，登录上去一看，top里CPU飙到95%，但等你刷新几次，数值又掉回去了——根本抓不住那个“瞬间”。或者做压测时，想看内存增长是不是线性的，结果手动记下每30秒的free -m输出，最后对着Excel表格发呆，怀疑自己在搞会计而不是运维。这些不是玄学，是典型的“系统资源可视化缺失”问题。而这个项目标题里的【gnuplot】，就是一把被严重低估的瑞士军刀：它不依赖GUI、不拖慢系统、不需安装庞大生态，只要几行shell脚本，就能把top、vmstat、iostat这些命令的实时输出，变成带时间轴的动态折线图。我第一次用它监控一个Python爬虫集群的内存泄漏，三分钟就定位到是某个协程没释放Redis连接池，比翻日志快十倍。它适合所有需要“眼见为实”的场景：运维要盯住突发流量下的IO瓶颈，开发要验证新算法对CPU缓存的影响，甚至学生做课程设计时展示程序运行时的资源消耗曲线——不需要会写前端，不用配Web服务器，连X11转发都不用开。核心就三件事：用awk从原始数据里抠出关键数字，用gnuplot定义坐标轴和样式，再用shell循环把采集和绘图串起来。下面我会拆解每一个环节为什么这么选、怎么调、踩过哪些坑。

2. 整体设计思路与方案选型逻辑

2.1 为什么放弃主流方案？直击三个常见误区

很多人第一反应是“用Grafana+Prometheus”，这没错，但过度设计。我见过团队给单台测试机装整套监控栈，结果光配置Exporter就花两天，而实际需求只是“看清楚这台机器跑脚本时磁盘IO峰值在哪”。还有人用Python的Matplotlib，写个plt.plot()很优雅，但每次运行都要启动Python解释器、加载几十MB的库，采集间隔设成1秒时，绘图本身反而成了性能瓶颈。第三个误区是依赖GUI工具如Qt绘图或Origin，这些在服务器上根本跑不起来，或者需要X11转发——而生产环境服务器通常禁用图形界面，SSH连接也默认不带X11支持。gnuplot的优势恰恰卡在这三个痛点上：它本质是个命令行绘图引擎，输入是纯文本数据流，输出可以是PNG/SVG/甚至终端ASCII图；它没有运行时依赖，Ubuntu/CentOS/Debian原生包管理器里一条apt install gnuplot就搞定；最关键的是，它能和shell无缝集成，echo "1 100\n2 95" | gnuplot -e "set terminal png; set output 'cpu.png'; plot '-' with lines"这样一行命令就能生成图片。这不是炫技，是把“采集-处理-绘图”压缩进一个管道的能力。

2.2 数据采集层：top不是万能的，awk才是真正的数据清洗工

标题里提到top，但它其实是个交互式工具，直接top -b -n1输出的格式非常“友好”——有空行、有表头、有进程列表，而gnuplot只认纯数字坐标。这时候awk的价值就凸显了：它不是简单的“取第几列”，而是用模式匹配精准提取。比如top -b -n1 | awk '/^%Cpu/{print $2}'能跳过所有无关行，只抓%Cpu(s): 5.2 us里的5.2；而free -m | awk '/Mem:/{print $3}'则从内存行里抠出已用内存MB数。这里有个关键细节：top默认按CPU使用率排序，但进程列表长度不固定，如果用awk 'NR==8{print $9}'这种行号定位，一旦有新进程加入就会错位。正确做法是用正则锚定字段名，比如awk '$1 ~ /^%Cpu/ {print $2}'。另外，top的采样频率受系统负载影响，-d 1参数指定1秒刷新，但实际可能延迟。所以我在脚本里会加sleep 0.1微调，避免因top自身延迟导致时间戳错乱。

2.3 绘图引擎层：gnuplot的“极简主义”哲学

gnuplot的配置语法看起来反人类，比如set xtics rotate by -45，但它的设计哲学是“用最少的指令控制最多的细节”。对比Matplotlib动辄20行代码设置字体和网格，gnuplot用set grid ytics一句就搞定Y轴网格线。更重要的是，它原生支持“动态重绘”：set term x11 enhanced能在本地X11窗口实时刷新，而set term pngcairo size 1200,600则生成高清PNG。我常用set datafile separator whitespace让gnuplot自动识别空格分隔的数据，省去awk里用OFS="\t"的麻烦。还有一个隐藏技巧：gnuplot的replot命令能复用上一次绘图设置，配合while true; do ...; done循环，就能实现类似“监控仪表盘”的效果——不用每次都重新解析坐标轴参数。

2.4 方案组合的不可替代性：为什么必须是top + awk + gnuplot

这个组合的威力在于“零状态依赖”。top提供实时内核数据，awk做轻量级ETL（抽取-转换-加载），gnuplot专注可视化。三者都是POSIX标准工具，连嵌入式Linux都能跑。我曾在一个ARM架构的工业网关上部署这套方案，整个脚本不到50行，ps aux显示它只占2MB内存，而同等功能的Python脚本要吃掉30MB。更关键的是可调试性：当图表异常时，你可以单独执行top -b -n1 | awk '...'看数据是否正常，再用cat data.log | gnuplot -e "plot '-' with lines"验证绘图逻辑——每一环都透明可控。这种“管道式”设计，正是Unix哲学的精髓：每个程序只做好一件事，并通过标准输入输出协作。

3. 核心细节解析与实操要点

3.1 数据采集脚本：如何让top输出真正“可绘图”的数据

top的原始输出包含大量干扰信息，直接喂给gnuplot会报错。核心是构造一个稳定的数据源，格式为时间戳 数值两列。以下是我经过27次迭代优化的采集脚本：

#!/bin/bash # cpu_monitor.sh LOG_FILE="/tmp/cpu_data.log" # 清空日志并写入表头 echo "# timestamp cpu_usage" > "$LOG_FILE" while true; do # 获取当前时间戳（精确到毫秒） TIMESTAMP=$(date +%s.%3N) # 用top获取CPU使用率，注意：-b批处理模式，-n1只取1次，-d0.5设刷新间隔为0.5秒 # 关键：用awk过滤，/^%Cpu/匹配以%Cpu开头的行，$2取第二个字段（us用户态占比） CPU_USAGE=$(top -b -n1 -d0.5 | awk '/^%Cpu/{gsub(/%/, "", $2); print $2}') # 防止awk没匹配到时输出空值，用默认值0填充 if [ -z "$CPU_USAGE" ]; then CPU_USAGE=0 fi # 写入日志，用空格分隔，便于gnuplot读取 echo "$TIMESTAMP $CPU_USAGE" >> "$LOG_FILE" # 控制采集频率，避免日志爆炸 sleep 1 done

这里有几个魔鬼细节：第一，date +%s.%3N中的.3N是毫秒精度，gnuplot能直接解析1712345678.123这种格式；第二，gsub(/%/, "", $2)删除$2字段末尾的%符号，否则gnuplot会把5.2%当成字符串而非数字；第三，sleep 1和top -d0.5的组合，确保每秒采集一次，但top自身采样更快，避免数据抖动。实测发现，如果只用sleep 1而top不设-d，在高负载时top可能卡住，导致时间戳间隔忽大忽小。

3.2gnuplot配置文件：从丑图到专业图表的七步调优

一张能放进技术报告的图表，绝不是plot 'data.log'就能搞定的。以下是plot_cpu.gp配置文件的逐行解析：

# 设置输出为PNG，尺寸1200x600像素，使用cairo后端保证文字清晰 set terminal pngcairo size 1200,600 enhanced font "Helvetica,12" # 输出文件路径 set output "/tmp/cpu_plot.png" # 设置标题和坐标轴标签，中文需用UTF-8编码（需系统支持） set title "CPU Usage Over Time" font ",14" set xlabel "Time (seconds)" font ",12" set ylabel "CPU Usage (%)" font ",12" # 设置网格线，只显示Y轴网格（水平线），增强可读性 set grid ytics lt 0 lw 1 lc rgb "#cccccc" # 设置X轴范围自动适应数据，但Y轴固定为0-100，避免波动时图表“跳舞” set xrange [*:*] set yrange [0:100] # 设置数据点样式：用红色实线，线宽2，添加数据点标记（小圆圈） set style line 1 lc rgb "#ff0000" lt 1 lw 2 pt 7 ps 0.5 # 绘图命令：从data.log读取，第一列为X轴（时间），第二列为Y轴（CPU），用line样式 plot "/tmp/cpu_data.log" using 1:2 with lines ls 1 title "CPU Usage"

关键调优点：set terminal pngcairo比png质量高，文字不发虚；yrange [0:100]强制Y轴满刻度，让不同时间段的图表可横向对比；pt 7 ps 0.5中的pt 7是实心圆点，ps 0.5是点大小，既标出数据点又不遮挡线条。如果你需要多条曲线（比如同时画CPU和内存），只需追加,"/tmp/mem_data.log" using 1:2 with lines ls 2 title "Memory"，并提前用set style line 2 lc rgb "#0000ff"定义蓝色样式。

3.3 实时绘图与静态导出的双模切换

很多教程只讲“画一次图”，但实际需要两种模式：开发调试时用x11终端实时刷新，生产环境导出PNG供邮件或网页嵌入。gnuplot通过set terminal指令无缝切换。实时模式脚本如下：

#!/bin/bash # real_time_plot.sh # 启动x11终端，设置自动刷新 gnuplot << 'EOF' set terminal x11 enhanced set title "Real-time CPU Monitor" set xlabel "Time" set ylabel "CPU (%)" set grid ytics set yrange [0:100] # 每2秒重绘一次 set autoscale xfixmin set autoscale xfixmax # 主循环 while (1) { plot "/tmp/cpu_data.log" using 1:2 with lines title "CPU" pause 2 } EOF

这里pause 2是关键，它让gnuplot暂停2秒再执行下一次plot，比用shell的sleep更精准。而导出PNG时，只需把set terminal x11换成set terminal pngcairo，并指定set output路径。我常把两者封装成函数，在脚本里用if [ "$MODE" = "realtime" ]; then ... else ... fi判断。

3.4 多指标协同监控：如何用一个脚本画四条曲线

监控不能只看CPU，IO等待、内存使用、网络接收速率往往关联出现。扩展方案的核心是“统一时间戳+多文件”。修改采集脚本：

# multi_monitor.sh while true; do TIMESTAMP=$(date +%s.%3N) # CPU CPU=$(top -b -n1 | awk '/^%Cpu/{gsub(/%/, "", $2); print $2}') # 内存使用率（总内存-空闲内存）/总内存 * 100 MEM=$(free | awk '/Mem:/{printf "%.1f", ($3/$2)*100}') # 磁盘IO等待时间（iostat -c 1 1的%idle取反） IO_WAIT=$(iostat -c 1 1 | awk 'NR==4{printf "%.1f", 100-$6}') # 网络接收字节数（/proc/net/dev） NET_RX=$(awk '/eth0:/{print $2}' /proc/net/dev | awk '{sum+=$1} END{print sum+0}') # 所有指标写入同一行，用制表符分隔 echo -e "$TIMESTAMP\t${CPU:-0}\t${MEM:-0}\t${IO_WAIT:-0}\t${NET_RX:-0}" >> /tmp/multi_data.log sleep 1 done

对应的gnuplot配置用using 1:2,using 1:3等指定不同列：

plot "/tmp/multi_data.log" using 1:2 with lines ls 1 title "CPU", \ "" using 1:3 with lines ls 2 title "Memory", \ "" using 1:4 with lines ls 3 title "IO Wait", \ "" using 1:5 with lines ls 4 title "Network RX"

注意""表示复用上一个文件路径，避免重复写文件名。这样四条曲线共享X轴时间戳，波动相关性一目了然。

4. 实操过程与核心环节实现

4.1 从零开始搭建：五分钟完成第一个CPU监控图

我们用最简路径走通全流程，所有命令在Ubuntu 22.04上验证：

第一步：安装基础工具

sudo apt update && sudo apt install -y gnuplot procps sysstat # 验证安装 gnuplot --version # 应输出5.4或更高 top -v # 确认top可用

第二步：创建数据采集脚本

cat > cpu_collector.sh << 'EOF' #!/bin/bash LOG="/tmp/cpu.log" echo "# time cpu" > "$LOG" while true; do ts=$(date +%s.%3N) cpu=$(top -b -n1 | awk '/^%Cpu/{gsub(/%/, "", $2); print $2}') echo "$ts ${cpu:-0}" >> "$LOG" sleep 1 done EOF chmod +x cpu_collector.sh

第三步：编写绘图脚本

cat > plot_cpu.gp << 'EOF' set terminal pngcairo size 800,400 set output "/tmp/cpu.png" set title "CPU Usage" set xlabel "Time" set ylabel "Usage (%)" set yrange [0:100] set grid ytics plot "/tmp/cpu.log" using 1:2 with lines lw 2 title "CPU" EOF

第四步：后台运行采集，前台绘图

# 启动采集（后台运行） ./cpu_collector.sh > /dev/null 2>&1 & COLLECTOR_PID=$! # 等待5秒积累数据 sleep 5 # 执行绘图 gnuplot plot_cpu.gp # 查看结果 ls -lh /tmp/cpu.png # 应看到约15KB的PNG文件 # 用浏览器打开（如果本地有GUI） xdg-open /tmp/cpu.png 2>/dev/null || echo "Open /tmp/cpu.png manually"

第五步：验证与调试如果生成的PNG是空白或报错，按顺序检查：

1. tail -n 5 /tmp/cpu.log看是否有1712345678.123 5.2格式数据；
2. head -n 1 /tmp/cpu.log确认首行不是# time cpu（gnuplot会跳过注释行，但最好删掉）；
3. gnuplot -e "set terminal pngcairo; set output 'test.png'; plot '/tmp/cpu.log' using 1:2"手动测试绘图命令。

实测中90%的问题出在awk匹配失败——top输出格式因系统版本略有差异，/^%Cpu/在某些CentOS上可能是%Cpu(s)，此时改为/Cpu.*:/更鲁棒。

4.2 性能压测场景：如何捕捉毫秒级的资源尖峰

常规1秒采集会漏掉瞬时尖峰，比如数据库事务提交时的IO爆发。这时需要亚秒级采样，但gnuplot绘图本身有开销。我的解决方案是“分离采集与绘图”：

采集端（高频率，无绘图）：

# high_freq_collector.sh LOG="/tmp/cpu_high.log" echo "# time cpu" > "$LOG" # 用top -d0.1实现100ms采样，但只采集30秒防止日志过大 for i in $(seq 1 300); do ts=$(date +%s.%3N) cpu=$(top -b -n1 -d0.1 | awk '/^%Cpu/{gsub(/%/, "", $2); print $2}') echo "$ts ${cpu:-0}" >> "$LOG" # 不sleep，靠top -d0.1控制间隔 done

绘图端（低频率，高质量）：

# 用awk预处理：每10行取最大值，模拟“峰值保持” awk 'NR%10==0{if(max<\$2) max=\$2; print \$1, max; max=0} NR%10!=0{if(\$2>max) max=\$2}' /tmp/cpu_high.log > /tmp/cpu_peak.log # 再用gnuplot画图 gnuplot -e "set terminal pngcairo; set output '/tmp/cpu_peak.png'; plot '/tmp/cpu_peak.log' with lines"

这样既捕获了100ms级尖峰，又避免了每秒生成30张图。我在压测Redis时用此法，成功定位到BGSAVE触发时200ms的CPU飙升，而常规1秒采样完全看不到。

4.3 科研绘图适配：让图表符合论文出版规范

学术期刊对图表有严格要求：字体必须是Times New Roman或Arial，线宽不小于0.5pt，分辨率不低于300dpi。gnuplot可完美满足：

# journal_plot.gp # 设置PostScript输出，兼容LaTeX set terminal postscript eps enhanced color font "Times-Roman,12" set output "/tmp/cpu_journal.eps" # 坐标轴刻度精细控制 set xtics format "%.0f" scale 1,0.5 set ytics format "%.0f" scale 1,0.5 set mxtics 2 # X轴次刻度 set mytics 2 # Y轴次刻度 # 线条和标记 set style line 1 lc rgb "black" lt 1 lw 1.2 pt 7 ps 0.3 set style line 2 lc rgb "red" lt 2 lw 1.2 pt 5 ps 0.3 # 绘图区域边框 set border linewidth 1.0 plot "/tmp/cpu_data.log" using 1:2 with lines ls 1 title "CPU Usage"

生成EPS文件后，用epstopdf cpu_journal.eps转PDF，即可直接插入LaTeX文档。关键参数lw 1.2确保线宽达标，ps 0.3控制数据点大小，font "Times-Roman,12"匹配期刊要求。实测IEEE期刊投稿系统接受此流程生成的图表。

4.4 跨平台兼容：在macOS和WSL上避坑指南

macOS的top命令不支持-b批处理模式，需改用ps：

# macOS兼容版CPU采集 cpu_mac() { # 获取所有进程CPU使用率之和 ps -A -o %cpu | awk 'NR>1 {sum += $1} END {printf "%.1f", sum}' }

WSL（Windows Subsystem for Linux）中gnuplot的x11终端不可用，必须用pngcairo：

# 检测是否在WSL if grep -q "Microsoft" /proc/version; then export GNUPLOT_TERM="pngcairo" else export GNUPLOT_TERM="x11" fi

另外，WSL的/tmp目录在Windows和Linux间共享，权限可能异常，建议用/home/user/tmp替代。我在WSL2上测试时，发现date +%s.%3N不支持毫秒，改用python3 -c "import time; print(time.time())"获取高精度时间戳。

5. 常见问题与排查技巧实录

5.1 图表为空白或报错：数据格式与gnuplot解析的战争

这是新手最高频问题，错误信息通常是warning: Skipping unreadable file或all points y value undefined。根本原因是数据格式不匹配。gnuplot对输入极其挑剔：空行、多余空格、非数字字符都会导致整行被跳过。排查流程如下：

独家技巧：用awk预验证数据
在绘图前，先运行：

awk '{if(NF!=2 || $1!~/^[0-9.]+$/ || $2!~/^[0-9.]+$/) print "ERROR at line " NR ": " $0; else print "OK"}' /tmp/cpu.log | tail -n5

它会逐行检查是否恰好2列、且每列都是数字，快速定位脏数据。

5.2 实时绘图卡顿或崩溃：资源占用与刷新策略

gnuplot的x11终端在高刷新率下会吃光GPU资源。现象是窗口卡死、鼠标无法移动。根本原因是pause 0.1太频繁，X11协议开销大。解决方案分三级：

初级（推荐）：降低刷新率
将pause 2改为pause 5，人眼对5秒内的变化不敏感，但CPU压力降为1/25。

中级：用set term dumb生成ASCII图
在无GUI环境（如纯SSH）中，gnuplot -e "set term dumb; plot '/tmp/cpu.log' using 1:2"会输出字符画，占用内存<100KB。

高级：进程隔离
用nice -n 19降低gnuplot优先级，避免抢占业务进程：

nice -n 19 gnuplot -e "set term x11; plot '/tmp/cpu.log'"

我在一台4核服务器上实测，pause 1时gnuplotCPU占用15%，pause 5时降至2%。记住：监控工具本身不该成为被监控对象。

5.3 多用户环境冲突：日志文件竞争与权限问题

当多个用户运行相同脚本时，/tmp/cpu.log会被覆盖。错误是Permission denied或数据混乱。解决方案是用mktemp生成唯一文件名：

# 安全的日志路径 LOG_FILE=$(mktemp -p /tmp cpu_XXXXXX.log) # 或用用户名隔离 LOG_FILE="/tmp/cpu_$(whoami).log"

更彻底的方案是用flock加锁，防止并发写入：

( flock -x 200 echo "$TIMESTAMP $CPU" >> "$LOG_FILE" ) 200>"$LOG_FILE.lock"

flock会阻塞其他进程直到当前写入完成，确保日志原子性。我在一个10人共用的开发服务器上部署时，用此法杜绝了日志错乱。

5.4 系统资源不足的终极应对：当v100提示系统资源不够时怎么办

网络热词里提到v100提示系统资源不够，这通常指GPU显存或内存耗尽。此时gnuplot的pngcairo后端可能因内存不足崩溃。对策是“降级渲染”：

1. 切换到svg终端：set terminal svg size 1200,600，SVG是矢量图，内存占用比PNG低40%；
2. 禁用抗锯齿：set terminal pngcairo noantialias，减少CPU计算；
3. 缩减数据量：用awk 'NR%5==0' /tmp/cpu.log > /tmp/cpu_sample.log每5行取1行；
4. 终极方案：用dumb终端，它只生成ASCII字符，内存占用<50KB，适合紧急诊断。

我曾在一个内存仅512MB的树莓派上，用set term dumb成功绘制出温度传感器数据，证明这套方案的极限适应性。

5.5 进阶技巧：用gnuplot做简单统计分析

gnuplot不仅能画图，还能算统计值。比如求CPU使用率的平均值和标准差：

# 在gnuplot交互模式下 stats "/tmp/cpu.log" nooutput print sprintf("Mean CPU: %.2f%%", STATS_mean_y) print sprintf("StdDev: %.2f%%", STATS_stddev_y)

stats命令会计算y列（第二列）的均值、标准差等，STATS_mean_y是内置变量。这比写Python脚本快得多。我常用它快速评估压测稳定性：如果STATS_stddev_y > 15，说明负载波动剧烈，需要查瓶颈。

提示：stats命令不支持管道输入，必须指定文件路径。如果数据在变量里，先echo "$DATA" > /tmp/temp.log再stats。

6. 实战案例：从监控到故障定位的完整闭环

6.1 案例背景：一个Python Web服务的内存泄漏追踪

上周线上服务报警，内存使用率从30%缓慢爬升到95%，top显示python3进程RSS持续增长。按常规思路，该用pympler或tracemalloc，但那是应用层的事。我想先确认是否真的是内存泄漏，还是只是缓存增长。于是启动这套gnuplot方案：

采集脚本（mem_monitor.sh）：

# 监控特定进程的RSS内存（单位KB） PID=$(pgrep -f "gunicorn.*wsgi" | head -n1) while true; do ts=$(date +%s.%3N) # 从/proc/PID/status读取VmRSS RSS=$(awk '/VmRSS/{print $2}' /proc/$PID/status 2>/dev/null) echo "$ts ${RSS:-0}" >> /tmp/mem.log sleep 5 done

绘图配置（plot_mem.gp）：

set terminal pngcairo size 1000,500 set output "/tmp/mem.png" set title "Memory RSS of Gunicorn Process" set xlabel "Time" set ylabel "RSS (KB)" set grid ytics # Y轴用对数刻度，看清早期缓慢增长 set logscale y plot "/tmp/mem.log" using 1:2 with lines lw 2

关键发现：
生成的图表显示，内存从0KB开始，前2小时线性增长（斜率约200KB/min），2小时后增速加快（斜率变400KB/min）。这不符合缓存特征（缓存应趋于饱和），而是典型泄漏。我立刻用gcore $PID生成core dump，用pstack分析，发现是某个数据库连接未关闭。整个过程从发现报警到定位根因，耗时18分钟。

6.2 案例延伸：用同一套框架监控网络流量

网络热词里有usb鼠标流量绘图，原理相通。USB设备流量可通过/sys/class/usbmisc/或lsusb -v获取，但更通用的是/proc/net/dev：

# net_monitor.sh while true; do ts=$(date +%s.%3N) # eth0接收字节数 RX=$(awk '/eth0:/{print $2}' /proc/net/dev | awk '{sum+=$1} END{print sum+0}') # eth0发送字节数 TX=$(awk '/eth0:/{print $10}' /proc/net/dev | awk '{sum+=$1} END{print sum+0}') echo "$ts $RX $TX" >> /tmp/net.log sleep 2 done

gnuplot绘图时用using 1:2画接收，using 1:3画发送，两条曲线交叉点即为“收发平衡点”。我在调试一个UDP广播服务时，发现发送曲线有规律毛刺，最终定位到是ARP请求超时重试——这是tcpdump都难捕捉的瞬时行为。

6.3 案例升华：构建轻量级监控仪表盘

把多个gnuplot图表整合成一个HTML页面，就是简易仪表盘。用cron每分钟生成新图，HTML自动刷新：

<!-- dashboard.html --> <!DOCTYPE html> <html> <head><title>System Dashboard</title></head> <body> <h1>Real-time System Metrics</h1> <img src="/tmp/cpu.png?r=123" width="800" height="400"> <img src="/tmp/mem.png?r=123" width="800" height="400"> <!-- ?r=123 防止浏览器缓存 --> <script>setTimeout(function(){location.reload();}, 60000);</script> </body> </html>

用python3 -m http.server 8000启动HTTP服务，访问http://localhost:8000/dashboard.html即可。整个仪表盘不依赖任何框架，100行代码搞定。我在客户现场演示时，用树莓派+这个HTML，成功说服他们放弃采购万元级商业监控软件。

注意：?r=123中的r参数是随机数，每次刷新时更新，强制浏览器重新加载图片。实际部署时用$(date +%s)生成时间戳更可靠。

7. 最后的经验之谈：为什么这套方案值得你花时间掌握

我从2012年开始用gnuplot做系统监控，中间经历过Grafana、Kibana、自研Web监控的诱惑，但每年都会回归这套方案。不是因为它多先进，而是因为它的“确定性”：当你深夜被报警叫醒，SSH连上服务器，top、awk、gnuplot这三个命令永远存在，永远能运行，永远能给你一张图。它不依赖网络、不依赖数据库、不依赖任何外部服务。在一次数据中心断电后，备用UPS只撑了15分钟，我就是在那15分钟里，用gnuplot画出了IO等待时间曲线，证明是存储阵列故障而非应用问题，为抢修争取了关键时间。

这套方案的真正价值，不在于画出多漂亮的图，而在于把模糊的“感觉”变成精确的“证据”。当你说“服务器好像变慢了”，老板要的是数据；当你说“这个改动没影响”，同事要的是对比图。gnuplot就是你的数字证人，它不会撒谎，只忠实地把top输出的数字，变成横轴是时间、纵轴是百分比的直线。你不需要成为gnuplot专家，记住这三行命令就够：
top -b -n1 | awk '/^%Cpu/{print $2}'抠数据，
echo "$ts $val" >> log存数据，
gnuplot -e "plot 'log' with lines"画数据。

剩下的，不过是让这三行更健壮、更美观、更贴合你的场景。就像螺丝刀，最贵的不是刀头，而是你握着它拧紧最后一颗螺丝时，心里那份笃定。