基于耗时的异步化日志采样是通过Nginx的map指令结合$request_time变量对请求按耗时分级（如full/sample/skip），再用多条access_log指令绑定不同条件与缓冲参数，实现慢请求全量记录、快请求抽样或丢弃的日志策略。
什么是基于耗时的异步化日志采样？
在高并发场景下，全量记录 access 日志会带来 I/O 压力和存储成本。但完全关闭又丢失关键排障信息。折中方案是：只对“慢请求”（如耗时 >500ms）或“异常耗时区间”做完整日志记录，而对快请求按比例抽样（如 1%），甚至不记。Nginx 自身不支持运行时耗时判断写日志，但可通过 map + $request_time 配合自定义日志格式与多 log 指令，实现“分级打点、异步落盘”的效果——本质是把不同耗时区间的请求分发到不同 access_log 指令，再由各指令绑定独立的 buffer / flush / gzip 等参数，达到逻辑上的“异步化采样”。
核心配置结构：用 map 分流耗时区间
先定义一个基于 $request_time 的映射变量，将请求按毫秒级耗时划分为多个等级，每个等级对应一个日志级别标识（如 full / sample / skip）：
注意：$request_time 是 Nginx 变量，单位为秒，精度为毫秒（如 0.423 表示 423ms），需用浮点比较。
map $request_time $log_level {
default skip;
~^[0-9]*\.[0-5][0-9]{2}$ sample; # 0.000–0.599s → 抽样
~^[0-9]*\.[6-9][0-9]{2}$ full; # 0.600–0.999s → 全量
~^[1-9][0-9]*\.[0-9]{3}$ full; # ≥1.000s → 全量
}
说明：
- 正则匹配比 numeric 比较更可靠（Nginx map 不支持 >= 运算）；
- 使用 ~^ 表示正则开头匹配，避免误判（如 10.5 匹配到 0.5）；
- 可按需扩展更多区间，例如增加 debug（>5s）单独输出到 error.log 风格日志。
绑定多路日志：让不同 level 走不同 access_log 指令
Nginx 不允许在 if 中写 access_log，但支持 access_log 指令的条件开关（通过变量值控制是否启用该行）。只需为每个 level 定义一条 access_log，并用 if= 参数绑定变量：
-
全量日志：写入
/var/log/nginx/slow.log，开启 buffer 和 flush，兼顾性能与可靠性 -
抽样日志：写入
/var/log/nginx/sample.log，buffer 更大、flush 间隔更长，降低刷盘频次 -
跳过日志：不显式写任何内容，或指向
/dev/null（仅占位）
配置示例：
log_format full '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time $pipe';
<p>log_format sample '$remote_addr $request_time $status $uri';</p><p>access_log /var/log/nginx/slow.log full if=$full_condition;
access_log /var/log/nginx/sample.log sample if=$sample_condition;
access_log /dev/null combined if=$skip_condition;</p><h1>在 server 或 location 块中动态生成条件变量：</h1><p>set $full_condition "";
set $sample_condition "";
set $skip_condition "";</p><p>if ($log_level = "full") { set $full_condition "1"; }
if ($log_level = "sample") { set $sample_condition "1"; }
if ($log_level = "skip") { set $skip_condition "1"; }
⚠️ 注意：if 在 location 外使用有局限，推荐将上述 set + if 放入 location {} 内；且 Nginx 官方不推荐大量使用 if，此处仅用于轻量条件赋值，影响可控。
增强实用性：配合 logrotate 与下游采集器
该策略真正落地需配套运维机制：
- logrotate 需区分 slow.log 和 sample.log：slow.log 更重要，建议 daily + compress + delaycompress；sample.log 可 weekly + missingok
- 下游采集（如 filebeat / fluent-bit）应设置不同 pipeline：slow.log 启用 full JSON 解析 + 实时告警；sample.log 可聚合统计 QPS/耗时分布，不进实时链路
-
验证是否生效？ 用 ab / wrk 发起不同延迟请求（如 sleep 1s 的 upstream），再检查对应日志文件是否有新增条目，同时
tail -f /var/log/nginx/*.log观察分流效果
不复杂但容易忽略：$request_time 在日志写入时才最终确定，所以 map + if 组合能真实反映本次请求耗时，无需额外模块或 Lua。
