Примеры временных рядов DQL

Примеры временных рядов DQL

Метрики на платформе позволяют точно определять и извлекать любые данные метрик с помощью Языка запросов Ключ-АСТРОМ (DQL). После ознакомления с основами запросов DQL и командой timeseries используйте примеры на этой странице, чтобы начать получать ответы из ваших метрик.

Пример 1: Средняя загрузка CPU по всем хостам

В этом примере вы запрашиваете среднюю загрузку CPU по всем мониторимым хостам в вашей среде. ЕдиныйАгент собирает измерения CPU со своего хоста. Эти метрики доступны через ключи метрик, начинающиеся с dt.host.cpu. Наблюдение за агрегированной загрузкой CPU по всем хостам помогает визуально подтвердить, как ваша инфраструктура реагирует на всплески нагрузки и восстанавливается после них, а также отслеживать медленные, незаметные тенденции роста.

timeseries usage=avg(dt.host.cpu.usage)

Пример 2: Средняя загрузка CPU по хостам с ограничением до топ-3 хостов

В этом примере вы получаете среднюю загрузку CPU каждого мониторимого хоста и фокусируетесь на трёх хостах с наибольшей загрузкой. ЕдиныйАгент собирает измерения CPU со своего хоста. Эти метрики доступны через ключи метрик, начинающиеся с dt.host.cpu. Построение графиков загрузки CPU отдельных хостов помогает визуализировать нормальную и аномальную нагрузку. Фокусируясь на трёх хостах с наибольшей загрузкой CPU, вы можете начать исследование недостаточно обеспеченных ресурсами приложений. Аналогично, фокусировка на хостах с наименьшей загрузкой CPU может выявить избыточное выделение ресурсов и привести к возможностям экономии.

Запрос данных:

timeseries usage=avg(dt.host.cpu.usage), usage_summary=avg(dt.host.cpu.usage, scalar:true), by:{dt.entity.host}
| fieldsAdd entityName(dt.entity.host)
| sort usage_summary desc
| limit 3

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

timeseries usage=avg(dt.host.cpu.usage, scalar:true), by:{dt.entity.host}
| fieldsAdd entityName(dt.entity.host)
| sort usage desc
| limit 3

| fields dt.entity.host, dt.entity.host.name, usage

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

Пример 3: Средняя загрузка CPU по IP-адресу хоста

В этом примере вы используете условие in для запроса хостов по их IP-адресу. Используя оператор in с classicEntitySelector, можно фильтровать по ipAddress и другим атрибутам хоста. Использование параметра filter команды timeseries более производительно, чем объединение timeseries с командой filter.

timeseries usage=avg(dt.host.cpu.usage), filter: {in( dt.entity.host, classicEntitySelector("type(host),ipAddress(\"10.102.39.126\")") )}

Пример 4: Количество хостов, отправляющих данные о загрузке CPU

В этом примере вы научитесь объединять timeseries с summarize. Сначала вы запрашиваете хосты, отправляющие данные о загрузке CPU, а затем подсчитываете количество хостов в результате. Другие команды DQL также можно объединять с timeseries, как показано в предыдущих примерах, но в отличие от них, summarize дополнительно агрегирует набор данных, возвращённый timeseries. Эта двухэтапная агрегация будет полезна по мере усложнения ваших запросов.

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

Пример 5: Топ хостов по прочитанным байтам с соответствующими записанными байтами

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

timeseries by:{dt.entity.host}, { bytes_read=sum(dt.host.disk.bytes_read, scalar:true), bytes_written=sum(dt.host.disk.bytes_written, scalar:true) }
| sort bytes_read desc
| limit 3
| fields dt.entity.host, entityName(dt.entity.host), bytes_read, bytes_written

Пример 6: Доступный CPU по ноде Kubernetes

В этом примере вы рассчитываете доступный CPU на всех нодах вашего гипотетического кластера «openfeature». Чтобы вернуть временной ряд, а не одно значение, мы используем оператор [] для вычисления разницы отдельных значений временных рядов. Результатом является другой временной ряд, который можно визуализировать с помощью линейного графика. Доступный CPU важен для эффективного использования ресурсов и предотвращения конфликтов за ресурсы. Временной ряд, визуализированный с помощью линейного графика, — это один из способов показать, как доступный CPU меняется со временем.

timeseries { cpu_allocatable = min(dt.kubernetes.node.cpu_allocatable), requests_cpu = max(dt.kubernetes.container.requests_cpu) }, by:{dt.entity.kubernetes_cluster, dt.entity.kubernetes_node}
| fieldsAdd // add friendly names
entityName(dt.entity.kubernetes_cluster), entityName(dt.entity.kubernetes_node)
| fieldsAdd result = cpu_allocatable[] - requests_cpu[]
| fieldsRemove cpu_allocatable, requests_cpu

Пример 7: Средняя загрузка CPU хоста по размеру хоста

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

timeseries usage=avg(dt.host.cpu.usage, scalar:true), by:{dt.entity.host}
| fieldsAdd cpuCores = entityAttr(dt.entity.host, "cpuCores")
| summarize by:{cpuCores}, avg(usage), count_hosts=count()

Пример 8: Запрос нескольких метрик загрузки CPU одним запросом

В этом примере вы научитесь использовать команду append для возврата нескольких метрик CPU одним запросом. Объединение запросов в одну команду может быть полезно для сравнения измерений из разных контекстов, так как они будут построены вместе. Поскольку вы запрашиваете много метрик с одного хоста и не выполняете арифметических операций, команда append здесь предпочтительнее, чем запрос нескольких метрик одной командой timeseries. Команда append — это сравнительно более гибкий вариант, так как не требует эквивалентных аргументов by или filter. Кроме того, объединение append более эффективно с точки зрения DQL.

timeseries idle=avg(dt.host.cpu.idle), by:{dt.entity.host}, filter:{dt.entity.host == "HOST-EFAB6D2FE7274823"}
| append [ timeseries system=avg(dt.host.cpu.system), by:{dt.entity.host}, filter:{dt.entity.host == "HOST-EFAB6D2FE7274823"} ]
| append [ timeseries user=avg(dt.host.cpu.user), by:{dt.entity.host}, filter:{dt.entity.host == "HOST-EFAB6D2FE7274823"} ]

Пример 9: Коэффициент отказов соединений по хосту

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

timeseries { new = sum(dt.process.network.sessions.new), reset = sum(dt.process.network.sessions.reset, default:0), timeout = sum(dt.process.network.sessions.timeout, default:0) }, by:{dt.entity.host}
| fieldsAdd result = 100 * (reset[] + timeout[]) / new[]
| filter arrayAvg(result) > 0
| sort arrayAvg(result) desc

Пример 10: Мониторинг доступности хостов

В этом примере вы будете мониторить доступность хостов и подсчитывать те, которые в данный момент работают. Вы можете использовать команду timeseries с параметром nonempty для расчёта доступности хостов. Этот параметр гарантирует, что вы получите результат, даже когда никакие данные не соответствуют фильтру — например, когда ни один хост не работает. Это обеспечивает более точное представление о доступности хостов.

timeseries availability = sum(dt.host.availability, default:0), nonempty:true, filter:{availability.state == "up"}

Пример 11: Проба готовности

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

timeseries failure_count=sum(log.readiness_probe.failure_count, default:0), success_count=sum(log.readiness_probe.success_count, default:0), by:{dt.entity.host}, union:true

Аргумент union:true охватывает все хосты, даже если у них не было ни отказов, ни успехов.

Пример 12: Коэффициент отказов

В этом примере вы запрашиваете коэффициент отказов в секунду для конкретной конечной точки («/api/accounts»). Используя параметр rate, можно нормализовать данные временного ряда к определённой длительности. Мониторинг коэффициентов отказов запросов критически важен для понимания производительности приложения, выявления узких мест и обеспечения оптимального пользовательского опыта. Ключ-АСТРОМ по умолчанию показывает количество запросов в минуту, так как метрики сервисов Ключ-АСТРОМ собирают данные о запросах с минутной гранулярностью.

timeseries sum(dt.service.request.failure_count, rate:1s), filter:{startsWith(endpoint.name, "/api/accounts")}

Пример 13: Планирование ёмкости

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

timeseries avail=avg(dt.host.disk.avail), by:{dt.entity.host}, from:-24h
| append [ timeseries avail.yesterday=avg(dt.host.disk.avail), by:{dt.entity.host}, shift:-168h ]
| filter startsWith(entityName(dt.entity.host), "prod-")

Пример 14: Проверка доступности и резервирования хостов

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

timeseries num_hosts = count(dt.host.cpu.usage), by:{cloud.availability_zone}, filter:{startsWith(cloud.availability_zone, "region-1")}

Пример 15: Оптимизация производительности

В этом примере вы используете агрегацию percentile для отслеживания 90-го процентиля времени отклика гипотетической конечной точки /api/accounts. Отслеживание процентилей времени отклика сервиса помогает выявлять узкие места и области для улучшения. Если конкретная транзакция постоянно превышает этот порог, вы можете решить, требует ли она расследования и дополнительной оптимизации.

timeseries p90 = percentile(dt.service.request.response_time, 90), filter:{startsWith(endpoint.name, "/api/accounts")}

Пример 16: Правильный подбор размера развёртываний

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

timeseries avail=avg(dt.host.disk.avail, scalar:true), by:{dt.entity.disk, dt.entity.host}, filter:{startsWith(dt.entity.host, "my-app-")}
| fieldsAdd disk_usage=if(avail>450000000000, "underused", else: "optimal")
| limit 3

Пример 17: Разделение загрузки CPU по аннотациям Kubernetes

В этом примере вы разделяете загрузку CPU по аннотации Kubernetes. Вы можете использовать аннотацию Kubernetes app.kubernetes.io/component для оценки производительности компонентов вашего приложения. Аннотации — это атрибуты облачных приложений, и обычно они не загружаются вместе с метрикой. Вам следует разделить по облачному приложению и найти соответствующую аннотацию. Многие функции команды summarize принимают итеративные выражения, такие как cpu_usage[], для сохранения временного ряда.

timeseries cpu_usage = sum(dt.kubernetes.container.cpu_usage, rollup:max), by:{dt.entity.cloud_application}
| fieldsAdd annotations = entityAttr(dt.entity.cloud_application, "kubernetesAnnotations")
| fieldsAdd component = annotations[`app.kubernetes.io/component`]
| summarize cpu_usage = sum(cpu_usage[]), by:{timeframe, interval, component}