【Envoy 数据面】可观测数据面：Stats、Access Log、Tracing 与请求路径耦合
内容提要
本文介绍Envoy数据面可观测性，聚焦stats、access log和tracing三种信号。它们都耦合在请求路径上，分别擅长聚合告警、单请求失败分类和跨跳相关。排障时按admin统计树前缀（listener/http/cluster/server）缩小范围，用RESPONSE_FLAGS定位失败原因，tracing需业务传播上下文。强调ACK配置不等于根因已解释，需结合机制篇和排障清单。
延伸解读
信号与路径耦合：排障先定层
Stats、access log 和 tracing 都挂在请求路径上，分别对应聚合告警、单请求失败分类和跨跳相关。排障时，先通过 admin 统计树按 listener/http/cluster/server 前缀缩小范围，再结合 downstream 与 upstream 结果码对比，判断问题出在入口、路由还是上游池。这种分层定位思路比只看整体 5xx 更有效。
RESPONSE_FLAGS：单请求失败的关键线索
Access log 中的 RESPONSE_FLAGS 字段能标记本地失败类型，如无健康上游、超时、重置等，是定位单请求失败的重要入口。但 access log 在请求结束后才输出，高 QPS 下需配合采样或过滤，否则存储和 CPU 成本高。同时，它不能单独证明控制面已 ACK 的配置对所有 Worker 生效，需结合 config_dump 和 warming 状态。
Tracing 的边界：上下文传播与采样
Tracing 依赖业务传播 trace header 或 x-request-id，否则链路会断。默认采样意味着 not_traceable 计数上升不等于错误率上升。Envoy 的 span 描述的是代理跳的元数据，而非应用内部函数栈。排障时，用 x-request-id 将 access log 的失败分类与 tracing 的跨跳火焰关联，但不要期望 tracing 覆盖每一次请求。
Q&A
Envoy 数据面的可观测性信号有哪些？它们各自的主要用途是什么？
Envoy 数据面的可观测性信号主要有三种：Stats（统计）、Access log（访问日志）和 Tracing（追踪）。Stats 用于聚合告警、容量和趋势分析；Access log 用于单请求的事后复盘和失败分类；Tracing 用于跨跳延迟和父子关系的关联。
Envoy 的 Stats 分为哪几类？分别对应什么？
Envoy 的 Stats 分为 Downstream、Upstream 和 Server 三类。Downstream 对应入口侧，包括 listener、HCM、TCP Proxy 上的连接/请求计数和延迟直方图；Upstream 对应出口侧，包括连接池、Router、上游请求时间和结果码；Server 是进程级指标，如 uptime、内存、热重启代数等。
如何通过 Admin 统计树快速定位 Envoy 问题？
通过 Admin 的 /stats 接口（支持 format=prometheus）导出分层点分名，按前缀缩小范围。例如：listener.<name>. 检查连接接收和 listener 更新；http.<stat_prefix>. 查看 HCM 请求量、响应码类等；cluster.<name>. 检查上游健康、连接池、熔断溢出；server. 查看进程存活、内存、热重启世代；runtime. 检查运行时开关。
Access log 中哪些字段对排障最有用？
Access log 中排障最常用的字段包括：RESPONSE_FLAGS（本地失败分类，如无健康上游、超时、重置等）、DURATION 与 upstream service time（区分代理内耗时和上游耗时）、UPSTREAM_HOST / cluster（最终选中的上游）、X-REQUEST-ID（与 tracing 和应用日志对齐的钥匙）。
Envoy 的 Tracing 有什么特点？为什么需要业务传播上下文？
Envoy 的 Tracing 默认采样，通过 HCM 配置，支持多种 provider（如 Zipkin、Jaeger、Datadog 等）。它需要业务传播上下文，因为如果中间应用不转发 trace header 或 x-request-id，链路会断。Envoy 生成的 span 描述的是代理跳上的 HTTP/gRPC 元数据，不是应用内部函数栈。
当遇到 5xx 错误时，应该优先查看哪些信号？
当遇到 5xx 错误时，优先查看 cluster.* 和 http.* 的 stats，以确定是哪一层的问题。如果不够，再结合 access log 的 RESPONSE_FLAGS 来定位单次请求的失败原因。
为什么说 ACK 配置不等于根因已解释？
因为 ACK 配置只表示控制面已确认配置，但观测信号（如 stats、access log）可能无法解释根因。例如，warming 状态、证书问题、池耗尽等需要结合机制篇和排障清单（如第 15 篇）来进一步分析。
