IKuznetsov: Новая страница: «Распределённое приложение под высокой нагрузкой может генерировать огромный объём дан...»

2025-10-08T18:37:24Z

Новая страница: «Распределённое приложение под высокой нагрузкой может генерировать огромный объём дан...»

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

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

В '''OpenTelemetry''' существует два основных метода выборки:

* Выборка данных выполняется в вашем приложении с помощью '''OpenTelemetry''' '''SDK''' и обычно включает в себя сохранение случайной выборки транзакций. Метод отбора данных прост и эффективен, но имеет важные ограничения. Например, поскольку решение о отборе данных принимается в начале транзакции, на него не могут повлиять никакие события, происходящие после этого.
* Хвостовая выборка используется для принятия решений о выборке на основе информации, неизвестной на момент начала транзакции. В '''OpenTelemetry''' хвостовая выборка обычно выполняется с помощью сборщика данных, который временно сохраняет полный набор данных мониторинга до завершения транзакции. Затем сборщик принимает решение о сохранении или удалении данных транзакции на основе набора политик выборки. Поскольку хвостовая выборка обычно не является случайной, важно обеспечить беспристрастность любых рассчитываемых метрик. Это можно сделать, вычислив метрики по всему набору транзакций, как показано ниже, или по отдельному потоку, сформированному случайным образом.

В следующем примере конфигурации показано, как настроить экземпляр '''Collector''' для сбора данных трассировки и импорта их в виде запроса '''OTLP''' в Ключ-АСТРОМ. Он использует [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/connector/spanmetricsconnector коннектор <code>spanmetrics</code>] для вычисления метрик сервиса на основе трассировок перед сбором данных, чтобы гарантировать их точность.

== Предустановка ==

* Один из следующих дистрибутивов '''Collector''' с процессорами [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/processor/transformprocessor transform], [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/processor/filterprocessor filter], и [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/processor/tailsamplingprocessor tail_sampling], а также соединителем [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/connector/spanmetricsconnector spanmetrics]:
** [[Collector Ключ-АСТРОМ|'''Collector''' Ключ-АСТРОМ]]
** [[Collector Ключ-АСТРОМ|OpenTelemetry Contrib]]
** [[Collector Ключ-АСТРОМ|Пользовательская версия Builder]]
* [[Экспорт с помощью OTLP|URL-адрес конечной точки API Ключ-АСТРОМ]], на которую следует экспортировать данные.
* [[Экспорт с помощью OTLP|Токен API]] с соответствующей областью доступа (требуется только для '''SaaS''' и АктивногоШлюза)

Информацию о настройке '''Collector''' с использованием указанной ниже конфигурации см. в разделах [[Развертывание Collector|Развертывание коллектора]] и [[Настройка Collector|Конфигурация коллектора]].

== Демо конфигурация ==
{| class="wikitable"
|receivers:

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

http:

endpoint: 0.0.0.0:4318

processors:

tail_sampling:

# This configuration keeps errors, traces longer than 500ms, and 20% of all remaining traces.

# Adjust with policies of your choice.

policies:

- name: policy1-keep-errors

type: status_code

status_code: {status_codes: [ERROR, UNSET]}

- name: policy2-keep-slow-traces

type: latency

latency: {threshold_ms: 500}

- name: policy3-keep-random-sample

type: probabilistic

probabilistic: {sampling_percentage: 20}

decision_wait: 30s

connectors:

spanmetrics:

aggregation_temporality: "AGGREGATION_TEMPORALITY_DELTA"

namespace: "requests"

metrics_flush_interval: 15s

exporters:

otlphttp:

endpoint: ${env:DT_ENDPOINT}

headers:

Authorization: Api-Token ${env:DT_API_TOKEN}

service:

pipelines:

traces:

receivers: [otlp]

processors: [tail_sampling]

exporters: [otlphttp]

traces/spanmetrics:

receivers: [otlp]

processors: []

exporters: [spanmetrics]

metrics:

receivers: [spanmetrics]

processors: []

exporters: [otlphttp]
|}

== Компоненты ==
Для нашей конфигурации мы настраиваем следующие компоненты.

=== Приемники ===
В разделе <code>receivers</code> мы указываем стандартный приемник <code>otlp</code> в качестве активного компонента приемника для нашего экземпляра '''Collector''' и настраиваем его на прием запросов '''OTLP''' по '''gRPC''' и '''HTTP'''.

=== Процессоры ===

* <code>[https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/processor/tailsamplingprocessor tail_sampling]</code> для выборки распределенных следов на основе свойств следа.

=== Разъемы ===
В разделе <code>connectors</code> мы указываем [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/connector/spanmetricsconnector соединитель <code>spanmetrics</code>] для вычисления показателей сервиса из диапазонов.

=== Экспортеры ===
В разделе <code>exporters</code> мы указываем [https://github.com/open-telemetry/opentelemetry-collector/tree/v0.136.0/exporter/otlphttpexporter экспортер <code>otlphttp</code>] по умолчанию и настраиваем его с помощью URL-адреса нашего API Ключ-АСТРОМ и требуемого токена аутентификации.

Для этой цели мы устанавливаем следующие две переменные среды и ссылаемся на них в значениях конфигурации для <code>endpoint</code> и <code>Authorization</code>.

* <code>DT_ENDPOINT</code> содержит базовый URL-адрес конечной точки API Ключ-АСТРОМ (например, <code><nowiki>https://{your-environment-id}.live.astromkey.com/api/v2/otlp</nowiki></code>)
* <code>DT_API_TOKEN</code> содержит токен API

=== Сервисные контейнеры ===
Под <code>service</code>, мы собираем три контейнера:

* <code>traces</code> собирает приемник '''OTLP''', процессор выборки хвостов и экспортер <code>otlphttp</code> для отправки выборочных диапазонов в Ключ-АСТРОМ.
* <code>traces/spanmetrics</code> использует тот же приемник '''OTLP''' и соединитель <code>spanmetrics</code> для вычисления метрик обслуживания из полученных диапазонов без выборки и пересылает вычисленные метрики в <code>metrics</code>.
* <code>metrics</code> использует процессоры <code>transform</code>, <code>filter</code>, и <code>transform/spanmetrics</code> для форматирования метрик для приема метрик Ключ-АСТРОМ перед отправкой метрик в Ключ-АСТРОМ с помощью экспортера <code>otlphttp</code>.

== Рекомендации по выборке OpenTelemetry ==

=== Смешанный режим выборки ===
'''OpenTelemetry''' и ЕдиныйАгент используют несовместимые подходы к выборке, которые не следует смешивать. Если распределённая трассировка, которая может включать несколько приложений и служб, использует какой-либо из этих методов лишь частично, это, скорее всего, приведёт к несогласованным результатам и неполным распределённым трассировкам. Для обеспечения полного сбора данных каждая распределённая трассировка должна быть оцифрована только одним из методов.

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

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

Например, вероятностный сэмплер, экономящий 5% трафика, приведёт к метрике пропускной способности, составляющей 5% от фактической. Если вы используете хвостовую выборку '''OpenTelemetry''' для сбора 100% медленных или ошибочных трасс, ваши сервисные метрики будут не только показывать неверную пропускную способность, но и будут неправильно определять частоту ошибок и время отклика.

Чтобы снизить эту проблему, если вы хотите сэмплировать трассировки '''OpenTelemetry''', следует рассчитать метрики сервиса перед сэмплированием и использовать их, а не метрики, полученные из трассировки, рассчитанные Ключ-АСТРОМ. Если для сэмплирования используется '''Collector''', метрики, полученные из трассировки, должны быть рассчитаны '''Collector''' до применения сэмплирования или '''SDK'''. Это можно сделать с помощью [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.136.0/connector/spanmetricsconnector коннектора <code>spanmetrics</code>], как показано в примере выше.

Примеры данных - История изменений

IKuznetsov: Новая страница: «Распределённое приложение под высокой нагрузкой может генерировать огромный объём дан...»