IKuznetsov: Новая страница: « = Лучшие практики оптимизации затрат на метрики = По мере внедрения открытых стандартов наблюдаемости одним из ключевых преимуществ этого подхода является контроль над тем, какие данные вы отправляете в Ключ-АСТРОМ: какие метрики собираете, как их фил...»

2026-10-13T23:14:24Z

Новая страница: « = Лучшие практики оптимизации затрат на метрики = По мере внедрения открытых стандартов наблюдаемости одним из ключевых преимуществ этого подхода является контроль над тем, какие данные вы отправляете в Ключ-АСТРОМ: какие метрики собираете, как их фил...»

Новая страница

= Лучшие практики оптимизации затрат на метрики =
По мере внедрения открытых стандартов наблюдаемости одним из ключевых преимуществ этого подхода является контроль над тем, какие данные вы отправляете в Ключ-АСТРОМ: какие метрики собираете, как их фильтруете и как обогащаете перед экспортом. Однако без осознанной настройки вы можете обнаружить, что загружаете больше данных метрик, чем необходимо. Это добавляет шум и увеличивает затраты. Ключ-АСТРОМ предоставляет мощные инструменты для фильтрации, уточнения и контроля загрузки метрик как на источнике, так и в Ключ-АСТРОМ, чтобы ваши данные оставались действенными, экономичными и соответствовали тому, что вашим командам действительно нужно мониторить. Используйте лучшие практики на этой странице, чтобы понимать, оптимизировать и управлять затратами на метрики. Загрузка метрик — основной драйвер затрат, связанных с метриками (поскольку хранение включено бесплатно в течение первых 15 месяцев, а запросы включены бесплатно). Поэтому эта страница посвящена пониманию и оптимизации затрат на загрузку.

== Основные концепции ==
Вот список основных концепций, которые следует понимать перед изучением того, как Ключ-АСТРОМ тарифицирует потребление метрик.
{| class="wikitable"
!Термин
!Определение
|-
|Метрика
|Именованное числовое измерение, представляющее определённый аспект системы, наблюдаемый во времени.
|-
|Измерение
|Пара «ключ-значение», используемая для фильтрации, разделения или группировки метрик.
|-
|Точка данных метрики
|Единичное записанное значение, взятое в определённый момент времени.
|-
|Временной ряд
|Уникальная комбинация метрики и значений её измерений.
|-
|Кардинальность
|Количество уникальных временных рядов, которые создаёт метрика.
|}

== Понимание загрузки метрик ==
Перед оптимизацией загрузки метрик важно понять, какие метрики загружаются и хранятся в Ключ-АСТРОМ и как они распределяются по вашей организации. Количество загруженных точек данных метрик основано на трёх основных факторах:

* Количество метрик.
* Интервалы сбора.
* Кардинальность.

Любое увеличение этих факторов ведёт к более высокому потреблению. Например, метрика, разделённая по измерениям (таким как <code>service</code>, <code>status_code</code> и <code>region</code>), создаёт один временной ряд для каждой отдельной комбинации. Чем больше комбинаций, тем выше кардинальность и тем больше точек данных генерируется за цикл сбора. В этом разделе объясняется, как анализировать загрузку метрик, чтобы помочь вам принимать обоснованные решения по оптимизации. Все запросы '''DQL''' можно выполнять в Ключ-АСТРОМ, например, с помощью '''Блокнотов''', '''Дашбордов''' или '''Workflows'''.

=== 1. Найдите центры затрат, продукты затрат или источники метрик с высокой кардинальностью ===
Начните с определения того, какие центры затрат, продукты затрат или источники метрик вносят наибольший вклад в кардинальность ваших метрик. Это помогает определить, какие бизнес-подразделения загружают больше всего метрик, что позволяет нацелить усилия по оптимизации туда, где они дадут наибольший эффект. Выполните следующие запросы '''DQL''', чтобы увидеть разбивку по центрам затрат, продуктам затрат или источникам метрик.<pre>metrics
| summarize count = count(), by: {dt.metrics.source}
| sort count desc</pre><pre>metrics
| summarize count = count(), by: {dt.cost.costcenter}
| sort count desc</pre><pre>metrics
| summarize count = count(), by: {dt.cost.product}
| sort count desc</pre>Команда <code>metrics</code> сканирует максимум 100 000 рядов. Если вы сканируете большой объём данных, результаты этих запросов могут быть усечены, и вы не получите полную картину для вашей среды. Если вы достигли этого лимита, используйте запросы '''DQL''', описанные в разделе «Детализация по ключам метрик», чтобы сузить область запроса, например, сосредоточившись на конкретном источнике метрик. Подробнее о лимитах <code>metrics</code> см. в разделе «Команды метрик DQL». Если запрос возвращает только значения null, распределение затрат на метрики ещё не настроено. Подробнее см. в разделе «Обеспечение распределения затрат на метрики».

=== 2. Детализация по ключам метрик ===
Определив атрибуты с высокой кардинальностью, отфильтруйте по ним и изучите отдельные ключи метрик. Следующие примеры '''DQL''' показывают, как определить метрики для отфильтрованных центров затрат, продуктов затрат или источников метрик. Эти запросы выявляют, какие конкретные метрики внутри отфильтрованных атрибутов вносят наибольший вклад в кардинальность. Вы также можете использовать эти фильтры, чтобы ограничить объём сканируемых данных, поскольку команда <code>metrics</code> сканирует максимум 100 000 рядов.<pre>metrics
| filter dt.metrics.source == "metric_source_name"
| summarize count = count(), by: {metric.key}
| sort count desc</pre><pre>metrics
| filter dt.cost.costcenter == "cost_center_name"
| summarize count = count(), by: {metric.key}
| sort count desc</pre><pre>metrics
| filter dt.cost.product == "product_name"
| summarize count = count(), by: {metric.key}
| sort count desc</pre>Используйте '''Блокноты''' для выполнения запросов '''DQL'''.

=== 3. Анализ конкретного ключа метрики ===
После детализации с помощью команды <code>metrics</code> вы можете использовать команду <code>timeseries</code>, чтобы получить кардинальность для конкретного ключа.<pre>timeseries count(metric.key, scalar: true)</pre>Подробнее см. в разделе «Примеры DQL timeseries». В следующем примере показаны результаты этого запроса '''DQL''', выраженные как '''Визуализация одного значения'''. Используйте команду '''DQL''' <code>timeseries</code> для просмотра кардинальности для конкретной метрики.

== Понимание загрузки метрик через Коллектор OTel ==
Если вы загружаете метрики через '''Коллектор OTel''', вы можете использовать следующие советы для более детального анализа загрузки метрик.

=== 1. Используйте метрики самоконтроля Ключ-АСТРОМ ===
Ключ-АСТРОМ предоставляет встроенные метрики самоконтроля для загрузки метрик '''OTLP'''. Эти метрики показывают, сколько точек данных '''OTLP''' поступает в '''API''' загрузки, и дают высокоуровневое представление о том, какой объём данных метрик загружается. Их также можно использовать для проверки того, что после применения фильтров на стороне клиента или в '''Коллекторе''' поступает меньше точек данных. Доступные метрики самоконтроля описаны в таблице ниже.
{| class="wikitable"
!Описание
!Ключ метрики
|-
|Количество входящих точек данных OTLP
|<code>dt.sfm.active_gate.metrics.ingest.otlp.datapoints.received.total</code>
|-
|Количество принятых точек данных
|<code>dt.sfm.active_gate.metrics.ingest.otlp.datapoints.accepted</code>
|-
|Количество отклонённых точек данных
|<code>dt.sfm.active_gate.metrics.ingest.otlp.datapoints.rejected</code>
|-
|Количество запросов OTLP
|<code>dt.sfm.active_gate.rest.request_count</code>, отфильтрованный по операции POST /otlp/v1/metrics
|}
<small>1 Эту метрику можно разбить по причине, чтобы понять, почему точки данных были отклонены.</small> <small>2 Один запрос OTLP может содержать несколько точек данных OTLP. Эта метрика может быть недоступна в некоторых средах.</small>

=== 2. Используйте внутреннюю телеметрию Коллектора OTel ===
'''Коллектор''' предоставляет внутреннюю телеметрию, которую можно использовать для понимания того, сколько метрик получено и сколько экспортировано.

* <code>otelcol_receiver_accepted_metric_points</code>: количество точек данных метрик, полученных '''Коллектором'''.
* <code>otelcol_exporter_sent_metric_points</code>: количество точек данных метрик, экспортированных '''Коллектором'''.

Эти метрики доступны только в том случае, если '''Коллектор OTel''' настроен на экспорт данных внутренней телеметрии в Ключ-АСТРОМ. Подробнее см. в разделе «Самоконтроль Коллектора OTel».

=== 3. Используйте отладочный экспортёр Коллектора OTel ===
Чтобы проверить отдельные метрики и их атрибуты, можно использовать отладочный экспортёр '''Коллектора'''. Он выводит метрики непосредственно в консоль '''Коллектора''' и полезен для диагностики и проверки. В приведённом ниже блоке кода представлен пример, который можно интегрировать в конфигурацию '''Коллектора'''.<pre>exporters:
debug:
verbosity: detailed
service:
pipelines:
metrics:
receivers: [otlp]
processors: [batch]
exporters: [debug, otlp_http/astromkey]</pre>

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

* '''В Ключ-АСТРОМ, с помощью OpenPipeline'''. Если вы предпочитаете централизованный, унифицированный подход к управлению пайплайном данных, мы рекомендуем '''OpenPipeline'''.
* '''На источнике, например с помощью Коллектора OTel'''. Если ваш вариант использования требует сокращения объёма данных на раннем этапе, до того как они покинут вашу сеть, оптимизация на источнике часто подходит лучше.

=== 1. Отбрасывание метрик ===
Отбрасывание метрик помогает исключить неиспользуемые данные, такие как метрики, которые вы не использовали в течение последнего года. Хотя правила '''OpenPipeline''' оцениваются во время загрузки в кластере Ключ-АСТРОМ, любые метрики, отброшенные этими правилами (или выше по потоку перед загрузкой), не сохраняются и не удерживаются. В результате они не влекут затрат, связанных с тарификацией «Метрики — загрузка и обработка». Отбрасывание записей означает, что они никогда не сохраняются. Следовательно, они не подлежат восстановлению.

==== Отбрасывание метрик в OpenPipeline ====
'''OpenPipeline''' позволяет отбрасывать метрики на этапе '''Обработка''' с помощью процессора '''Отбросить запись'''. Это позволяет отбрасывать метрики по имени, отбрасывать точки данных на основе атрибутов ресурса и отбрасывать точки данных на основе атрибутов точки метрики. Перейдите в '''Настройки > Обработка и контекстуализация > OpenPipeline > Метрики'''. Направьте целевые метрики в пайплайн. На этапе '''Обработка''' добавьте процессор '''Отбросить запись'''. Установите условие сопоставления в запрос '''DQL''', который идентифицирует метрики, которые вы хотите отбросить. Например, можно:

* Отбрасывать метрики с определёнными атрибутами.
<pre>matchesValue(environment, "dev")</pre>

* Отбрасывать все метрики с определёнными атрибутами для конкретных ключей метрик.
<pre>matchesValue(environment, "dev") AND matchesValue(metric.key, "my.metric.key")</pre>Процессор '''Отбросить запись''' выполняется для всех совпадений. Каждая запись метрики, соответствующая запросу, отбрасывается и никогда не записывается в хранилище.

==== Отбрасывание метрик на источнике ====
Отбрасывание метрик в '''Коллекторе OTel''' предотвращает загрузку определённых временных рядов или точек данных. Вы можете отбрасывать метрики на разных этапах процесса загрузки: у производителя данных. Как правило, чем ближе к клиенту вы отбрасываете данные, тем ниже общие затраты. Однако:

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

В '''SDK OTel'''. В '''SDK OTel''' концепция, используемая для отбрасывания метрик, называется '''View'''. При создании пользовательских метрик всегда учитывайте кардинальность метрик и избегайте использования волатильных измерений (например, временных меток или других атрибутов, которые быстро меняются со временем).

В '''Коллекторе OTel'''. Вы можете настроить пайплайн '''Коллектора''' для отбрасывания метрик или отдельных точек данных. Процессор '''filter''' позволяет отбрасывать метрики по имени, отбрасывать точки данных на основе атрибутов ресурса и отбрасывать точки данных на основе атрибутов точки метрики. Примеры использования процессора '''filter''' показаны в блоке кода ниже.<pre>processors:
filter/drop-unwanted:
error_mode: ignore
metrics:
metric:
# Отбросить метрики, соответствующие этим именам
- 'IsMatch(name, "my.metric.key")'
datapoint:
# Отбросить точки данных с определёнными атрибутами
- 'attributes["environment"] == "dev"'
# Или отбросить точки данных с определёнными атрибутами только для конкретных имён метрик.
- attributes["environment"] == "dev" and metric.name == "my.metric.key"</pre>

=== 2. Снижение кардинальности метрик ===
Измерения с высокой кардинальностью, такие как ID пользователей или ID запросов, значительно увеличивают требования к хранению метрик. Удаление измерения с высокой кардинальностью уменьшает количество хранимых временных рядов и может снизить затраты. Поддержание измерений значимыми и ограниченными критически важно для управления затратами и производительностью.

==== Снижение кардинальности в OpenPipeline ====
При обработке метрик в '''OpenPipeline''' измерения метрик хранятся как поля записи. Когда вы удаляете поле из записи, это измерение не загружается для данной метрики. Хотя это сохраняет сводные данные на уровне метрик и сводные данные по оставшимся измерениям, это удаляет данные по каждому значению для удалённого измерения. Вы можете использовать либо процессор '''DQL''', либо процессор '''Удалить поля'''.

Чтобы использовать процессор '''DQL''':

* Перейдите в '''Настройки > Обработка и контекстуализация > OpenPipeline > Метрики'''.
* Направьте целевые метрики в пайплайн.
* На этапе '''Обработка''' добавьте процессор '''DQL'''.
* Для '''Условия сопоставления''' установите сопоставление, нацеленное на соответствующие метрики.
<pre>metric.key == "my.high.cardinality.metric"</pre>

* В определении процессора '''DQL''' укажите поля измерений с высокой кардинальностью, которые нужно удалить, например <code>user.id</code> или <code>request.id</code>.
<pre>fieldsRemove user.id, request.id</pre>Чтобы использовать процессор '''Удалить поля''':

* Перейдите в '''Настройки > Обработка и контекстуализация > OpenPipeline > Метрики'''.
* Направьте целевые метрики в пайплайн.
* На этапе '''Обработка''' добавьте процессор '''Удалить поля'''.
* Для '''Условия сопоставления''' установите сопоставление, нацеленное на соответствующие метрики.
<pre>metric.key == "my.high.cardinality.metric"</pre>

* В поле '''Удалить поля''' введите имя поля измерения с высокой кардинальностью, которое хотите удалить, например <code>user.id</code> или <code>request.id</code>. Затем выберите '''Добавить''', чтобы добавить поле. Можно добавить несколько полей в один процессор.

==== Снижение кардинальности на источнике ====
Вы можете использовать '''Коллектор OTel''' для удаления нежелательных атрибутов из метрик перед загрузкой. Для этого используйте процессор '''transform''', чтобы удалить атрибуты с высокой кардинальностью, такие как <code>user.id</code> и <code>request.id</code>, на уровне точки данных. Вы можете интегрировать следующий пример кода в конфигурацию '''Коллектора'''.<pre>processors:
transform:
metric_statements:
- context: datapoint
statements:
- delete_key(attributes, "user.id")
- delete_key(attributes, "request.id")</pre>

=== 3. Установите разумные интервалы загрузки ===
Чтобы уменьшить разрешение и гранулярность метрик, настройте интервал сбора на источнике до того, как данные достигнут Ключ-АСТРОМ. Тщательно выбирайте метрики с более длительными интервалами загрузки, чтобы убедиться, что они по-прежнему соответствуют требованиям мониторинга и анализа. Следующие метрики могут быть хорошими кандидатами для уменьшенных интервалов загрузки:

* Менее критичные метрики.
* Более длительные временные рамки, такие как часы или дни.
* Метрики, которые медленно меняются со временем, например использование диска.

Если метрика отправляется в Ключ-АСТРОМ каждые пять минут, только одно измерение собирается и хранится для каждого пятиминутного интервала. Для метрик, собираемых с интервалами менее одной минуты, Ключ-АСТРОМ агрегирует входящие измерения в фиксированные одноминутные интервалы для эффективного хранения и запросов. Следовательно, каждый временной ряд тарифицируется не более чем за одну точку данных в минуту. Более длительные интервалы загрузки могут создавать пробелы при просмотре данных с одноминутным разрешением. Это может повлиять на существующие настройки оповещения.

== Управление затратами ==

=== 1. Непрерывно проверяйте загрузку метрик ===
Чтобы обеспечить надёжные, экономичные и стабильные данные наблюдаемости, непрерывно проверяйте кардинальность и интервалы загрузки в рамках ваших процессов CI/CD (SDLC). Изменения в инструментировании или конфигурации могут непреднамеренно привести к чрезмерной кардинальности, слишком частому сбору метрик или сдвигам в поведении данных. Всё это может увеличить затраты на загрузку. Вы можете использовать Ключ-АСТРОМ для автоматизации этих проверок. Проверяйте запросы '''DQL''' через '''Site Reliability Guardian (SRG)''', интегрированный в рабочие процессы разработки, что помогает обнаруживать аномалии данных на раннем этапе. Оценки '''SRG''' могут предупреждать, когда новый код или изменения конфигурации изменяют кардинальность, интервалы сбора или другие аспекты профиля телеметрии. Подробнее см. в разделе «Site Reliability Guardian». Непрерывная проверка создаёт проактивную обратную связь: команды могут исправить инструментирование или скорректировать конфигурацию '''OpenTelemetry''' до того, как изменения попадут в производственную среду.

=== 2. Обеспечьте распределение затрат на метрики ===
Вы можете распределить затраты на загрузку метрик по конкретным центрам затрат или продуктам. Для этого обогатите загрузку метрик атрибутами распределения затрат (<code>dt.cost.costcenter</code> или <code>dt.cost.product</code>) в качестве метаданных. Подробнее см. в разделе «Настройка распределения затрат».

=== 3. Проверьте бизнес-ценность загрузки метрик ===
Проверьте бизнес-ценность каждой метрики перед загрузкой. Оставьте только метрики, которые поддерживают определённые варианты использования, чтобы минимизировать объём точек данных и снизить затраты.

Лучшие практики оптимизации затрат на метрики - История изменений