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

Применение АппОптима / ИИ/ Автоматизированные базовые линии

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

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

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

Трафик

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

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

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

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

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

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

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

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

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

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

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

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

Определение базовых размеров

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

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

• Действие пользователя: действие пользователя приложения (например, 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, ваш базовый куб будет содержать следующие контрольные значения:

Russia - Moscow – Chrome – Reference response time : 2s, error rate: 0%, load: 2 actions/min

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

Russia - Moscow – Chrome – Reference response time : 2s, error rate: 0%, load: 2 actions/min

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

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

Интеллектуальное оповещение

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

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

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

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

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