Блог

У меня есть приложение tomcat, развернутое на ec2 и за балансировщиком нагрузки приложения. В балансировщике нагрузки также установлен сигнал тревоги для целевого времени отклика, который выглядит следующим образом (скриншот), пороговое значение целевого времени отклика

Теперь в метрике указано, что время отклика не может превышать 1 мс. Но когда я смотрю на диаграмму, есть несколько случаев, когда целевое время отклика превышает 2000 мс в течение непрерывных 5 минут, как показано на рисунке, диаграмма времени отклика

И все же тревога срабатывает только иногда, а не постоянно.

1. Почему тревога не срабатывает почти все время?
2. Может ли кто-нибудь лучше объяснить целевое время отклика, чем объяснение, приведенное на https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html
3. Является ли 1 мс реалистичным целевым временем отклика для измерения, если я вижу, что иногда значения достигают 5000 мс?
4. Я вижу сообщение на рис. 1 «Значение будет преобразовано в соответствие с единицами измерения cloudwatch». И все же в cloudwatch генерируется сигнал тревоги о неработоспособном хосте без сопоставления со значением 1 мс

Я наткнулся на это, когда искал свои собственные проблемы. Я знаю, что это устарело, но я подумал, что должен опубликовать некоторую информацию для других, которые сталкиваются с этим.

Если вы выполните определение журнала доступа ELB для target_processing_time :

 The total time elapsed (in seconds, with millisecond precision) 
from the time the load balancer sent the request to a target 
until the target started to send the response headers.
  

Для Amazon это довольно глупая статистика, и на самом деле она не так уж полезна. Если ваше веб-приложение не буферизовано и сразу выдает заголовки ответов, это значение будет неизменно низким и мало повлияет на вашу реальную производительность.

Лучший способ — отслеживать собственные сроки доставки в своем приложении и публиковать для них пользовательские показатели.