背景
请求异常，到底是 istio 流控规则导致，还是业务应用的返回，流量断点出现在哪个具体的 pod？
这是使用 mesh 最常见的困境，在微服务中引入 envoy 作为代理后，当流量访问和预期行为不符时，用户很难快速确定问题是出在哪个环节。客户端收到的异常响应，诸如 403、404、503 或者连接中断等，可能是链路中任一 sidecar 执行流量管控的结果， 但也有可能是来自某个服务的合理逻辑响应。
envoy 流量模型
Envoy 接受请求流量叫做 Downstream，Envoy 发出请求流量叫做Upstream。在处理Downstream 和 Upstream 过程中， 分别会涉及2个流量端点，即请求的发起端和接收端：
在这个过程中， envoy 会根据用户规则，计算出符合条件的转发目的主机集合，这个集合叫做 UPSTREAM_CLUSTER, 并根据负载均衡规则，从这个集合中选择一个 host 作为流量转发的接收端点，这个 host 就是 UPSTREAM_HOST。
以上就是 envoy 请求处理的 流量五元组信息， 这是 envoy 日志里最重要的部分，通过这个五元组我们可以准确的观测流量「从哪里来」和「到哪里去」。
- UPSTREAM_CLUSTER
- DOWNSTREAM_REMOTE_ADDRESS
- DOWNSTREAM_LOCAL_ADDRESS
- UPSTREAM_LOCAL_ADDRESS
- UPSTREAM_HOST
除了以上流量五元组，流量分析中常用的重要信息还有：
- RESPONSE_CODE: 响应状态码
- RESPONSE_FLAGS: 很重要的信息，envoy 中自定义的响应标志位， 可以认为是envoy 附加的流量状态码, 如 如
「NR」表示找不到路由
「UH」表示upstream cluster 中没有健康的 host
「RL」表示触发 rate limit
「UO」触发断路器
RESPONSE_FLAGS 可选值有十几个，这些信息在调试中非常关键。
- X-REQUEST-ID: 一次 C 到 S 的 http 请求，envoy 会在 C 端生产 request id，并附加到 header 中，传递到 S 端，在 2 端的日志中都会记录该值， 因此可以通过这个 ID 关联请求的上下游。注意不要和全链路跟踪中的 trace id 混淆。
- ROUTE_NAME: 匹配执行的路由名称
日志分析示例
image.png通过日志重点观测 2 个信息:
- 断点是在哪里 ？
- 原因是什么？ 示例一：一次正常的 client-server 请求：
image.png示例二：no healthy upstream, 比如目标 deployment 健康副本数为 0
image.png示例三：No route configured , 比如 DestinationRule 缺乏对应的 subset
image.png示例四，Upstream connection failure，比如服务未正常监听端口
image.png
