如何通过Ubuntu Tomcat日志进行负载测试 - 问答

用 Ubuntu 上的 Tomcat 日志做负载测试的可行路径

总体思路

明确目标：围绕吞吐量（RPS）、响应时间（p95/p99）、错误率、线程池/连接池利用、JVM GC 行为等指标进行验证。
生成负载：在测试环境用工具对 Tomcat 施加稳定且可重复的并发压力（如 Apache JMeter、wrk）。
采集日志：在压测窗口内完整保留 access_log（请求级别数据）与 catalina.out / localhost.log / GC 日志*（错误与 JVM 行为）。
关联分析：用命令行或 ELK/Grafana 将“日志指标”与“系统资源指标”对齐到同一时间轴，定位瓶颈与回放问题。
迭代验证：调整 JVM/线程池/数据库/缓存 等配置后重复压测，观察日志指标是否按预期改善。

步骤一准备可观测性

访问日志开关：在 server.xml 的 Host 中确保开启 AccessLogValve，示例：

<Valve className="org.apache.catalina.valves.AccessLogValve"
       directory="logs" prefix="access_log" suffix=".log"
       pattern="%h %l %u %t "%r" %s %b %D" />

其中 %D 输出请求处理毫秒数，便于计算 p95/p99。

日志位置与实时查看：Tomcat 日志通常在 /var/log/tomcatX/ 或 /opt/tomcat/logs/；用 tail -f catalina.out 实时观察异常与 GC 线索。
GC 日志：在 JAVA_OPTS 中开启（建议仅在测试环境开启），便于从日志侧观察停顿与回收压力：
```
-Xlog:gc*,gc+heap=debug:file=/opt/tomcat/logs/gc.log:time,tags:filecount=5,filesize=50M
```
资源与 JMX（可选）：用 top/htop/vmstat/iostat 观察 CPU/内存/IO；通过 JMX 获取更细的线程、内存与类加载信息，辅助解释日志现象。

步骤二生成负载

轻量 HTTP 基准：使用 wrk 快速验证并发能力与延迟分布
```
wrk -t12 -c100 -d30s http://<Tomcat_IP>:8080/app/test
```
含义：12 线程、100 并发连接、持续 30 秒。
功能与复杂场景：使用 Apache JMeter 创建线程组（并发用户、Ramp-up、循环），添加 HTTP 请求采样器 与 聚合报告/响应时间图 监听器，便于导出吞吐、错误率与分位响应时间。
运行规范：在非生产环境执行，控制并发与持续时间，避免对线上造成影响；压测期间保持日志与资源监控开启。

步骤三用日志计算关键指标

吞吐量 RPS：统计单位时间请求数

# 以 1 分钟窗口计算
awk -F' ' '{ts=$4; gsub(/\[|\]/,"",ts); if(ts>=start && ts<end) count++; }
    END { print "RPS=" count/60 }' access_log

响应时间 p95/p99：基于 %D（毫秒）

awk -F' ' '{t=$NF} END { n=asort(t); print "p95="t[int(n*0.95)], "ms"; print "p99="t[int(n*0.99)], "ms" }' access_log

错误率：统计 HTTP 状态码 >= 400

awk '$9 ~ /^[4-5][0-9][0-9]$/ {err++; total++} END { print "Errors=" err, "Total=" total, "ErrorRate=" err/total*100 "%" }' access_log

峰值并发估算（近似）：按请求到达时间排序，计算同一时刻“未完成请求”的最大数量

awk -F' ' '{
  gsub(/\[|\]/,"",$4); split($4, a, ":"); t=a[2]*3600+a[3]*60+a[4];
  start[t]++; end[t+$NF/1000]++
}
END {
  cur=0; peak=0;
  for(i in start) { cur+=start[i]-end[i]; if(cur>peak) peak=cur }
  print "PeakConc(approx)=" peak
}' access_log

日志侧异常线索：grep -i "ERROR\|Exception" catalina.out；grep -i "OutOfMemory\|GC overhead" catalina.out；tail -f catalina.out 观察运行期异常与 Full GC 迹象。

步骤四可视化与瓶颈定位

集中化与可视化：用 ELK（Elasticsearch + Logstash + Kibana） 或 Grafana + Loki/Prometheus 将 access_log/catalina.out/GC 日志 统一采集、解析与展示，构建RPS、p95/p99、错误率、线程池利用等仪表盘，便于对比不同压测场景。
关联资源曲线：将日志指标与 CPU、内存、磁盘 IO、网络 曲线对齐（如 top/htop/vmstat/iostat/iftop），识别是应用逻辑、数据库/缓存、线程池/连接池还是系统资源导致的劣化。
深入诊断（可选）：开启 JMX 结合 VisualVM/JMC 观察线程、内存与热点方法；必要时采集 线程转储（jstack） 分析阻塞与锁竞争，解释日志中出现的超时与错误聚集。

0 赞

0 踩