Поделиться
Как выстроить мониторинг приложений на бесплатных ИТ-продуктах
При развитии ИТ у блока мониторинга ИТ-инфраструктуры или бизнес-приложений всегда особый статус-кво. Его польза очевидна, но в тоже время масштаб эффекта подвергается сомнению — ведь все и так работает. Open Source-продукты в этой сфере, типа Zabbix, Elasticsearch, Prometheus, положили конец скепсису по поводу того, что затраты на систему мониторинга могут оказаться несопоставимы с результатами ее внедрения. Как построить действенную систему мониторинга и при этом серьезно сэкономить, — в кейсе крупного оператора связи.
В основе любого бизнес-сервиса лежит стек прикладных систем, которые, как правило, внедрялись в разное время. В итоге ИТ-ландшафт представляет собой десятки приложений, тесно интегрированных друг с другом. Подобная картина встречается повсеместно. Ее недостаток в том, что бизнес замечает проблемы в работе сервисов только с началом поступления жалоб от клиентов или сотрудников. А кроме того, в компаниях часто не выработаны метрики, по которым можно отслеживать успешность исполнения тех или иных бизнес-процессов. В этом случае быстро найти «бутылочное горлышко» и определить, в чем причина задержек в операциях, затруднительно. Проблемы копятся, наслаиваются, и разрешить их становится все сложнее. В сумме это дает недовольных клиентов, снижение производительности труда сотрудников и финансовые потери.
Открытый мониторинг
Следующий виток — компания созрела до использования системы мониторинга бизнес-сервисов. И для выполнения этой задачи на рынке существуют качественные коммерческие продукты, но воплощение часто упирается в выделение бюджета. Сегодня этот фактор не несет ограничений, потому что в сфере мониторинга много Open Source решений с возможностями по кастомизации.
К примеру, полностью на решениях с открытым исходным кодом систему мониторинга бизнес-приложения создала команда «Инфосистемы Джет» в крупном операторе связи. Система охватывает ключевые клиентские сервисы на сайте телекомкомпании, которыми каждый день пользуются десятки тысяч людей. Это авторизация клиента, отображение разделов сайта, операции с услугами, например, смена тарифного плана, оплата и пр. Их состояние отслеживается по нескольким параметрам: среднему времени процесса авторизации пользователя, количеству успешных и неуспешных входов, числу и успешности обработки запросов, статусам прохождения платежей и так далее. Состояние этих параметров отражается на дашбордах, которые показывают эффективность работы пользовательского раздела на сайте оператора. Для этого эксперты ИТ-интегратора организовали сбор данных и аналитику для клиентского раздела сайта оператора.
Чтобы оценить техническое состояние инфраструктуры, были выбраны метрики, позволяющие обнаружить проблемы в работе сервисов: ошибки по разным типам, разбивка транзакций по времени исполнения, статистика неуспешных платежей, статистика работы SMS-шлюза и целый ряд других параметров.
«Основной плюс такого решения в том, что можно наблюдать метрики, критичные для бизнеса, и сопоставлять их с техническими данными. В реальном времени контролируется соответствие ИТ-экосистемы бизнес-требованиям — от инфраструктурных решений до уровня бизнес-сервисов», — комментирует Алексей Акопян, руководитель отдела систем мониторинга «Инфосистемы Джет».
А что находится под этой видимой частью, показывающей работу сервисов на дашбордах? За сбор параметров работы инфраструктурных компонентов отвечает Zabbix, метрики бизнес-приложений собирают logstash и filebeat, а хранение и аналитика обширного спектра параметров работы сервисов выполнено на базе хорошо известного Elasticsearch. Grafana применяется для визуализации информации. Все эти инструменты предварительно были интегрированы, протестированы командой «Инфосистемы Джет» и внедрены у оператора в виде готового стэка.
Архитектура кластера Elasticsearch позволяет постепенно расширять вычислительные мощности и наращивать объемы хранимых данных. Кстати, различные схемы внедрения являются еще одним преимуществом подобного подхода к мониторингу на базе стэка ELK: можно сразу запустить масштабный проект мониторинга бизнес-приложений, либо наращивать возможности системы по частям, когда бизнес-эффект контроля тех или иных метрик становится очевиден.
«Расширение системы мониторинга на базе Elasticsearch происходит относительно несложно. Подключение дополнительных источников не требует внедрения новых компонентов. Нужно только уделять внимание оптимизации запросов при отображении аналитики в дашбордах, а также следить за поддерживающей ИТ-инфраструктурой, потому что кластер Elasticsearch становится более требователен к ресурсам с ростом потоков данных и усложнением запросов», — отмечает Алексей Акопян.
Сложные данные
Доступность Open Source продуктов создает иллюзию легкости проектов с их использованием. Само по себе внедрение кластера Elasticsearch с визуализацией на основе Grafana уже отработано специалистами «Инфосистем Джет». Но подготовка данных и их анализ остается трудоемкой задачей, которая требует скрупулезного внимания и не решается по шаблону.
Дело в том, что практически в каждой инфраструктуре есть свой набор информационных систем, составляющих основу тех или иных бизнес-процессов, со своей уникальной архитектурой и особенностями взаимодействия между собой. И параметры функционирования информационных систем или их компонентов, а также отдельных элементов инфраструктуры, по-разному влияют на доступность и производительность бизнес-сервисов. Поэтому внедрение системы мониторинга должен предварять аудит бизнес-сервисов с определением метрик, характеризующих их работу. Также нужно тщательно продумывать способы получения этих данных и их подготовку к загрузке в систему мониторинга. Правильно сделать это — заложить основу успеха для создания системы мониторинга. Однако для сложных и тяжелых инфраструктур именно подготовительный этап может стать самым долгим и дорогим с точки зрения используемых ресурсов. Этот факт является еще одним аргументом в пользу постепенного внедрения системы мониторинга.
Подвести черту
Когда в телекомкомпании заработала система мониторинга бизнес-приложения, первые результаты в виде наглядной статистики параметров работы различных компонентов каждого сервиса на одном дашборде произвели впечатление. По сути дашборд отражал клиентский опыт взаимодействия с сервисом оператора. С помощью этого удалось оценить большинство важных параметров функционирования компонентов бизнес-систем. Мониторинг позволил выявить аномалии межсервисного взаимодействия и определить влияние отказа инфраструктурных компонентов на работу каждого сервиса. При этом можно оценить стоимость отказов или сбоев в работе сервисов для бизнеса и принимать меры по улучшению инфраструктуры в соответствии с существующими приоритетами.
Так компания может разумно подходить к модернизации и оптимизации ИТ-систем, действуя в соответствии со своими приоритетами. И тот факт, что высокого уровня прозрачности взаимодействия сервисов и инфраструктуры можно добиться на базе бесплатных Open Source решений, — хорошая новость для бизнесов, заинтересованных в улучшении своих бизнес-сервисов.
Короткая ссылка
