Можно ли контролировать продолжительность HTTP-запросов? (с момента получения запроса балансировщиком нагрузки до момента, когда балансировщик нагрузки возвращает ответ клиенту)
Я хотел бы отслеживать эту метрику в веб-интерфейсе, потому что я хочу включить время очереди. Если я измерю продолжительность бэкэнда, я могу получить хорошую статистику, но реальная производительность может быть плохой (например, если запрос помещается в очередь в самом балансировщике нагрузки).
Например, я хотел бы отслеживать веб-приложение во время всплесков трафика, чтобы убедиться, что ответы по-прежнему быстрые с точки зрения пользователя (например, <3 секунд).
HAproxy предлагает всю эту информацию в журналах.
видеть Формат журнала Haproxy HTTP
В частности, вы ищете раздел № 6,
6 TR '/' Tw '/' Tc '/' Tr '/' Ta * 30/10/69/109
где
«TR» - это общее время в миллисекундах, затраченное на ожидание полного HTTP-запроса от клиента (не считая тела) после получения первого байта. Может иметь значение «-1», если соединение было прервано до того, как можно было получить полный запрос или был получен неверный запрос. Он всегда должен быть очень маленьким, потому что запрос обычно помещается в один пакет. Большое время здесь обычно указывает на сетевые проблемы между клиентом и haproxy или запросы, вводимые вручную. См. «Таймеры» ниже для более подробной информации.
«Tw» - это общее время ожидания в различных очередях в миллисекундах. Может иметь значение «-1», если соединение было прервано до попадания в очередь. См. «Таймеры» ниже для более подробной информации.
«Tc» - это общее время в миллисекундах, затраченное на ожидание установления соединения с конечным сервером, включая повторные попытки. Может иметь значение «-1», если запрос был прерван до установления соединения. См. «Таймеры» ниже для более подробной информации.
«Tr» - это общее время в миллисекундах, затраченное на ожидание отправки сервером полного ответа HTTP, не считая данных. Может иметь значение «-1», если запрос был прерван до получения полного ответа. Обычно оно соответствует времени обработки запроса сервером, хотя оно может изменяться в зависимости от объема данных, отправленных клиентом на сервер. Большое количество запросов GET обычно указывает на перегруженный сервер. См. «Таймеры» ниже для более подробной информации.
«Ta» - это время, в течение которого запрос оставался активным в haproxy, то есть общее время в миллисекундах, прошедшее между получением первого байта запроса и отправкой последнего байта ответа. Он охватывает всю возможную обработку, кроме квитирования (см. Th) и времени простоя (см. Ti). Есть одно исключение: если была указана опция «logasap», то отсчет времени останавливается в момент отправки журнала. В этом случае перед значением добавляется знак «+», указывающий, что последний будет больше. См. «Таймеры» ниже для более подробной информации.
Экспорт этих показателей из журналов в более удобный формат / бэкэнд может быть выполнен разными способами, на ум приходит Logstash, поскольку он может анализировать эти журналы и отправлять их во множество различных бэкэндов.