如何检测 Web 服务请求丢失问题

导读

『StabilityGuide』是阿里多位阿里技术工程师共同发起的稳定性领域的知识库开源项目，涵盖性能压测、故障演练、JVM、应用容器、服务框架、流量调度、监控、诊断等多个技术领域，以更结构化的方式来打造稳定性领域的知识库，欢迎您的加入。

@GitHub :

https://github.com/StabilityMan/StabilityGuide

问题描述

最近偶尔有用户反馈某些 HTTP 接口出现超时问题，而 web 服务端的 Trace 监控没有出现 http 返回值为 503 等异常状况。出现这种状况通常是web容器出现问题，客户端链接不上来。本文将主要介绍如何去监控这类问题。

咱们是用典型的 Web 服务架构，应用经过域名访问到咱们的 LVS（Linux Virtual Server）机器，LVS 后面对应了多台 Web 服务器。

 

考虑到没法对 LVS 进行跟踪，而 Web 服务器（Tomcat 上出现堆积，没法评估影响范围）。考虑再三后，咱们准备在Tomcat 和 LVS 上加一个 Nginx，用于追踪用户访问的真实状况。Nginx 是一款自由、开源的高性能 HTTP 服务器。经过 Nginx 代码，咱们能够掌握第一手的用户访问的真实状况，原本是打算经过 Nginx 的 Access 日志来作统计， 后来参考 阿里云链路追踪的文档，用链路追踪能够把 HTTP 的埋点和 Tomcat 连起来看，能够更详情地发现问题。

 

环境准备和问题复现

编译安装 Nginx 和 Jaeger Agent，具体的安装过程能够参考 阿里云链路追踪文档。

测试环境：须要重现超时问题，写了一个小程序，开启 200 个线程，每一个线程连续向服务发送 500 个请求。总共提交 100000 个请求。

排查过程

排查的主题思路， 对比 Web 服务端数据和 Nginx 服务端的链路统计数据，若是两种的请求数不一致，那能够肯定有请求丢失。再根据链路上的详情数据来肯定丢失请求的缘由。

一、Web 服务端数据统计

发送请求后，发现 web 服务端一共处理 98717 个请求，比客户端少了 1283 个请求。

 

二、Nginx 服务端统计

查看 Nginx 的请求，一共有 100000 个请求，说明 Nginx 收到了所有请求，可是进入到 Web 服务上处理的只有 98717 个请求（经过 javax.servlet.Filter 埋点来监控）。

三、问题分析

检查 Nginx 服务，发现 Nginx 的有些请求的 HTTP 的返回码 499。以下图所示：

 

对比正常的 HTTP 链路，发现 Nginx 的请求的 HTTP 的返回码 499，只有一个 Span 就返回了，而 HTTP 返回码为 200 的，能够看到完整的调用链路(链路上除了 Nginx 的 Span，还有 Web服务的 Span），以下图展现：

 

咱们能够这样来解释这个问题，客户端流量进入 Web 服务器，若是 Web 服务器处理不过来（超出可承受的最大流量或者 Web 服务器自己可能出现 FullGC，OOM，死锁，线程池慢问题）， 那客户端设置超时的请求将会出现 499，未进入 javax.servlet.Filter 处理，Web 服务端看不到任何访问记录。

那是否是能够认为出现 HTTP 返回值为 499 的请求都是服务端处理失败的请求？

四、进一步排查

咱们捞取下 Nginx 上返回 499 的请求，总共 2719条，大于 Web 服务丢失的 1283 个请求。这个数据对不上，是什么缘由呢？咱们在仔细查看了下数据，有 Nginx 返回 499 的请求，可是 Web 服务返回了 200。这些请求进入 Web 服务处理程序，可是 Web 服务还没返回就超时了。若是没有 Tracing 把上下文连接起来，咱们很难经过 Nginx 日志或者 Web 服务日志来解释这个问题（一个请求，Nginx 返回 499，而 Web 服务返回 200），以下图所示：

 

把 Nginx 和 Web 容器服务（Tomcat）的链路打通，咱们能够查看 HTTP 请求每一个环节的状态，很方便地定位问题。

总结

针对这种 Web 服务无响应的问题，能够经过加一层代理（Nginx代码），很好的排查问题。同时也很好统计 Web 服务器形成多少请求失败，影响多少用户。对故障定级，影响面能够进行准确的评估。

 

推荐产品 Tracing Analysis

• 登陆链路追踪控制台，在概览页面上打开 查看 Token 开关。
• 单击须要使用的链路数据采集客户端（Jaeger 或 Zipkin）按钮。
• 在下方表格中相应地域的 相关信息 Trace 列中，单击接入点信息末尾的复制按钮。

提示：若是应用部署于阿里云生产环境，则选择内网接入点，不然选择公网接入点。对于 Zipkin，通常状况下请使用 v2 版接入点，v1 版接入点仅限对 Zipkin 十分了解的高阶用户使用。

本文做者：徐建伟，花名竹影，阿里云技术专家，多年系统架构，性能调优经验， 目前主要从事链路跟踪，应用监控相关工做。

原文连接

本文为云栖社区原创内容，未经容许不得转载。