Комментарии 6
Интересное решение.
Скажите пожалуйста, на чем у вас крутятся camel-приложения и как вы мониторите их активность?
Скажите пожалуйста, на чем у вас крутятся camel-приложения и как вы мониторите их активность?
Вообще, у нас несколько подходов к внедрению. В основном мы выкладываемся с использованием deb-пакетов, а сервисы стартуют как отдельный java-процесс или процесс с embedded Jetty. ActiveMQ, как правило, запускается отдельно, а вот Hazelcast мы тоже чаще всего встраиваем в сам сервис.
Мониторинги живости приложений у нас осуществляется внутренней системой, которая с заданной периодичностью осуществляет ряд проверок на живость. Например, проверяет доступность входных REST-ручек и работоспособность маршрутов, посылая в них фейковые сообщения и ожидая ответа на определённой очереди из ActiveMQ. В случае возникновения проблем, мониторинг оповещает всех заинтересованных лиц.
Мониторинг активности мы осуществляем с помощью Graphite, просто отправляем различные метрики в процессе работы туда. А в Graphite уже строим различные наглядные графики, которые выводим на большой телевизор :).
Также существует практика мониторинга очередей ActiveMQ, поскольку если они забиваются, то система утрачивает работоспособность. Это происходит, как правило, если маршруты составлены неверно, либо имеются ошибки в обработчиках сообщений.
Мониторинги живости приложений у нас осуществляется внутренней системой, которая с заданной периодичностью осуществляет ряд проверок на живость. Например, проверяет доступность входных REST-ручек и работоспособность маршрутов, посылая в них фейковые сообщения и ожидая ответа на определённой очереди из ActiveMQ. В случае возникновения проблем, мониторинг оповещает всех заинтересованных лиц.
Мониторинг активности мы осуществляем с помощью Graphite, просто отправляем различные метрики в процессе работы туда. А в Graphite уже строим различные наглядные графики, которые выводим на большой телевизор :).
Также существует практика мониторинга очередей ActiveMQ, поскольку если они забиваются, то система утрачивает работоспособность. Это происходит, как правило, если маршруты составлены неверно, либо имеются ошибки в обработчиках сообщений.
Если падает процесс ActiveMq на одном сервере, разве сообщения из этой очереди не потеряются? Или какая-то репликация на другие сервера есть?
Сообщения, само собой, из очередей этого конкретного инстанса могут потеряться. В наших проектах очереди, как правило, не копятся, поэтому потери данных в случае падения минимальны, что для наших целей допустимо.
Если бы требования к целостности данных были выше можно было бы, например, сделать очереди персистентными и настроить репликацию.
Если бы требования к целостности данных были выше можно было бы, например, сделать очереди персистентными и настроить репликацию.
С этой точки зрения не очень понятно, зачем вам ActiveMq, не легче было запустить процесс с Camel рутом, который бы слушал входящие http сообщения и обрабатывал их асинхронно?
Схема, которую мы используем, довольно универсальна и позволяет охватить широкий спектр задач. ActiveMQ даёт массу преимуществ. В частности позволяет гибко управлять конфигурацией и оперативно подстраиваться к меняющимся требованиям (например, по количеству консьюмеров). Помимо очередей мы используем JMS для обмена данными внутри кластера через топики и для транспорта файлов между нодами. Также важна и её надёжность.
С точки зрения самой технологии, мы не проводили серьёзное исследование насколько ActiveMQ лучше или хуже чем, например, Kafka. Вполне вероятно, что решение с другим брокером нам ты также подошло.
С точки зрения самой технологии, мы не проводили серьёзное исследование насколько ActiveMQ лучше или хуже чем, например, Kafka. Вполне вероятно, что решение с другим брокером нам ты также подошло.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полезные приёмы работы с Apache Camel