腾讯云-Istio案例分析: 请求中断分析

背景

请求异常，到底是 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