4. Envoy 访问日志配置:访问日志格式、日志字段(响应时间、上游时间)、日志采样策略
访问日志是延迟诊断的第一手数据源。Envoy 的访问日志不仅记录请求/响应的元数据,还内置了精确到毫秒/微秒的时间戳字段,能够直接反映客户端到 Envoy、Envoy 到上游以及上游处理三个阶段的耗时。本章将围绕日志格式定义、关键延迟字段解析以及采样策略展开,帮助你在生产环境中高效采集延迟数据。
4.1 访问日志格式配置
Envoy 通过 access_log 字段配置日志输出,支持 file(本地文件)、grpc(gRPC 流式上报)和 open_telemetry(OTLP 协议)等输出方式。格式由 format 或 typed_json 定义,推荐使用 typed_json 结构以便下游解析。
📌 生产建议: 使用 JSON 格式而非纯文本,避免字段解析歧义;同时开启
typed_json 以保留数字类型(如延迟字段的毫秒值),方便日志分析系统直接聚合。
4.1.1 基础格式示例(纯文本)
access_log:
- name: envoy.access_loggers.file
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
path: /var/log/envoy/access.log
format: "[%START_TIME%] %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL% %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% %UPSTREAM_HOST% %UPSTREAM_CLUSTER%
4.1.2 推荐 JSON 格式(含延迟字段)
access_log:
- name: envoy.access_loggers.file
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
path: /var/log/envoy/access.json
json_format:
start_time: "%START_TIME%"
method: "%REQ(:METHOD)%"
path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%"
protocol: "%PROTOCOL%"
response_code: "%RESPONSE_CODE%"
response_flags: "%RESPONSE_FLAGS%"
duration_ms: "%DURATION%"
upstream_service_time_ms: "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%"
upstream_host: "%UPSTREAM_HOST%"
upstream_cluster: "%UPSTREAM_CLUSTER%"
request_id: "%REQ(X-REQUEST-ID)%"
bytes_received: "%BYTES_RECEIVED%"
bytes_sent: "%BYTES_SENT%"
4.2 关键延迟字段解析
Envoy 提供了多个与时间相关的日志字段,下表列出延迟诊断中最核心的四个字段及其含义:
| 字段名 | 类型 | 含义 | 延迟诊断用途 |
|---|---|---|---|
%DURATION% |
整数(毫秒) | 从 Envoy 收到完整请求头到发出完整响应头的时间 | 端到端总延迟(客户端感知) |
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% |
整数(毫秒) | 上游服务实际处理时间(Envoy 从发送请求到收到响应头) | 上游处理延迟(排除 Envoy 内部排队/重试) |
%REQUEST_DURATION% |
整数(毫秒) | 从 Envoy 收到完整请求头到发出完整请求体到上游的时间 | 请求传输延迟(客户端→Envoy→上游) |
%RESPONSE_DURATION% |
整数(毫秒) | 从 Envoy 收到上游响应头到发出完整响应体到客户端的时间 | 响应传输延迟(上游→Envoy→客户端) |
💡 延迟计算技巧:
DURATION - upstream_service_time 可估算 Envoy 内部处理耗时(包括连接池等待、重试、过滤器链处理等)。若该差值持续偏高,应优先排查 Envoy 配置或资源瓶颈。
4.3 日志采样策略
全量日志在高 QPS 场景下会产生巨大的磁盘 I/O 和存储成本,且对延迟诊断而言,统计分布比全量记录更有价值。Envoy 支持两种采样方式:
4.3.1 基于 Runtime 的采样(推荐)
通过 access_log_flush_interval 和 access_log_sampling 控制采样率,无需重启 Envoy:
access_log:
- name: envoy.access_loggers.file
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
path: /var/log/envoy/access.json
json_format: { ... }
# 采样率:0.0 ~ 1.0,0.1 表示记录 10% 的请求
sampling_drop: 0.9 # 丢弃 90% 的日志,保留 10%
4.3.2 基于请求属性的条件采样
Envoy 支持通过 filter 对特定请求进行采样,适合只关注错误或高延迟请求的场景:
access_log:
- name: envoy.access_loggers.file
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
path: /var/log/envoy/error_access.log
json_format: { ... }
filter:
status_code_filter:
comparison:
op: GE
value:
default_value: 500
runtime_key: "access_log.error_status"
⚠️ 采样陷阱: 若仅对错误请求采样,会丢失正常请求的延迟基线,导致无法计算 P50/P95/P99 等百分位指标。建议同时保留一份低采样率(如 1%)的全量日志用于延迟分布分析。
4.4 延迟诊断日志流架构
下图展示了一个典型的延迟诊断日志采集链路:Envoy 按采样策略输出 JSON 日志,经 Filebeat/Fluentd 采集后写入 Elasticsearch 或 Loki,最终通过 Grafana 或 Kiali 进行延迟分析。
4.5 采样策略对比与选择
| 策略 | 配置方式 | 适用场景 | 延迟诊断效果 |
|---|---|---|---|
| 全量日志 | sampling_drop: 0.0 |
低 QPS(<1000/s)、调试环境 | 精确到每个请求,但存储成本高 |
| 固定采样率 | sampling_drop: 0.9(保留10%) |
生产环境常规场景 | 可计算 P50/P95/P99,误差可控 |
| 条件采样(错误) | status_code_filter + 低采样全量 |
错误监控 + 延迟基线 | 错误全量 + 正常请求 1% 采样 |
| 自适应采样 | 外部控制器动态调整 runtime key | 大促/高负载自动降级 | 负载高时自动降低采样率 |
📊 推荐实践: 生产环境采用“双层采样”——错误请求全量记录(
status_code_filter),正常请求按 1%~10% 固定采样。这样既能快速定位异常延迟,又能保留延迟分布的整体视图。