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 为什么放弃主流方案直击三个常见误区很多人第一反应是“用GrafanaPrometheus”这没错但过度设计。我见过团队给单台测试机装整套监控栈结果光配置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 NR8{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_USAGE0 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 多指标协同监控如何用一个脚本画四条曲线监控不能只看CPUIO等待、内存使用、网络接收速率往往关联出现。扩展方案的核心是“统一时间戳多文件”。修改采集脚本# 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 NR4{printf %.1f, 100-$6}) # 网络接收字节数/proc/net/dev NET_RX$(awk /eth0:/{print $2} /proc/net/dev | awk {sum$1} END{print sum0}) # 所有指标写入同一行用制表符分隔 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 21 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是空白或报错按顺序检查tail -n 5 /tmp/cpu.log看是否有1712345678.123 5.2格式数据head -n 1 /tmp/cpu.log确认首行不是# time cpugnuplot会跳过注释行但最好删掉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%100{if(max\$2) max\$2; print \$1, max; max0} NR%10!0{if(\$2max) 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 NR1 {sum $1} END {printf %.1f, sum} }WSLWindows Subsystem for Linux中gnuplot的x11终端不可用必须用pngcairo# 检测是否在WSL if grep -q Microsoft /proc/version; then export GNUPLOT_TERMpngcairo else export GNUPLOT_TERMx11 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对输入极其挑剔空行、多余空格、非数字字符都会导致整行被跳过。排查流程如下现象可能原因排查命令解决方案warning: Skipping unreadable file文件路径错误或权限不足ls -l /tmp/cpu.logcat /tmp/cpu.log | head -n3检查路径拼写用chmod 644 /tmp/cpu.logall points y value undefinedY列数据含非数字字符如5.2%cat /tmp/cpu.log | grep -v ^# | head -n5 | od -c在awk中用gsub(/[^0-9.]/, , $2)清理图表只有零星几个点时间戳格式错误如2024-04-05 10:00:00head -n5 /tmp/cpu.log改用date %s或date %s.%3NX轴显示为科学计数法1.71e09时间戳过大gnuplot自动缩放gnuplot -e set format x %H:%M; plot /tmp/cpu.log using 1:2用set format x %H:%M自定义X轴显示独家技巧用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.lockflock会阻塞其他进程直到当前写入完成确保日志原子性。我在一个10人共用的开发服务器上部署时用此法杜绝了日志错乱。5.4 系统资源不足的终极应对当v100提示系统资源不够时怎么办网络热词里提到v100提示系统资源不够这通常指GPU显存或内存耗尽。此时gnuplot的pngcairo后端可能因内存不足崩溃。对策是“降级渲染”切换到svg终端set terminal svg size 1200,600SVG是矢量图内存占用比PNG低40%禁用抗锯齿set terminal pngcairo noantialias减少CPU计算缩减数据量用awk NR%50 /tmp/cpu.log /tmp/cpu_sample.log每5行取1行终极方案用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.gpset 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/min2小时后增速加快斜率变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 sum0}) # eth0发送字节数 TX$(awk /eth0:/{print $10} /proc/net/dev | awk {sum$1} END{print sum0}) echo $ts $RX $TX /tmp/net.log sleep 2 donegnuplot绘图时用using 1:2画接收using 1:3画发送两条曲线交叉点即为“收发平衡点”。我在调试一个UDP广播服务时发现发送曲线有规律毛刺最终定位到是ARP请求超时重试——这是tcpdump都难捕捉的瞬时行为。6.3 案例升华构建轻量级监控仪表盘把多个gnuplot图表整合成一个HTML页面就是简易仪表盘。用cron每分钟生成新图HTML自动刷新!-- dashboard.html -- !DOCTYPE html html headtitleSystem Dashboard/title/head body h1Real-time System Metrics/h1 img src/tmp/cpu.png?r123 width800 height400 img src/tmp/mem.png?r123 width800 height400 !-- ?r123 防止浏览器缓存 -- scriptsetTimeout(function(){location.reload();}, 60000);/script /body /html用python3 -m http.server 8000启动HTTP服务访问http://localhost:8000/dashboard.html即可。整个仪表盘不依赖任何框架100行代码搞定。我在客户现场演示时用树莓派这个HTML成功说服他们放弃采购万元级商业监控软件。注意?r123中的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画数据。剩下的不过是让这三行更健壮、更美观、更贴合你的场景。就像螺丝刀最贵的不是刀头而是你握着它拧紧最后一颗螺丝时心里那份笃定。