Система документаційного забезпечення в нашому банку постійно розвивається і масштабується, а вимоги до швидкості та стійкості до відмови при цьому тільки зростають. Якогось моменту обслуговувати СДО без ефективного централізованого моніторингу стало надто ризиковано. Щоб убезпечити бізнес-процеси у ВТБ та спростити роботу адміністраторів, ми впровадили рішення на основі стеку відкритих технологій. З його допомогою ми можемо проактивно реагувати на інциденти, запобігаючи потенційним проблемам. Під катом історія про наш досвід використання вільного ПЗ для моніторингу масштабних бізнес-систем.
Навіщо моніторити систему документообігу
Документаційним забезпеченням у банку ВТБ з 2005 року «керує» система CompanyMedia. У СДО працює понад 60 тисяч користувачів, які щомісяця створюють понад мільйон нових документів. Наші сервери повинні функціонувати 24 години на добу: практично будь-якої миті в системі знаходиться по 2500–3000 осіб, які підключаються по всій країні, від Петропавловська-Камчатського до Калінінграда. Кожна секунда роботи СДН - це 10-15 змін.
Щоб система чітко виконувала покладені на неї завдання, ми розгорнули стійку до відмови інфраструктуру із застосуванням серверів проксування, балансування запитів, захисту інформації, повнотекстового пошуку, інтеграційних маршрутів і резервного копіювання. Щоб підтримувати та адмініструвати проект такого масштабу, потрібні колосальні ресурси. Адміністратори цілодобово відстежують базову інформацію про роботу серверів, завантаження оперативної пам'яті, процесорного часу, підсистеми введення-виводу тощо. Але, крім цього, потрібна тонша аналітика:
- розрахунок часу, що витрачається виконання бізнес-сценаріїв;
- відстеження динаміки продуктивності системи та навантаження на неї;
- пошук відхилень у компонентах системи від затверджених нефункціональних вимог.
Через 11 років після впровадження СДО питання проактивного реагування на різні помилки постало особливо гостро. Керівництво банку усвідомило, що працювати без моніторів і консолі життєдіяльності системи — це грати з вогнем: найменший збій у бізнес-системі такого рівня може призвести до мільйонних збитків.
У 2016 році ми почали впровадження інструментів для оперативного виявлення проблем у функціонуванні СДО, у тому числі для спостереження за параметрами, що цікавлять нас, в режимі реального часу. Попередньо систему прикладного моніторингу розгортали та тестували у рамках інфраструктури компанії «ІнтерТраст».
З чого все починалося
Сьогодні централізована система прикладного моніторингу СДО ВТБ, заснована на СПО-продуктах, допомагає запобігати більшій частині помилок, пов'язаних із документообігом, швидко та точно класифікувати проблеми, оперативно реагувати на будь-які інциденти. Вона включає дві підсистеми:
- для моніторингу ІТ-інфраструктури сервісів системи;
- для моніторингу виникнення помилок у роботі СДО.
Все почалося з єдиної безкоштовної програми для моніторингу. Перебравши кілька варіантів, ми зупинилися на Zabbix — вільному програмному забезпеченні, яке спочатку писалося під банківські сервіси та обладнання. Ця система з веб-інтерфейсом PHP, яка може зберігати дані в MySQL, PostgreSQL, SQLite або Oracle Database, ідеально відповідала нашим запитам.
Zabbix запускає своїх агентів на кожному сервері і збирає інформацію по метрикам, що цікавлять, в режимі реального часу в єдину базу даних. За допомогою програми зручно збирати дані про навантаження на процесори та оперативну пам'ять, використання мережі та інших компонентів, перевіряти доступність і реакцію стандартних сервісів (SMTP або HTTP), виконувати зовнішні програми, підтримувати моніторинг через SNMP.
Розгорнувши Zabbix, ми налаштували стандартні апаратні метрики, і спочатку було достатньо. Але СДВ ВТБ постійно розвивається і зростає: у 2016 році кількість серверів помітно збільшилася, з'явилися міграційні процеси, до системи підключилися Банк Москви, ВТБ Капітал, ВТБ24. Стандартних метрик стало мало, і ми навчили Zabbix відстежувати інформацію про наявність черг на кожному з томів, підключених до сервера (з коробки Zabbix відображає лише загальну дискову чергу), а також час, який займає відпрацювання тієї чи іншої процедури.
Крім того, ми оснастили систему множинними тригерами — умовами, за яких адміністратору надсилається повідомлення (повідомлення «Телеграм», SMS на номер телефону або лист на електронну пошту). Тригери налаштовуються для набору параметрів. Наприклад, можна вказати певний відсоток вільного місця на диску, і система сповіщатиме адміністратора, коли заданий поріг буде досягнуто, або інформувати, якщо якась фонова процедура виконується довше звичайного.
Підключення до Java та візуалізація даних
Ми значно розширили спектр даних, що аналізуються, але незабаром і цього стало недостатньо для ефективного моніторингу. Скориставшись тим, що СДН від CompanyMedia є Java-додатком, ми підключилися до Java Virtual Machine через інтерфейс JMX і змогли знімати метрики Java безпосередньо. Причому як стандартні параметри життєдіяльності Java, такі як інтенсивність роботи GC чи витрата Heap, а й специфічні проби, які стосуються безпосередньо до виконуваному коду програми.
У 2017 році, приблизно через рік після впровадження системи моніторингу, стало зрозуміло, що для нормальної роботи з колосальним масивом даних, який збирається в Zabbix, не вистачає візуалізації — комплексних екранів. Оптимальним варіантом вирішення цієї проблеми знову стало вільне ПЗ - Grafana, зручний дашборд для метрик, що дозволяє агрегувати всі дані на одному екрані.
Інтерфейс Grafana інтерактивний, нагадує OLAP-систему. Підсистема виводить дані, які отримує Zabbix на єдиний екран, представляючи інформацію у вигляді зручних для аналізу графіків і схем. Адміністратор легко налаштовує під себе зрізи, які йому потрібні.
Моніторинг та превентивне усунення помилок у системі СДО
Фільтрувати та аналізувати інформацію, що отримується під час моніторингу, допомагає СПО-платформа ELK. Цей Opensource-продукт складається з трьох потужних інструментів для збору, зберігання та аналізу даних: Elasticsearch, Logstash та Kibana. Впровадження цієї підсистеми дозволяє, зокрема, бачити в режимі реального часу, скільки помилок сталося в системі, на яких серверах і чи це помилки.
Тепер адміністратор може засікти проблему на ранній стадії, ще до того, як з нею стикається користувач. Такий проактивний моніторинг дозволяє запобігати порушенням працездатності системи, своєчасно усуваючи помилки. Крім того, ми можемо зрозуміти, як змінилася поведінка системи після оновлення, а також виявити нові проблеми у разі їх появи.
Моніторинг бізнес-операцій
Крім базових функцій моніторингу споживання ресурсів, система має можливість аналізу та контролю бізнес-операцій.
Контроль загального часу виконання бізнес-операцій дозволяє виявляти нові чинники та розуміти, який вплив вони мають на роботу системи.
Контроль часу виконання запитів у кожному бізнес-сервісу дає можливість засікти операції, мають відхилення від норми.
На скріншоті вище приклад моніторингу фонового завдання з погляду її відхилення від норми.
Перелік контрольованих завдань з погляду їхньої активності на певному сервері дозволяє виявляти помилки — зокрема дублювання виконання завдань — за всіма серверами.
Також проводиться моніторинг трендів часу виконання фонових процедур.
Система зростає, розвивається та допомагає справлятися з проблемами
З використанням описаної системи моніторинг роботи серверів СДО значно спростився. Проте періодично виникають різного роду конфлікти, що впливають на швидкість документообігу та викликають скарги користувачів. Так ми зрозуміли, що необхідно контролювати і поведінку самого додатку, а не сервери.
Для вирішення цього завдання до системи моніторингу підключили API балансувальник, який працює з кластером серверів додатків. Завдяки цьому адміністратор може бачити, який час відповідає сервер за кожним запитом користувача.
Дані про час відповідей серверів стали доступні для аналізу, що дало змогу пов'язати уповільнення СДО з процесами, що відбуваються на сервері. Виявилася зокрема цікава ситуація: сервер працює повільно, хоча в цей момент він не завантажений. Аналізуючи аномалію, ми виявили відхилення у роботі Garbage Collector Java. Зрештою з'ясувалося, що саме некоректна робота цього сервісу призводила до цієї ситуації. Взявши під контроль Garbage Collector Java, ми повністю вирішили проблему.
Ось так вільне програмне забезпечення допомагає розвиватися і зростати системі документообігу в банківській сфері. Ми порушили лише основні питання щодо системи моніторингу СДО ВТБ. Якщо вам цікаві подробиці — питайте у коментарях, ми з радістю поділимося з вами своїм досвідом.
Джерело: habr.com