Важливі для Kubernetes компоненти

OpenTelemetry Collector підтримує багато різних приймачів та процесорів для полегшення моніторингу Kubernetes. У цьому розділі розглядаються компоненти, які є найважливішими для збору даних Kubernetes та їх покращення.

Компоненти, розглянуті на цій сторінці:

Процесор атрибутів Kubernetes: додає метадані Kubernetes до вхідної телеметрії застосунків.
Приймач kubeletstats: отримує метрики вузлів, podʼів та контейнерів з API сервера у kubelet.
Приймач filelog: збирає логи Kubernetes та журнали застосунків, записані в stdout/stderr.
Приймач кластера Kubernetes: збирає метрики на рівні кластера та події сутностей.
Приймач обʼєктів Kubernetes: збирає обʼєкти, такі як події, з API сервера Kubernetes.
Приймач Prometheus: отримує метрики у форматі Prometheus.
Приймач метрик хосту: збирає метрики хосту з вузлів Kubernetes.

Для трасування застосунків, метрик або журналів ми рекомендуємо OTLP приймач, але будь-який приймач, що підходить для ваших даних, є відповідним.

Процесор атрибутів Kubernetes

Шаблон розгортання	Підходить
DaemonSet (агент)	Так
Deployment (шлюз)	Так
Sidecar	Ні

Процесор атрибутів Kubernetes автоматично виявляє podʼи Kubernetes, витягує їх метадані та додає витягнуті метадані до відрізків, метрик та журналів як атрибути ресурсів.

Процесор атрибутів Kubernetes є одним з найважливіших компонентів для колектора, що працює в Kubernetes. Будь-який колектор, що отримує дані застосунків, повинен використовувати його. Оскільки він додає контекст Kubernetes до вашої телеметрії, процесор атрибутів Kubernetes дозволяє вам корелювати трейси вашого застосунку, метрики та журнали з телеметрією Kubernetes, такою як метрики podʼів та трейси.

Процесор атрибутів Kubernetes використовує API Kubernetes для виявлення всіх podʼів, що працюють у кластері, і зберігає запис їх IP-адрес, UID podʼів та цікавих метаданих. Стандартно дані, що проходять через процесор, асоціюються з podʼом через IP-адресу вхідного запиту, але можуть бути налаштовані різні правила. Оскільки процесор використовує API Kubernetes, він потребує спеціальних дозволів (див. приклад нижче). Якщо ви використовуєте Helm чарт OpenTelemetry Collector, ви можете використовувати пресет kubernetesAttributes для початку роботи.

Наступні атрибути додаються стандартно:

k8s.namespace.name
k8s.pod.name
k8s.pod.uid
k8s.pod.start_time
k8s.deployment.name
k8s.node.name

Процесор атрибутів Kubernetes також може встановлювати власні атрибути користувачів ресурсів для трейсів, метрик та журналів, використовуючи мітки Kubernetes та анотації Kubernetes, які ви додали до своїх podʼів та просторів імен.

k8sattributes:
  auth_type: 'serviceAccount'
  extract:
    metadata: # витягнуто з podʼа
      - k8s.namespace.name
      - k8s.pod.name
      - k8s.pod.start_time
      - k8s.pod.uid
      - k8s.deployment.name
      - k8s.node.name
    annotations:
      # Витягує значення анотації podʼа з ключем `annotation-one` та вставляє його як атрибут ресурсу з ключем `a1`
      - tag_name: a1
        key: annotation-one
        from: pod
      # Витягує значення анотації простору імен з ключем `annotation-two` з регулярним виразом та вставляє його як атрибут ресурсу з ключем `a2`
      - tag_name: a2
        key: annotation-two
        regex: field=(?P<value>.+)
        from: namespace
    labels:
      # Витягує значення мітки простору імен з ключем `label1` та вставляє його як атрибут ресурсу з ключем `l1`
      - tag_name: l1
        key: label1
        from: namespace
      # Витягує значення мітки podʼа з ключем `label2` з регулярним виразом та вставляє його як атрибут ресурсу з ключем `l2`
      - tag_name: l2
        key: label2
        regex: field=(?P<value>.+)
        from: pod
  pod_association: # Як асоціювати дані з podʼом (порядок має значення)
    - sources: # Спочатку спробуйте використовувати значення атрибуту ресурсу k8s.pod.ip
        - from: resource_attribute
          name: k8s.pod.ip
    - sources: # Потім спробуйте використовувати значення атрибуту ресурсу k8s.pod.uid
        - from: resource_attribute
          name: k8s.pod.uid
    - sources: # Якщо жоден з них не працює, використовуйте зʼєднання запиту для отримання IP podʼа.
        - from: connection

Існують також спеціальні параметри конфігурації для випадків, коли колектор розгортається як DaemonSet Kubernetes (агент) або як Deployment Kubernetes (шлюз). Для деталей дивіться Сценарії розгортання

Для деталей конфігурації процесора атрибутів Kubernetes дивіться Процесор атрибутів Kubernetes.

Оскільки процесор використовує API Kubernetes, він потребує правильних дозволів для коректної роботи. Для більшості випадків використання, ви повинні надати службовому обліковому запису, що запускає колектор, наступні дозволи через ClusterRole.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: collector
  namespace: <OTEL_COL_NAMESPACE>
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: otel-collector
rules:
  - apiGroups:
      - ''
    resources:
      - 'pods'
      - 'namespaces'
    verbs:
      - 'get'
      - 'watch'
      - 'list'
  - apiGroups:
      - 'apps'
    resources:
      - 'replicasets'
    verbs:
      - 'get'
      - 'list'
      - 'watch'
  - apiGroups:
      - 'extensions'
    resources:
      - 'replicasets'
    verbs:
      - 'get'
      - 'list'
      - 'watch'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: otel-collector
subjects:
  - kind: ServiceAccount
    name: collector
    namespace: <OTEL_COL_NAMESPACE>
roleRef:
  kind: ClusterRole
  name: otel-collector
  apiGroup: rbac.authorization.k8s.io

Приймач kubeletstats

Шаблон розгортання	Підходить
DaemonSet (агент)	Переважний
Deployment (шлюз)	Так, але буде збирати метрики лише з вузла, на якому він розгорнутий
Sidecar	Ні

Кожен вузол Kubernetes запускає kubelet, який включає API сервер. Приймач Kubernetes підключається до цього kubelet через API сервер для збору метрик про вузол та робочі навантаження, що працюють на вузлі.

Існують різні методи автентифікації, але зазвичай використовується службовий обліковий запис. Службовий обліковий запис також потребує правильних дозволів для отримання даних з Kubelet (див. нижче). Якщо ви використовуєте Helm чарт OpenTelemetry Collector, ви можете використовувати пресет kubeletMetrics для початку роботи.

Стандартно метрики будуть збиратися для podʼів та вузлів, але ви можете налаштувати приймач для збору метрик контейнерів та томів. Приймач також дозволяє налаштувати як часто метрики збираються:

receivers:
  kubeletstats:
    collection_interval: 10s
    auth_type: 'serviceAccount'
    endpoint: '${env:K8S_NODE_NAME}:10250'
    insecure_skip_verify: true
    metric_groups:
      - node
      - pod
      - container

Для деталей про те, які метрики збираються, дивіться Стандартні метрики. Для деталей конфігурації дивіться Приймач kubeletstats.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: otel-collector
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: otel-collector
rules:
  - apiGroups: ['']
    resources: ['nodes/stats']
    verbs: ['get', 'watch', 'list']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: otel-collector
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: otel-collector
subjects:
  - kind: ServiceAccount
    name: otel-collector
    namespace: default

Приймач filelog

Шаблон розгортання	Підходить
DaemonSet (агент)	Переважний
Deployment (шлюз)	Так, але буде збирати журнали лише з вузла, на якому він розгорнутий
Sidecar	Так, але це буде вважатися складною конфігурацією

Приймач filelog читає та аналізує журнали з файлів. Хоча це не специфічний для Kubernetes приймач, він все ще є де-факто рішенням для збору будь-яких журналів з Kubernetes.

Приймач filelog складається з операторів, які зʼєднуються разом для обробки журналу. Кожен оператор виконує просту відповідальність, таку як аналіз мітки часу або JSON. Налаштування приймача filelog не є тривіальним. Якщо ви використовуєте Helm чарт OpenTelemetry Collector, ви можете використовувати пресет logsCollection для початку роботи.

Оскільки журнали Kubernetes зазвичай відповідають набору стандартних форматів, типова конфігурація приймача filelog для Kubernetes виглядає так:

filelog:
  include:
    - /var/log/pods/*/*/*.log
  exclude:
    # Виключити журнали з усіх контейнерів з назвою otel-collector
    - /var/log/pods/*/otel-collector/*.log
  start_at: end
  include_file_path: true
  include_file_name: false
  operators:
    # аналізувати журнали контейнерів
    - type: container
      id: container-parser

Для деталей конфігурації приймача filelog дивіться Приймач filelog.

На додачу до конфігурації приймача filelog, ваша установка OpenTelemetry Collector в Kubernetes потребуватиме доступу до журналів, які вона хоче збирати. Зазвичай це означає додавання деяких томів та volumeMounts до вашого маніфесту колектора:

---
apiVersion: apps/v1
kind: DaemonSet
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
        - name: opentelemetry-collector
          ...
          volumeMounts:
            ...
            # Монтувати томи до контейнера колектора
            - name: varlogpods
              mountPath: /var/log/pods
              readOnly: true
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
            ...
      volumes:
        ...
        # Зазвичай колектор потребує доступу до журналів podʼів та журналів контейнерів
        - name: varlogpods
          hostPath:
            path: /var/log/pods
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers
        ...

Приймач кластера Kubernetes

Шаблон розгортання	Підходить
DaemonSet (агент)	Так, але призведе до дублювання даних
Deployment (шлюз)	Так, але більше однієї репліки призведе до дублювання даних
Sidecar	Ні

Приймач кластера Kubernetes збирає метрики та події сутностей про кластер в цілому, використовуючи API сервер Kubernetes. Використовуйте цей приймач для відповідей на питання про фази podʼів, умови вузлів та інші питання на рівні кластера. Оскільки приймач збирає телеметрію для кластера в цілому, лише один екземпляр приймача потрібен у кластері для збору всіх даних.

Існують різні методи автентифікації, але зазвичай використовується службовий обліковий запис. Службовий обліковий запис також потребує правильних дозволів для отримання даних з API сервера Kubernetes (див. нижче). Якщо ви використовуєте Helm чарт OpenTelemetry Collector, ви можете використовувати пресет clusterMetrics для початку роботи.

Для умов вузлів приймач стандартно збирає лише Ready, але його можна налаштувати для збору більше. Приймач також можна налаштувати для звітування набору доступних ресурсів, таких як cpu та memory:

k8s_cluster:
  auth_type: serviceAccount
  node_conditions_to_report:
    - Ready
    - MemoryPressure
  allocatable_types_to_report:
    - cpu
    - memory

Щоб дізнатися більше про метрики, які збираються, дивіться Стандартні метрики. Для деталей конфігурації дивіться Приймач кластера Kubernetes.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: otel-collector-opentelemetry-collector
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: otel-collector-opentelemetry-collector
rules:
  - apiGroups:
      - ''
    resources:
      - events
      - namespaces
      - namespaces/status
      - nodes
      - nodes/spec
      - pods
      - pods/status
      - replicationcontrollers
      - replicationcontrollers/status
      - resourcequotas
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - apps
    resources:
      - daemonsets
      - deployments
      - replicasets
      - statefulsets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - daemonsets
      - deployments
      - replicasets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - batch
    resources:
      - jobs
      - cronjobs
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - autoscaling
    resources:
      - horizontalpodautoscalers
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: otel-collector-opentelemetry-collector
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: otel-collector-opentelemetry-collector
subjects:
  - kind: ServiceAccount
    name: otel-collector-opentelemetry-collector
    namespace: default

Приймач обʼєктів Kubernetes

Шаблон розгортання	Підходить
DaemonSet (агент)	Так, але призведе до дублювання даних
Deployment (шлюз)	Так, але більше однієї репліки призведе до дублювання даних
Sidecar	Ні

Приймач обʼєктів Kubernetes збирає, або шляхом отримання, або спостереження, обʼєкти з API сервера Kubernetes. Найпоширеніший випадок використання цього приймача — це спостереження за подіями Kubernetes, але його можна використовувати для збору будь-якого типу обʼєктів Kubernetes. Оскільки приймач збирає телеметрію для кластера в цілому, лише один екземпляр приймача потрібен у кластері для збору всіх даних.

Наразі для автентифікації можна використовувати лише службовий обліковий запис. Службовий обліковий запис також потребує правильних дозволів для отримання даних з API сервера Kubernetes (див. нижче). Якщо ви використовуєте Helm чарт OpenTelemetry Collector і хочете отримувати події, ви можете використовувати пресет kubernetesEvents для початку роботи.

Для обʼєктів, налаштованих для отримання, приймач буде використовувати API Kubernetes для періодичного отримання переліку всіх обʼєктів у кластері. Кожен обʼєкт буде перетворено на власний журнал. Для обʼєктів, налаштованих для спостереження, приймач створює потік з API Kubernetes, який отримує оновлення, коли обʼєкти змінюються.

Щоб побачити, які обʼєкти доступні для збору у вашому кластері, запустіть kubectl api-resources:

kubectl api-resources
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
bindings                                       v1                                     true         Binding
componentstatuses                 cs           v1                                     false        ComponentStatus
configmaps                        cm           v1                                     true         ConfigMap
endpoints                         ep           v1                                     true         Endpoints
events                            ev           v1                                     true         Event
limitranges                       limits       v1                                     true         LimitRange
namespaces                        ns           v1                                     false        Namespace
nodes                             no           v1                                     false        Node
persistentvolumeclaims            pvc          v1                                     true         PersistentVolumeClaim
persistentvolumes                 pv           v1                                     false        PersistentVolume
pods                              po           v1                                     true         Pod
podtemplates                                   v1                                     true         PodTemplate
replicationcontrollers            rc           v1                                     true         ReplicationController
resourcequotas                    quota        v1                                     true         ResourceQuota
secrets                                        v1                                     true         Secret
serviceaccounts                   sa           v1                                     true         ServiceAccount
services                          svc          v1                                     true         Service
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1        false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1        false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io/v1                false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io/v1              false        APIService
controllerrevisions                            apps/v1                                true         ControllerRevision
daemonsets                        ds           apps/v1                                true         DaemonSet
deployments                       deploy       apps/v1                                true         Deployment
replicasets                       rs           apps/v1                                true         ReplicaSet
statefulsets                      sts          apps/v1                                true         StatefulSet
tokenreviews                                   authentication.k8s.io/v1               false        TokenReview
localsubjectaccessreviews                      authorization.k8s.io/v1                true         LocalSubjectAccessReview
selfsubjectaccessreviews                       authorization.k8s.io/v1                false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io/v1                false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io/v1                false        SubjectAccessReview
horizontalpodautoscalers          hpa          autoscaling/v2                         true         HorizontalPodAutoscaler
cronjobs                          cj           batch/v1                               true         CronJob
jobs                                           batch/v1                               true         Job
certificatesigningrequests        csr          certificates.k8s.io/v1                 false        CertificateSigningRequest
leases                                         coordination.k8s.io/v1                 true         Lease
endpointslices                                 discovery.k8s.io/v1                    true         EndpointSlice
events                            ev           events.k8s.io/v1                       true         Event
flowschemas                                    flowcontrol.apiserver.k8s.io/v1beta2   false        FlowSchema
prioritylevelconfigurations                    flowcontrol.apiserver.k8s.io/v1beta2   false        PriorityLevelConfiguration
ingressclasses                                 networking.k8s.io/v1                   false        IngressClass
ingresses                         ing          networking.k8s.io/v1                   true         Ingress
networkpolicies                   netpol       networking.k8s.io/v1                   true         NetworkPolicy
runtimeclasses                                 node.k8s.io/v1                         false        RuntimeClass
poddisruptionbudgets              pdb          policy/v1                              true         PodDisruptionBudget
clusterrolebindings                            rbac.authorization.k8s.io/v1           false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io/v1           false        ClusterRole
rolebindings                                   rbac.authorization.k8s.io/v1           true         RoleBinding
roles                                          rbac.authorization.k8s.io/v1           true         Role
priorityclasses                   pc           scheduling.k8s.io/v1                   false        PriorityClass
csidrivers                                     storage.k8s.io/v1                      false        CSIDriver
csinodes                                       storage.k8s.io/v1                      false        CSINode
csistoragecapacities                           storage.k8s.io/v1                      true         CSIStorageCapacity
storageclasses                    sc           storage.k8s.io/v1                      false        StorageClass
volumeattachments                              storage.k8s.io/v1                      false        VolumeAttachment

Для деталей конфігурації дивіться Приймач обʼєктів Kubernetes.

Оскільки процесор використовує API Kubernetes, він потребує правильних дозволів для коректної роботи. Оскільки службові облікові записи є єдиним варіантом автентифікації, ви повинні надати службовому обліковому запису правильний доступ. Для будь-якого обʼєкта, який ви хочете забирати, ви повинні переконатися, що його назва додана до ролі кластера. Наприклад, якщо ви хочете забирати podʼи, то роль кластера буде виглядати так:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: otel-collector-opentelemetry-collector
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: otel-collector-opentelemetry-collector
rules:
  - apiGroups:
      - ''
    resources:
      - pods
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: otel-collector-opentelemetry-collector
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: otel-collector-opentelemetry-collector
subjects:
  - kind: ServiceAccount
    name: otel-collector-opentelemetry-collector
    namespace: default

Приймач Prometheus

Шаблон розгортання	Підходить
DaemonSet (агент)	Так
Deployment (шлюз)	Так
Sidecar	Ні

Prometheus є загальним форматом метрик як для Kubernetes, так і для сервісів, що працюють на Kubernetes. Приймач Prometheus є мінімальною заміною для збору цих метрик. Він підтримує повний набір опцій scrape_config Prometheus.

Існує кілька розширених функцій Prometheus, які приймач не підтримує. Приймач повертає помилку, якщо конфігурація YAML/код містить будь-що з наступного:

alert_config.alertmanagers
alert_config.relabel_configs
remote_read
remote_write
rule_files

Для деталей конфігурації дивіться Приймач Prometheus.

Приймач Prometheus є Stateful, що означає, що є важливі деталі, які слід враховувати при його використанні:

Колектор не може автоматично масштабувати процес збору при запуску кількох реплік колектора.
При запуску кількох реплік колектора з однаковою конфігурацією, він буде збирати цілі кілька разів.
Користувачі повинні налаштувати кожну репліку з різною конфігурацією збору, якщо вони хочуть вручну розподілити процес збору.

Щоб полегшити налаштування приймача Prometheus, OpenTelemetry Operator включає додатковий компонент з назвою Target Allocator. Цей компонент можна використовувати для вказівки колектору, які точки доступу Prometheus він повинен слухати.

Для отримання додаткової інформації про дизайн приймача дивіться Дизайн.

Приймач метрик хосту

Шаблон розгортання	Підходить
DaemonSet (агент)	Переважний
Deployment (шлюз)	Так, але буде збирати метрики лише з вузла, на якому він розгорнутий
Sidecar	Ні

Приймач метрик хосту збирає метрики з хосту, використовуючи різні скрепери. Існує деякий перетин з Приймачем kubeletstats, тому якщо ви вирішите використовувати обидва, можливо, варто відключити ці метрики, що дублюють одна одну.

У Kubernetes приймач потребує доступу до тому hostfs для коректної роботи. Якщо ви використовуєте Helm чарт OpenTelemetry Collector, ви можете використовувати пресет hostMetrics для початку роботи.

Доступні скрепери:

Скрепер	Підтримувані ОС	Опис
cpu	Усі, крім macOS¹	Метрики використання CPU
disk	Усі, крім macOS¹	Метрики вводу/виводу диска
load	Усі	Метрики навантаження CPU
filesystem	Усі	Метрики використання файлової системи
memory	Усі	Метрики використання памʼяті
network	Усі	Метрики вводу/виводу мережевого інтерфейсу та метрики зʼєднань TCP
paging	Усі	Метрики використання та вводу/виводу сторінкового простору/свопу
processes	Linux, macOS	Метрики кількості процесів
process	Linux, Windows, macOS	Метрики CPU, памʼяті та вводу/виводу диска для кожного процесу

Для деталей про те, які метрики збираються та деталей конфігурації дивіться Приймач метрик хосту.

Якщо вам потрібно налаштувати компонент самостійно, переконайтеся, що ви монтуєте том hostfs, якщо ви хочете збирати метрики вузла, а не контейнера.

---
apiVersion: apps/v1
kind: DaemonSet
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
        - name: opentelemetry-collector
          ...
          volumeMounts:
            ...
            - name: hostfs
              mountPath: /hostfs
              readOnly: true
              mountPropagation: HostToContainer
      volumes:
        ...
        - name: hostfs
          hostPath:
            path: /
      ...

і потім налаштуйте приймач метрик хосту для використання volumeMount:

receivers:
  hostmetrics:
    root_path: /hostfs
    collection_interval: 10s
    scrapers:
      cpu:
      load:
      memory:
      disk:
      filesystem:
      network:

Для отримання додаткової інформації про використання приймача в контейнері дивіться Збір метрик хосту зсередини контейнера (лише Linux)

Не підтримується у macOS, коли компілюється без cgo, що є стандартним для образів, випущених SIG колектора. ↩︎ ↩︎

Відгук

Чи це було корисним?

Дякуємо. Ми цінуємо ваші відгуки!

Будь ласка, дайте нам знати як ми можемо покращити цю сторінку. Ми цінуємо ваші відгуки!

Востаннє змінено December 26, 2024: [uk] Ukrainian documentation for OpenTelemetry (2a3c5648)