Ваш критично важливий "вінтажний" застосунок — це чорна скринька? Давайте змінимо це за 5 хвилин!
Майже на кожному підприємстві є ОДНА система. Вона працює в кутку, виконуючи критично важливу функцію протягом багатьох років. Вона надійна, але також є повною чорною скринькою. Ніхто не хоче до неї торкатися, боячись зламати її, а оригінальні розробники давно пішли. Це може бути Головна книга (бухгалтерських операцій) з 90-х, рушій маршрутизації логістики на складі або агрегатор даних на виробничому майданчику. Ви знаєте, що він працює, тому що, ну, він ще не зламався… поки що.
Кінцева мета зрозуміла: нам потрібно переписати або мігрувати цей застосунок на сучасну, масштабовану та підтримувану платформу. Але такий проєкт займає місяці, а то й роки. Що нам робити в цей час? Ми не можемо працювати в темряві.
Хоча проєкт OpenTelemetry часто відзначають за його роль у сучасних хмарних архітектурах, його цінність не обмежується цим. Насправді, він надає потужне, часто недооцінене рішення для тих систем, які не є хмарними. Він виступає мостом до модернізації. Надаючи нам певну видимість у роботу застарілих застосунків сьогодні, ми можемо зменшити ризики їхньої експлуатації, спланувати їхню заміну та створити бізнес-кейс на основі даних для їхнього майбутнього. Давайте розглянемо, як це зробити за допомогою змодельованого застарілого застосунку, не змінюючи жодної лінії його коду.
OpenTelemetry: Сучасна спостережуваність для застарілого коду
Щоб змоделювати поширений застарілий шаблон, ми створили простий застосунок. Основний виконуваний файл, написаний на C (імітує процес системного рівня), запускає Java Virtual Machine (JVM) для виконання конкретного завдання, наприклад, обробки транзакції або запису.
Процес виглядає так:
C Application (legacy_app) -> запускає JVM -> викликає Java method для обробки завдання
Коли ми запускаємо ./legacy_app, він працює. Але ми не можемо відповісти на критично важливі питання: чи відповідає він бізнес-потребам? Чи не закінчується у нього памʼять і чи не зламається він під час обробки в кінці дня? Чи є уповільнення в цьому застосунку основною причиною скарг клієнтів минулого тижня?
Давайте дізнаватися.
Етап 1: Базовий моніторинг стану (Чи є система стабільною?)
Нашою першою метою є отримання моніторингу життєвих показників для нашого застосунку. Нам потрібно бачити його використання CPU і памʼяті, щоб переконатися, що він не збирається зламатися. Ми можемо досягти цього за допомогою агента OpenTelemetry для Java, просто прикріпивши його до застосунку за допомогою прапорця -javaagent у параметрах запуску JVM. У нашому прикладі ми можемо зробити це, використовуючи змінну середовища _JAVA_OPTIONS.
Крок 1: Налаштування середовища
У нашому терміналі ми налаштуємо агент, не торкаючись застосунку.
# --- Частина 1: Налаштування базового моніторингу справності системи ---
# 1. Дайте нашій службі описову назву
export OTEL_SERVICE_NAME=legacy-part-processor
# 2. Увімкніть ТІЛЬКИ експортер метрик
export OTEL_METRICS_EXPORTER=otlp
# 3. Вкажіть агенту gRPC-адресу колектора
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4317
# 4. Вкажіть протокол OTLP
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
# 5. Увімкніть моніторинг роботи для Java 8
export OTEL_INSTRUMENTATION_RUNTIME_TELEMETRY_JAVA8_ENABLED=true
# 6. Прикріпіть агент OpenTelemetry Java
export _JAVA_OPTIONS="-javaagent:./opentelemetry-javaagent.jar"
Крок 2: Запустіть незмінений застосунок та переконайтеся, що він працює.
./legacy_app
Спочатку перевіримо, чи працює наш старий застосунок. Швидкий погляд на логи терміналу показує постійний потік повідомлень, що підтверджує, що наш процес працює нормально:
[C Wrapper] Reading new Part ID from assembly line: 3035
[Java Processor] Received Part ID 3035. Fetching processing parameters...
[Java Processor] Part ID 3035 processed successfully.
[C Wrapper] Processing request for Part ID 3035 completed successfully.
[C Wrapper] Reading new Part ID from assembly line: 3036
[Java Processor] Received Part ID 3036. Fetching processing parameters...
[Java Processor] Part ID 3036 processed successfully.
[C Wrapper] Processing request for Part ID 3036 completed successfully.
[C Wrapper] Reading new Part ID from assembly line: 3037
[Java Processor] Received Part ID 3037. Fetching processing parameters...
[Java Processor] Part ID 3037 processed successfully.
[C Wrapper] Processing request for Part ID 3037 completed successfully.
Дані з нашого застосунку проходять стандартний шлях: агент OTel надсилає метрики до OpenTelemetry Collector, які потім збираються Prometheus для зберігання. Потім ми використовуємо Grafana для підключення до Prometheus і візуалізації даних. Оскільки це звичайна і добре задокументована конфігурація, ми пропустимо конкретні файли конфігурації і перейдемо безпосередньо до того, що нам дозволяє побачити ця видимість.
Крок 3: Створіть базовий дашборд моніторингу
Ось момент, коли все зʼєднується. Тепер ми можемо перейти до Grafana і за допомогою всього трьох простих запитів миттєво створити наш перший дашборд. І так, ми отримали базовий моніторинг для нашого застосунку, що охоплює середнє використання CPU, середнє споживання памʼяті та час, витрачений на збір сміття.
Результат: Базові метрики справності для нашого старого застосунку!
Завдяки цій єдиній зміні ми встановили основний рівень спостережуваності. Критичні метрики JVM починають надходити до нашого бекенду негайно, надаючи дані, необхідні для відповіді на ключові операційні запитання:
- Використання памʼяті: Чи витікає памʼять у нашому застосунку? Чи впаде він під час пікових годин?
- Завантаження ЦП: Чи відстає процес під час періодів високого навантаження?
- Збір сміття: Чи викликають часті “паузи” в застосунку каскадні тайм-аути в інших службах?
Ми перейшли від повної чорної скриньки до наявності інформаційної панелі справності в реальному часі.
Етап 2: Показники ефективності (Чи є система ефективною?)
Справність — це одна річ, але ефективність — зовсім інша. Після перегляду коду ми можемо побачити, що основна логіка нашого застосунку знаходиться в методі processTransaction(). Але статичний код не може відповісти на динамічні запитання. Скільки часу це займає для виконання під реальним навантаженням? Чи є це вузьким місцем?
Крок 1: Оновлення середовища
Ми додамо кілька змінних середовища, щоб вказати агенту конкретно вимірювати цей метод. Для сценаріїв, коли ви не можете змінити вихідний код програми, Java-агент OpenTelemetry пропонує потужне рішення: otel.instrumentation.methods.include. Це налаштування дозволяє вам вказати агенту автоматично створювати відрізки навколо конкретних методів.
# --- Частина 2: Налаштування продуктивності застосунку ---
# 1. Увімкення експортерів трейсів
export OTEL_TRACES_EXPORTER=otlp
# 2. Вкажіть агенту, який метод інструментувати
export OTEL_INSTRUMENTATION_METHODS_INCLUDE="LegacyJavaProcessor[processData]"
Крок 2: Запустіть застосунок та змініть наявний дашборд
Відрізки трейсів, які ми тепер збираємо, є сировиною для набагато більш насиченого дашборда. Наш OTel Collector налаштований на аналіз цих відрізків і генерацію “Золотих сигналів” моніторингу застосунків. Давайте повернемося до Grafana і додамо графіки для наших трьох основних метрик: викликів на хвилину, середнього часу відповіді та помилок на хвилину.
Результат: Основні бізнес-KPI для нашого застарілого застосунку!
Агент OpenTelemetry тепер вимірює кожну окрему транзакцію. Використовуючи OTel Collector з конектором spanmetrics, ми отримуємо важливі показники продуктивності:
Затримка (Час обробки): Тепер ми нарешті знаємо, скільки часу потрібно для обробки однієї транзакції. Чи достатньо це швидко? Чи відповідаємо ми нашим SLO?
Продуктивність (Виклики на хвилину): Ми можемо бачити, скільки транзакцій ми обробляємо за хвилину. Чи витримує наша система навантаження? Чи може вона впоратися з піковим навантаженням?
Рівень помилок (Якість роботи): Тепер ми можемо відстежувати стан нашої бізнес-логіки. Який наш рівень відмов? Чи можемо ми виявити проблеми до того, як вони загостряться?
Підсумки
Іноді навіть обмежена видимість набагато краща, ніж повна сліпота. Інструментуючи вашу застарілу чорну скриньку всього лише кількома змінними середовища та агентом OpenTelemetry, ви отримуєте дієві інсайти без ризикованих змін коду або дорогих переробок. Це не просто технічна перемога — це стратегічний крок вперед. Озброївшись реальними даними, ви можете приймати більш обґрунтовані рішення, проактивно вирішувати потенційні проблеми та зміцнювати впевненість у своїх планах на майбутнє.
Навіть якщо ваша початкова думка — ваш застосунок занадто застарілий, щоб отримати вигоду з OpenTelemetry, завжди варто перевірити свій технологічний стек. Частіше за все, є спосіб його інструментувати, навіть без зміни коду. Екосистема постійно розвивається, і багато фреймворків та платформ тепер підтримують інструментування на основі агентів або контейнерів sidecar, що робить ще простішим отримання цінних телеметричних даних навіть з найстаріших систем.
Памʼятайте: кожен шматочок видимості, отриманий сьогодні, купує вам час, стійкість і спокій до того часу, поки ваша модернізація не буде завершена.