Я управляю веб-службой, и для моей компании очень важно обнаруживать и уведомлять, если какая-либо из служб не работает, а также если какая-либо из выполняемых ею операций требует слишком много времени для ответа. До сих пор существовало отдельное веб-приложение (включая интерфейсное и внутреннее) только для запроса случайных операций к этим конечным точкам каждые 15 минут, но я нашел его запутанным, поскольку для этого требуется поддержка всего веб-приложения, и я знаю много бесплатных веб-сервисов. это должно сделать работу.
Я установил AWS Healthchecks для замены веб-приложения для опроса и отлично работает для части времени безотказной работы, теперь мой вопрос касается части времени ответа.
Все эти службы проверки работоспособности API, похоже, готовы к не очень сложным запросам, поэтому API должен отвечать за предоставление конечной точки «статуса» для служб проверки работоспособности и включение в эти «ОК» таких вещей, как задержка базы данных, или должна быть «проверка работоспособности». "ответственный за выполнение сложных запросов? Какой подход более правильный?
Спасибо!
Вероятно, вам не следует контролировать производительность базы данных через пути проверки работоспособности приложения - могут возникнуть некоторые опасные случаи. Допустим, вы используете ASG в AWS и используете проверки работоспособности LB, чтобы определить, следует ли ASG чередовать машины. Если у вас возникнет конфликт базы данных (не связанный с вашим приложением), ваша ASG начнет удалять узлы. Таким образом, у вас будет не только плохо работающая база данных, но и исчерпанная ASG.
Как правило, производительность следует контролировать вне диапазона работоспособности. Мы активно используем statsd и накачиваем в него все наши показатели, приложение и базу данных, чтобы мы могли строить графики и предупреждать на их основе.
Также имейте в виду, что по мере масштабирования скорость вашей проверки работоспособности также будет увеличиваться - у нас есть некоторые службы, которые получают тысячи запросов на проверку работоспособности в секунду, и если каждый из них выполняет синтетический дорогостоящий запрос, наш уровень данных перейдет в автономный режим. .
Логика также становится более сложной по мере добавления слоев кеширования - что должна возвращать конечная точка проверки работоспособности, если база данных исправна, а ваш кеш KV - нет?
В целом, хотя сквозной мониторинг имеет решающее значение для эффективной стратегии мониторинга, я настоятельно рекомендую внешний мониторинг существующих метрик запросов, которые поступают в базу данных - они являются репрезентативными для реальной производительности пользователя и предоставят вам количественные метрики для как на самом деле работает ваше приложение.