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 进行延迟分析。

Envoy 延迟诊断日志流架构 客户端 Envoy 网关 采样策略 + JSON 日志 上游服务 请求 转发 访问日志文件 /var/log/envoy/access.json 写入 Filebeat 日志采集 Elasticsearch 延迟索引 Grafana 延迟仪表盘 关键延迟字段 DURATION UPSTREAM_SERVICE_TIME REQUEST/RESPONSE_DURATION

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% 固定采样。这样既能快速定位异常延迟,又能保留延迟分布的整体视图。