Типовий інцидент в аналітичній системі: керівник відділу продажів бачить застарілі дані у звіті, хоча технічні метрики Kafka broker, Spark executor та СУБД знаходяться в нормі. Станом на кінець березня 2019 року, наявність успішних логів виконання завдань не гарантує доставку бізнесово-коректного результату. Проблема часто криється у «сліпих зонах» між компонентами: відкладеному оновленні реляційних вітрин, накопиченні затримок у споживачах (consumer lag) або некоректному просуванні часових міток (watermarks) у потокових обчисленнях.
Архітектура наскрізного моніторингу
Для забезпечення прозорості необхідно розділити спостереження на три взаємопов'язані рівні:
- Інфраструктурний: моніторинг ресурсів (CPU, RAM, диск) через Prometheus та JMX-метрики.
- Процесний: відстеження станів потоків (Kafka consumer group lag, Spark structured streaming progress, Airflow DAGs).
- Дані (Data Quality): контроль актуальності (Freshness), повноти (Completeness) та звірка (Reconciliation) між джерелом і DWH.
Важливо враховувати, що після виходу Apache Kafka 2.2.0 (22 березня 2019 року), деякі метрики можуть повертати NaN замість очікуваних числових значень. Це вимагає оновлення конфігурацій та порогів сповіщень (alerts) у Grafana, щоб уникнути хибних інцидентів.
Робота з Kafka, Spark та NiFi: практичні аспекти
Під час відстеження пропущеного батчу або затримки даних важливо корелювати події за часом. Враховуйте, що затримка (lag) у Kafka — це лише швидкість читання, яка не відображає час запису в цільову базу.
Для моніторингу Spark 2.4.0 необхідно використовувати lastProgress, щоб аналізувати inputRowsPerSecond та triggerDuration. Окремої уваги потребує Apache NiFi 1.9.1. Станом на 27 березня 2019 року розробниками підтверджено критичну проблему (NIFI-6150) з накопиченням вмісту в content repository, що призводить до вичерпання дискового простору. Продукти, що використовують цю версію, потребують ручного моніторингу заповнення дисків до виходу виправлення.
Звірка даних та подолання розривів у часі
Ключовим елементом надійності є Reconciliation (звірка). Оскільки кожен компонент системи має власну внутрішню логіку роботи з часом (event time vs processing time), критично важливо будувати систему контрольних сум на кожному етапі:
- Фіксація контрольних підсумків при виході з Kafka.
- Перевірка кількості оброблених рядків у Spark-транзакції.
- Верифікація хешів або сум записів після завантаження в DWH.
Такий підхід дозволяє виявити, чи не губляться дані в процесі трансформації через розсинхронізацію годинників або збої у мікропакетній обробці.
План дій щодо впровадження наскрізної видимості
Для мінімізації часу виявлення інцидентів (MTTD) та відновлення (MTTR) рекомендується дотримуватися наступного алгоритму:
- Аудит джерел: ідентифікація критичних бізнес-показників та визначення допустимих часових меж (SLA).
- Впровадження кореляційних ідентифікаторів: використання Batch ID та Event ID для відстеження одного пакету даних крізь всю ланцюжок інструментів.
- Налаштування інтегрованих дашбордів: об'єднання технічних метрик Prometheus з результатами перевірок якості даних у Grafana.
- Створення ескалаційних політик: розмежування сповіщень на технічні (Infrastructure/Pipeline) та бізнесові (Data Quality), щоб уникнути втоми від сповіщень.
- Регулярний контроль оновлень: перед кожним оновленням сервісів (як у випадку з Kafka або NiFi) проводити валідацію метрик на сумісність з моніторинговою системою.
Автор матеріалу