Включение конечных точек приема телеметрии Ключ-АСТРОМ

Ключ-АСТРОМ Operator версии 1.6+

Включите конечные точки телеметрии Ключ-АСТРОМ в Kubernetes для локального сбора данных кластера.

• Прием данных через конечные точки OTLP, Jaeger, StatsD или Zipkin.
• Анализируйте контекстно-зависимые данные с помощью встроенных приложений, DQL, Notebooks и Дашбордов.

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

• Для токена приема данных требуются области действия токена openTelemetryTrace.ingest, logs.ingest, и metrics.ingest, и они должны быть предоставлены через поле dataIngestToken в том же секрете, что и ваш токен API.

Настройка и использование

Следующие два шага объясняют, как настроить и использовать конечные точки сбора телеметрических данных.

Создание DynaKube

Чтобы включить конечные точки для сбора телеметрических данных, укажите список необходимых протоколов в поле DynaKube .spec.telemetryIngest.protocols.

Маршрутизация данных При работе АктивногоШлюза в кластере Kubernetes сборщик OpenTelemetry будет настроен на маршрутизацию всех полученных данных через АктивныйШлюз внутри кластера, а не на прямое подключение к общедоступному АктивномуШлюзу. Кроме того, будут автоматически включены функции, необходимые для сбора телеметрических данных. Если внутрикластерный АктивныйШлюз не развернут (т.е. .spec.activeGate не указан), OpenTelemetry Collector будет настроен на прямую связь с вашим клиентом Ключ-АСТРОМ.

apiVersion: dynatrace.com/v1beta5 kind: DynaKube metadata:   name: dynakube   namespace: dynatrace spec:   apiUrl:  https://ENVIRONMENTID.live.dynatrace.com/api   activeGate:     capabilities:       - kubernetes-monitoring     replicas: 1     resources:       requests:         cpu: 500m         memory: 1.5Gi       limits:         cpu: 1000m         memory: 1.5Gi   telemetryIngest:     protocols:     - jaeger     - zipkin     - otlp     - statsd   templates:     otelCollector:       imageRef:         repository: public.ecr.aws/dynatrace/dynatrace-otel-collector         tag: <tag>

Образ Collector OTel

Образ Collector OTel получен из поддерживаемых нами публичных реестров. Убедитесь, что используемый образ tag существует! Вы также можете использовать свой личный реестр.

Настройка приложений

После применения DynaKube Ключ-АСТРОМ Operator развернёт Ключ-АСТРОМ OpenTelemetry Collector с образом по умолчанию (настраивается с помощью .spec.templates.otelCollector.imageRef) и сервисом Kubernetes с названием <dynakube-name>-telemetry-ingest.dynatrace (настраивается с помощью .spec.telemetryIngest.serviceName) для сбора телеметрических данных. Номер используемого порта зависит от протокола, поддерживаемого вашим приложением. Чтобы найти соответствующие номера портов, см. ссылку ниже.

В следующем фрагменте показано, как можно настроить приложение с помощью переменной среды, которая инструментируется с помощью OpenTelemetry SDK:

env:   - name: OTEL_EXPORTER_OTLP_ENDPOINT     value: http://dynakube-telemetry-ingest.dynatrace.svc:4317

Справочник портов

Следующие порты открыты для приема телеметрических данных:

Name	Protocol	Port
OTLP GRPC	TCP	4317
OTLP HTTP	TCP	4318
Zipkin	TCP	9411
Jaeger GRPC	TCP	14250
Jaeger Thrift Binary	UDP	6832
Jaeger Thrift Compact	UDP	6831
Jaeger Thrift HTTP	TCP	14268
StatsD	UDP	8125

Дополнительные конфигурации

Использование конечных точек HTTPS

По умолчанию конечные точки Ingest работают в режиме HTTP. Если вы хотите зашифровать телеметрический трафик с помощью HTTPS, вы можете обратиться к секретному ключу Kubernetes TLS через .spec.telemetryIngest.tlsRefName. После этого конечные точки Ingest будут настроены на использование указанных сертификатов и взаимодействие HTTPS.

Пример приложения OpenTelemetry, использующего HTTPS В следующем фрагменте показано, как можно настроить приложение, оснащенное OpenTelemetry SDK, через переменную среды: env:   - name: OTEL_EXPORTER_OTLP_ENDPOINT     value: https://dynakube-telemetry-ingest.dynatrace.svc:4318

Настройка имени службы сбора телеметрических данных.

По умолчанию имя службы для сбора телеметрических данных — telemetry-ingest.dynatrace. Имя службы можно изменить, установив .spec.telemetryIngest.serviceName. Указанное значение будет использоваться в качестве имени службы, но службы по-прежнему будут находиться в пространстве имён DynaKube, где также развёрнут Ключ-АСТРОМ OpenTelemetry Collector.

Имейте в виду, что наличие нескольких DynaKubes с одинаковым именем службы приведет к конфликтам имен служб.

Конечные точки доступны по адресу http://telemetry-service.dynatrace.svc.cluster.local:4318.

Пример apiVersion: dynatrace.com/v1beta5 kind: DynaKube metadata:   name: dynakube   namespace: dynatrace spec:   apiUrl:  https://ENVIRONMENTID.live.dynatrace.com/api   telemetryIngest:     serviceName: my-telemetry-service     protocols:     - jaeger     - zipkin     - otlp     - statsd   templates:     otelCollector:       imageRef:         repository: public.ecr.aws/dynatrace/dynatrace-otel-collector         tag: <tag> Образ Collector OTel Образ Collector OTel получен из поддерживаемых нами публичных реестров. Убедитесь, что используемый образ tag существует! Вы также можете использовать свой личный реестр.

Настройки прокси

Любой прокси-сервер, указанный в .spec.proxy, будет передан в OpenTelemetry Collector через переменные среды HTTP_PROXY и HTTPS_PROXY. Если используется внутрикластерный АктивныйШлюз, URL-адрес внутрикластерного АктивногоШлюза будет автоматически добавлен в переменную среды NO_PROXY, чтобы избежать ненужных циклов связи.

Доверенные центры сертификации

Если вам необходимо использовать сертификаты для связи через прокси, их можно указать в .spec.trustedCAs. Системные центры сертификации из образа контейнера OpenTelemetry Collector загружаются вместе с центрами сертификации в trustedCAs. Системные центры сертификации содержат сертификаты, необходимые для связи с публичными АктивнымиШлюзами.

Постоянное хранилище АктивногоШлюза

При использовании приёма телеметрических данных с внутрикластерным АктивнымШлюзом, полученные данные буферизуются на PersistentVolume на АктивномШлюзе до тех пор, пока данные не будут успешно переданы. Для этого к АктивномуШлюзу монтируется PersistentVolumeClaim. В следующем примере показан PVC по умолчанию, настроенный Operator для АктивногоШлюза, если не указан пользовательский PVC:

apiVersion: v1 kind: PersistentVolumeClaim metadata:   name: <ActiveGate-name>   namespace: dynatrace spec:   accessModes:   - ReadWriteOnce   resources:     requests:       storage: 1Gi

Класс хранения по умолчанию

Убедитесь, что определён класс хранилища по умолчанию. В противном случае PersistentVolumeClaim АктивныйШлюз не будет предоставлен.

Пользовательский PersistentVolumeClaim можно настроить в .spec.activegate.volumeClaimTemplate.

Эфемерный объем

В целях тестирования PVC можно заменить локальным эфемерным хранилищем с использованием .spec.activeGate.useEphemeralVolume.

Не рекомендуется использовать .spec.activeGate.useEphemeralVolume в производственных средах.

Время выключения АктивногоШлюза

Если АктивныйШлюз отключается (например, в сценариях масштабирования), ему требуется некоторое время для очистки буферов путём отправки всех буферизованных данных в Ключ-АСТРОМ. В больших средах это может занять некоторое время, и Kubernetes может потенциально завершить работу АктивногоШлюза слишком рано. Чтобы увеличить так называемый льготный период завершения, можно увеличить его продолжительность с помощью параметра '.spec.activegate.terminationGracePeriodSeconds', чтобы дать поду АктивногоШлюза больше времени для корректного завершения работы.