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

问题描述

近期偶尔有用户反映部分HTTP接口存在超时问题，但通过Trace监控发现网络服务器没有。出现http返回值503等异常。发生这种情况时，通常是 Web 容器出现问题，客户端无法连接。本文将主要介绍如何监控此类问题。

我们使用典型的Web服务架构。应用程序通过以下方式访问我们的LVS（Linux虚拟服务器）机器e 域名. LVS 后面有多个 Web 服务器。

由于无法追踪LVS，以及Web服务器（堆叠了Tomcat），无法评估影响范围。经过深思熟虑，我们准备在Tomcat和LVS中添加Nginx来跟踪用户访问的实际状态。 Nginx 是一个免费、开源、高性能的 HTTP 服务器。通过Nginx代码，我们可以第一手掌握用户访问的真实情况。我们原本打算通过Nginx的Access日志来进行统计。后来我们参考了阿里云的链接追踪文档。我们可以通过链接跟踪来对比HTTP的埋点和Tomcat连接在一起，可以更详细地发现问题。

环境准备及问题复现，编译安装Nginx和Jaeger Agent。具体安装过程请参考阿里云链接跟踪文档。测试环境：为了重现超时问题，我写了一个小程序，启动了200个线程，每个线程连续向服务发送500个请求。总共提交了 100,000 个请求。

排查流程

排查的主题，对比Web服务器数据和Nginx服务器的链接统计，如果两种类型的请求数量不一致，则可以判定有一个请求丢失。然后根据链接上的详细数据判断请求丢失的原因。

1. Web服务器数据统计

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

2. Nginx服务器systemCount

查看Nginx请求，总共有10万个请求，说明Nginx已经收到了所有请求，但是Web服务上只处理了98717个请求（通过javax.servlet.Filter监控）埋点）。

3.问题分析

检查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的请求是服务器无法处理的请求奥塞斯？

4.进一步调查

我们检索了 Nginx 上返回 499 的请求，总共 2719 个，大于 Web 服务丢失的 1283 个请求。这个数据不匹配，为什么？我们仔细查看数据，发现Nginx返回了499个请求，但是Web服务返回了200个。这些请求进入了Web服务处理程序，但是Web服务在返回之前就超时了。如果没有 Tracing 链接上下文，我们很难通过 Nginx 日志或 Web 服务日志来解释这个问题（对于一个请求，Nginx 返回 499，Web 服务返回 200），如下图所示：

Put Nginx 和 Web 容器服务（Tomcat）之间的链接已打开。我们可以检查HTTP请求的各个环节的状态，轻松定位问题所在。

至此，“如何检测Web服务请求丢失”的学习就结束了。希望能够解答大家的疑惑。理论与实践相结合Ice能够更好的帮助大家学习，快去尝试吧！如果您想继续学习更多相关知识，请继续关注网站，小编会继续努力为您带来更多实用文章！