На вебинаре «Демо Observability платформы GMonit» одноименная компания представила возможности решения, преимущества сквозного онлайн-мониторинга для анализа процессов, изоляции инцидентов на первом уровне поддержки. В ходе демонстрации платформы эксперт показал, как использовать программный инструмент для оптимизации сервисов, находить ошибки еще до того, как они скажутся на получении прибыли, и пояснил, почему сигналы о неполадках зачастую игнорируются.
Команда инженеров GMonit создает решения для высоконагрузочных систем. Собственное направление R&D компания развивает вместе с Омским государственным университетом. Полученный в прошлом году от Фонда содействия инновациям грант расширил возможности специалистов и послужил толчком для развития продуктов. Миссия компании – упростить цифровую трансформацию, обеспечив прозрачность и управляемость ИТ-ландшафта.
Игнорирование сигналов
Происходящее в сегменте классического ИТ-мониторинга напоминает рутинный процесс, представляющий интерес исключительно для узкопрофильных специалистов. Но если проанализировать получаемые данные сквозь призму бизнеса, можно почерпнуть ценную информацию о состоянии дел в компании или на предприятии. О том, насколько это важно, в частности, для прогнозирования сбоев, какие возможности открываются для управленцев, рассказал технический специалист, pre-sale инженер команды GMonit Денис Василенков.
В большинстве российских компаний мониторинг есть, хотя бы в виде самописных систем, строятся графики, периодически поступают предупреждения (алерты), все соответствующим образом настроено. Если бы не одно. По статистике большая часть сигналов систем мониторинга просто игнорируется. И не потому, что команда ленивая, а потому что непонятно, как происходящее влияет на бизнес-процессы и работу компании в целом, отмечает эксперт.
Типичная ситуация: бьет тревога, но тот или иной сервис продолжает работать. Инженерная служба оценивает это так: «Порог не превышен, можно не трогать». Но если посмотреть на происходящее глазами бизнеса, то видно другое, а именно – потери. Клиент не дошел до корзины, и конверсия упала на 15%. Заказчик хотел применить бонусы, но не смог, в итоге ушел с онлайн-площадки. Все это для коммерческого отдела уже не просто баг, а реально упущенная выгода.
В поле зрения классического мониторинга находятся инфраструктура, контроль точечных вещей, при этом не видно ни процесса, ни клиента, ни воронку. Для бизнеса важны детали – насколько удобно клиенту оформить заказ, на каком шаге и что у него не получилось, и почему в итоге он не реализовал задуманное, ушел к конкуренту.
На платформе GMonit происходящее можно оценить глазами потенциального заказчика, в частности, увидеть, на каком шаге он «споткнулся» (или может это сделать), где тормозит система. Но главное – сколько денег теряет бизнес в данный момент. Получение алерта о том, что просела выручка, сегодня недостаточно – бизнесу нужно понять почему.
По словам эксперта, в этом одна из ключевых ценностей платформы («не приходится гадать, что упало и где копать»). Система сообщит о потере денег и уточнит причину, например, отказала опция применения бонусов. И это один из приоритетов для разработчиков GMonit.
Ради здоровья бизнеса
Большая часть вебинара была посвящена демонстрации платформы и рассказу о том, какие метрики связаны в цепочку, как пользоваться продуктом.
Один из дашбордов платформы – «Здоровье бизнеса». Агенты устанавливаются на тот или иной уровень (Front End, Back End, инфраструктуру, мобильное приложение, закрытую «коробку», например «1С»). Слева – ключевые показатели выручки, потери, график конверсии и другие важные для бизнеса метрики, которые соотносятся с временным интервалом. В ходе демонстрации были показаны метрики, выбранные за 30 минут, последний час.
В рамках конкретного кейса на одном из графиков было видно, что с 16.32 конверсия снижается, растет потенциальная потеря. Выясняется, что на шаге «оформить заказ» со стороны Front End запросы начинают обрабатываться долго. Отмеченные красным цифры сигнализируют о том, что здесь формируется проблема.
В то же время со стороны Back End увеличивается количество «плохих» запросов. Кроме того, и внешние сервисы – платежные – подсвечиваются красным. Очевидно, что этап «оформить заказ» находится в плохом положении. Не составляет труда вникнуть в детали происходящего – увидеть информацию о транзакции. Технические детали включают в себя сведения о том, из чего состоит время ответа, в момент начала деградации виден компонент, который стал замедляться.
Примечательно, что указанная временная точка неполадки коррелирует с ростом количества ошибок 500. Становится понятно, что проблема на стороне контроллера. Если углубиться в детали, можно восстановить цепочку событий.
На уровне сервиса видны транзакция платежного сервиса, который написан на Java, и ее компоненты. С упомянутой точки 16.32 наметилась тенденция к росту продолжительности обработки запросов. Исходный показатель Apdex – своего рода градусник здоровья приложения, на которое по умолчанию устанавливается агент, – подтверждает, что сервис начинает давать сбои.
Переход в функциональность распределенной трассировки показывает полную цепочку событий и атрибуты ошибки. Эксперт пояснил, как производится подсчет денег, которые потеряла компания. Данные транзакции дообогащаются атрибутами самой трассировки. В частности, рассматриваемая транзакция была выполнена с ошибкой 500.
Таким образом, на платформе виден класс ошибки, с какого устройства заходил пользователь, в какой валюте оплачивал заказ, по какому адресу и т. д. На основе этих сведений формируется контекст ошибки. От количества подобных ошибок зависит объем потерь.
Эксперт отметил, что в процессе трассировки собирается информация о логах (лог-файлах), но не обо всех. Они привязаны к трассировке, поэтому пользователь может сэкономить на хранении данных. Накопление логов – практика, ставшая для многих привычкой. Разработчики платформы отказались от такого подхода – лог-файлы собираются только в рамках конкретных транзакций, обогащая контекст.
Еще одна фишка программного инструмента GMonit – представление верхнеуровневых приложений в рамках карты сервисов. Топология строится автоматически на основе трассировок. Каждый кружок – это сервис-компонент или внешний вызов. С помощью фильтров можно включить/выключить компоненты. Функциональность доступна из «коробки».
Не менее любопытный раздел – детекция аномалий. Заинтересованный управленец почерпнет ценную информацию о пользовательском опыте, например, стоит ли улучшить верстку отдельных страниц ресурса. Оценить, пользуется ли спросом страница, можно на основе сведений о ее пропускной способности, деталей об уникальных посетителях (с какой версии браузера пользователи чаще заходят или не заходят на страницу), локациях, откуда выполняются запросы. Частая практика, когда сбои в том или ином сервисе происходят из новой версии релиза.
Характеризуя дорожную карту развития GMonit, эксперт подчеркнул, что многое в продукте реализовано благодаря запросам клиентов. В рамках пилотных проектов компания обсуждает функции, которые в первую очередь представляют интерес.
Подробно описывать процедуру демонстрации платформы – едва ли продуктивная затея. У желающих вникнуть в детали есть возможность запросить демо – достаточно зайти на сайт команды GMonit. Для небольших компаний доступна бесплатная версия Lite, предлагающая мониторинг производительности приложений с картой сервисов.
