是否可以监控HTTP 请求的持续时间？（从负载均衡器收到请求的那一刻起，到负载均衡器将响应返回给客户端的那一刻）
我想在前端监控这个指标，因为我想包括排队时间。如果我测量后端的持续时间，我可能会得到很好的统计数据，但实际性能可能很差（例如，如果请求在负载均衡器本身中排队）。
例如，我想在流量高峰期间监控 Web 应用程序，以确保从用户的角度来看响应仍然很快（例如 < 3 秒）。
小智 5
HAproxy 在日志中提供所有这些信息。
特别是您正在寻找第 6 节，
6 TR '/' Tw '/' Tc '/' Tr '/' Ta* 10/0/30/69/109
在哪里
“TR”是在收到第一个字节后等待来自客户端（不包括正文）的完整 HTTP 请求所花费的总时间（以毫秒为单位）。如果在收到完整请求或收到错误请求之前连接中止，则它可以是“-1”。它应该总是很小，因为一个请求通常可以放在一个数据包中。这里的大时间通常表示客户端和 haproxy 之间的网络问题或手动键入的请求。有关更多详细信息，请参阅下面的“计时器”。
“Tw”是在各个队列中等待所花费的总时间（以毫秒为单位）。如果连接在到达队列之前中止，则它可以是“-1”。有关更多详细信息，请参阅下面的“计时器”。
“Tc”是等待与最终服务器建立连接所花费的总时间（包括重试），以毫秒为单位。如果请求在建立连接之前被中止，它可以是“-1”。有关更多详细信息，请参阅下面的“计时器”。
“Tr”是等待服务器发送完整 HTTP 响应所花费的总时间（以毫秒为单位），不计算数据。如果在收到完整响应之前请求被中止，它可以是“-1”。它通常与服务器对请求的处理时间相匹配，尽管它可能会因客户端发送到服务器的数据量而改变。“GET”请求的大量时间通常表示服务器过载。有关更多详细信息，请参阅下面的“计时器”。
“Ta”是请求在 haproxy 中保持活动的时间，它是从收到请求的第一个字节到发送响应的最后一个字节之间经过的总时间（以毫秒为单位）。它涵盖了除握手（见 Th）和空闲时间（见 Ti）之外的所有可能的处理。有一个例外，如果指定了“option logasap”，则在发出日志时停止计时。在这种情况下，值前会加上一个“+”号，表示最后一个会更大。有关更多详细信息，请参阅下面的“计时器”。
可以通过多种方式将这些指标从日志导出为更有用的格式/后端，想到 Logstash，因为它可以解析这些日志并将它们发送到许多不同的后端