Dynatrace Extension для Oracle: опыт разработки плагина под кастомную бизнес-логику

Dynatrace — это Observability платформа, которая позволяет автоматически мониторить состояние IT-систем и приложений. Значительное количество возможностей платформы доступно «из коробки», однако иногда возникает необходимость адаптировать ее под специфические задачи бизнеса. В таких случаях на помощь приходит Dynatrace Extensions 2.0 — простой декларативный механизм, позволяющий описывать источники данных и метрики сбора в едином yaml-файле.

Недавно мы реализовали проект по кастомной разработке плагина для Банка Грузии (Bank of Georgia, BoG). Задача заключалась в обеспечении сбора определенных критических метрик из внутренней бизнес-системы банка, работающей с базой данных Oracle, а также отслеживании статуса системы, определенного ее собственными алгоритмами. Сбор данных из Oracle позволяет создать удобные дашборды для мониторинга и настроить систему сообщений Dynatrace, которая мгновенно информирует соответствующие команды в случае возникновения критических состояний. Важно отметить, что в статье не используются реальные метрики из проекта из соображений безопасности и конфиденциальности.

В реализации проекта важную роль сыграли сотрудники банка — Vazha Pirtskhalaishvili (Head of DevOps & DataOps Engineering) и Giorgi Kalandadze (Expert DevOps Engineer). Они четко сформулировали задачу, обеспечили рабочую среду для разработки расширения и консультировали на всех этапах работы с базой данных Oracle.

Особенностью проекта было то, что бизнес-система использовала локальный алфавит. Из-за этого стандартный JDBC-драйвер не мог корректно подключаться к базе данных. Проблема поддержки неанглийского языка является довольно распространенной в IT-индустрии, и многие компании десятками лет не могут реализовать надлежащую поддержку языков, особенно использующих нелатинский алфавит. Решением стало использование кастомного JDBC-драйвера, который команда банка разработала для собственных приложений. Компонент Dynatrace ActiveGate, на котором и происходит работа расширения, позволяет добавлять кастомные драйверы, что значительно упростило реализацию.

Следующим вызовом стало то, что Dynatrace может хранить только числовые метрики, тогда как статус системы в базе данных был представлен в текстовом формате. Поскольку внесение изменений в саму базу — сложный и длительный процесс, этот вариант сразу отклонили. Решение нашли в виде сложного SQL-запроса с использованием элементов PL/SQL, процедурного языка Oracle для создания процедур и функций в базе данных. Благодаря активному участию Giorgi Kalandadze, этот запрос удалось оперативно разработать и протестировать. В результате статусы были преобразованы в числовые значения: 0 — OK, 1 — WARNING, 2 — ERROR.

Финальный вид плагина:

В самом Dynatrace мы настроили соответствующие правила, по которым при возникновении любых состояний, кроме OK, формируется отчет о проблеме. Dynatrace генерирует этот отчет на основе найденных в системе аномалий, связанных с метриками, журналами (лог-файлами), событиями и пользовательской активностью. В зависимости от статуса и критичности, сообщения направляются соответствующим командам через различные каналы связи.

Таким образом, благодаря возможностям расширения функционала Dynatrace, мы успешно адаптировали платформу под специфические потребности Банка Грузии. Это позволило команде банка оперативно получать информацию о состоянии важных бизнес-систем и значительно сократить время реакции на инциденты.

Наша команда имеет значительный опыт в разработке кастомных расширений для Dynatrace. Если вы хотите максимально эффективно интегрировать платформу с учетом собственных бизнес-целей, обращайтесь за консультацией: