В какой то момент разработки приложения, каждый из нас приходит к тому, что нам нужно больше информации о том, что происходит внутри приложения или же в возможности мониторить приложение. В случае с Play Framework уже существует готовое решение в виде отличной библиотеки с открытым исходным кодом Kamon в паре с модулем kamon-play. Но сегодня мы собираемся взглянуть на альтернативное решение, интеграцию и использование Drowizard Metrics ранее известное как Codahale Metrics с Play Framework. Так я начал искать готовые решения которые могли бы мне помочь в интеграции этих двух инструментов. Я нашел несколько не полных решений: К сожалению модуль metrics-play предоставляет только базовый функционал из всего что имеется в среде Dropwizard Metrics. Это может быть достаточно, если вам нужны простые метрики которые доступны через REST api, но у меня были более высокие требования и я решил дополнить функционал этого модуля написав следующие модули: Собственно об этом мы будем говорить далее. Metrics предоставляет мощный инструментарий для мониторинга поведения критических компонентов в продакшн среде. Так же, предоставляет средства отправки измеренных данных через репортеров. Metrics репортеры — это отличный способ отправки данных из самого приложения в предпочитаемую систему хранения и визуализации метрик. На момент написания статьи поддерживаемые репортеры следующие: Dropwizard Metrics и комьюнити также предосталяют другие репортеры, на пример Ganglia Reporter, CSV Reporter, InfluxDB Reporter, ElasticSearch Reporter и другие. Добавление фэктори для поддержки репортеров в библиотеку является легкой задачей. По умолчанию, для того что бы использовать метрики нужно вызвать Metric Registry для создания метрик, создать контекст и в ручную управлять им. На пример: Что бы держать все DRY есть аннотации, модуль metrics-annotation-play будет создавать и надлежащим образом вызвать Timer для @Timed, Meter для @Metered, Counter для @Counted и Gauge для @Gauge. @ExceptionMetered тоже поддерживается, он создает Meter, который измеряет частоту выбрасывания исключений. Предыдущий пример можно переписать следующим образом: или же можно сдекарировать весь класс, что создаст метрики для всех явных методов: Данный функционал поддерживается только для классов созданных через Guice, так же имеются некоторые ограничения AOP. Давайте попробуем использовать библиотеку в реальном приложении и рассмотрим, как все работает. Исходный код приложения можно найти тут. Я использую шаблон activator play-scala с sbt plugin. Мы должны добавить JCenter в список resolvers и зависимости: Для примера я использую сonsole репортер, давайте добавим конфигурацию в application.conf. Как вы видите я деактивировал метрики jvm и logback, что бы не потерять наши метрики и добавил репортер, который будет выводить метрики в stdout c периодичностью 10 секунд. Теперь мы можем начать использовать аннотации, я сдекорирую метод index контроллера HomeController: На самом деле вы не должны использовать все аннотации разом, т.к. @Timed комбинирует в себе Counter и Meter, но я это сделал для демонстрации возможностей. После старта приложения и запроса Главной Страницы, репортер должен вывести метрики в stdout: Конечно же вы все еще можете просмотреть метрики через REST api, для этого надо добавить конфигурацию в routes файл: Metrics так же поддерживает возможность использования автоматических проверок работоспособности приложения(health checks). Больше информации можно найти в официальной документации. Для создания надлежащей среды использования метрик нужна поддержка большего количества репортеров. Это должно быть еще одним направлением развития библиотеки. На данный момент, что бы измерить время выполнения Future нужно в ручную выполнять все действия. Надлежащая поддержка Future может помочь в асинхронной среде Play Framework и может быть хорошим дополнением. Hdrhistogram предоставляет альтернативную реализацию коллектора (reservoir) высокого качества, который может быть использован для Histogram и Timer. Software Engineer