Руководство по написанию DQL для Anomaly Detection

• Latest Dynatrace
• How-to guide
• 15-min read

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

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

Написание правильного DQL

Anomaly Detection выполняет запрос каждую минуту и проводит проверки на основе настроенных условий нарушений оповещений для вашего запроса timeseries или makeTimeseries. Запрос timeseries, используемый в конфигурации пользовательского оповещения, должен содержать следующее:

• Либо вложенное поле timeframe с полями start и end, либо просто оба поля start и end.
• Поле длительности interval равное 1 минуте (interval: 1m).

При использовании команды timeseries или makeTimeseries настоятельно рекомендуется использовать interval: 1m. В противном случае пользовательское оповещение может не работать. * Одно или несколько полей типа array, содержащих только значения double, значения long или null.

Все поля в записи timeseries, кроме timeframe, duration и массивов типа string, рассматриваются как измерения. Любые значения null и поля object также рассматриваются как измерения.

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

Использование небольшого набора полей со стабильными значениями измерений

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

timeseries cpu_usage = avg(dt.host.cpu.usage), by:{dt.entity.host}


| fieldsAdd tags = entityAttr(dt.entity.host, "tags")


| filter iAny(tags[] ==  "Windows")


| fieldsAdd entityName(dt.entity.host)


| fieldsAdd average_usage = arrayAvg(cpu_usage)

Этот запрос имеет следующие измерения:

• dt.entity.host: строка, содержащая идентификатор хоста.
• tags: массив строк.
• dt.entity.host.name: строка, содержащая имя идентификатора хоста.
• average_usage: значение типа double, содержащее среднее значение использования CPU.

Только одно из них является стабильным:

• dt.entity.host -- стабильное измерение, поскольку идентификатор хоста не изменяется.

Стабильные измерения не изменяются со временем, и их значения не зависят от других измерений и их значений. Остальные измерения, следовательно, являются нестабильными:

• tags изменяется при добавлении или удалении тегов хоста. Даже если теги остаются прежними, значение измерения изменяется при изменении порядка тегов.
• dt.entity.host.name изменяется при переименовании хоста.

dt.entity.host.name может считаться стабильным, если имя не изменяется. * average_usage постоянно изменяется по мере изменения использования CPU хостов с течением времени.

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

timeseries cpu_usage = avg(dt.host.cpu.usage), by:{dt.entity.host}


| fieldsAdd tags = entityAttr(dt.entity.host, "tags")


| filter iAny(tags[] ==  "Windows")


| fieldsKeep cpu_usage, dt.entity.host, timeframe, interval

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

timeseries {cpu_usage = avg(dt.host.cpu.usage), value.A = avg(dt.host.cpu.usage, scalar:true)}, by:{dt.entity.host}

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

Пользовательское оповещение извлекает данные из Grail на основе предопределенных скользящих окон. Если вы вручную переопределяете временной интервал в DQL-запросе, пользовательское оповещение получит данные, отличные от запрошенных, что приведет к сбоям при выполнении запроса.

При создании пользовательского оповещения:

• Не используйте from: и to: при создании DQL-запроса для пользовательского оповещения. В противном случае вы будете получать сбои при каждой попытке пользовательского оповещения выполнить ваш запрос:

timeseries sum(dt.service.request.failure_count),


by:{http.response.status_code},


from:now()-1h, to:now() // удалите эти параметры

* Не переопределяйте поле timeframe:

fetch bizevents


| makeTimeseries count(), time:timestamp


| fieldsAdd timeframe = timeframe(duration(5, "min")) // присваивает новое значение полю timeframe

Избегайте сортировки в запросе

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

timeseries avg(dt.host.cpu.usage), by: { dt.entity.host }


| sort `avg(dt.host.cpu.usage)` desc // удалите это


| filter dt.entity.host == "HOST-1234"

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

timeseries avg(dt.host.cpu.usage), by: { dt.entity.host }


| limit 10 // удалите это; для выбора конкретных хостов рекомендуется использовать filter

Связанные темы

• Приложение Anomaly Detection
• Dynatrace Query Language