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