Примеры данных

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

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

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

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

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

• Один из следующих дистрибутивов Collector с процессорами transform, filter, и tail_sampling, а также соединителем spanmetrics: 
  • Collector Ключ-АСТРОМ
  • OpenTelemetry Contrib
  • Пользовательская версия Builder
• URL-адрес конечной точки API Ключ-АСТРОМ, на которую следует экспортировать данные.
• Токен API с соответствующей областью доступа (требуется только для SaaS и АктивногоШлюза)

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

Демо конфигурация

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]

Компоненты

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

Приемники

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

Процессоры

• tail_sampling для выборки распределенных следов на основе свойств следа.

Разъемы

В разделе connectors мы указываем соединитель spanmetrics для вычисления показателей сервиса из диапазонов.

Экспортеры

В разделе exporters мы указываем экспортер otlphttp по умолчанию и настраиваем его с помощью URL-адреса нашего API Ключ-АСТРОМ и требуемого токена аутентификации.

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

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

Сервисные контейнеры

Под service, мы собираем три контейнера:

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

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

Смешанный режим выборки

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

Метрики сервисов, полученные с помощью трассировки

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

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

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

Чтобы снизить эту проблему, если вы хотите сэмплировать трассировки OpenTelemetry, следует рассчитать метрики сервиса перед сэмплированием и использовать их, а не метрики, полученные из трассировки, рассчитанные Ключ-АСТРОМ. Если для сэмплирования используется Collector, метрики, полученные из трассировки, должны быть рассчитаны Collector до применения сэмплирования или SDK. Это можно сделать с помощью коннектора spanmetrics, как показано в примере выше.