这篇文章主要介绍“怎么检测Web服务请求丢失问题”，在日常操作中，相信很多人在怎么检测Web服务请求丢失问题问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么检测Web服务请求丢失问题”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：空间域名、网络空间、营销软件、网站建设、双台子网站维护、网站推广。

问题描述

最近偶尔有用户反馈某些 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 服务端的链路统计数据，如果两种的请求数不一致，那可以确定有请求丢失。再根据链路上的详情数据来确定丢失请求的原因。

1、Web 服务端数据统计

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

2、Nginx 服务端统计

查看 Nginx 的请求，一共有 100000 个请求，说明 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），如下图所示：

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

到此，关于“怎么检测Web服务请求丢失问题”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！

当前文章：怎么检测Web服务请求丢失问题
网站网址：http://chengdu.cdxwcx.cn/article/ishjgp.html