|
|
| Строка 1: |
Строка 1: |
|
| |
|
| = Примеры временных рядов DQL =
| |
| Метрики на платформе позволяют точно определять и извлекать любые данные метрик с помощью '''Языка запросов Ключ-АСТРОМ (DQL)'''. После ознакомления с '''основами запросов DQL''' и командой <code>timeseries</code> используйте примеры на этой странице, чтобы начать получать ответы из ваших метрик.
| |
|
| |
| == Пример 1: Средняя загрузка CPU по всем хостам ==
| |
| В этом примере вы запрашиваете среднюю загрузку CPU по всем мониторимым хостам в вашей среде. '''ЕдиныйАгент''' собирает измерения CPU со своего хоста. Эти метрики доступны через ключи метрик, начинающиеся с <code>dt.host.cpu</code>. Наблюдение за агрегированной загрузкой CPU по всем хостам помогает визуально подтвердить, как ваша инфраструктура реагирует на всплески нагрузки и восстанавливается после них, а также отслеживать медленные, незаметные тенденции роста.<pre>timeseries usage=avg(dt.host.cpu.usage)</pre>
| |
|
| |
| == Пример 2: Средняя загрузка CPU по хостам с ограничением до топ-3 хостов ==
| |
| В этом примере вы получаете среднюю загрузку CPU каждого мониторимого хоста и фокусируетесь на трёх хостах с наибольшей загрузкой. '''ЕдиныйАгент''' собирает измерения CPU со своего хоста. Эти метрики доступны через ключи метрик, начинающиеся с <code>dt.host.cpu</code>. Построение графиков загрузки CPU отдельных хостов помогает визуализировать нормальную и аномальную нагрузку. Фокусируясь на трёх хостах с наибольшей загрузкой CPU, вы можете начать исследование недостаточно обеспеченных ресурсами приложений. Аналогично, фокусировка на хостах с наименьшей загрузкой CPU может выявить избыточное выделение ресурсов и привести к возможностям экономии.
| |
|
| |
| '''Запрос данных:'''<pre>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</pre>'''Упрощение результатов:''' в некоторых ситуациях таблица может быть удобнее для чтения, чем линейный график. Давайте запросим данные, которые лучше всего работают с табличным выводом, сосредоточившись на столбцах, которые нас больше всего интересуют: <code>dt.entity.host</code> и <code>usage</code>.<pre>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</pre>Это по сути тот же запрос, что и выше, но без временного ряда.
| |
|
| |
| == Пример 3: Средняя загрузка CPU по IP-адресу хоста ==
| |
| В этом примере вы используете условие <code>in</code> для запроса хостов по их IP-адресу. Используя оператор <code>in</code> с <code>classicEntitySelector</code>, можно фильтровать по <code>ipAddress</code> и другим атрибутам хоста. Использование параметра <code>filter</code> команды <code>timeseries</code> более производительно, чем объединение <code>timeseries</code> с командой <code>filter</code>.<pre>timeseries usage=avg(dt.host.cpu.usage), filter: {in( dt.entity.host, classicEntitySelector("type(host),ipAddress(\"10.102.39.126\")") )}</pre>
| |
|
| |
| == Пример 4: Количество хостов, отправляющих данные о загрузке CPU ==
| |
| В этом примере вы научитесь объединять <code>timeseries</code> с <code>summarize</code>. Сначала вы запрашиваете хосты, отправляющие данные о загрузке CPU, а затем подсчитываете количество хостов в результате. Другие команды '''DQL''' также можно объединять с <code>timeseries</code>, как показано в предыдущих примерах, но в отличие от них, <code>summarize</code> дополнительно агрегирует набор данных, возвращённый <code>timeseries</code>. Эта двухэтапная агрегация будет полезна по мере усложнения ваших запросов.<pre>timeseries usage=avg(dt.host.cpu.usage), by:{dt.entity.host}
| |
| | summarize count()</pre>
| |
|
| |
| == Пример 5: Топ хостов по прочитанным байтам с соответствующими записанными байтами ==
| |
| В этом примере вы обогащаете один результат контекстом из другой метрики. Даже если вы сосредоточены на операциях чтения с диска, соответствующие операции записи на диск могут дать полезный контекст.<pre>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</pre>
| |
|
| |
| == Пример 6: Доступный CPU по ноде Kubernetes ==
| |
| В этом примере вы рассчитываете доступный CPU на всех нодах вашего гипотетического кластера «openfeature». Чтобы вернуть временной ряд, а не одно значение, мы используем оператор <code>[]</code> для вычисления разницы отдельных значений временных рядов. Результатом является другой временной ряд, который можно визуализировать с помощью линейного графика. Доступный CPU важен для эффективного использования ресурсов и предотвращения конфликтов за ресурсы. Временной ряд, визуализированный с помощью линейного графика, — это один из способов показать, как доступный CPU меняется со временем.<pre>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</pre>
| |
|
| |
| == Пример 7: Средняя загрузка CPU хоста по размеру хоста ==
| |
| В этом примере вы научитесь использовать функцию <code>entityAttr</code> для анализа загрузки CPU хоста по размеру хоста. '''ЕдиныйАгент''' собирает локальный контекст со своего хоста: информацию о том, сколько CPU установлено и сколько памяти он имеет. Вы можете добавить эту информацию в свой запрос с помощью функции <code>entityAttr</code>. Информация на уровне хоста иногда может быть слишком детальной и трудной для интерпретации. В таких ситуациях хорошо выбранный атрибут сущности может помочь вам исследовать и анализировать, как отдельные хосты вносят вклад в более широкие тенденции.<pre>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()</pre>
| |
|
| |
| == Пример 8: Запрос нескольких метрик загрузки CPU одним запросом ==
| |
| В этом примере вы научитесь использовать команду <code>append</code> для возврата нескольких метрик CPU одним запросом. Объединение запросов в одну команду может быть полезно для сравнения измерений из разных контекстов, так как они будут построены вместе. Поскольку вы запрашиваете много метрик с одного хоста и не выполняете арифметических операций, команда <code>append</code> здесь предпочтительнее, чем запрос нескольких метрик одной командой <code>timeseries</code>. Команда <code>append</code> — это сравнительно более гибкий вариант, так как не требует эквивалентных аргументов <code>by</code> или <code>filter</code>. Кроме того, объединение <code>append</code> более эффективно с точки зрения '''DQL'''.<pre>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"} ]</pre>
| |
|
| |
| == Пример 9: Коэффициент отказов соединений по хосту ==
| |
| В этом примере вы примените то, что узнали из предыдущих примеров, чтобы рассчитать коэффициент отказов и найти хосты, на которых выполняются процессы с большим количеством неудачных соединений. Этот пример использует параметр <code>default</code> для управления случаем, когда отказов нет. Он вставляет значение 0 везде, где данные отсутствуют. Расчёт коэффициента отказов распространён и критически важен для мониторинга целей уровня обслуживания. Обнаружение постоянных или повторяющихся высоких коэффициентов отказов в тестовых средах может указывать на проблему развёртывания до того, как приложение попадёт в производственную среду.<pre>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</pre>
| |
|
| |
| == Пример 10: Мониторинг доступности хостов ==
| |
| В этом примере вы будете мониторить доступность хостов и подсчитывать те, которые в данный момент работают. Вы можете использовать команду <code>timeseries</code> с параметром <code>nonempty</code> для расчёта доступности хостов. Этот параметр гарантирует, что вы получите результат, даже когда никакие данные не соответствуют фильтру — например, когда ни один хост не работает. Это обеспечивает более точное представление о доступности хостов.<pre>timeseries availability = sum(dt.host.availability, default:0), nonempty:true, filter:{availability.state == "up"}</pre>
| |
|
| |
| == Пример 11: Проба готовности ==
| |
| В этом примере вы запрашиваете метрики логов, чтобы подсчитать успешные и неудачные пробы готовности по хостам. Вы можете использовать параметр <code>union</code>, чтобы охватить все хосты, включая те, у которых нет ни отказов, ни успехов.<pre>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</pre>Аргумент <code>union:true</code> охватывает все хосты, даже если у них не было ни отказов, ни успехов.
| |
|
| |
| == Пример 12: Коэффициент отказов ==
| |
| В этом примере вы запрашиваете коэффициент отказов в секунду для конкретной конечной точки («/api/accounts»). Используя параметр <code>rate</code>, можно нормализовать данные временного ряда к определённой длительности. Мониторинг коэффициентов отказов запросов критически важен для понимания производительности приложения, выявления узких мест и обеспечения оптимального пользовательского опыта. Ключ-АСТРОМ по умолчанию показывает количество запросов в минуту, так как метрики сервисов Ключ-АСТРОМ собирают данные о запросах с минутной гранулярностью.<pre>timeseries sum(dt.service.request.failure_count, rate:1s), filter:{startsWith(endpoint.name, "/api/accounts")}</pre>
| |
|
| |
| == Пример 13: Планирование ёмкости ==
| |
| В этом примере вы запрашиваете текущую доступность диска хоста и используете параметр <code>shift</code> для сравнения с использованием 7 дней назад. Мониторинг доступности диска хоста помогает при планировании ёмкости. Если сегодняшнее использование дискового пространства стабильно выше, чем 7 дней назад, это может сигнализировать о необходимости дополнительных ресурсов хранения. И наоборот, снижение использования может позволить оптимизировать ресурсы.<pre>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-")</pre>
| |
|
| |
| == Пример 14: Проверка доступности и резервирования хостов ==
| |
| В этом примере вы используете агрегацию <code>count</code> для отслеживания количества хостов, мониторимых в каждой зоне доступности облачного региона. Приложения часто развёртывают хосты в нескольких зонах доступности (AZ) для обеспечения высокой доступности. Подсчёт хостов в каждой зоне доступности помогает проверить, сбалансировано ли распределение, и в случае сбоя сети или других проблем в одной зоне доступности рабочая нагрузка может переключиться на другую зону.<pre>timeseries num_hosts = count(dt.host.cpu.usage), by:{cloud.availability_zone}, filter:{startsWith(cloud.availability_zone, "region-1")}</pre>
| |
|
| |
| == Пример 15: Оптимизация производительности ==
| |
| В этом примере вы используете агрегацию <code>percentile</code> для отслеживания 90-го процентиля времени отклика гипотетической конечной точки /api/accounts. Отслеживание процентилей времени отклика сервиса помогает выявлять узкие места и области для улучшения. Если конкретная транзакция постоянно превышает этот порог, вы можете решить, требует ли она расследования и дополнительной оптимизации.<pre>timeseries p90 = percentile(dt.service.request.response_time, 90), filter:{startsWith(endpoint.name, "/api/accounts")}</pre>
| |
|
| |
| == Пример 16: Правильный подбор размера развёртываний ==
| |
| В этом примере вы используете функцию <code>if</code> для маркировки недоиспользуемых пар хост-диск. Выявление избыточно выделенных развёртываний помогает снизить операционные затраты. Удалив избыточно выделенную инфраструктуру, вы можете определить правильный размер развёртывания для вашего приложения.<pre>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</pre>
| |
|
| |
| == Пример 17: Разделение загрузки CPU по аннотациям Kubernetes ==
| |
| В этом примере вы разделяете загрузку CPU по аннотации Kubernetes. Вы можете использовать аннотацию Kubernetes <code>app.kubernetes.io/component</code> для оценки производительности компонентов вашего приложения. Аннотации — это атрибуты облачных приложений, и обычно они не загружаются вместе с метрикой. Вам следует разделить по облачному приложению и найти соответствующую аннотацию. Многие функции команды <code>summarize</code> принимают итеративные выражения, такие как <code>cpu_usage[]</code>, для сохранения временного ряда.<pre>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}</pre>
| |
