Настройка Collector
Для успешной настройки экземпляра Collector необходимо настроить каждый компонент (приемник, дополнительный процессор и экспортер) по отдельности в файле конфигурации Collector YAML и включить их через дополнительные объекты конвейера.
| Ключ-АСТРОМ Collector
Обратите внимание, что при настройке Ключ-АСТРОМ Collector вы можете настраивать только те компоненты, которые поставляются вместе с ним. Полный список всех поддерживаемых компонентов Collector можно найти разделе Ключ-АСТРОМ Collector. |
Пример конфигурации
Ниже приведен пример файла YAML для очень простой конфигурации Collector, который можно использовать для экспорта трассировок, метрик и логов OpenTelemetry в Ключ-АСТРОМ.
| receivers:
otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: cumulativetodelta: exporters: otlphttp: endpoint: "${env:DT_ENDPOINT}" headers: Authorization: "Api-Token ${env:DT_API_TOKEN}" service: pipelines: traces: receivers: [otlp] processors: [] exporters: [otlphttp] metrics: receivers: [otlp] processors: [cumulativetodelta] exporters: [otlphttp] logs: receivers: [otlp] processors: [] exporters: [otlphttp] |
В этом файле YAML мы настраиваем следующие компоненты:
- Приемник OTLP (
otlp), который может принимать данные через gRPC и HTTP - Процессор для преобразования любых метрик с кумулятивной временностью в дельта-метриках.
- Экспортер HTTP OTLP (
otlphttp), настроенный с конечной точкой Ключ-АСТРОМ и токеном API
В приведенном выше примере конфигурации токен Ключ-АСТРОМ должен иметь разрешения Ingest OpenTelemetry traces (openTelemetryTrace.ingest), Ingest metrics (metrics.ingest) и Ingest logs (logs.ingest).
|
Раздел, посвященный токенам API, содержит дополнительную информацию о том, как получить и настроить токен API.
В разделе служб вы определяете каждый компонент отдельно.
- Расширения можно включить в их собственном разделе, в то время как приемники, процессоры и экспортеры сгруппированы в разделе конвейера.
- Конвейеры могут иметь тип трассировок, метрик или логов.
- Каждый приёмник/процессор/экспортер может использоваться более чем в одном конвейере. Для процессоров, упомянутых в нескольких конвейерах, каждому конвейеру назначается отдельный экземпляр процессора. Это отличается от приёмников/экспортеров, упомянутых в нескольких конвейерах, где для всех конвейеров используется только один экземпляр приёмника/экспортера. Также обратите внимание, что порядок обработки данных определяется порядком процессоров.
- Вы также можете определить одни и те же компоненты несколько раз. Например, у вас может быть два разных приёмника или даже две или более отдельных частей экспортера.
- Даже если компонент правильно настроен в своем разделе, он не будет включен, если он также не определен в разделе служб.
Проверка конфигурации
Важно убедиться, что используемая конфигурация Collector синтаксически и семантически корректна. Например, в YAML для отступов используются пробелы (а не табуляции), что позволяет определить иерархию документа, и необходимо использовать правильный уровень отступа для каждого раздела и компонента. Collector предоставляет встроенную команду validate для проверки конфигурации и корректной настройки компонентов и служб.
| astromkey-otel-collector validate --config=[PATH_TO_YOUR_CONFIGURATION_FILE] |
Если вы запускаете экземпляр контейнера Collector, вы также можете использовать следующую команду Docker для запуска проверки непосредственно из вашего контейнера.
| docker run -v $(pwd):$(pwd) -w $(pwd) ghcr.io/astromkey/astromkey-otel-collector/astromkey-otel-collector:0.37.0 validate --config=[YOUR_CONFIGURATION_FILE] |
Дельта-метрики
Ключ-АСТРОМ требует, чтобы данные метрик отправлялись с дельта-метрикой, а не с кумулятивной.
Если ваше приложение не позволяет настраивать дельта-метрики, вы можете использовать процессор cumulativetodelta, чтобы экземпляр Collector корректировал кумулятивные значения в соответствии со значениями дельты. Приведённый выше пример конфигурации показывает, как настроить процессор и ссылаться на него в конфигурации Collector.
Связанные и сбалансированные по нагрузке коллекторы
При использовании более одного экземпляра Collector важно поддерживать стабильное распространение значений по всем экземплярам.
Это особенно важно при отправке запросов OTLP через разные экземпляры Collector (например, балансировка нагрузки), поскольку каждый экземпляр Collector отслеживает собственное смещение дельты, что может привести к повреждению данных, передаваемых в бэкэнд Ключ-АСТРОМ.
В таких сценариях мы рекомендуем направлять ваши запросы OTLP через один исходящий экземпляр Collector, который пересылает данные в бэкенд Ключ-АСТРОМ и выполняет дельта-преобразование. Остальные экземпляры Collector должны использовать кумулятивную агрегацию для обеспечения стабильного и согласованного распространения значений.
API-токены
Для запросов OTLP к АктивномуШлюзу требуется информация аутентификации, предоставляемая токенами API Ключ-АСТРОМ.
В предыдущем примере конфигурации показано, как настроить заголовок Authorization для экспортера.
| exporters:
otlphttp: headers: Authorization: "Api-Token ${env:DT_API_TOKEN}" |
Хотя вы можете жестко закодировать токен API, мы рекомендуем использовать внешний источник данных, например переменные среды, для повышения безопасности.
В этом примере мы устанавливаем токен API, используя переменную среды DT_API_TOKEN из секрета Kubernetes, и ссылаемся на переменную с помощью ${env:}.