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

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

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

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

Трафик

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

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

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

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

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

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

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

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

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

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

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

Для геолокации Dynatrace предлагает несколько уровней детализации. Например, Dynatrace рассчитывает не только время отклика для всего региона США, но и время отклика для каждого штата, а также для каждого города в каждом штате. То же самое верно и для других регионов (например, Европы, Азии). И наоборот, для действий пользователя возможно более грубое представление, поскольку действия пользователя могут быть сгруппированы в 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типа не поддерживают автоматическую базовую настройку. Вместо этого используйте статические пороги .

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

Автоматический базовый уровень пытается определить наилучшие эталонные значения для входящего трафика приложений и служб. Для этого Dynatrace автоматически создает базовый куб для фактического входящего трафика приложений и служб. Это означает, что если ваш трафик поступает в основном из Нью-Йорка и большинство ваших пользователей используют браузер 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

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

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

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

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

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

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

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