Статьи

Мониторинг приложений Camel в облаке

Apache Camel — это швейцарский армейский нож для интеграции приложений. Если ваше приложение обрабатывает данные из разных систем, рано или поздно вам придется использовать некоторые из 130 (и растущего числа) доступных разъемов. Верблюд также имеет отличную облачную поддержку. Вы можете использовать либо компонент jCoulds, который предоставляет переносимый уровень абстракции сервисов для Amazon, GoGrid, VMWare, Azure и Rackspace, либо использовать специфичные для Amazon компоненты для SQS, SNS, S3, SES, SDB, DDB (некоторые из которых предоставлены мной).

В этом уроке я покажу вам, как контролировать приложения Camel с помощью JMX и сервиса Amazon CloudWatch. Необходимость такого мониторинга возникла после того, как я создал livephotostream— приложение для потоковой передачи фотографий, которое я создал во время игры с Camel. Это приложение извлекает фотографии в реальном времени из потокового API Twitter, а не данные реального времени из Instagram и Tumblr, а затем отображает их с помощью Bootstrap, а иногда и Websocket. И я хотел посмотреть, сколько фотографий он получает, сколько из них терпит неудачу, сколько времени занимает обработка фотографии и так далее. В итоге я создал компонент camel-cloudwatch и простое приложение, демонстрирующее, как использовать его для отображения метрик JMX.

Amazon CloudWatch

Amazon CloudWatch обеспечивает мониторинг облачных ресурсов AWS, отслеживая различные метрики и активируя аварийные сигналы на основе этих метрик. Он позволяет вам отслеживать ресурсы AWS в режиме реального времени, такие как экземпляры EC2, тома EBS, балансировщики нагрузки, экземпляры RDS … Но для моего приложения, ориентированного на сообщения, помимо использования ЦП, использования памяти, сообщений SQS и т. Д. Я хочу чтобы увидеть также показатели, относящиеся к моему приложению Camel, такие как ExchangesCompleted, ExchangesFailed, MaxProcessingTime, MeanProcessingTime или число обменов, обработанных данным маршрутом или даже конкретным процессором в маршруте. К счастью, Camel отслеживает и демонстрирует эти показатели через JMX. Вы можете прочитать о том , как получить доступ к этим метрический с Jconsole или FuseIDE на Михал Warecki отличном блоге
пост, Но подключение к java-приложению, работающему на экземпляре AWS через JMX с использованием jConsonle или другого приложения, не радует. Вместо этого я предпочел бы видеть эти метрики на симпатичных графиках, которые предоставляет CloudWatch, и даже получать уведомления, если какая-либо из метрик достигает порогового значения.

Это когда новый производитель облачных часов становится полезным. Это позволяет отправлять пользовательские метрики в сервис Amazon AmazonWatch. Все, что вам нужно сделать, это дать пространство имен вашим метрикам и отправить каждую метрику, указав ее имя, значение и, необязательно, единицу измерения и метку времени. Если вы не укажете единицу и метку времени, она будет использовать счет в качестве единицы, а текущее время в качестве метрического времени.

Camel-JMX

Допустим, мы хотим определить количество неудачных обменов на маршруте Camel. Этот показатель можно получить с
помощью компонента jmx , который позволяет подписаться на уведомления mbean. Приведенный ниже потребитель jmx приведет к созданию и развертыванию нового MonitorBean на локальном сервере mbean, который отслеживает атрибут «ExchangesFailed» в компоненте «processingRoute». И если значение этого атрибута изменится, этот потребитель отправит новое сообщение, содержащее изменение — т.е. количество сбоев на данный момент. После этого все, что вам нужно сделать, это установить это значение как заголовок сообщения CamelAwsCwMetricValue и дать ему имя с заголовком CamelAwsCwMetricName. Остальное будет обработано производителем облачных часов.

<camel:route>

<camel:from uri="jmx:platform?objectDomain=org.apache.camel&monitorType=counter&differenceMode=false&key.context=MC-SS071464.local/monitorContext&key.type=routes&key.name=%22processingRoute%22&observedAttribute=ExchangesFailed&initThreshold=1&granularityPeriod=5000&offset=1&format=raw"/>

 

<setHeader headerName="CamelAwsCwMetricName">

<simple>${body.observedAttribute}</simple>

</setHeader>

<setHeader headerName="CamelAwsCwMetricValue">

<simple>${body.derivedGauge}</simple>

</setHeader>

<setHeader headerName="CamelAwsCwMetricUnit">

<constant>Count</constant>

</setHeader>

 

<camel:to uri="aws-cw://www.livephotostream.com/live?accessKey=XXX&secretKey=XXX"/>

</camel:route>

Маршрут выше не требует никакого дополнительного кода. Он отправит любые изменения атрибута ExchangesFailed в службу CloudWatch, и вы увидите, что количество ошибок не меняется на графике CloudWatch:

Недостатком использования потребителя jmx для мониторинга bean-компонента является то, что вам нужно будет создать отдельного потребителя и маршрут для каждого отслеживаемого bean-компонента и атрибута. Другой подход заключается в том, чтобы иметь процессор, который может получать доступ к bean-компонентам с JMX-сервера, читать все интересующие атрибуты и отправлять их все сразу, используя компонент cloudwatch.

<route>

<from uri="timer://jmxMonitoringTimer?fixedRate=true&period=10000"/>

 

<process ref="jmxMetricReader" />

 

<camel:to uri="aws-cw://www.livephotostream.com/context?accessKey=XXX&secretKey=XXX"/>

</route>

В этом сценарии вам также понадобится таймер для запуска опроса. Производитель облачных часов может генерировать метрику на основе заголовков сообщений, как в первом примере, или просто отправлять объекты метрики из тела сообщения, если они присутствуют, как во втором примере. Процессор для извлечения данных из верблюда jmx также прост и его можно увидеть в демонстрационном
приложении на моей учетной записи guthub.

Результатом последнего маршрута является пара метрик, которые отправляются в CloudWatch каждую минуту. Как видно из следующего изображения, количество успешно завершенных обменов постоянно увеличивается, но с другой скоростью:

С другой стороны, среднее время обработки (в миллисах) отличается для каждого сообщения, но с небольшим интервалом и резко не увеличивается.

Если новых метрик в CloudWatch не существует, он будет создан для вас, но если вы хотите настроить аварийные сигналы и запустить автоматические действия, вам все равно придется войти в консоль amazon и вручную. И, наконец, не забудьте проверить свой «облачный счет» после добавления всех этих метрик, они не бесплатны;)