Привет, Хабр. Я Вероника, java-разработчик, который иногда юзает Camunda без слез. Здесь моя первая статья, в которой мы переложили BPMN-диаграмму на java код и реализовали небольшой процесс на примере пятничного вечера.
Вторую статью я хочу посвятить мониторингу бизнес-процессов. Согласитесь, отслеживать каждый отдельный процесс в оперейте не очень удобно, и тем более оперейт не предназначен для сбора статистики.
Давайте представим реальную ситуацию. Мы зарелизились в прод. Всё работает прекрасно, ну или так кажется на первый взгляд. Но тут приходит бизнес, которому нужны графики, диаграммы и отчеты. Что делать, думаете вы. Добавлять кастомные метрики в микросервис?
Без паники. В Camunda 8 предусмотрен удобный механизм мониторинга бизнес-процессов.
Для начала я немного подправлю docker-compose и добавлю туда Kibana
Если посмотреть на компоненты архитектуры камунды (рисунок взят с официального сайта), то можно увидеть, что Camunda 8 использует Elasticsearch в качестве основного хранилища для данных, связанных с выполнением бизнес-процессов.
А если мы вспомним про стек ELK, то одним из компонентов является не только Elasticsearch, но и Kibana. С помощью Kibana мы можем визуализировать данные, полученные из Elasticsearch. Как раз то, что нужно бизнесу, все эти красивые графики и диаграмы.
Итак, что мы можем визуализировать в нашем пятничном вечере. Допустим, бизнес очень хочет знать, сколько человек решили остаться дома и есть пиццу, а не идти в клуб.
Сейчас абстрагируемся от моей учебной диаграммы. Давайте подумаем реальный кейс, где это может пригодиться. Допустим, у нас есть процесс:
Найти клиента
Провалидировать данные клиента
Отправить заявление клиента
Получить подтверждение об успешной отправке.
На дашборде в Kibana мы сможем увидеть, сколько подтверждений пришло за выбранный период времени. Согласитесь, очень удобно.
Возвращаемся к вечеру пятницы и стартуем процесс
Переходим в оперейт, напоминаю, он доступен на порту 8081.
И видим, что процесс пошел по нижнему пути, то есть человек остался дома и заказал пиццу. Далее идем в Kibana. Как помним, она у нас крутится на 5601 порту.
Начинаем делать красивое — создаем первый дашборд. Далее нам необходимо создать визуализацию.
Сейчас надо откатиться немного назад, потому что когда вы провалитесь в Create visualization, увидите немного уличной магии.
Поэтому, прежде чем создавать визуализацию, необходимо добавить индекс.
Что вообще происходит, когда отрабатывает оперейт?
Все его элементы и их состояния zeebe отбрасывает в Elastic. То есть вы сможете узнать, какой элемент диаграммы отработал, в какое время и много другой информации. Это все видно в секции Discover, если выбрать индекс zeebe-record-process*
В этом индексе вы можете видеть тип элемента, его value.elementId. Про value.elementId: где его смотреть и что это такое расскажу чуть позже.
Сами индексы можно настраивать в секции Management → Stack Management → Kibana → Index Pattern.
То есть если вы добавите в индекс паттерн zeebe-record-process*, то далее сможете использовать его в Discover.
Возвращаемся к дашборду. Напомню, изображение ниже вы сможете увидеть, если нажмете на кнопку Create visualization в создании дашборда.
А теперь смотрим внимательно. Напомню, нам необходимо собирать статистику по элементу «Остаться дома и заказать пиццу». У каждого элемента на BPMN-диаграмме есть value.elementId. Посмотреть его можно в моделере.
Также необходимо установить фильтр intent в ELEMENT_COMPLETED. Поясню: intent – это в каком состоянии находится элемент на диаграмме. ELEMENT_COMPLETED означает, что выполнение элемента успешно завершено. По оси X выбираем timestamp.
После того как нажмете Save and return, должны увидеть что-то такое.
У меня здесь два графика, второй абсолютно такой же, но сделан с абсолютными значениями. Ну и как бывший геймер говорю вам: не забывайте почаще сохраняться, нажимая кнопочку Save в верхнем правом углу.
Зная id каждого элемента, вы можете отслеживать абсолютно любое событие, будь то сервисная таска или Zeebe BPMN Error. В моем реальном боевом проекте мы отбрасываем Zeebe BPMN Error, если от смежных микросервисов приходит 500, так как затем удобно собирать статистику, в какие моменты и почему система работала нестабильно.
Я показала лишь малую толику возможностей мониторинга, но, уверена, вы сможете настроить дашборды под свои потребности.
Напоминаю, код находится здесь.
С вопросами велкам в комментарии — обсудим.