Компания «ИнтерТраст» внедрила в ВТБ решение прикладного мониторинга системы документационного обеспечения на основе стека открытых технологий

Разработанная система централизованного мониторинга для прикладного администратора системы документационного обеспечения (СДО) банка ВТБ позволила реализовать режим проактивного реагирования на инциденты, повысить прозрачность работы системы, а также существенно снизить риски администраторов.

Система CompanyMedia используется в банке ВТБ с 2005 года. В настоящий момент в системе документационного обеспечения Банка (СДО), построенной на базе CompanyMedia, работает более 60000 пользователей, система поддерживает большой документопоток – ежемесячно по делопроизводству создается более 1 000 000 документов, одновременно в системе работают 2500-3000 пользователей, в секунду происходит 10-15 изменений. При этом банком предъявляются высокие требования к отказоустойчивости системы в каждом ее компоненте. Для бесперебойной работы системы развернута отказоустойчивая инфраструктура для задач взаимодействия пользователей с системой с применением серверов проксирования, балансировки запросов, защиты информации, полнотекстового поиска, интеграционных маршрутов , бэкапирования и прочих.

Проект такого масштаба требует больших ресурсов для поддержки и администрирования системы, как со стороны компании «ИнтерТраст», так и со стороны банка. Администраторам необходимо отслеживать не только базовую информацию о работе серверов (такую как, например, потребление ресурсов оперативной памяти и процессорного времени), но и проводить более тонкую аналитику: сколько времени тратится на выполнение бизнес сценариев, какова динамика производительности системы и профиль нагрузки, есть ли заметные отклонения в каком-либо компоненте системы от утвержденных нефункциональных требований и т.д. На все это накладывается аспект географической распределенности пользователей, работающих в системе: от Петропаловска-Камчатского до Калининграда, и, фактически, работы в режиме доступности системы 24 часа в сутки.

В такой ситуации вопрос проактивного реагирования на различного рода ошибки встает очень остро. Специалисты компании «ИнтерТраст» совместно с ДИТ ВТБ пришли к выводу о необходимости создания центральных мониторов и консоли жизнедеятельности системы, которые позволяют следить в режиме реального времени за нужными параметрами инфраструктуры и своевременно выявлять проблемы в функционировании системы. Для решения этих задач была создана система прикладного мониторинга, которая перед внедрением в банке ВТБ была развернута и протестирована в рамках инфраструктуры компании «ИнтерТраст».

Реализованная специалистами «ИнтерТраст» централизованная система прикладного мониторинга СДО базируется на СПО продуктах и включает в себя две подсистемы. Одна выполняет задачи мониторинга ИТ-инфраструктуры сервисов системы, другая осуществляет мониторинг возникновения ошибок в работе СДО. Централизованная система прикладного мониторинга позволила кардинально оптимизировать время реакции на возникающие инциденты, классификацию проблем и как следствие повысить качество обслуживания. Большинство ошибок и проблем в работе СДО администраторы могут решать превентивно, благодаря такому комплексу мониторинга.

Система прикладного мониторинга ИТ-инфраструктуры использует два компонента: СПО подсистему Zabbix и визуализатор Grafana. Zabbix запускает своих агентов на каждом сервере и собирает данные по интересующим метрикам в режиме реального времени в единую базу данных. Подсистема Grafana предоставляет возможности анализа этих данных, выводя необходимую для оперативного анализа информацию на единый экран (дашборд), представляя данные в виде удобных для анализа графиков и схем.

Визуализатор  позволяет администратору настроить под себя те срезы и графики, которые ему нужны и удобны.

Интерфейс Grafana интерактивный, фактически это очень похоже на OLAP систему.

Система мониторинга отслеживает не только информацию по ЦПУ и оперативной памяти, но также информацию о том, на каком диске заканчивается место, сколько времени заняла отработка той или иной процедуры. Кроме того реализована система оповещений – триггеров, которая позволяет информировать администратора о тех вещах, которые ему интересно и важно отслеживать. Эти триггеры настраиваются для любого набора параметров. Например, можно указать, какой процент свободного места является значимым, и система оповестит администратора, когда этот порог будет достигнут или проинформировать администратора если какая либо фоновая процедура стала выполняться дольше обычного и т.д.

Мониторинг и превентивное устранение ошибок в системе СДО

Помимо этого в рамках централизованного комплекса мониторинга специалистами компании «ИнтерТраст» развернута система отслеживания и анализа ошибок в СДО на базе платформы ELK (Elasticsearch, Logstash, Kibana). Данная система позволяет администраторам узнавать в реальном режиме времени, сколько ошибок произошло в системе, на каких серверах, повторяемые это ошибки или нет и многое другое.  

Администратор имеет возможность классифицировать проблему на ранней стадии ее появления еще до того, как с ней может столкнуться пользователь СДО. Такой проактивный мониторинг позволяет улавливать тренды в нарушениях работоспособности системы и своевременно его устранять. Кроме того эта система позволяет понять, как изменилось поведение системы после обновления, какие новые проблемы появились.

Мониторинг бизнес операций

Помимо базовых функций мониторинга потребления ресурсов системой проводится анализ и контроль бизнес операций

Контроль общего времени выполнения бизнес операций позволяет выявлять влияние различных новых возникающих факторов в ретроспективе работы системы.

Контроль времени исполнения запросов в разрезе каждого бизнес сервиса позволяет выявлять операции с отклонением от нормы

Пример мониторинга фоновой задачи с точки зрения отклонения от нормы ее выполнения.

Перечень контролируемых задач с точки зрения их активности на определенном сервере позволяет выявлять ошибки включения задач (дублирования исполнения задач) по всем серверам.

Мониторинг трендов времени исполнения фоновых процедур.

Проблемы и особенности мониторинга и превентивного устранения ошибок в СДО

Мониторинг СДО начался с внедрения Zabbix в 2016 году. Были настроены стандартные аппаратные метрики, и поначалу  этого было достаточно. Потом СДО начала усложняться, количество серверов увеличилось, появились миграционные процессы, подключились Банк Москвы, ВТБ Капитал, ВТБ24. Стандартных метрик стало не хватать.  Прежде всего, мы оснастили Zabbix множественными триггерами. Триггер - это некое условие, при котором Zabbix отправляет администратору уведомление: в Телеграмм, смс, в почту. Таким образом, мы значительно расширили спектр анализируемых данных, но со временем и этого стало не хватать для эффективного мониторинга. Так как система CompanyMedia -  Java приложение, мы через интерфейс JMX подключились  к Java Virtual Machine и начали снимать непосредственно метрики Java.  Данных стало собираться много и мы задействовали компонент Zabbix – Javagateway, который позволяет агрегировать метрики. И тут мы столкнулись с новой проблемой. Поскольку система задействует очень много серверов, в Java gateway поступало слишком большое количество файловых дескрипторов, после чего он переставал работать. Для устранения этой проблемы был написан скрипт, который следит за дескрипторами. Если их больше положенного количества, он автоматически перезагружает службу.

В 2017 году стало понятно, что для нормальной работы с большим массивом данных, собираемых в Zabbix, не хватает визуализации  - комплексных экранов. Так в системе мониторинга  появилась Grafana, которая позволяет все данные агрегировать на одном экране. Это очень удобно, когда все показатели по аппаратной утилизации всех серверов выводятся на один экран. Так, благодаря Zabbix и Grafana, контролируется работа всех серверов. Но в СДО все равно периодически возникают разного рода конфликты, влияющие на быстродействии системы, что вызывает жалобы пользователей. Стало очевидно, что необходимо также  контролировать поведение самого приложения, а не только серверов.  К системе мониторинга по API был подключен  балансировщик, который работает с кластером серверов. Для анализа стали доступны данные о времени ответов серверов, т.е. администратор стал видеть, за какое время отвечает сервер по каждому запросу пользователя. Таким образом, получилось связать  замедление СДО с процессами происходящими на сервере. Выявилась, в частности, интересная  ситуация: сервер не загружен, но он работает медленно.  Разбираясь с этой проблемой, пришли к необходимости  мониторинга garbage collector java, некорректная работа которого и приводила к данной ситуации. Контроль garbage collector java позволил полностью устранить эту проблему.

Таким образом, система мониторинга живет и развивается совместно с СДО.