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