可通过nginx的$log_sent_http_content_type与$status变量组合日志格式,实现按状态码分组统计响应mime类型分布;需在http块中定义log_format并启用access_log,版本≥1.7.0,再用awk等工具做交叉计数,并注意content-type规范化及状态码语义分析。

可以通过在 Nginx 的 log_format 中直接引用 $sent_http_content_type 变量,并结合状态码变量(如 $status),实现按状态码分组统计响应 MIME 类型的分布情况。
配置日志格式以同时捕获状态码和 Content-Type
Nginx 默认不记录响应头中的 Content-Type,需显式将其纳入自定义日志格式。注意:$sent_http_content_type 是发送给客户端的响应头值(已小写、去空格,如 text/html),若为空则显示为短横线 -。
- 在
http块中定义日志格式,例如:
- 将该格式应用于某个
access_log(如access_log /var/log/nginx/mime.log mime_by_status;) - 确保 Nginx 版本 ≥1.7.0(
$sent_http_*系列变量自此版本稳定支持)
用日志分析工具做多维聚合统计
原始日志是扁平文本,需借助命令行或日志分析工具完成“状态码 × MIME 类型”的交叉计数。
- 使用
awk快速统计(示例):
- 输出类似:
200 text/html 1245、404 application/json 87 - 若需更清晰的表格视图,可配合
column -t或导入到 Excel / Grafana(通过 Loki + Promtail 可实现动态查询)
注意 Content-Type 的规范化与空值处理
$sent_http_content_type 的实际值受后端应用控制,常存在不规范写法(如大小混用、带参数、空值),影响统计准确性。
- 常见非标准值示例:
TEXT/HTML; charset=utf-8、application/json;charset=UTF-8、-(未设置) - 建议在日志采集阶段做预处理:用
sed或 Logstash 过滤掉;.*参数部分,统一转小写,将-替换为unknown - 也可在 Nginx 中用
map指令提前归一化(需搭配perl_set或 Lua 模块,原生 Nginx 不支持正则替换)
结合状态码语义理解 MIME 分布合理性
单纯统计数字不够,需结合 HTTP 状态码含义判断是否异常:
-
2xx响应通常应有明确类型(如text/html、application/json),若大量出现-或application/octet-stream,可能表示静态文件未正确配置types -
304 Not Modified响应理论上不应携带Content-Type(RFC 7232),若日志中频繁出现304 text/plain,说明后端或中间件误设了该头 -
4xx/5xx错误页若返回text/html是正常,但若返回application/json,需确认是否为 API 接口统一错误格式











