Description
Describe the enhancement:
haproxy.http.request.time_active_ms
and haproxy.tcp.processing_time_ms
were replaced with event.duration
as a part of #10274.
But they are part of a series of timers from the HAProxy standpoint, on the other hand.
HTTP log:
haproxy.http.request.time_wait_ms
(TR)haproxy.total_waiting_time_ms
(Tw)haproxy.connection_wait_time_ms
(Tc)haproxy.http.request.time_wait_without_data_ms
(Tr)haproxy.http.request.time_active_ms
(Ta) <- This is the one.
https://www.haproxy.com/documentation/hapee/latest/onepage/#8.2.3
"Ta" is the time the request remained active in HAProxy, which is the total time in milliseconds elapsed between the first byte of the request was received and the last byte of response was sent. ...
11f9116#diff-0078d1ec55d764408e26baf72301ef6d64ad871b081a95bb148fbbfd4b52c421L4918
Time the request remained active in haproxy, which is the total time in milliseconds elapsed between the first byte of the request was received and the last byte of response was sent.
TCP log:
haproxy.total_waiting_time_ms
(Tw)haproxy.connection_wait_time_ms
(Tc)haproxy.processing_time_ms
(Tt) <- This is the one.
https://www.haproxy.com/documentation/hapee/latest/onepage/#8.2.2
"Tt" is the total time in milliseconds elapsed between the accept and the last close. ...
11f9116#diff-0078d1ec55d764408e26baf72301ef6d64ad871b081a95bb148fbbfd4b52c421L4951
Total time in milliseconds elapsed between the accept and the last close
Describe a specific use case for the enhancement or feature:
- When analyzing/visualizing HAProxy performance, because of the scale difference, users always need to downscale
event.duration
(in nanoseconds) to gethaproxy.http.request.time_active_ms
andhaproxy.tcp.processing_time_ms
(in milliseconds). - Because of the natural expectation that Filebeat extracts all timers in bulk, missing
haproxy.http.request.time_active_ms
andhaproxy.tcp.processing_time_ms
are confusing HAProxy experts.