Блог

Название категории: Команда

Машинное обучение в мониторинг системах и планы компании

Мониторинг сайтов, мониторинг инфраструктуры и ML

Заставка блога

Доброго времени суток, дорогие друзья!

Сегодня хотелось бы поговорить о планах компании Кивил касательно мониторинга и функциональных возможностей сервиса в перспективе. Мы считаем, что Вы должны знать о том, какое направление держит компания и какие проблемы и вызовы ставит перед собой команда разработчиков данного ПО (сервиса мониторинга ссылок, серверов и АПИ).

Машинное обучение в системах мониторинга

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

Вопрос эффективной подачи информации и ее структурирования согласно приоритету однозначно является серьезной задачей для разработчиков. Один и тот же показатель в разной трактовке или группе может показывать совсем разную картину. Сегодня мы опустим тему UI/UX (пользовательского интерфейса и опыта) в мониторинг системах, а поговорим по большей части о мониторинге с применением машинного обучения (ML или machine learning).

Как в системе мониторинга HTTP/REST сервисов или TCP-сокетов (UDP-сокетов) нам может помочь машинное обучение? Почему именно машинное обучение может автоматизировать большую часть работы? Об этом и не только попробуем порассуждать в данной статье. Стоит заметить, что на данный момент наша команда работает над частью того, о чем идет речь, но все же здесь будут только размышления и идеи к реализации, к которым мы дойдем, но с ростом аудитории и потребностей. Про наши исследования и пробы будем говорить тогда, когда прийдет время и Вам станет интересно знать о том, как мониторинг может поднять Вашу эффективность.

Представим себе абстрактную модель того, как это может работать. Где-то на границах нашего сервиса есть переменное количество микросервисов, которые собирают большое количество метрик по всем Вашим узлам. Вся эта информация собирается на одном узле нашей системы, который занимается исключительно пакетной обработкой полученных данных. Данный агрегатор формирует ценную (совокупную) информацию и согласно установленных условий занимается назначением приоритета по каждой группе показателей. В это же время оператор наблюдает за Панелью управления и большим количеством показателей, а Блок Машинного Обучения изучает все текущие метрики и их историю для того, чтобы можно было предоставить оператору самую ценную информацию к анализу.

В таком случае, такая система сможет не только отбрасывать фоновые показатели и шум, но и собирать группы метрик в зависимости от ситуации для анализа, а это потенциальное снижение количества информации для вывода оператору на экран. Вместе с этим, системы прогнозирования сбоев работы аппаратно-программных комплексов и микросервисов смогут уведомлять оператора о возможных исходах, которые приведут к критическим ситуациям. Например, рост динамики показателей, которые отвечают за задержку сети или время ответа сервера(ов) или линейный рост задержек выполняемых операций. В финале цепочки Блок по Восстановлению работоспособности каждого отдельного юнита Вашей системы сможет выполнять комплекс действий по устранению возможных проблем внутри Вашей архитектуры. Используя такие системы для тестирования и мониторинга Вы поднимете уровень отказоустойчивости своих систем, что является острой необходимостью для любых проектов уже сегодня!

Человек не машина и не должен ею быть! Он не может анализировать информацию с уведомлений, графиков и таблиц одновременно. Он не может в секунду или даже минуту собрать всю информацию воедино и докопаться до сути проблемы. Он не может за момент обработать большое количество информации с логов по каждому юниту и сопоставить ее. Возможно Вы заметили, что мы задумываемся и о системах агрегации логов, но про такой сервис от Кивил поговорим не сегодня.

Команда QiWeal стремится к тому, чтобы вычислительные мощности, которые мы имеем на сегодня максимально помогали нам (простым смертным) в таких вопросах. Потому что машина, даже средних мощностей может в секунду проанализировать намного больше байт информации, чем человек и это не изменится никогда!

Самый интересный с точки зрения разработки модуль — сервис установки приоритета группам метрик с анализом их динамики во времени. Сервис такого рода даст возможность прогнозирования критических ситуаций на ряду с совершенствованием сетей машинного обучения. Это важно хотя бы потому, что разрабатывая системы мониторинга мы начали понимать, что не всегда критические показатели наносят самый крупный вред или простой в работе. Не всегда резкий скачек показателя вверх/вниз несет за собой даже мелкий сбой. Зачастую оператор или администратор спешит исправлять то, что громче всех кричит, а не то, что потенциально несет за собой критическую ситуацию. С помощью модуля, который сможет оценивать группы метрик, выставлять приоритет и прогнозировать поведение системы мы сможем существенно облегчить работу по поддержанию высоконагруженных систем.

Подводя итоги, можно задаться вопросом, а почему технологии, которые помогают автоматизировать процесс разработки и развертывания веб-сервисов развиваются и создаются целые направления и методологии (DevOps или его имплементация SRE, например), а вот систем автоматизации или методологий мониторинга с блоками восстановления после сбоев в крупных промышленных масштабах так и нет? Почему есть ошибки, которые технический специалист каждую смену закрывает по 10 раз и нет общедоступных систем, которые бы это автоматизировали? Неужели компаниям нужно под каждый тип ошибки разрабатывать свою версию ПО для решения? Пожалуй, оставим этот вопрос пока без ответа.

Мне кажется, что все дело в том, что нет единого стандарта для общения пользовательских сервисов с мониторинговыми системами. С развитием отрасли мониторинга даже сейчас все-равно нет возможности дать клиентам инструменты для быстрой интеграции, что позволило бы решить большое количество текущих вопросов и задач. Нужен стандарт по классификации состояний системы. Нужны реализации по Блоку Выявлений Аномалий в данных метрик, а так же Блок Визуализации Взаимосвязей Компонентов Инфраструктуры на разных уровнях, чтобы сопоставление информации было более эффективным время провождением оператора!

Не хочется заканчивать статью на такой ноте, поэтому замечу, что конечно не все так плачевно, как может показаться Вам, читая данную статью и конечно же, Вы можете привести ряд продуктов, которые частично решают какую-либо проблему, но думаю все-равно согласитесь с тем, что нет методологий и конкретных предложений должного уровня и с хорошей эко-системой. Исходя из этого, мы уже работаем над данным вопросом и поддержим любые кооперации и предложения!

Спасибо, что дочитали статью до конца и разделили эти мысли! Надеемся, Вы пройдете этот пусть с нами!

Вам может быть интересно

Подняться вверх