1. 项目概述做压力测试最怕的就是“盲测”。你这边Jmeter脚本跑得飞起TPS每秒事务数和响应时间曲线画得挺漂亮但服务器那边可能已经“水深火热”了——CPU飙到100%、内存耗尽开始疯狂交换、磁盘IO堵成停车场甚至网络连接数爆表而你却浑然不知。等到测试结束分析报告时才发现数据异常再回头去查当时的现场早已消失问题复现和根因定位变得异常困难。这种“后知后觉”的测试价值大打折扣。所以一个合格的性能测试工程师必须掌握在压测过程中实时监控目标服务器性能的能力。这就像赛车手在极限驾驶时不仅要看前方的赛道更要时刻紧盯仪表盘上的转速、水温、油压。本次分享的核心就是解决这个痛点在Jmeter执行分布式压测或单机压测时如何对作为压测目标或Jmeter自身的Linux服务器进行全方位、自动化的性能监控并提供一个可靠的Shell脚本自启动方案确保监控与压测同步启停数据无缝关联。这个方案的价值在于它将性能测试从单纯的“客户端负载模拟”升级为“端到端的系统观测”。你不仅能知道系统在压力下的“外在表现”响应时间、吞吐量更能清晰地看到其“内在状态”资源利用率从而快速定位瓶颈是在应用代码、数据库、中间件还是基础设施资源。下面我们就从设计思路开始拆解这套监控体系的构建。2. 监控体系设计与核心思路拆解2.1 为什么需要独立的监控脚本很多朋友可能会问Jmeter本身不是有PerfMon Metrics Collector监听器吗装上ServerAgent也能监控服务器啊。没错这是一个方案但在生产级压测或复杂场景下它有明显的局限性。首先PerfMon通过JMX或SSH拉取数据在高频采集比如每秒一次且监控多项指标时其自身会产生不小的网络开销和采集负载这可能会干扰测试结果尤其是在压测机资源紧张时。其次它的定制化能力较弱如果你想监控一些特定的进程资源、某个NIC网络接口卡的详细流量、或是磁盘的await平均等待时间这类更深入的IO指标PerfMon就显得力不从心。再者它的数据存储和展示依赖于Jmeter的UI或生成的结果文件对于长时间的稳定性测试数据管理和后期分析不够灵活。因此我们采用在目标服务器上部署独立Shell监控脚本的方案。其核心优势在于资源开销极低Shell脚本调用系统原生命令如vmstat,sar,pidstat数据采集发生在操作系统层面效率极高对系统性能的影响微乎其微。数据全面且深入可以灵活组合任何Linux性能工具获取从全局到进程级、从硬件到内核的任意指标。灵活性与独立性监控数据可以实时输出到控制台也可以写入文件、发送到时间序列数据库如InfluxDB或监控平台如Prometheus。脚本的生命周期可以独立控制与Jmeter测试强关联。问题现场快照除了时序数据脚本还可以在关键指标如CPU持续90%超过阈值时自动触发更详细的现场抓取如jstack抓取Java线程栈、tcpdump抓取网络包为问题诊断保留第一手证据。2.2 监控指标选型我们到底需要看什么监控不是数据堆砌要有明确的目的。针对压力测试我们主要关注四大核心资源CPU、内存、磁盘I/O和网络。每一类都需要选择关键的、能真实反映瓶颈的指标。CPU监控整体利用率%usr%sys%idlevmstat或mpstat命令提供。%usr高通常表示应用计算密集%sys高可能意味着系统调用频繁或内核态有瓶颈。负载平均值Load Averageuptime命令输出。1分钟、5分钟、15分钟的平均负载。如果负载持续高于CPU核心数说明系统过载。进程级CPU消耗pidstat命令。定位到具体是哪个进程如Java应用、数据库消耗了大量CPU。内存监控使用率与交换Swapfree -m命令。重点观察available内存真正可用的内存而非free。siswap in和soswap out在vmstat中显示一旦出现非零值说明物理内存不足性能会急剧下降。页错误Page Faultvmstat中的cs上下文切换和in中断虽不直接对应内存但频繁的上下文切换常与内存不足相关。磁盘I/O监控利用率%utiliostat命令。显示设备带宽使用率。持续接近100%表示磁盘是瓶颈。响应时间awaitiostat命令。I/O请求的平均等待时间毫秒。值过高表明磁盘队列过长或设备慢。读写吞吐量rkB/swkB/s每秒读写数据量结合利用率看是否达到硬件极限。网络监控带宽与包量sar -n DEV命令。监控特定网卡如eth0的rxkB/s接收、txkB/s发送和rxpck/s、txpck/s收发包数。连接状态ss -s或netstat -s。查看TCP连接数特别是TIME_WAIT、重传率等对于Web服务压测至关重要。2.3 整体架构与数据流设计我们的方案架构非常简单高效监控脚本server_monitor.sh部署在待监控的Linux服务器上。它是一个Shell脚本内部通过cron但非系统cron或循环sleep定时如每秒执行一系列性能命令。数据采集与存储脚本将格式化后的性能数据时间戳、指标名、值追加写入一个带时间戳的CSV文件中。例如server_metrics_20231027_143022.csv。CSV格式通用便于用Excel、Pythonpandas或Jmeter后续导入进行关联分析。自启动与关联通过另一个控制脚本start_test_with_monitor.sh实现一键启动。该脚本首先在目标服务器上启动监控脚本通过SSH记录监控日志文件的路径和PID然后在压测机上启动Jmeter测试最后在测试结束时通过SSH清理目标服务器上的监控进程。确保监控窗口与压测窗口完全对齐。数据关联分析压测结束后你会得到两个核心文件Jmeter生成的.jtl结果文件包含时间戳、响应时间等和服务器监控的.csv文件。通过时间戳对齐你可以在分析工具如Grafana或自定义Python脚本中绘制叠加图表直观地看到“当服务器CPU达到80%时应用响应时间从50ms陡增至500ms”这样的因果关系。3. 核心Shell监控脚本详解与编写3.1 脚本骨架与环境检查一个健壮的监控脚本首先要处理好自身运行环境、参数和信号。我们创建一个名为server_perf_monitor.sh的脚本。#!/bin/bash # 服务器性能监控脚本 # 用法./server_perf_monitor.sh [监控间隔(秒)] [监控时长(秒)] set -euo pipefail # 启用严格模式遇到错误或未定义变量则退出 # 默认参数 INTERVAL${1:-1} # 采集间隔默认1秒 DURATION${2:-0} # 监控总时长0表示无限直到手动停止 OUTPUT_DIR./perf_logs # 监控数据输出目录 LOG_FILE${OUTPUT_DIR}/monitor_$(date %Y%m%d_%H%M%S).log # 脚本运行日志 METRIC_FILE${OUTPUT_DIR}/metrics_$(date %Y%m%d_%H%M%S).csv # 指标数据文件 # 创建输出目录 mkdir -p $OUTPUT_DIR # 记录启动信息 echo $(date %Y-%m-%d %H:%M:%S) - 监控脚本启动间隔${INTERVAL}秒输出至${METRIC_FILE} | tee -a $LOG_FILE # 检查必要命令是否存在 for cmd in vmstat iostat sar pidstat mpstat; do if ! command -v $cmd /dev/null; then echo 错误命令 $cmd 未找到请安装 sysstat 包。 | tee -a $LOG_FILE exit 1 fi done # 写入CSV文件头 echo timestamp,cpu_user,cpu_system,cpu_idle,load_1m,mem_available_mb,swap_si,swap_so,io_util,io_await,io_rkb_s,io_wkb_s,net_rx_kb_s,net_tx_kb_s,tcp_established $METRIC_FILE关键点解析set -euo pipefail这是编写可靠Shell脚本的黄金法则。-e让脚本在任何一个命令失败时立即退出-u遇到未定义的变量时报错-o pipefail确保管道命令中任意一个环节失败整个管道都视为失败。这能避免脚本在部分命令出错后继续运行产生脏数据。参数化通过命令行参数接收INTERVAL和DURATION使得脚本可以灵活用于短时压测或长时间稳定性测试。输出文件命名使用date %Y%m%d_%H%M%S生成带精确启动时间戳的文件名避免了文件覆盖也便于与Jmeter测试结果的时间对齐。依赖检查在开始前检查vmstat、iostat等关键命令是否存在。这些命令通常来自sysstat包如果缺失脚本会明确提示并退出。3.2 核心数据采集函数实现接下来我们编写核心的数据采集函数collect_metrics。这个函数会在每次循环中被调用收集所有预设的指标。# 核心数据采集函数 collect_metrics() { local timestamp$(date %Y-%m-%d %H:%M:%S.%3N) # 精确到毫秒的时间戳 # 1. CPU与系统负载 - 使用 mpstat 和 uptime local cpu_stats$(mpstat 1 1 | awk NR4 {print $4,$6,$13}) # %usr, %sys, %idle local load_1m$(uptime | awk -Fload average: {print $2} | awk -F, {print $1} | xargs) # 2. 内存与Swap - 使用 free 和 vmstat local mem_info$(free -m | awk NR2 {print $7}) # Available memory in MB local swap_io$(vmstat 1 2 | tail -1 | awk {print $7,$8}) # si, so # 3. 磁盘I/O - 使用 iostat (假设监控 sda 设备请根据实际情况调整 DEVICE) local DEVICEsda local io_stats$(iostat -dxk $DEVICE 1 2 | grep ^$DEVICE | tail -1 | awk {print $14,$10,$6,$7}) # $14: %util, $10: await, $6: rkB/s, $7: wkB/s # 4. 网络 - 使用 sar (假设网卡 eth0请根据实际情况调整 NIC) local NICeth0 local net_stats$(sar -n DEV 1 1 | grep -w $NIC | tail -1 | awk {print $5,$6}) # $5: rxkB/s, $6: txkB/s (注意某些版本sar单位可能是kB/s需确认) # 5. TCP连接数 - 使用 ss local tcp_conn$(ss -s | awk /^TCP:/ {print $4}) # ESTAB 连接数 # 将所有指标输出为一行CSV echo ${timestamp},${cpu_stats},${load_1m},${mem_info},${swap_io},${io_stats},${net_stats},${tcp_conn} $METRIC_FILE }注意事项与实操心得命令采样技巧mpstat 1 1、iostat 1 2、sar 1 1这种格式第一个数字是采样间隔秒第二个数字是采样次数。我们取第二次tail -1的结果是为了避免获取到命令启动时的瞬时值或统计区间不完整的值确保数据是过去一个间隔内的平均值更稳定。设备名适配脚本中的DEVICEsda和NICeth0是示例在生产环境中必须修改。你可以通过lsblk命令查看磁盘设备名可能是vda,nvme0n1等通过ip addr或ifconfig查看活跃的网络接口名可能是ens192,enp0s3等。一个更健壮的做法是写一个函数自动探测主要磁盘和活跃网卡。网络单位确认不同版本的sar命令其网络流量单位可能是kB/s或kBps也可能是rxpck/s。你需要在你自己的服务器上运行一次sar -n DEV 1 1查看输出列的标题来确认。必要时可以在awk中做单位换算如$5*8如果单位是kB/s想转为kbps。时间戳精度使用date %Y-%m-%d %H:%M:%S.%3N获取毫秒级时间戳这对于后期与Jmeter的毫秒级日志进行精确对齐非常有帮助。3.3 主循环与信号处理脚本需要一个主循环来定时执行采集并优雅地处理用户中断如CtrlC。# 信号处理函数用于优雅退出 cleanup() { echo -e \n$(date %Y-%m-%d %H:%M:%S) - 收到中断信号停止监控。 | tee -a $LOG_FILE echo $(date %Y-%m-%d %H:%M:%S) - 监控数据已保存至$METRIC_FILE | tee -a $LOG_FILE exit 0 } # 注册信号处理 trap cleanup INT TERM # 主监控循环 echo $(date %Y-%m-%d %H:%M:%S) - 开始采集性能数据... | tee -a $LOG_FILE START_TIME$(date %s) ITERATION0 while true; do collect_metrics ((ITERATION)) CURRENT_TIME$(date %s) ELAPSED$((CURRENT_TIME - START_TIME)) # 如果设置了监控时长则检查是否超时 if [ $DURATION -gt 0 ] [ $ELAPSED -ge $DURATION ]; then echo $(date %Y-%m-%d %H:%M:%S) - 达到预设监控时长 ${DURATION} 秒停止监控。 | tee -a $LOG_FILE break fi # 等待指定的间隔时间但扣除数据采集本身耗时 SLEEP_TIME$(echo $INTERVAL - ($(date %s.%N) - $CURRENT_TIME) | bc) if (( $(echo $SLEEP_TIME 0 | bc -l) )); then sleep $SLEEP_TIME fi done cleanup # 正常结束时也执行清理关键点解析trap cleanup INT TERM这行代码至关重要。它捕获SIGINT(CtrlC) 和SIGTERM(kill命令) 信号。当用户想停止脚本时不会直接退出而是先执行cleanup函数打印结束信息确保最后一条数据已写入文件再优雅退出。避免了文件损坏或数据丢失。精确间隔控制简单的sleep $INTERVAL会导致实际循环周期大于INTERVAL因为数据采集本身需要时间。我们通过计算SLEEP_TIME INTERVAL - 采集耗时并使用高精度计算工具bc来尽可能保证采集间隔的准确性。这对于生成均匀时间序列数据很重要。时长控制通过DURATION参数可以实现定时自动停止监控非常适合无人值守的自动化测试场景。4. 自启动控制脚本与Jmeter集成方案监控脚本写好了但我们需要一个“指挥官”来协调监控和压测的启停。这个控制脚本是方案自动化的核心。4.1 控制脚本设计思路控制脚本run_perf_test.sh需要完成以下任务读取配置文件或参数获取目标服务器列表、SSH凭证、Jmeter测试计划路径等。通过SSH在每台目标服务器上启动监控脚本并记录其进程IDPID和生成的监控文件路径。在压测控制机Master上启动Jmeter测试分布式或非分布式。等待Jmeter测试完成或超时。测试完成后通过SSH连接到各目标服务器发送信号停止监控脚本并可选地将监控数据文件拉取到本地。4.2 控制脚本关键代码段这里展示核心的SSH远程启动和停止部分。#!/bin/bash # 性能测试集成控制脚本 # 配置区域 TARGET_SERVERS(userserver1 userserver2) # SSH连接字符串 JMETER_SCRIPT/path/to/your/testplan.jmx JMETER_HOME/opt/apache-jmeter-5.6.3 LOCAL_RESULT_DIR./test_results_$(date %Y%m%d_%H%M%S) MONITOR_SCRIPT_REMOTE_PATH/tmp/server_perf_monitor.sh MONITOR_INTERVAL1 # 监控间隔 MONITOR_DURATION600 # 监控时长假设测试约10分钟 # 为本次测试创建本地结果目录 mkdir -p $LOCAL_RESULT_DIR # 1. 将监控脚本分发到所有目标服务器 echo 分发监控脚本到目标服务器... for server in ${TARGET_SERVERS[]}; do scp ./server_perf_monitor.sh ${server}:${MONITOR_SCRIPT_REMOTE_PATH} ssh $server chmod x ${MONITOR_SCRIPT_REMOTE_PATH} done # 2. 在目标服务器上启动监控 declare -A monitor_pids declare -A metric_files echo 在目标服务器上启动性能监控... for server in ${TARGET_SERVERS[]}; do # 在远程服务器后台启动监控脚本并获取其PID和输出文件路径 # 注意这里通过命令替换和echo来获取远程脚本输出的文件路径需要监控脚本支持 # 一种更简单的方式是固定远程输出路径或者让监控脚本将文件路径写入一个已知位置。 output_info$(ssh $server cd /tmp nohup ${MONITOR_SCRIPT_REMOTE_PATH} ${MONITOR_INTERVAL} ${MONITOR_DURATION} /dev/null 21 echo \$!) pid$(echo $output_info | head -1) monitor_pids[$server]$pid echo 服务器 $server 监控进程PID: $pid # 假设我们知道监控文件会生成在 /tmp/perf_logs/ 下并以时间戳命名。实际中可能需要更复杂的逻辑来定位文件。 metric_files[$server]/tmp/perf_logs/metrics_*.csv # 示例路径需适配 done # 3. 等待片刻确保监控已启动 sleep 5 # 4. 启动Jmeter测试 echo 启动Jmeter性能测试... cd $JMETER_HOME/bin || exit ./jmeter -n -t $JMETER_SCRIPT -l ${LOCAL_RESULT_DIR}/result.jtl -e -o ${LOCAL_RESULT_DIR}/html_report JMETER_PID$! echo Jmeter主进程PID: $JMETER_PID # 5. 等待Jmeter测试结束 wait $JMETER_PID JMETER_EXIT_CODE$? echo Jmeter测试结束退出码: $JMETER_EXIT_CODE # 6. 停止所有目标服务器上的监控 echo 停止远程性能监控... for server in ${TARGET_SERVERS[]}; do pid${monitor_pids[$server]} if [ -n $pid ]; then ssh $server kill -TERM $pid 2/dev/null echo 监控进程 $pid 已停止 || echo 停止监控进程 $pid 失败或进程已结束 fi # 可选将监控文件拉取到本地 remote_file_pattern${metric_files[$server]} for file in $(ssh $server ls $remote_file_pattern 2/dev/null); do scp ${server}:${file} ${LOCAL_RESULT_DIR}/ echo 已拉取监控文件: $(basename $file) done done echo 性能测试与监控全部完成。结果位于: $LOCAL_RESULT_DIR实操心得与避坑指南SSH免密登录这是自动化脚本的前提。务必先在控制机和所有目标服务器之间配置好SSH密钥对实现免密登录。否则脚本会卡在密码输入环节。监控文件路径同步脚本中metric_files数组的赋值是个难点。因为监控脚本生成的文件名包含动态时间戳控制脚本无法预先知道。有两种解决方案方案A推荐修改监控脚本在启动时将生成的文件完整路径写入一个固定的“状态文件”如/tmp/perf_monitor_status控制脚本通过读取这个文件来获取路径。方案B在远程启动命令中让监控脚本将文件输出到一个固定前缀时间戳的路径然后控制脚本通过模式匹配如ls /tmp/perf_logs/metrics_*.csv来拉取最新文件。但要注意文件排序和选择。进程管理可靠性使用nohup ... 和echo $!获取后台进程PID是标准做法。但在网络不稳定或远程环境复杂时kill命令可能无法送达。更健壮的做法是监控脚本在启动时将自己的PID写入一个文件控制脚本通过读取该文件来发送信号或者使用pkill -f根据脚本名来终止进程。错误处理上述示例脚本为了清晰省略了大量错误处理如scp/ssh失败、文件不存在等。生产脚本中应对每个关键操作scp, ssh, kill检查返回值并记录详细的日志便于排错。5. 数据关联分析与可视化实践监控数据采集下来后如何与Jmeter结果关联分析是产生价值的最后一步。5.1 数据预处理与时间对齐Jmeter的.jtl文件通常是CSV格式包含时间戳timeStamp毫秒级Unix时间戳、耗时elapsed等。我们的监控CSV文件也包含时间戳。第一步是将它们的时间轴对齐。你可以使用Python的pandas库轻松完成import pandas as pd # 1. 读取Jmeter结果 jmeter_df pd.read_csv(result.jtl) # 假设时间戳列名为 timeStamp单位毫秒 jmeter_df[datetime] pd.to_datetime(jmeter_df[timeStamp], unitms) jmeter_df.set_index(datetime, inplaceTrue) # 按秒重采样计算每秒的平均响应时间、TPS等 jmeter_resampled jmeter_df[elapsed].resample(1S).agg([mean, count]).rename(columns{mean: avg_response_ms, count: tps}) # 2. 读取服务器监控数据 monitor_df pd.read_csv(metrics_20231027_143022.csv, parse_dates[timestamp]) monitor_df.set_index(timestamp, inplaceTrue) # 监控数据可能已经是1秒间隔无需重采样但确保索引频率一致 monitor_df monitor_df.asfreq(1S) # 3. 合并两个DataFrame按时间索引左连接以Jmeter数据为主 combined_df pd.merge(jmeter_resampled, monitor_df, left_indexTrue, right_indexTrue, howleft)5.2 关键场景图表分析使用matplotlib或seaborn绘制叠加图表是发现关联性的最直观方式。import matplotlib.pyplot as plt fig, axes plt.subplots(4, 1, figsize(15, 12), sharexTrue) # 子图1: TPS 与 CPU利用率 ax1 axes[0] ax1.plot(combined_df.index, combined_df[tps], colorblue, labelTPS) ax1.set_ylabel(TPS, colorblue) ax1.tick_params(axisy, labelcolorblue) ax1.legend(locupper left) ax1_twin ax1.twinx() ax1_twin.plot(combined_df.index, combined_df[cpu_user], colorred, linestyle--, labelCPU %usr) ax1_twin.set_ylabel(CPU %usr, colorred) ax1_twin.tick_params(axisy, labelcolorred) ax1_twin.legend(locupper right) ax1.set_title(TPS vs CPU Utilization) # 子图2: 平均响应时间 与 内存可用量 ax2 axes[1] ax2.plot(combined_df.index, combined_df[avg_response_ms], colorgreen, labelAvg Response (ms)) ax2.set_ylabel(Response (ms), colorgreen) ax2.tick_params(axisy, labelcolorgreen) ax2.legend(locupper left) ax2_twin ax2.twinx() ax2_twin.plot(combined_df.index, combined_df[mem_available_mb], colororange, linestyle--, labelMem Available (MB)) ax2_twin.set_ylabel(Mem (MB), colororange) ax2_twin.twin_params(axisy, labelcolororange) ax2_twin.legend(locupper right) ax2.set_title(Response Time vs Memory Available) # 子图3: TPS 与 磁盘IO等待时间 ax3 axes[2] ax3.plot(combined_df.index, combined_df[tps], colorblue, labelTPS) ax3.set_ylabel(TPS, colorblue) ax3.twin_params(axisy, labelcolorblue) ax3.legend(locupper left) ax3_twin ax3.twinx() ax3_twin.plot(combined_df.index, combined_df[io_await], colorpurple, linestyle--, labelDisk Await (ms)) ax3_twin.set_ylabel(Await (ms), colorpurple) ax3_twin.twin_params(axisy, labelcolorpurple) ax3_twin.legend(locupper right) ax3.set_title(TPS vs Disk I/O Await) # 子图4: 网络吞吐量 ax4 axes[3] ax4.plot(combined_df.index, combined_df[net_rx_kb_s], labelNetwork RX (KB/s), colorcyan) ax4.plot(combined_df.index, combined_df[net_tx_kb_s], labelNetwork TX (KB/s), colormagenta) ax4.set_ylabel(Network (KB/s)) ax4.set_xlabel(Time) ax4.legend() ax4.set_title(Network Throughput) plt.tight_layout() plt.show()通过这样的图表你可以清晰地看到CPU瓶颈当TPS曲线上升时%usr曲线同步线性上升并最终达到高位平台而TPS不再增长甚至下降。内存瓶颈mem_available_mb持续下降当接近零时swap_si/so开始活动同时avg_response_ms急剧上升。磁盘I/O瓶颈io_await指标飙升同时可能伴随着%util持续高位而TPS和响应时间恶化。网络瓶颈net_rx/tx_kb_s达到网卡带宽上限或tcp_established连接数接近系统端口或应用限制。5.3 进阶集成到Grafana进行实时看板对于长期或复杂的测试可以将监控数据实时写入InfluxDB或Prometheus然后用Grafana制作动态看板。这需要修改监控脚本将采集的数据通过对应客户端的API推送出去而非写入本地文件。这超出了本文基础篇的范围但思路是相通的将采集、传输、存储、展示解耦构建更强大的监控体系。6. 常见问题排查与实战技巧在实际操作中你肯定会遇到各种问题。这里记录一些典型的坑和解决方法。6.1 监控脚本自身资源消耗过高问题运行监控脚本后发现服务器上多了一个CPU占用很高的bash或awk进程。排查使用top -p pid或pidstat -p pid 1观察监控脚本进程的资源消耗。如果采集间隔太短如0.1秒且命令复杂可能会消耗1-2%的CPU。解决适当降低采集频率。对于大多数压测场景1-5秒的间隔足以捕捉趋势。优化Shell脚本。避免在循环内频繁启动新进程。可以考虑将一些命令合并或者使用更高效的工具如用dstat替代多个命令的组合但dstat可能默认不安装。将消耗大的计算如复杂的awk处理移到循环外或使用Python等更高效的语言重写数据采集核心部分。6.2 SSH远程执行命令超时或失败问题控制脚本在执行ssh命令启动远程监控或拉取文件时卡住或报错。排查网络与防火墙确保控制机与目标服务器之间的22端口是通的。SSH配置检查~/.ssh/config或/etc/ssh/ssh_config是否有超时设置。在脚本的ssh命令中增加超时参数ssh -o ConnectTimeout10 -o BatchModeyes userhost command。BatchModeyes可以避免密码提示等交互。命令执行环境远程执行的命令可能因为环境变量如PATH问题找不到。使用绝对路径或者在远程命令中先source /etc/profile。后台进程与终端使用nohup时确保将标准输出和错误重定向如 /dev/null 21否则可能会因为尝试写入不存在的终端而挂起。6.3 监控数据与Jmeter时间戳对不齐问题合并图表时两条曲线的时间轴有偏移关联性看不出来。排查时区问题确保监控脚本和Jmeter运行所在的服务器时区一致。最好都使用UTC时间。在脚本中使用date -u来获取UTC时间。时钟同步确保所有服务器压测机、被压测服务器的时钟通过NTP服务同步。使用date命令检查各机器时间差。采集延迟监控脚本的collect_metrics函数执行需要时间特别是当系统负载很高时命令执行会变慢。这会导致数据点的时间戳比实际采集时刻晚。我们的脚本通过计算SLEEP_TIME进行补偿但无法完全消除。对于要求极端精确的场景可以考虑在命令执行前记录时间戳或者使用内核更底层的追踪工具如/proc文件系统但复杂度会大大增加。对于性能趋势分析秒级的对齐精度通常足够。6.4 磁盘I/O监控不到数据或数据为0问题iostat输出的%util和await一直是0或很低但应用明显感觉慢。排查监控了错误的设备通过lsblk或df -h确认你的应用数据实际写在哪个磁盘或分区上。数据库、日志文件可能在不同的挂载点。监控sda可能没用需要监控sda1,sdb等。缓存Cache效应Linux有强大的Page Cache和Buffer Cache。如果数据读写大部分命中缓存磁盘实际I/O就会很少iostat显示自然很低。此时应关注内存使用情况。可以使用iostat -dxkm 1查看更详细的指标或使用sar -B查看页统计。使用iotop进行进程级定位如果整体磁盘指标不高但应用IO等待长可能是某个进程在频繁进行小文件或随机IO。使用sudo iotop命令可以实时查看每个进程的磁盘读写速率这是定位“元凶”的利器。6.5 网络监控指标单位混淆问题sar -n DEV看到的rxkB/s数值和网卡带宽如千兆网卡125MB/s对不上感觉差了很多。解析这里是最容易混淆的地方。sar命令输出的rxkB/s和txkB/s单位是千字节/秒 (kB/s)注意是小写的k代表1024字节。而网卡带宽通常说的“千兆”1Gbps单位是千兆比特/秒。1 Gbps 1000 Mbps 1000,000,000 bit/s转换为字节/秒 (B/s): 1000,000,000 / 8 125,000,000 B/s ≈ 122,070 KB/s ≈ 119.2 MB/s 所以如果你的rxkB/s显示为 90000那么实际网络速率大约是 90000 KB/s * 8 / 1000 ≈ 720 Mbps已经达到了千兆网卡的70%以上这是一个很高的负载。务必在分析时做好单位换算。
