Самоконтроль OpenTelemetry Collector

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

Основные характеристики включают в себя:

• Время бесперебойной работы процесса и время ЦП с момента запуска: отслеживайте продолжительность работы процесса и потребляемое время ЦП.
• Использование памяти: отслеживайте потребление памяти и использование кучи для обеспечения оптимальной производительности.
• Получатели: просмотр принятых и отклоненных товаров, отсортированных по типу данных.
• Процессоры: отслеживают входящие и исходящие элементы для понимания потока данных.
• Экспортеры: отслеживают отправленные, не поставленные в очередь и не отправленные элементы, классифицируя их по типу данных. Кроме того, отслеживают размер и емкость очереди.
• Запросы и ответы HTTP/gRPC: количество, продолжительность и размер запросов и ответов для анализа эффективности связи.

Дашборды используют показатели внутренней телеметрии Collector.

Обзор доступных метрик смотрите в списке внутренних метрик.

Доступ к дашбордам

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

После установки приложения в разделе «Готовые дашборды» приложения «Дашборды» будут доступны следующие панели:

• Самоконтроль OTel Collector (все коллекторы) — показывает обзор всех обнаруженных экземпляров OpenTelemetry Collector.
• Самоконтроль OTel Collector (отдельный коллектор) — позволяет просмотреть конкретный экземпляр Collector.

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

Дашборды используют возможности самоконтроля OpenTelemetry Collector, а также определённые атрибуты экспортируемых данных метрик. Обязательные атрибуты:

• service.name
• service.instance.id

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

Панели мониторинга используют только те показатели, которые имеют значение service.name из этого списка:

astromkey-otel-collector,otelcorecol,otelcontribcol,otelcol,otelcol-contrib

В верхней части панелей мониторинга можно фильтровать данные по определённым записям service.name. Вы также можете редактировать переменную и добавлять названия служб, если у вашего коллектора другое название service.name, и оно не отображается на дашборде.

Отправка внутренней телеметрии (данных самоконтроля) в Ключ-АСТРОМ

Каждый Collector OpenTelemetry имеет возможности самоконтроля, но их необходимо активировать.

Данные самоконтроля можно экспортировать из Collector по протоколу OTLP.

• Приведенная ниже конфигурация предполагает, что переменные среды DT_ENDPOINT и DT_API_TOKEN установлены .
• Для отправки данных в Ключ-АСТРОМ через OTLP вам потребуется указать конечную точку Ключ-АСТРОМ и токен Ingest с заданной областью действия metrics.ingest. Подробнее см. в документации по экспорту OTLP .
• Переменная среды DT_ENDPOINTдолжна содержать базовый URL и базовый /api/v2/otlp. Пример: https://{your-environment-id}.live.astromkey.com/api/v2/otlp

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

service:   # turn on self-monitoring   telemetry:     metrics:       # metrics verbosity level. Higher verbosity means more metrics.       # The dashboard relies on metrics at level detailed.       level: detailed       # set up OTLP exporter       readers:         - periodic:             interval: 60000             exporter:               otlp:                 protocol: http/protobuf                 temporality_preference: delta                 endpoint: "${env:DT_ENDPOINT}/v1/metrics"                 headers:                   - name: Authorization                     value: "Api-Token ${env:DT_API_TOKEN}"

Обратите внимание, что OpenTelemetry Collector может автоматически объединять файлы конфигурации. Если указанная выше конфигурация хранится в файле с именем selfmon-config.yaml, вы можете запустить Collector следующим образом:

./astromkey-otel-collector --config=your-already-existing-config.yaml --config=selfmon-config.yaml

Конечно, вы также можете добавить конфигурацию непосредственно в существующую конфигурацию Collector.

Ключ-АСТРОМ принимает данные метрик с дельта-временностью через OTLP/HTTP.

• Collector и Collector Contrib версий 0.107.0 и выше, а также Ключ-АСТРОМ Collector версий 0.12.0 и выше поддерживают экспорт данных метрик в этом формате.
• Более ранние версии игнорируют флаг temporality_preference и, следовательно, требуют дополнительной обработки (кумулятивного преобразования в дельта-преобразование) перед приёмом. Такое преобразование можно выполнить с помощью экземпляра Collector, но это усложнит настройку, поэтому изначально оно не рассматривается в данном документе.

Обогащение данных самоконтроля OpenTelemetry Collector атрибутами Kubernetes

Collector изначально добавляет данные service.instance.id ко всем экспортируемым метрикам. Это позволяет различать экземпляры Collector.

Однако service.instance.id произвольно созданный UUID, поэтому его нелегко интерпретировать. Экспортированные данные можно дополнить дополнительными атрибутами, например, атрибутами Kubernetes, которые легче интерпретировать человеку.

Существует два основных способа добавления атрибутов Kubernetes к телеметрическим данным OpenTelemetry Collector:

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

Чтение атрибутов из среды контейнера

API Kubernetes downwards позволяет внедрять информацию о среде Kubernetes, в которой работает определенный модуль.

Информация о поде и контейнере может быть предоставлена ​​сборщику через переменные окружения. В документации Kubernetes объясняется, как указать такие данные, как имя узла, пространство имён или имя пода, в качестве переменных окружения. Эти переменные затем доступны для чтения внутри контейнера.

В следующем примере спецификации модуля значения <> являются заполнителями для фактических данных спецификации модуля.

apiVersion: v1 kind: Pod metadata:   name: <your-pod-name> spec:   containers:     - name: <your-container>       image: <your-image>       env:         - name: MY_NODE_NAME           valueFrom:             fieldRef:               fieldPath: spec.nodeName         - name: MY_POD_NAME           valueFrom:             fieldRef:               fieldPath: metadata.name         - name: MY_POD_NAMESPACE           valueFrom:             fieldRef:               fieldPath: metadata.namespace

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

Приведённая ниже конфигурация предполагает, что вы внедрили переменные окружения MY_NODE_NAME, MY_POD_NAME, и MY_POD_NAMESPACE в контейнер OpenTelemetry Collector и добавили атрибуты к экспортированным телеметрическим данным. Для расширения данных телеметрии в реальном времени дополнительный экземпляр Collector не требуется.

service:   telemetry:     resource:       # This section reads the previously injected environment variables       # and attaches them to the telemetry the Collector generates about itself.       k8s.namespace.name: "${env:MY_POD_NAMESPACE}"       k8s.pod.name: "${env:MY_POD_NAME}"       k8s.node.name: "${env:MY_NODE_NAME}"     # the rest of the configuration did not change compared to above.     metrics:       level: detailed       readers:         - periodic:             exporter:               otlp:                 endpoint: <...>

Обогащение данных с помощью процессора k8sattributes

В этом подходе экземпляры Collector настроены на отправку внутренних телеметрических данных самим себе через приёмник otlp, чтобы дополнять входящую телеметрию атрибутами Kubernetes с помощью процессора k8sattributesprocessor. Он извлекает эти данные из API Kuberenetes и прикрепляет их к проходящим через него телеметрическим данным.

Для этого варианта необходимо настроить конвейер для обогащения данных самоконтроля с помощью процессора k8sattributesprocessor в конфигурации Collector:

receivers:   otlp:     protocols:       grpc:         endpoint: ${env:MY_POD_IP}:4317       http:         cors:           allowed_origins:             - http://*             - https://*         endpoint: ${env:MY_POD_IP}:4318 processors:   batch:   k8sattributes:     extract:       metadata:         - k8s.pod.name         - k8s.pod.uid         - k8s.pod.ip         - k8s.deployment.name         - k8s.replicaset.name         - k8s.statefulset.name         - k8s.daemonset.name         - k8s.job.name         - k8s.cronjob.name         - k8s.namespace.name         - k8s.node.name         - k8s.cluster.uid         - k8s.container.name       annotations:         - from: pod           key_regex: metadata.astromkey.com/(.*)           tag_name: $$1     pod_association:       - sources:         - from: resource_attribute           name: k8s.pod.name         - from: resource_attribute           name: k8s.namespace.name       - sources:         - from: resource_attribute           name: k8s.pod.ip       - sources:         - from: resource_attribute           name: k8s.pod.uid       - sources:         - from: connection   memory_limiter:     check_interval: 5s     limit_percentage: 80     spike_limit_percentage: 25   transform:     error_mode: ignore     metric_statements:       - context: resource         statements:           - set(attributes["k8s.workload.kind"], "job") where IsString(attributes["k8s.job.name"])           - set(attributes["k8s.workload.name"], attributes["k8s.job.name"]) where IsString(attributes["k8s.job.name"])           - set(attributes["k8s.workload.kind"], "cronjob") where IsString(attributes["k8s.cronjob.name"])           - set(attributes["k8s.workload.name"], attributes["k8s.cronjob.name"]) where IsString(attributes["k8s.cronjob.name"])           - set(attributes["k8s.workload.kind"], "daemonset") where IsString(attributes["k8s.daemonset.name"])           - set(attributes["k8s.workload.name"], attributes["k8s.daemonset.name"]) where IsString(attributes["k8s.daemonset.name"])           - set(attributes["k8s.workload.kind"], "statefulset") where IsString(attributes["k8s.statefulset.name"])           - set(attributes["k8s.workload.name"], attributes["k8s.statefulset.name"]) where IsString(attributes["k8s.statefulset.name"])           - set(attributes["k8s.workload.kind"], "replicaset") where IsString(attributes["k8s.replicaset.name"])           - set(attributes["k8s.workload.name"], attributes["k8s.replicaset.name"]) where IsString(attributes["k8s.replicaset.name"])           - set(attributes["k8s.workload.kind"], "deployment") where IsString(attributes["k8s.deployment.name"])           - set(attributes["k8s.workload.name"], attributes["k8s.deployment.name"]) where IsString(attributes["k8s.deployment.name"])           # remove the delete statements if you want to preserve these attributes           - delete_key(attributes, "k8s.deployment.name")           - delete_key(attributes, "k8s.replicaset.name")           - delete_key(attributes, "k8s.statefulset.name")           - delete_key(attributes, "k8s.daemonset.name")           - delete_key(attributes, "k8s.cronjob.name")           - delete_key(attributes, "k8s.job.name") exporters:   otlphttp/astromkey:     endpoint: ${env:DT_ENDPOINT}     headers:       Authorization: "Api-Token ${env:DT_API_TOKEN}" service:   pipelines:     metrics:       receivers:         - otlp       processors:         - k8sattributes         - transform         - memory_limiter         - batch       exporters:         - otlphttp/astromkey   # turn on self-monitoring   telemetry:     metrics:       # metrics verbosity level. Higher verbosity means more metrics.       # The dashboard relies on metrics at level detailed.       level: detailed       readers:         - periodic:             interval: 10000             timeout: 5000             exporter:               otlp:                 protocol: http/protobuf                 temporality_preference: delta                 endpoint: ${env:MY_POD_IP}:4318

Когда следует масштабировать с помощью дашбордов

Единый дашборд Collector содержит несколько плиток, которые можно использовать в качестве индикатора для указания необходимости масштабирования:

• Телеметрические данные, проходящие через плитки Collector, предоставляют обзор того, сколько элементов данных (интервалов/логов/метрик) проходят через Collector и сколько из них принимаются, отправляются и отклоняются. Если наблюдается увеличение количества отклоненных интервалов, это обычно указывает на то, что Collector превысил свой лимит памяти, при условии, что процессор memorylimiter является частью конвейеров.
• Плитки показателей размера очереди включают метрики текущего размера очереди экспортера и емкости очереди экспортера . Эти метрики могут дать представление о том, сколько элементов в данный момент находится в очереди экспортера. Если это число увеличивается, это может означать, что либо недостаточно доступных рабочих процессов для отправки данных, либо серверная часть, на которую отправляются данные, работает слишком медленно.

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

Дополнительную информацию о масштабировании Collector см. в разделе Масштабирование.