Лучшие практики оптимизации затрат на метрики

Материал из Документация Ключ-АСТРОМ

Лучшие практики оптимизации затрат на метрики

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

Основные концепции

Вот список основных концепций, которые следует понимать перед изучением того, как Ключ-АСТРОМ тарифицирует потребление метрик.

Термин Определение
Метрика Именованное числовое измерение, представляющее определённый аспект системы, наблюдаемый во времени.
Измерение Пара «ключ-значение», используемая для фильтрации, разделения или группировки метрик.
Точка данных метрики Единичное записанное значение, взятое в определённый момент времени.
Временной ряд Уникальная комбинация метрики и значений её измерений.
Кардинальность Количество уникальных временных рядов, которые создаёт метрика.

Понимание загрузки метрик

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

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

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

1. Найдите центры затрат, продукты затрат или источники метрик с высокой кардинальностью

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

metrics
| summarize count = count(), by: {dt.metrics.source}
| sort count desc
metrics

| summarize count = count(), by: {dt.cost.costcenter}


| sort count desc
metrics

| summarize count = count(), by: {dt.cost.product}


| sort count desc

Команда metrics сканирует максимум 100 000 рядов. Если вы сканируете большой объём данных, результаты этих запросов могут быть усечены, и вы не получите полную картину для вашей среды. Если вы достигли этого лимита, используйте запросы DQL, описанные в разделе «Детализация по ключам метрик», чтобы сузить область запроса, например, сосредоточившись на конкретном источнике метрик. Подробнее о лимитах metrics см. в разделе «Команды метрик DQL». Если запрос возвращает только значения null, распределение затрат на метрики ещё не настроено. Подробнее см. в разделе «Обеспечение распределения затрат на метрики».

2. Детализация по ключам метрик

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

metrics
| filter dt.metrics.source == "metric_source_name"
| summarize count = count(), by: {metric.key}
| sort count desc
metrics

| filter dt.cost.costcenter == "cost_center_name"
| summarize count = count(), by: {metric.key}


| sort count desc
metrics

| filter dt.cost.product == "product_name"
| summarize count = count(), by: {metric.key}


| sort count desc

Используйте Блокноты для выполнения запросов DQL.

3. Анализ конкретного ключа метрики

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

timeseries count(metric.key, scalar: true)

Подробнее см. в разделе «Примеры DQL timeseries». В следующем примере показаны результаты этого запроса DQL, выраженные как Визуализация одного значения. Используйте команду DQL timeseries для просмотра кардинальности для конкретной метрики.

Понимание загрузки метрик через Коллектор OTel

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

1. Используйте метрики самоконтроля Ключ-АСТРОМ

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

Описание Ключ метрики
Количество входящих точек данных OTLP dt.sfm.active_gate.metrics.ingest.otlp.datapoints.received.total
Количество принятых точек данных dt.sfm.active_gate.metrics.ingest.otlp.datapoints.accepted
Количество отклонённых точек данных dt.sfm.active_gate.metrics.ingest.otlp.datapoints.rejected
Количество запросов OTLP dt.sfm.active_gate.rest.request_count, отфильтрованный по операции POST /otlp/v1/metrics

1 Эту метрику можно разбить по причине, чтобы понять, почему точки данных были отклонены. 2 Один запрос OTLP может содержать несколько точек данных OTLP. Эта метрика может быть недоступна в некоторых средах.

2. Используйте внутреннюю телеметрию Коллектора OTel

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

  • otelcol_receiver_accepted_metric_points: количество точек данных метрик, полученных Коллектором.
  • otelcol_exporter_sent_metric_points: количество точек данных метрик, экспортированных Коллектором.

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

3. Используйте отладочный экспортёр Коллектора OTel

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

exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlp_http/astromkey]

Оптимизация затрат при загрузке

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

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

1. Отбрасывание метрик

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

Отбрасывание метрик в OpenPipeline

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

  • Отбрасывать метрики с определёнными атрибутами.
matchesValue(environment, "dev")
  • Отбрасывать все метрики с определёнными атрибутами для конкретных ключей метрик.
matchesValue(environment, "dev") AND matchesValue(metric.key, "my.metric.key")

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

Отбрасывание метрик на источнике

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

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

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

В Коллекторе OTel. Вы можете настроить пайплайн Коллектора для отбрасывания метрик или отдельных точек данных. Процессор filter позволяет отбрасывать метрики по имени, отбрасывать точки данных на основе атрибутов ресурса и отбрасывать точки данных на основе атрибутов точки метрики. Примеры использования процессора filter показаны в блоке кода ниже.

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"

2. Снижение кардинальности метрик

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

Снижение кардинальности в OpenPipeline

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

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

  • Перейдите в Настройки > Обработка и контекстуализация > OpenPipeline > Метрики.
  • Направьте целевые метрики в пайплайн.
  • На этапе Обработка добавьте процессор DQL.
  • Для Условия сопоставления установите сопоставление, нацеленное на соответствующие метрики.
metric.key == "my.high.cardinality.metric"
  • В определении процессора DQL укажите поля измерений с высокой кардинальностью, которые нужно удалить, например user.id или request.id.
fieldsRemove user.id, request.id

Чтобы использовать процессор Удалить поля:

  • Перейдите в Настройки > Обработка и контекстуализация > OpenPipeline > Метрики.
  • Направьте целевые метрики в пайплайн.
  • На этапе Обработка добавьте процессор Удалить поля.
  • Для Условия сопоставления установите сопоставление, нацеленное на соответствующие метрики.
metric.key == "my.high.cardinality.metric"
  • В поле Удалить поля введите имя поля измерения с высокой кардинальностью, которое хотите удалить, например user.id или request.id. Затем выберите Добавить, чтобы добавить поле. Можно добавить несколько полей в один процессор.

Снижение кардинальности на источнике

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

processors:
  transform:
    metric_statements:
      - context: datapoint
        statements:
          - delete_key(attributes, "user.id")
          - delete_key(attributes, "request.id")

3. Установите разумные интервалы загрузки

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

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

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

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

1. Непрерывно проверяйте загрузку метрик

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

2. Обеспечьте распределение затрат на метрики

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

3. Проверьте бизнес-ценность загрузки метрик

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

Источник — https://doc.ruscomtech.ru/index.php?title=Лучшие_практики_оптимизации_затрат_на_метрики&oldid=7072