IKuznetsov: Новая страница: «В следующем примере конфигурации показано, как настроить экземпляр '''Collector''' и его собст...»

2025-10-06T17:11:29Z

Новая страница: «В следующем примере конфигурации показано, как настроить экземпляр '''Collector''' и его собст...»

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

В следующем примере конфигурации показано, как настроить экземпляр '''Collector''' и его собственный пакетный процессор для постановки в очередь и пакетной обработки запросов '''OTLP''', а также повышения пропускной способности.
{| class="wikitable"
|<u>Рекомендуемая конфигурация</u>

Для оптимальной производительности вашего экземпляра '''Collector''' мы рекомендуем применять эту конфигурацию во всех настройках.

Если вы используете другие процессоры, убедитесь, что пакетный процессор настроен последним в вашем конвейере.
|}

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

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

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

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

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

http:

endpoint: 0.0.0.0:4318

processors:

batch/traces:

send_batch_size: 5000

send_batch_max_size: 5000

timeout: 60s

batch/metrics:

send_batch_size: 3000

send_batch_max_size: 3000

timeout: 60s

batch/logs:

send_batch_size: 1800

send_batch_max_size: 2000

timeout: 60s

exporters:

otlphttp:

endpoint: ${env:DT_ENDPOINT}

headers:

Authorization: "Api-Token ${env:DT_API_TOKEN}"

service:

pipelines:

traces:

receivers: [otlp]

processors: [batch/traces]

exporters: [otlphttp]

metrics:

receivers: [otlp]

processors: [batch/metrics]

exporters: [otlphttp]

logs:

receivers: [otlp]

processors: [batch/logs]

exporters: [otlphttp]
|}

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

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

Это сделано для демонстрационных целей. Вы можете указать здесь любой другой допустимый получатель (например, <code>zipkin</code>).

=== Процессоры ===
В разделе <code>processors</code> мы указываем отдельный [https://github.com/open-telemetry/opentelemetry-collector/tree/v0.136.0/processor/batchprocessor <code>batch</code> процессор] для каждого телеметрического сигнала со следующими параметрами:

* <code>send_batch_size</code>: устанавливает минимальное количество записей, которые процессор поместит в очередь перед отправкой всего пакета.
* <code>send_batch_max_size</code>: устанавливает максимальное количество записей, которое может содержать пакет. При большем количестве записей пакет будет разбит на более мелкие.
* <code>timeout</code>: определяет интервал времени, по истечении которого будет отправлен пакет. Пакет отправляет <code>timeout</code> только в том случае, если условие <code>send_batch_size</code> не достигнуто.

При такой конфигурации сборщик помещает записи телеметрии в очередь пакетами, обеспечивая хороший баланс между размером и количеством экспортных запросов к API Ключ-АСТРОМ.
{| class="wikitable"
|<u>Значения размера пакетов</u>
На конечный размер пакета влияет не только количество отдельных записей телеметрии, но и количество связанных с ними атрибутов и их размер.

Например, атрибуты диапазонов/метрик/логов могут увеличить размер пакета при том же количестве записей в зависимости от количества/величины атрибутов.

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

Метрики самоконтроля АктивногоШлюза можно использовать для диагностики отклоненных запросов. Например, можно использовать фильтрацию <code>dsfm:active_gate.rest.request_count</code> по размеру <code>operation</code> (<code>POST /otlp/v1/<...></code> для захвата '''OTLP''') и разделение по <code>response_code</code>. Запросы большого размера отклоняются с кодом статуса HTTP <code>413</code>.

Другой альтернативой является проверка логов '''Collector''' на наличие сообщений об ошибках, таких как: <code>HTTP Status Code 413, Message=Max Payload size of</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.dynatrace.com/api/v2/otlp</nowiki></code>)
* <code>DT_API_TOKEN</code> содержит токен API

=== Сервисные контейнеры ===
В разделе <code>service</code> мы собираем наши объекты приемника и экспортера в конвейеры для трассировок, метрик и логов и включаем наш пакетный процессор, ссылаясь на <code>processors</code> для каждого соответствующего конвейера.

Пакеты запроса OTLP - История изменений

IKuznetsov: Новая страница: «В следующем примере конфигурации показано, как настроить экземпляр '''Collector''' и его собст...»