События метрик, вызывающих оповещения

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

В Dynatrace есть два основных источника одиночных событий:

• События на основе метрик (события, инициированные серией измерений)
• События, не зависящие от какой-либо метрики (например, сбои процессов, изменения развертывания и события перемещения ВМ).

Пользовательские события метрик настраиваются в глобальных настройках вашей среды и видны всем пользователям Dynatrace в вашей среде.

Автоадаптивная базовая линия

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

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

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

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

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

Базовый расчет

Базовыми значениями для расчета базовых показателей являются данные метрик за последние семь дней. Измерения за каждую минуту используются для расчета 99 -го процентиля всех измерений. Это определяет соответствующую базовую линию . Межквантильный диапазон между 25 -м и 75 -м процентилями затем используется в качестве флуктуации сигнала , которую можно добавить к базовой линии. Используя параметр number of signal fluctuation(nx флуктуация сигнала), вы можете контролировать, сколько раз флуктуация сигнала добавляется к базовой линии, чтобы получить фактический порог для оповещения.

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

По умолчанию любые 3 минуты из скользящего окна в 5 минут должны превышать ваш базовый порог, чтобы вызвать событие. Это означает, что событие должно иметь 3 минуты нарушения в пределах любого 5-минутного скользящего окна.

Статический порог

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

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

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

На рисунках ниже потребление памяти неуклонно увеличивается в течение 30 дней. Статически заданный порог в 40 МБ будет обнаруживать ненормальное поведение процесса, в то время как адаптивный базовый уровень будет увеличиваться вместе со значением метрики.

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

По умолчанию любые 3 минуты из скользящего окна в 5 минут должны превышать ваш порог, чтобы вызвать событие. То есть для события потребуется 3 минуты нарушения в пределах любого 5-минутного скользящего окна.

Расширенный запрос метрики

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

Примеры расширенных запросов включают в себя:

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

Ограничения окружающей среды

Существует общее ограничение в 10 000 конфигураций событий метрик для каждой среды мониторинга, которые можно разделить на следующие категории:

• Базовые запросы — для базовых запросов нет ограничений по размерам. Например, вы можете создать оповещение для 20 000 ядер ЦП в одной конфигурации события метрики. Несмотря на то, что ограничения на размер нет, ограничение регулирования в 100 одновременных предупреждений на конфигурацию используется в качестве меры предосторожности.
• Расширенные запросы — применяются дополнительные ограничения:
  • 100 000 измерений на среду
  • 1000 измерений на конфигурацию события метрики
  • 100 расширенных конфигураций запросов для каждой стратегии мониторинга. У вас может быть 100 конфигураций с автоадаптивным базовым уровнем и 100 конфигураций с настраиваемыми пороговыми значениями.

Оповещение об отсутствии данных

Dynatrace предоставляет вам возможность настроить оповещение об отсутствии данных в метрике. Если оповещение включено, Dynatrace регулярно проверяет, содержит ли скользящее окно события метрики какие-либо измерения. Например, если скользящее окно установлено на 3 минуты в течение любых 5 минут , Dynatrace инициирует предупреждение, если данные не будут получены в течение 3-минутного периода.

Условие отсутствующих данных и базовое/пороговое условие объединяются логикой ИЛИ .

Показать пример

Заполнители описания события

Для предоставления подробной информации об оповещении используется {missing_data_samples}заполнитель для описания события. Он отображает количество минут без полученных данных.

Нерегулярные или задержанные потоки данных

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

Для ожидаемых данных с опозданием (например, показателей интеграции с облаком с 5-минутной задержкой) используйте длинные скользящие окна, покрывающие задержки. Для 5-минутной задержки используйте скользящее окно не менее 10 минут.

Ограничения

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

Масштаб мероприятия

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

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

Предварительный просмотр области предупреждений может отображать до 100 сущностей, которые обеспечивают выбранную метрику и соответствуют всем указанным фильтрам.

Если вы установите порог для более чем 100 объектов, предварительный просмотр будет недоступен, и это приведет к значительному количеству предупреждений.

Осведомленность о топологии

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

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

Прием метрик позволяет отправлять все типы измерений метрик, независимо от количества сущностей, к которым они относятся. Существуют следующие сценарии:

Измерения не связаны с какой-либо сущностью

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

Пример: показатели выручки, измеренные для всех розничных магазинов по географическому региону.

Измерения относятся к одному объекту

Если вы определяете событие метрики для измерения, связанного с одним объектом, результирующее событие будет вызвано для этого объекта.

Пример: выполнение пакетных заданий измеряется на отслеживаемом узле, где измерение связано с узлом.

Измерения связаны с несколькими объектами

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

Пример: количество запусков пакетного задания, измеренное для процесса на отслеживаемом узле, где измерение относится как к процессу, так и к узлу.

Серьезность события

Серьезность события определяет, следует ли поднимать проблему или нет, и должен ли ИИ Дэвиса определять основную причину данного события.

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

Дополнительные сведения о встроенных событиях и их уровнях серьезности см. в разделе Типы событий .

Продолжительность события

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

Событие остается открытым до тех пор, пока метрика не останется в пределах порогового или базового уровня для определенного количества одноминутных интервалов в одном и том же окне оценки, после чего Dynatrace закрывает событие. По умолчанию количество таких слотов де-оповещения равно размеру окна оценки. Например, если размер окна оценки установлен на 5, метрика должна оставаться в пределах порогового или базового уровня в течение 5 последовательных одноминутных интервалов времени, чтобы закрыть событие. Вы можете изменить количество слотов для отмены предупреждений через API Metric Events .

Селектор показателей в событиях показателей

Селектор метрик — это мощный инструмент для запроса данных. Он предоставляет вам две основные возможности:

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

В этом примере мы хотим обнаружить аномалии в комбинированном входящем и исходящем сетевом трафике путем вычисления суммы всех прочитанных ( builtin:host.net.bytesRx) и записанных байтов ( builtin:host.net.bytesTx). Метрическое выражение для этого:

((builtin:host.net."bytesTx":splitBy())+(builtin:host.net."bytesRx":splitBy()))

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

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

Проверка тревожных данных на графиках

Объединение метрик для обнаружения аномалий

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

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

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

Отображение топологии

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

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

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

Переопределить сопоставление топологии

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

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

Создать событие метрики

Чтобы создать конфигурацию события метрики

1. В меню Dynatrace выберите « Настройки » > « Обнаружение аномалий » > «Пользовательские события для предупреждений » и выберите «Создать настраиваемое событие для предупреждений» .
2. Перейдите на вкладку « Сборка ».
3. Выберите метрику для события метрики. Вы можете выбрать метрику по категории, к которой она принадлежит, или по точному имени метрики.
4. Выберите тип агрегирования для метрики (где применимо).
5. по желаниюВыберите измерения, которые будут учитываться событием.
6. по желаниюДобавьте фильтры сущностей на основе правил.
7. Определите стратегию мониторинга.
   1. Выберите стратегию:
      • Автоадаптивная базовая линия — Dynatrace автоматически вычисляет пороговое значение и динамически адаптирует его к поведению вашей метрики.
      • Статический порог — порог , который не меняется во времени.
   2. Укажите скользящее окно для сравнения. Скользящее окно определяет, как часто пороговое значение (вычисленное автоматически или заданное вручную) должно нарушаться в течение скользящего окна времени, чтобы возникло событие (нарушения не обязательно должны быть последовательными). Это поможет вам избежать чрезмерно агрессивного оповещения об одиночных нарушениях. Вы можете установить скользящее окно до 60 минут.
   3. В зависимости от выбранной стратегии укажите:
      • Автоадаптивная базовая линия — сколько раз флуктуация сигнала добавляется к базовой линии.
      • Статический порог — пороговое значение. Dynatrace предлагает значение на основе предыдущих данных.
   4. Выберите поведение оповещения об отсутствующих данных . Если оповещение об отсутствии данных включено, оно объединяется с базовым/пороговым условием по логике ИЛИ .
8. Выберите временной интервал предварительного просмотра. Вы можете получать оповещения за 12 часов, один день или семь дней и оценивать, насколько эффективна ваша конфигурация.
9. Выберите название для вашего мероприятия. Заголовок должен быть короткой, легко читаемой строкой, описывающей ситуацию, например, High network activityили CPU saturation.
10. В разделе Описание события создайте осмысленное сообщение о событии. Сообщения о событиях помогают понять характер события. Вы можете использовать следующие заполнители:
    • {alert_condition}— состояние тревоги (выше/ниже порога).
    • {baseline}– нарушенное значение базовой линии.
    • {dims}— список всех измерений (и их значений) метрики, нарушивших порог. Вы также можете указать конкретное измерение: {dims:dt.entity.<entity>}. Чтобы получить список доступных измерений для вашей метрики, запросите его с помощью запроса дескриптора метрики GET .
    • {entityname}— название затронутого объекта.
    • {metricname}— название метрики, нарушившей порог.
    • {missing_data_samples}– количество выборок с отсутствующими данными. Доступно, только если включено предупреждение об отсутствии данных.
    • {severity}- тяжесть события.
    • {threshold}– нарушенное значение порога.
11. Выберите Создать пользовательское событие для оповещения , чтобы сохранить новое событие.

API событий метрик

Те же функции событий метрик доступны через API обнаружения аномалий — событий метрик . Используя API, вы можете перечислять, обновлять, создавать и удалять конфигурации.