用Nginx变量构造结构化日志，通过$arg_order_id、$http_x_business_tag等精准标记业务上下文，配合map预判路径、JSON/TSV格式输出、条件日志分流及promtail/Loki等链路实现可统计告警的指标体系。
直接用 Nginx 变量构造带业务语义的日志格式，再配合轻量级日志采集与结构化解析工具，就能把访问日志变成可统计、可告警的业务指标源。关键不在“全量记录”，而在“精准标记”和“字段可计算”。
选对变量：让日志自带业务上下文
基础变量如 $request_uri、$status、$request_time 是通用信息，但业务监控需要更细粒度的标识。例如：
- 用 $arg_order_id 提取订单接口中的 ID，便于后续按订单聚合响应耗时
- 用 $http_x_business_tag（自定义请求头）标记流量来源类型（如 “app_v3”、“h5_promo”），实现渠道维度归因
- 用 map 指令预判业务路径：~^/api/v2/(order|payment)/.* → 设为 $is_payment_flow 1，后续日志中直接带布尔标签
设计结构化格式：方便下游解析
避免空格分隔的 CLF 格式（易被 UA 或 Referer 中的空格破坏），推荐 JSON 格式或固定分隔符。例如：
JSON 示例（兼容 ELK / Loki / Grafana Tempo）：
log_format biz_json '{"time":"$time_iso8601","ip":"$remote_addr","uri":"$uri","status":$status,"rt":$request_time,"tag":"$http_x_business_tag","order_id":"$arg_order_id"}';
TSV 示例（适配 awk / promtail / custom script）：
log_format biz_tsv '$time_iso8601\t$remote_addr\t$uri\t$status\t$request_time\t$http_x_business_tag\t$arg_order_id';
注意：确保所有字段值做基础转义（如双引号、换行符过滤），避免解析错位。
分流写入 + 条件日志：降低分析成本
不是所有请求都需进监控流水线。用 access_log ... if= 实现按需落盘：
- 只记录支付成功回调：access_log /var/log/nginx/payment_success.log biz_json if=$is_payment_success;（配合 map 判断 $status=200 & $uri ~ /callback/pay）
- 只记录慢请求（>1s）：access_log /var/log/nginx/slow.log biz_json if=$is_slow_request;（map 中设 $request_time > 1.0）
- 错误请求单独归集：access_log /var/log/nginx/error_5xx.log biz_json if=$is_5xx;
对接自动化分析链路
日志格式定好后，真正驱动监控的是下游处理逻辑：
- 用 promtail + Loki：配置 pipeline 将 JSON 日志自动提取 labels（如 status、tag），再通过 LogQL 统计每分钟失败率：rate({job="nginx"} |~ `"status":5` [1m])
- 用 Filebeat + Elasticsearch：启用 ingest pipeline 做字段类型映射（如将 $request_time 转为 float），再用 Kibana 创建“各渠道平均响应时间趋势图”
- 用 简单脚本 + Prometheus Pushgateway：每 30 秒 tail 新增日志行，用 awk 解析 biz_tsv，按 tag/status 分组计数，推送到 Pushgateway 暴露为 Prometheus metrics
