如何通过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） 分析阻塞与锁竞争，解释日志中出现的超时与错误聚集。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！