KubeCon2023：基于实际案例解析Istio访问日志ResponseFlag系列

记录在2023年9月27日在上海Kubecon上发表的技术演讲《Detailed Parse and Reproduce Response Flags of Istio Access Log Based on Production Use Case 》

议题：

服务网格的访问日志在运维工作中发挥着非常关键的作用。特别是访问日志在HTTP响应码外提供应答标记Response Flags，通过针对性的标记提供有用的额外信息，帮助运维人员提高故障诊断的效率。但是Envoy社区官方文档中对应答标记的介绍非常简单，Istio社区也没有资料介绍这部分内容。在实际使用中当用户遇到包含DC、UF、UH等应答标记的日志时，很难找到权威材料参考来解决具体问题。 在本次演讲中，超盟将重现10多种生产中常碰到的应答标记的实践案例，解析每个标记的含义、产生场景，并介绍如何基于这些应答标记进行故障诊断和问题定界，进而解决案例中这些应答标记表示的问题。此外，还将解析生产用例中访问日志的6个有用的时间字段的含义，并介绍如何基于这些时间字段定界服务网格的延时相关问题。

Access logs of service mesh is practically important in ops work. Especially, Response Flags in each log help improve fault diagnosis efficiency by providing additional details of request. But the simple and brief definition of Response Flags in Envoy and Istio community makes it hard to refer to it to effectively find the real problem and root cause when running into logs containing “DC, UF, UH” like flags in practice. In this session, Chaomeng will introduce how Istio Access Log promote fault diagnosis efficiency in micro service Ops practice. He will reproduce 10+ different Response Flags cases of customer’s practice, analyze what each flags indicates and when such logs generated, and demonstrate how to perform fault diagnosis and problem demarcation based on the Flags, and how to solve the problem of each case. Additionally he will parse the meaning of 6 useful time information of access log, and introduce how to figure out the most time-consuming period.

背景：

访问日志是应用系统运维的重要手段，可以有效地帮助我们进行问题的定位定界。

在服务网格中，访问日志也是可观测性能力的一块重要内容。不同于指标提供访问的统计信息，访问日志记录了每一次访问的详细信息。不管是作为安全审计，还是做系统运维，访问日志都是最得力的手段。

访问日志记录了每次访问的时间、请求、应答、耗时、源服务和目标服务等信息。帮助运维人员进行有效的故障定位定界。生产中我们也经常会检索分析一批日志看特点，如是否慢的请求的应答体都比较大，来自某个特定服务的服务接口总出错，或者来自某个特定源服务的访问不正常等，帮助我们发现系统问题。

对于七层的访问日志一般我们会通过HTTP响应码了解请求的状况，如503、502、404、403等。Envoy在访问日志中引入了应答标记Response Flag，辅助HTTP响应码，进一步描述访问或连接的细节问题。如发生 了503错误后，通过503 UH、 503 UF、 503 UC、 503 NC 等区分各种不同的503产生的原因，提供线索让运维人员针对性地解决问题。

但是Envoy 和Istio社区的访问日志对于Response Flag的信息非常少，所有的内容也只是如下非常干巴的把组合的单词展开，没有解释清楚每个标记的含义，更没有说明哪种情况下会出现这个标记。身边的同事，还有我们的客户经常在生产中碰到了这些应Response Flag不知道如何处理。有客户的工程师反馈说，看到了Response Code里那几个奇怪UC、UH等字符比看见503还让人抓狂。

在日常支持客户各种环境的过程中，留意积累各种异常场景对应的Response Code，在内部给组内容同事做过一些小范围的分享，正好今年上海的KubeCon 2023，就尝试报了个相关议题做了个实践类的分享。

内容：

话说故障随时随地都可能发生，在这个时间点Wednesday September 27, 2023 3:50pm - 4:25pm CST，这个会议室3层 305B会议室| 3F Room 305B，在我的演讲开始前，我的笔记本接到现场的投影仪上，组织方的投影出了问题。换了现场其他的笔记本，组织方的两个外国工程师在笔记本上一顿设置，趴在地上对投影仪一顿设置，还是不行。最后只能短路了一些信号，只是最基础的现场录像。当时就感叹如果有一个像网格的Response Flag一样明确地标识出故障类型，现场的两个老哥了解到链路上的笔记本、投影仪、亦或其他组件有问题，就能快速修复，不用耽误现场那么多人的十几分钟时间，当然我也能避免尬在台上近距离围观一个问题定位过程。

在准备的这个演讲中比较详细地把我在生产中碰到的常见的Response Flag挨个构造条件重现一遍，剖析每个Flag的具体含义，不是Envoy官方文档的一行半精简文字；每个Flag表示的问题，当然构造的时候挑纯粹简单场景构造，但是能代表一类问题；对这些问题一般的处理方法，有些是故障的有针对性的处理，有些只是访问细节表达、网格配置内容体现的自然无需处理。作为参照帮助听众理解和解决生产中的类似问题。

会场现场大家反馈比较好，提问提的拖堂了不少，会场组织方的美眉一直提醒。John zheng特别过来说比我昨天刚在IstioCon上讲的另外一个关于Istio 安全的内容还要干货，有内容。谢谢John，刚才会议现场投影不可用，怀疑笔记本问题时，你借笔记本给我用，只是抱歉会后你强烈建议后面报个北美或欧洲的议题把这部分做个更大范围的分享，觉得麻烦没有积极回应。

前阵子家里有点事情，这个议题准备主要也是把工作中的点总结了下，没有顾上好好去规划评估内容和讲出来要花的时间，导致现场讲下来太干，内容太多。本来说话就很快，为了完成内容不得不更快，特别是看到后面组织方美眉一个劲的举牌子提示时间。导致有些内容比较粗的就过了下。想想也是，在规划的25分钟的时间里硬塞进了14个不算简单的实践，尽管硬拖堂讲了40分钟，还是讲的比较粗。

会后现场、微信群和YouTube下有听众要材料，感动于大家的认可和热情，在把PPT传到官方后，决定把PPT里的每个Slide的实践稍微展开描述性，也算对得起演讲标题的重现案例的说法。

下面是演讲中提到的每种Response Flag分别独立一个材料描述了下，这里汇总一个列表。

• 00：正常访问

• 01：下游连接终止 DC (DownstreamConnectionTermination)

• 02：上游服务没有健康的后端实例 UH (NoHealthyUpstream)

• 03：上游连接失败 UF (UpstreamConnectionFailure)

• 04：上游超过重试次数 URX (UpstreamRetryLimitExceded)

• 05：上游服务协议错误 UPE (UpstreamProtocolError)

• 06：下游服务协议错误 DPE (DownstreamProtocolError)

• 07：上游集群不存在 NC (NoClusterFound)

• 08：没有匹配的路由NR (NoRouteFound)

• 09：注入延时故障DI(DelayInjected)

• 10：注入错误故障FI(FaultInjected)

• 11：上游请求超时UT(UpstreamRequestTimeout)

• 12：上游连接中断UC(UpstreamConnectionTermination)

• 13：服务限流RL(RateLimited) 重现服务端限流

• 14：服务限流RL(RateLimited) 重现客户端限流

附：

• 演讲材料(官方Slides)
• Video(YouTube)
• 视频(国内)
• 视频(国内)
• 官方Sched主页