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-драйвер не міг коректно підʼєднуватися до бази даних. Проблема підтримки неанглійської мови є досить поширеною в ІТ-індустрії, і багато компаній десятками років не можуть реалізувати належну підтримку мов, особливо тих, що використовують нелатинський алфавіт. Рішенням стало використання кастомного JDBC-драйвера, який команда банку розробила для власних застосунків. Компонент Dynatrace ActiveGate, на якому і відбувається робота розширення, дозволяє додавати кастомні драйвери, що значно спростило реалізацію.

Наступним викликом стало те, що Dynatrace може зберігати лише числові метрики, тоді як статус системи у базі даних був представлений у текстовому форматі. Оскільки внесення змін у саму базу — складний та тривалий процес, цей варіант одразу відхилили. Рішення знайшли у вигляді складного SQL-запиту з використанням елементів PL/SQL, процедурної мови Oracle для створення процедур та функцій у базі даних. Завдяки активній участі Giorgi Kalandadze, цей запит вдалося оперативно розробити й протестувати. У результаті статуси було перетворено на числові значення: 0 — OK, 1 — WARNING, 2 — ERROR.

Фінальний вигляд плагіну:

У самому Dynatrace ми налаштували відповідні правила, за якими у разі виникнення будь-яких станів, крім OK, формується звіт про проблему. Dynatrace генерує цей звіт на основі знайдених у системі аномалій, повʼязаних із метриками, журналами (лог-файлами), подіями та користувацькою активністю. Залежно від статусу та критичності, повідомлення спрямовуються відповідним командам через різні канали зв’язку.

Отже, завдяки можливостям розширення функціоналу Dynatrace, ми успішно адаптували платформу під специфічні потреби Банку Грузії. Це дозволило команді банку оперативно отримувати інформацію про стан важливих бізнес-систем та значно скоротити час реакції на інциденти.

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