我们使用Kubernetes和Nginx入口控制器来运行我们的平台和各种后端服务。我们还使用新遗迹（&普罗米修斯，格拉法纳）为我们的可观测性 Jmeter 盘和警报。Nginx入口控制器是我们所有请求的入口点。
当我们不断收到请求时，如果后端服务的所有线程都很忙碌，那么我假设请求开始排队，并且随着线程/资源开始释放，它们最终得到了服务。
目前，我无法找到一个指标，该指标将给予我提供请求在被Nginx获取并最终由我们的后端提供服务之前等待的时间量。
Nginx入口控制器Prometheus度量包含以下4个延迟度量：
nginx_ingress_controller_request_duration_seconds（nginx变量：request_time）的数据nginx_ingress_controller_response_duration_seconds（nginx变量：upstream_response_time）的最大值nginx_ingress_controller_connect_duration_seconds（nginx变量：upstream_connect_time）的数据nginx_ingress_controller_header_duration_seconds（nginx变量：upstream_header_time）的数据
在绘制这些指标并尝试各种负载测试时，我发现所有这些指标都给出了请求被Nginx获取后的延迟，但似乎没有一个指标包括请求被Nginx获取前的等待时间。
我正在寻找以下问题的答案：
upstream_connect_time是否包括请求的等待时间（在被Nginx拾取之前）？- 以上4个指标中是否有任何一个包括请求的等待时间（在被Nginx拾取之前）？
- 我在这里提到的
ngx_http_upstream_module中发现了一个名为upstream_queue_time的变量。此指标是否给予了请求的等待时间（在Nginx拾取请求之前）？如果是，这是否仅适用于Nginx Plus？我可以使用哪个指标？ - 有没有其他方法可以让我了解请求的等待时间（在被Nginx选中之前）？
如果我的上述理解有误，请告知。
你的时间和专业知识，在回答这一点是真的很感激。谢谢你，我很好
1条答案
按热度按时间ovfsdjhp1#
据我所知，根据Nginx中的
epoll模型及其asynchronous/non-blocking性质，Nginx不会等待请求被拾取。有请求进来，Nginx会处理，会立即转移到上游，如果无法立即选择上游服务器，则会放入上游队列。它在队列中花费的时间在ngx_http_upstream_module中的$variable
upstream_queue_time中定义，如您所见。其他4个典型的内置定时变量如下：
*$request_time-完整请求时间，从NGINX从客户端读取第一个字节开始，到NGINX发送响应体的最后一个字节结束
*$upstream_connect_time-与上游服务器建立连接所花费的时间
*$upstream_header_time-从建立到上游服务器的连接到接收到响应头的第一个字节之间的时间
*$upstream_response_time-从建立到上游服务器的连接到接收到响应正文的最后一个字节之间的时间
回答您的问题：
upstream_connect_time是否包含请求的等待时间（在被Nginx拾取之前）？
不，我不知道
以上4个指标中是否有任何一个包括请求的等待时间（在被Nginx拾取之前）？
是的。$request_time涵盖了从请求进入到响应发出的所有时间。
我在这里提到的ngx_http_upstream_module中发现了一个名为upstream_queue_time的变量。此指标是否给予了请求的等待时间（在Nginx拾取请求之前）？如果是，这是否仅适用于Nginx Plus？我可以使用哪个指标？
该指标给出了请求在上行队列中的等待时间。
有没有其他方法可以让我了解请求的等待时间（在被Nginx选中之前）？
通常情况下，我们只需要减去Nginx的处理时间（入站+出站）（$request_time-$upstream_response_time）
如果我说错了请纠正我。