Nginx默认access-log不单独记录接口路径，需自定义log_format使用$uri字段提取解码后无参数的路径，配合精准过滤状态码、UA和路径才能准确统计TOP接口。
Access-Log 默认格式不包含接口路径？
Nginx 默认的 log_format（如 combined）只记录 $request 的完整请求行（例如 GET /api/v1/users?id=123 HTTP/1.1），但没单独剥离出「接口路径」。直接用 awk 或 cut 按空格切分容易被 query string 或特殊字符干扰，导致统计失真。
解决办法是自定义日志格式，显式提取路径：
log_format api_path '$remote_addr - $remote_user [$time_local] '
'"$request_method $uri $http_version" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" $request_time';
注意这里用的是 $uri 而非 $request_uri —— 前者已解码且不含 query string，更适合统计「接口」维度；后者保留原始编码和参数，适合调试但会把 /search?q=a 和 /search?q=b 当作不同接口。
- 在
http或server块中定义该格式，并在access_log中引用：access_log /var/log/nginx/api_access.log api_path; - 重载 Nginx：
nginx -s reload，旧日志不会自动切换格式，需等新请求写入 - 若已有大量
$request_uri日志，可用sed 's/ \?.*$//'粗略截取路径，但遇空格参数（如POST /upload HTTP/1.1后带 body）仍不可靠
用 awk + sort + uniq 统计 TOP 接口时为什么结果不准？
高频接口统计本质是「按路径聚合计数」，但常见命令链 awk '{print $7}' | sort | uniq -c | sort -nr 有三个硬伤：
-
$7是默认combined格式的第七字段，实际对应的是$request整体，不是路径 —— 若未改日志格式，它可能是"GET或/api/v1/users，取决于空格数量，完全不可控 - 未过滤掉健康检查、静态资源、404 等噪音请求，比如
/healthz或/favicon.ico可能冲淡真实业务接口排名 - 未排除爬虫 UA 或恶意扫描（如
User-Agent: sqlmap），它们常高频访问/admin类路径，但不属于正常业务流量
推荐组合命令（假设已启用 api_path 格式）：
$7
- 用
tail -F实时追加新日志，配合awk过滤+计数，再用sort -nr滚动刷新：
NR%100==0
- 简单聚合：用
sed替换数字 ID 段为通配符，例如sed -E 's:/[0-9]+(/|$):/{id}\1:g'，再统计。适用于 ID 规律明确（全数字、固定位置）的场景 - 精准路由映射：在应用层（如 Spring Boot 的 Actuator、或 Gin 的 middleware）注入统一 trace header（如
X-Route-Name: user-get-by-id），然后在 Nginxlog_format中加入$http_x_route_name。这样日志里直接有逻辑接口名，不依赖路径解析 - 注意：正则替换要避开非 ID 字段（如
/v1/2024中的年份），建议先采样验证替换效果
路径泛化本身有信息损失 —— 如果你要定位「哪个用户 ID 被刷得最多」，就必须保留原始 $uri；如果目标只是评估模块负载，那聚合后的逻辑接口名更有意义。别指望一个日志格式同时满足所有分析目标。
