日志分析如何统计接口访问的平均耗时与 P99

统计接口平均耗时和P99需先确认日志中存在结构化耗时字段（如Nginx的$request_time、Spring Boot的elapsedMs），再通过命令行快速验证或ELK/Prometheus等工具做稳定聚合，同时注意排除异常请求、按接口粒度分组、对齐时间窗口。

统计接口访问的平均耗时和 P99（即 99% 的请求耗时低于该值），核心在于从日志中准确提取耗时字段，并做数值聚合。关键不是“有没有日志”，而是“日志里有没有结构化耗时字段”以及“能否高效清洗和计算”。

确认日志中存在可提取的耗时字段

多数现代服务（如 Nginx、Spring Boot、APISIX、OpenResty）会在日志中记录响应时间，但格式各异：

1. Nginx 常用 $request_time（单位：秒，精度毫秒级，如 0.123）或 $upstream_response_time
2. Spring Boot + Logback 可通过 %X{elapsed} 或自定义 MDC 字段输出毫秒数（如 "elapsedMs":147）
3. 务必检查单条日志样例，确认耗时是纯数字（推荐毫秒整数或秒浮点），避免混入单位、括号或缺失值

用命令行快速验证与粗算（适合临时分析）

假设日志每行含毫秒耗时，如 ... "elapsedMs":286 ...，可用以下组合快速提取并计算：

1. 提取所有耗时：grep -o '"elapsedMs":[0-9]+' access.log | cut -d: -f2
2. 算平均值：... | awk '{sum += $1; n++} END {printf "%.2f msn", sum/n}'
3. 算 P99（需排序取第 99 百分位）：... | sort -n | awk -v n=$(wc -l) 'NR == int(0.99 * n) {print $1}'（注意：实际需处理边界，更稳可用 awk 脚本或 datamash）

用专业工具做稳定统计（推荐生产环境）

手动脚本难应对大日志量、多服务、实时性要求。建议：

1. ELK Stack（Elasticsearch + Logstash + Kibana）：Logstash 解析耗时字段为 numeric 类型，ES 用 avg 和 percentiles 聚合（P99 对应 "percents": [99]），Kibana 可视化看板一键展示
2. Prometheus + Grafana：不直接解析日志，而是让应用暴露 http_request_duration_seconds_bucket 等直方图指标，Grafana 用 histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[1h])) by (le)) 算 P99
3. ClickHouse / Loki + Promtail + Grafana：Loki 支持 LogQL 查询（rate({job="api"} |~ `"elapsedMs":[0-9]+` [1h])），但 P99 需配合 quantile_over_time 或导出后计算；ClickHouse 更适合原始日志建表后用 quantile(0.99)(elapsed_ms)

注意事项：避免常见偏差

统计结果失真往往不是计算错，而是数据源或口径问题：

1. 排除超时/异常请求：如 5xx 或耗时 >30s 的请求是否参与统计？业务上通常要单独看，而非混入 P99
2. 区分接口粒度：确保按 path 或 endpoint 分组再算，否则 /login 和 /health 的耗时会互相掩盖
3. 时间窗口对齐：P99 对窗口敏感，1 分钟窗口和 1 小时窗口结果差异可能很大，需明确业务 SLA 对应的时间粒度（如“近 5 分钟 P99
4. 采样影响：若日志已采样（如只记录 1% 请求），P99 会严重低估，务必确认是否全量落盘