Javalite для проекта микросервиса, доступна ли поддержка отслеживания / мониторинга приложений?

#javalite

#javalite

Вопрос:

Я должен использовать Javalite для своего проекта на основе архитектуры микросервиса, поэтому хотел проверить, доступна ли поддержка отслеживания (что-то похожее на / actuator / health amp; / actuator / prometheus в Spring Boot) через какой-либо существующий плагин или какие-либо предложения относительно пользовательских изменений для поддержки того же?

Ответ №1:

У ActiveWeb нет прямой поддержки для этого, но мы регулярно создаем подобные сервисы. «Работоспособность» означает много разных вещей для разных приложений. Мы создали множество корпоративных проектов с использованием JavaLite и на данный момент разработали следующий подход. Обычно у нас есть проект, состоящий из нескольких приложений:

  • Веб-приложение, ориентированное на клиента (Web)
  • Приложение для бэк-офиса для управления учетными записями, отчетности и т.д. (Администратор)
  • API веб-служб (API)
  • Приложение для внутренней обработки (рабочий)

Каждое приложение кластеризовано, поэтому у нас будет несколько экземпляров, и нам нужно знать работоспособность каждого экземпляра. Работоспособность каждого экземпляра определяется:

  1. Текущее свободное пространство кучи
  2. Доступ к базам данных (обычно нескольким)
  3. Доступ к кэшам
  4. Доступ к локальным службам (веб-api, worker и т.д.)
  5. Доступ к NFS
  6. Что еще имеет смысл для этого приложения

Итак … мы реализуем так называемый StatusController для каждого типа приложения. Такой контроллер состояния будет вызывать все службы, одну за другой, необходимые для функционирования этого приложения, когда вызывается его index() метод, и сгенерирует документ JSON с результатами. Если все хорошо, документ JSON прост {"status":"OK", "service1": "OK", "service2": "OK"} или что-то подобное. Если одна из служб недоступна, она генерирует исключение и отвечает файлом JSON, который содержит точное исключение: {"status":"ERROR", "service1": "OK", "service2": "Exception: exception stack trace"} .

Веб-приложение администратора также содержит единую страницу работоспособности, которая объединяет вызовы для всех приложений в кластере и отображает полный отчет, который также имеет цветовую маркировку (зеленый — ОК, красный -Ошибка). Итак, просматривая эту страницу, мы точно знаем, что не так в кластере, если есть проблема.

Однако страница работоспособности администратора также преследует вторую цель. Это веб-сервис, который вызывается Pingdom. Если кластер исправен, эта страница возвращает HTTP-код 200, и если есть хотя бы одна проблема, она вернет 500. Мы используем URL-адрес страницы работоспособности в Pingdom, который отслеживает эту страницу раз в минуту. Всякий раз, когда возникает проблема с какой-либо службой в кластере, StatusController возвращает 500 в Pingdom и отправляет уведомление тому, кто находится на вызове. Когда мы получаем уведомление, мы просматриваем страницу работоспособности для получения информации о том, что не так с кластером.

Мы разработали этот подход много лет назад, и с тех пор он верно служит нам.

Комментарии:

1. Спасибо за предложение @ipolevoy. Изучим это