直接看路径+响应时间+状态码组合可定位性能瓶颈，关键找返回200却异常慢的接口，需用%D（微秒）而非%T（秒级），并结合热度、延迟、失败率三维度分析。
直接看路径 + 响应时间 + 状态码的组合，就能揪出拖慢整体性能的那个“最短木板”。关键不是找错误，而是找那些返回200却慢得反常的接口。
聚焦真实耗时字段：%D 而非 %T
Apache 默认日志不记录微秒级响应时间，必须在 LogFormat 中显式启用 %D（单位：微秒）。%T 是秒级浮点数，精度不够，容易把 1.9s 和 2.1s 都归为“2秒”，掩盖真实瓶颈。
推荐日志格式片段：
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %U" combined-latency
用 awk 快速聚合慢路径（不依赖 ELK）
执行以下命令可提取平均响应超 1.2 秒的前 5 条业务路径：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
awk '$9 ~ /^[2-5]..$/ && $NF > 1200000 {print $11, $NF}' access.log | \awk '{sum[$1]+=$2; cnt[$1]++} END {for (p in sum) if (cnt[p] > 10) print sprintf("%.0f", sum[p]/cnt[p]), p}' | \sort -nr | head -5
说明：
• $9 是状态码（过滤 2xx/4xx/5xx），$NF 是 %D 字段（需按实际位置校准）
• $11 是 %U（路径，不含参数），避免 /user/1 和 /user/2 被拆开统计
• 加了 cnt[p] > 10 过滤低频噪声，只关注有业务意义的慢接口
交叉看三维度：热度 × 延迟 × 失败率
单一平均值会误导。比如一个接口 P99 是 800ms，但每分钟突增 300 次 504，说明它正处在雪崩边缘：
- 高频+高延迟：如
/api/order/create占总请求 22%，平均耗时 1800ms → 优先查该接口的数据库写入、分布式锁或远程 Feign 调用 - 低频+极高延迟：如
/report/daily-summary平均 8s，但每天只调 3 次 → 很可能是未优化的定时报表，不影响主链路，但暴露架构短板 - 延迟陡升时段：用
awk '{print substr($4,2,13)}'提取 “10/May/2026:14:2” 小时段，统计各路径每小时 P95，若每天 14:00–14:15 延迟翻倍 → 指向定时任务资源抢占或批处理作业
穿透到 Java 层验证
日志发现慢路径后，必须落到代码里确认：
- 对照 Spring 的
@RequestMapping("/api/order/create")找到对应 Controller 方法 - 检查该方法是否含：
– 未走索引的慢 SQL（开启 MySQL slow_log 或使用 Arthas trace）
– 同步调用第三方 HTTP 接口且无 fallback（Feign 超时设为 3s？熔断是否生效？）
– 日志打印在循环内、JSON 序列化大对象、未复用 HttpClient 实例 - 在方法入口加
StopWatch分段打点，确认是 DB、RPC 还是序列化环节最耗时
