Автоматизированная многомерная базовая линия

Применение АппОптима / Обнаружение и анализ проблем / Обнаружение проблем / Автоматизированная многомерная базовая линия

Сбор контекстно-зависимых данных и базовый уровень — это два основных столпа, на которых строится обнаружение аномалий. Необходимо огромное количество качественных и точных данных для определения базовых показателей, которые можно эффективно использовать для разграничения нормальных и аномальных ситуаций. Однако это различие часто размыто из-за высокой изменчивости данных или просто потому, что определение «нормального» во многом зависит от контекста и меняется по мере развития приложений, платформ, инфраструктуры и алгоритмов. Это делает создание точных предупреждений реальной проблемой.

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

АппОптима AI изучает типичные эталонные значения времени отклика приложений и служб, частоты ошибок и трафика.

Трафик

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

После периода обучения АппОптима прогнозирует трафик на следующую неделю, а затем сравнивает фактический входящий трафик приложений с прогнозом. Если АппОптима обнаруживает статистически значимое отклонение от прогнозируемых уровней трафика, она выдает предупреждение.

Частота ошибок

АппОптима также предупреждает об ошибках. Предупреждение об увеличении частоты ошибок начинается после того, как базовый куб готов и приложение или служба работают не менее 20 % в неделю (7 дней). Опять же, каждая базовая ячейка куба также содержит измеренную частоту ошибок. Это идеально адаптируется к отдельным версиям браузеров, которые могут показывать более высокий или более низкий уровень ошибок по сравнению с другими типами браузеров.

Время отклика

Что касается времени отклика, АппОптима собирает эталоны для медианы (выше которой находятся 50 % самых медленных абонентов) и 90-го процентиля (10 % самых медленных абонентов). Событие замедления возникает, если типичное время отклика для медианы или 90-го процентиля ухудшается.

АппОптима уделяет особое внимание 10% самых медленных откликов ваших клиентов. Это связано с тем, что если вы знаете только среднее (медианное или среднее) время отклика большинства ваших клиентов, вы упустите важный момент: некоторые из ваших клиентов испытывают неприемлемые проблемы с производительностью! Рассмотрим типичную службу поиска, которая выполняет некоторые вызовы базы данных. Время отклика на эти вызовы базы данных может сильно различаться в зависимости от того, могут ли запросы обслуживаться из кеша или они должны извлекаться из базы данных. Измерения среднего времени отклика в таком сценарии недостаточны, потому что, хотя большинство ваших клиентов (тех, чьи запросы к базе данных обслуживаются из кэша) имеют приемлемое время отклика, часть ваших клиентов (те, у которых запросы к базе данных извлекаются из базы данных) испытывают неприемлемую производительность. Такие проблемы решаются путем акцентирования внимания на самых медленных 10% ваших клиентов. Оповещение об ухудшении времени отклика начинается после того, как базовый куб готов и приложение или служба работают не менее 20 % недели (7 дней).

Многомерность

Многомерность предлагает очень детализированную схему базового уровня, что приводит к более сложному подходу к базовому уровню, что в конечном итоге приводит к более точным пороговым значениям. Чем точнее пороги, тем более интеллектуальным становится общий процесс обнаружения аномалий.

Рассмотрим в качестве примера базовый куб приложения, созданный для расчета пороговых значений времени отклика. Предположим, у вас есть веб-приложение под названием «easyTravel». Немногомерная система выучит эталонное значение времени отклика всего приложения. Однако более детальный подход будет углубляться в каждое действие пользователя и изучать отдельное эталонное значение для каждого из них. Предположим, что easyTravel состоит из четырех пользовательских действий login, logout, getBookingPageи getReportPage. Для каждого действия пользователя будет указано отдельное базовое время отклика.

Помимо действий пользователя, АппОптима учитывает географическое положение. Это означает, что АппОптима AI определит базовые уровни для комбинаций каждого действия пользователя с каждой геолокацией. Базовое время отклика 90 мс может быть, например, базовым временем отклика для действия выхода из системы. Но многомерность в АппОптима AI идет еще глубже. Каждая геолокация сочетается с типом браузера, а каждый тип браузера, в свою очередь, сочетается с операционной системой, что в конечном итоге приводит к указанию отдельного порога для каждой комбинации действий пользователя, геолокации, браузера и операционной системы. Сгенерированный базовый куб обеспечивает высокий уровень детализации и точности.

Для геолокации АппОптима предлагает несколько уровней детализации. Например, АппОптима рассчитывает не только время отклика для всего региона США, но и время отклика для каждого штата, а также для каждого города в каждом штате. То же самое верно и для других регионов (например, Европы, Азии). И наоборот, для действий пользователя возможно более грубое представление, поскольку действия пользователя могут быть сгруппированы в XHR и действия загрузки.

Базовые размеры

Идентификация эталонных значений основана, как объяснялось выше, на базовом кубическом расчете. Для приложений этот куб создается комбинацией четырех измерений приложений, а для служб они основаны на двух измерениях.

Базовые параметры приложения

• Действие пользователя : действие пользователя приложения (например, orange.jsf, login.jsp, logoutили specialOffers.jsp).
• Геолокация : иерархически организованный список геолокаций, из которых происходят пользовательские сеансы. Геолокации организованы по континентам, странам, регионам и городам.
• Браузер . Иерархически организованный список семейств браузеров, таких как Firefox и Chrome. Самые верхние категории — это семейства браузеров. За ними следуют версии браузеров в каждом семействе браузеров.
• Операционная система : Иерархически организованный список операционных систем, таких как Windows и Linux. Самые верхние категории — это операционные системы. За ними следуют отдельные версии ОС.

Базовые параметры службы

• Метод службы : отдельные методы службы службы (например, getBookingPageили getReportPage). В случае служб базы данных метод службы представляет различные запрашиваемые операторы SQL (например, call verify_location(?) select booking0_.id from Booking booking0_ where booking0_.user_name<>?). Дополнительно рассчитывается эталонное значение для предопределенных групп методов обслуживания, статических запросов и динамических запросов .
• Группа методов службы : статические или динамические группы для веб-служб и для служб базы данных, группы, соответствующие операциям с базой данных, таким как вставка, обновление, выбор и т. д. Для служб базы данных эталонное значение вычисляется для предопределенных групп методов службы inserts, updatesи selects.

Службы этого PROCESSтипа не поддерживают автоматическую базовую настройку. Вместо этого используйте статические пороги .

Как работает автоматизированный базовый уровень

Автоматический базовый уровень пытается определить наилучшие эталонные значения для входящего трафика приложений и служб. Для этого АппОптима автоматически создает базовый куб для фактического входящего трафика приложений и служб. Это означает, что если ваш трафик поступает в основном из Нью-Йорка и большинство ваших пользователей используют браузер Chrome, ваш базовый куб будет содержать следующие эталонные значения:

USA - New York – Chrome – Reference response time : 2s, error rate: 0%, load: 2 actions/min

Если ваше приложение также получает трафик из Пекина, но с совершенно другим временем отклика, базовый куб автоматически адаптируется и после этого будет содержать следующие эталонные значения:

USA - New York – Chrome – Reference response time : 2s, error rate: 0%, load: 2 actions/min

China – Bejing - QQ Browser - Reference response time : 4s, error rate: 1%, load: 1 actions/min

АппОптима проверяет, когда ваши приложения и службы изначально обнаруживаются ЕдиныйАгент. Базовый куб рассчитывается через два часа после того , как ваше приложение или служба первоначально обнаружены ЕдиныйАгент, чтобы он мог проанализировать двухчасовой фактический трафик, чтобы рассчитать предварительные эталонные значения и определить, откуда поступает ваш трафик. Расчет эталонного куба повторяется каждый день, чтобы АппОптима могла продолжать адаптироваться к изменениям вашего трафика.

Умное оповещение

Для генерации предупреждений базовые уровни оцениваются в пределах 5-минутных и 15-минутных скользящих интервалов времени. 5-минутное окно служит для быстрого оповещения в случае выявления достаточного количества значений выборки, превышающих базовые уровни. 15-минутный интервал используется для генерации предупреждений с большей достоверностью. Однако, если в течение одной минуты будет обнаружено, что большое количество значений выборки превысит базовые значения, АппОптима также выдаст предупреждение в это время.

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

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

После периода обучения АппОптима прогнозирует трафик на следующую неделю, а затем сравнивает фактический входящий трафик приложений с прогнозом. Если АппОптима обнаружит статистически значимое отклонение от прогнозируемых уровней трафика, это вызовет либо проблему, Unexpected low trafficлибо Unexpected high trafficпроблему.

Как правило, новые обнаруженные аномальные события в среде не обязательно приведут к немедленному срабатыванию предупреждения. Оповещения всегда дают представление об основной причине. Чтобы определить основные причины проблем, АппОптима использует контекстно-зависимый подход для обнаружения взаимозависимых событий во времени, процессах, хостах, службах, приложениях, а также в вертикальной и горизонтальной топологической перспективе мониторинга. Принимая во внимание все эти перспективы мониторинга, АппОптима точно определяет основные причины проблем. И только после этого будут генерироваться оповещения об обнаруженной проблеме.

Сезонные базовые линии

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

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

Пример базового уровня

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

Искусственный интеллект автоматически проверяет, соответствуют ли условия сезонной модели, и создает доверительный диапазон на основе сезонной модели. Как вы можете видеть на приведенной ниже диаграмме, модель распознает сезонность и не генерирует ложных тревог на пиках. Тем не менее, он все равно вызовет оповещение, если всплеск произойдет в другое время.

Параметры базовой модели

Cезонные базовые линии используют значения показателей за каждую минуту в течение последних 14 дней в качестве эталона для расчета базового уровня. Модель изучает обычное поведение показателя и стремится обнаруживать регулярно повторяющиеся закономерности. Она использует вероятностный прогноз для вычисления доверительной полосы, которая охватывает ожидаемый диапазон будущей точки.

Вы можете настроить ширину доверительной полосы с помощью параметра tolerance. Более высокий допуск означает более широкую доверительную полосу, что приводит к меньшему количеству запускаемых событий. Допустимый диапазон допуска составляет от 0.1 до 10, 4 со значением по умолчанию.

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

Простая модель вычисляет доверительный диапазон на основе надежной оценки распределения входных данных, и ее вычисленный интервал остается постоянным с течением времени. Для простой модели параметр tolerance управляет шириной доверительной полосы таким же образом, как и для сезонной модели.

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

Модель (будь то сезонная или простая) обновляется ежедневно.

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

Обучение базовой модели

Модель сезонного базового уровня использует значения показателей за каждую минуту в течение последних 14 дней для обучения и обучается по кортежу (уникальные комбинации метрика—измерение—значение измерения). Обучение происходит ежедневно.

На изображении ниже представлен обзор процесса обучения.

Первый шаг, проверка данных, гарантирует целесообразность обучения сезонной модели на данных показателей. Вот несколько причин для перехода к простой модели:

• в данных много пропущенных значений
• данные имеют много отклонений
• данные недостаточно изменчивы
• в данных не обнаруживается сезонности.

Если эта проверка завершается неудачей, вместо нее используется простая модель. Если проверка прошла успешно, следующим шагом является предварительная обработка входных данных. На этом этапе данные подготавливаются для обучения модели квантильной регрессии, которая изучает сезонное поведение на основе трех основных характеристик данных:

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

Эти функции используются для обучения модели квантильной регрессии, вероятностной регрессионной модели, которая устойчива к выбросам из-за оценки квантилей.

Следующим шагом является проверка модели, которая проверяет надежность прогнозируемых квантилей для подмножества данных. Если эта проверка завершается неудачей, вместо нее используется простая модель.

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