примечание редактора: несколько URL-адресов в этом посте содержат термин «мастер». Datadog не использует этот термин, но GitHub исторически использовал «мастер» в качестве имени по умолчанию для основной ветки репозитория. Теперь вместо новых репозиториев используется «main», и GitHub советует пользователям дождаться предстоящих изменений , которые позволят нам безопасно переименовать ветку «master» в наших существующих репозиториях.

Если вы читали часть 3 этой серии, вы узнали, как можно использовать различные команды и надстройки Kubernetes для выборочной проверки работоспособности и использования ресурсов кластерными объектами Kubernetes. В этом посте мы покажем вам, как вы можете получить более полное представление о своем кластере, собирая все данные телеметрии в одном месте и отслеживая их с течением времени. После прочтения этого поста у вас будет:

• Развернул агент Datadog для сбора всех метрик, выделенных во второй части этой серии.
• Развернутые kube-state-metrics для получения дополнительной информации о статусе на уровне кластера.
• Узнали, как Autodiscovery позволяет автоматически отслеживать контейнерные рабочие нагрузки, где бы в кластере они ни выполнялись.
• Включен сбор журналов, чтобы вы могли искать, анализировать и отслеживать все журналы из вашего кластера.
• Настройте Datadog APM для сбора распределенных трассировок из ваших контейнерных приложений.

Интеграция Datadog с Kubernetes, Docker, containerd, etcd, Istio и другими связанными технологиями предназначена для решения серьезных задач мониторинга организованных контейнеров и сервисов, как описано в части 1 .

Легко контролировать каждый слой

Прочитав предыдущие части этой серии, вы знаете, что важно отслеживать различные уровни вашей контейнерной инфраструктуры. Datadog интегрируется с каждой частью вашего кластера Kubernetes, чтобы предоставить вам полную картину работоспособности и производительности:

• Интеграция Kubernetes агента Datadog собирает метрики, события и журналы из компонентов вашего кластера, модулей рабочей нагрузки и других объектов Kubernetes.
• Интеграция со средами выполнения контейнеров, включая Docker и containerd, собирает метрики на уровне контейнера для детальной разбивки ресурсов.
• Где бы ни работали ваши кластеры Kubernetes, включая Amazon Web Services , Google Cloud Platform или Azure , агент Datadog автоматически отслеживает узлы ваших кластеров Kubernetes.
• Autodiscovery Datadog и более 600 встроенных интеграций автоматически отслеживают внедряемые вами технологии.
• APM и распределенная трассировка обеспечивают анализ приложений, работающих в ваших кластерах Kubernetes, на уровне транзакций.

Первым шагом в настройке комплексного мониторинга Kubernetes является развертывание агента Datadog на узлах вашего кластера.

Установите агент Datadog

Агент Datadog — это программное обеспечение с открытым исходным кодом, которое собирает и сообщает метрики, распределенные трассировки и журналы с каждого из ваших узлов, поэтому вы можете просматривать и контролировать всю свою инфраструктуру в одном месте. Помимо сбора данных телеметрии из Kubernetes, Docker и других инфраструктурных технологий, агент автоматически собирает и сообщает показатели ресурсов (такие как ЦП, память и сетевой трафик) с ваших узлов, независимо от базовой платформы инфраструктуры. В этом разделе мы покажем вам, как установить агент Datadog на базе узла вместе с агентом кластера Datadog , чтобы обеспечить комплексный и ресурсоэффективный мониторинг Kubernetes.

В документации Datadog описаны несколько способов установки Агента, включая использование диспетчера пакетов Helm и установку Агента непосредственно на узлы вашего кластера . Однако рекомендуемый подход для большинства случаев использования заключается в развертывании контейнерной версии агента. Развернув контейнерный агент в своем кластере в виде DaemonSet , вы можете гарантировать, что одна копия агента будет работать на каждом хосте в вашем кластере, даже при масштабировании кластера вверх и вниз. Вы также можете указать подмножество узлов, на которых вы хотите запустить агент, используя nodeSelectors .

В разделах ниже мы покажем вам, как установить агент Datadog в вашем кластере, если вы используете Docker. Для других сред выполнения, таких как containerd , обратитесь к документации Datadog.

Кластерный агент Datadog

Инструкции Datadog по развертыванию агента для Kubernetes предоставляют полный манифест для развертывания контейнерного агента на основе узла в качестве DaemonSet . Если вы хотите быстро приступить к работе в целях эксперимента, вы можете следовать этим инструкциям, чтобы развернуть агент в своем кластере. Однако в этом руководстве мы сделаем еще один шаг и покажем вам, как установить агент на всех ваших узлах и развернуть специализированный агент кластера Datadog, который дает несколько дополнительных преимуществ для крупномасштабных производственных сценариев использования. Например, агент кластера:

• снижает нагрузку на сервер API Kubernetes для сбора данных на уровне кластера, выступая в качестве прокси-сервера между сервером API и агентами на основе узлов.
• обеспечивает дополнительную безопасность за счет уменьшения разрешений, необходимых для агентов на основе узлов
• обеспечивает автоматическое масштабирование рабочих нагрузок Kubernetes с использованием любой метрики, собранной Datadog.

Перед развертыванием агента на основе узла и агента кластера необходимо выполнить несколько простых предварительных условий.

Настройка разрешений и секретов

Примечание. Этот раздел включает URL-адреса, в которых используется термин «мастер». Datadog не использует этот термин, но GitHub исторически использовал «мастер» в качестве имени по умолчанию для основной ветки репозитория.

Если в вашем кластере Kubernetes используется управление доступом на основе ролей, вы можете развернуть следующие манифесты, чтобы создать разрешения, которые потребуются агенту на основе узла и агенту кластера для работы в вашем кластере. Следующие манифесты создают два набора разрешений: один для агента кластера, у которого есть определенные разрешения для сбора метрик на уровне кластера и событий Kubernetes из API Kubernetes, и более ограниченный набор разрешений для агента на основе узла. Развертывание этих двух манифестов создаст ClusterRole, ClusterRoleBindingи ServiceAccountдля каждого варианта агента:

kubectl create -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/cluster-agent/cluster-agent-rbac.yaml"
kubectl create -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/cluster-agent/rbac.yaml"

Затем создайте секрет Kubernetes, чтобы предоставить ваш ключ API Datadog агенту, не встраивая ключ API в ваши манифесты развертывания (которыми вы, возможно, захотите управлять в системе управления версиями). Чтобы создать секрет, выполните следующую команду, используя ключ API из своей учетной записи Datadog :

kubectl create secret generic datadog-secret --from-literal api-key="<YOUR_API_KEY>"

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

echo -n '<32_CHARACTER_LONG_STRING>' | base64

Используйте полученный токен для создания секрета Kubernetes, который обе разновидности агента будут использовать для аутентификации друг друга:

kubectl create secret generic datadog-auth-token --from-literal=token=<TOKEN_FROM_PREVIOUS_STEP>

Разверните агент кластера

Теперь, когда вы создали секреты Kubernetes с помощью ключа API Datadog и маркера аутентификации, вы готовы развернуть агент кластера. Скопируйте приведенный ниже манифест в локальный файл и сохраните его какdatadog-кластер-agent.yaml:

apiVersion: v1
kind: Service
metadata:
  name: datadog-cluster-agent
  labels:
    app: datadog-cluster-agent
spec:
  ports:
  - port: 5005 # Has to be the same as the one exposed in the DCA. Default is 5005.
    protocol: TCP
  selector:
    app: datadog-cluster-agent
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: datadog-cluster-agent
  namespace: default
spec:
  selector:
    matchLabels:
      app: datadog-cluster-agent
  template:
    metadata:
      labels:
        app: datadog-cluster-agent
      name: datadog-agent
      annotations:
        ad.datadoghq.com/datadog-cluster-agent.check_names: '["prometheus"]'
        ad.datadoghq.com/datadog-cluster-agent.init_configs: '[{}]'
        ad.datadoghq.com/datadog-cluster-agent.instances: '[{"prometheus_url": "http://%%host%%:5000/metrics","namespace": "datadog.cluster_agent","metrics": ["go_goroutines","go_memstats_*","process_*","api_requests","datadog_requests","external_metrics", "cluster_checks_*"]}]'
    spec:
      serviceAccountName: dca
      containers:
      - image: datadog/cluster-agent:latest
        imagePullPolicy: Always
        name: datadog-cluster-agent
        env:
          - name: DD_API_KEY
            valueFrom:
              secretKeyRef:
                name: datadog-secret
                key: api-key
          # Optionally reference an APP KEY for the External Metrics Provider.
          # - name: DD_APP_KEY
          #   value: '<YOUR_APP_KEY>'
          - name: DD_CLUSTER_AGENT_AUTH_TOKEN
            valueFrom:
              secretKeyRef:
                name: datadog-auth-token
                key: token
          - name: DD_COLLECT_KUBERNETES_EVENTS
            value: "true"
          - name: DD_LEADER_ELECTION
            value: "true"
          - name: DD_EXTERNAL_METRICS_PROVIDER_ENABLED
            value: "true"

Манифест создает развертывание и службу Kubernetes для агента кластера. Развертывание гарантирует, что один агент кластера всегда работает где-то в кластере, тогда как служба обеспечивает стабильную конечную точку в кластере, чтобы агенты на основе узлов могли связываться с агентом кластера, где бы он ни работал. Обратите внимание, что ключ API Datadog и токен аутентификации извлекаются из секретов Kubernetes, а не сохраняются в виде открытого текста в самом манифесте. Чтобы развернуть агент кластера, примените указанный выше манифест:

kubectl apply -f datadog-cluster-agent.yaml

Убедитесь, что агент кластера успешно развернут.

Чтобы убедиться, что агент кластера работает правильно, выполните первую команду ниже, чтобы найти имя модуля агента кластера. Затем используйте это имя модуля для запуска команды агента кластераstatus , как показано во второй команде:

kubectl get pods -l app=datadog-cluster-agent

NAME                                     READY   STATUS    RESTARTS   AGE
datadog-cluster-agent-7477d549ff-s42zx   1/1     Running   0          11s

kubectl exec -it datadog-cluster-agent-7477d549ff-s42zx datadog-cluster-agent status

В выходных данных вы должны увидеть, что агент кластера успешно подключается к серверу API Kubernetes для сбора событий и данных о состоянии кластера, как показано в этом примере фрагмента кода:

  Running Checks
  ==============
  [...]    
    kubernetes_apiserver
    --------------------
      Instance ID: kubernetes_apiserver [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/kubernetes_apiserver.d/conf.yaml.default
      Total Runs: 4
      Metric Samples: Last Run: 0, Total: 0
      Events: Last Run: 0, Total: 52
      Service Checks: Last Run: 4, Total: 16
      Average Execution Time : 2.017s

Разверните агент на основе узла

После создания необходимых разрешений и секретов развертывание агента Datadog на базе узла в кластере становится простым. Приведенный ниже манифест основан на стандартном манифесте агента Kubernetes и устанавливает две дополнительные переменные среды: DD_CLUSTER_AGENT_ENABLED(устанавливается в true) и DD_CLUSTER_AGENT_AUTH_TOKEN(устанавливается с помощью секретов Kubernetes, как и в манифесте для агента кластера). Скопируйте следующий манифест в локальный файл и сохраните его какdatadog-agent.yaml.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: datadog-agent
spec:
  selector:
    matchLabels:
      app: datadog-agent
  template:
    metadata:
      labels:
        app: datadog-agent
      name: datadog-agent
    spec:
      serviceAccountName: datadog-agent
      containers:
      - image: datadog/agent:7
        imagePullPolicy: Always
        name: datadog-agent
        ports:
          - containerPort: 8125
            # Custom metrics via DogStatsD - uncomment this section to enable custom metrics collection
            # hostPort: 8125
            name: dogstatsdport
            protocol: UDP
          - containerPort: 8126
            # Trace Collection (APM) - uncomment this section to enable APM
            # hostPort: 8126
            name: traceport
            protocol: TCP
        env:
          - name: DD_API_KEY
            valueFrom:
              secretKeyRef:
                name: datadog-secret
                key: api-key
          - name: DD_COLLECT_KUBERNETES_EVENTS
            value: "true"
          - name: KUBERNETES
            value: "true"
          - name: DD_HEALTH_PORT
            value: "5555"
          - name: DD_KUBERNETES_KUBELET_HOST
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
          - name: DD_CLUSTER_AGENT_ENABLED
            value: "true"
          - name: DD_CLUSTER_AGENT_AUTH_TOKEN
            valueFrom:
              secretKeyRef:
                name: datadog-auth-token
                key: token
          - name: DD_APM_ENABLED
            value: "true"
        resources:
          requests:
            memory: "256Mi"
            cpu: "200m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        volumeMounts:
          - name: dockersocket
            mountPath: /var/run/docker.sock
          - name: procdir
            mountPath: /host/proc
            readOnly: true
          - name: cgroups
            mountPath: /host/sys/fs/cgroup
            readOnly: true
        livenessProbe:
          httpGet:
            path: /health
            port: 5555
          initialDelaySeconds: 15
          periodSeconds: 15
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
      volumes:
        - hostPath:
            path: /var/run/docker.sock
          name: dockersocket
        - hostPath:
            path: /proc
          name: procdir
        - hostPath:
            path: /sys/fs/cgroup
          name: cgroups

Затем выполните следующую команду, чтобы развернуть агент на основе узла в качестве DaemonSet, что гарантирует, что одна копия агента будет работать на каждом узле в кластере:

kubectl create -f datadog-agent.yaml

Убедитесь, что агент на основе узла успешно развернут.

Чтобы убедиться, что агент Datadog на основе узла работает в вашем кластере, выполните следующую команду:

kubectl get daemonset datadog-agent

NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
datadog-agent   3         3         3       3            3           <none>          12m

Выходные данные выше показывают, что агент был успешно развернут в кластере из трех узлов. Количествожеланныйа такжеТекущийpods должно быть равно количеству запущенных узлов в вашем кластере Kubernetes.

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

kubectl get pods -l app=datadog-agent

NAME                  READY   STATUS    RESTARTS   AGE
datadog-agent-7vzqh   1/1     Running   0          27m
datadog-agent-kfvpc   1/1     Running   0          27m
datadog-agent-xvss5   1/1     Running   0          27m

Затем используйте одно из этих имен модулей, чтобы запросить статус агента:

kubectl exec -it datadog-agent-7vzqh agent status

В выводе нужно искать как минимум два элемента. Во-первых, вы должны увидеть, что агент на основе узла не собирает никаких событий с сервера API Kubernetes и не выполняет никаких проверок служб на сервере API (поскольку эти обязанности были делегированы агенту кластера):

  Running Checks
  ==============
  [...]
    kubernetes_apiserver
    --------------------
      Instance ID: kubernetes_apiserver [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/kubernetes_apiserver.d/conf.yaml.default
      Total Runs: 110
      Metric Samples: Last Run: 0, Total: 0
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s

Во-вторых, вы должны увидеть раздел в конце вывода состояния, указывающий, что агент на основе узла общается с агентом кластера:

=====================
Datadog Cluster Agent
=====================

  - Datadog Cluster Agent endpoint detected: https://10.137.5.251:5005
  Successfully connected to the Datadog Cluster Agent.

Погрузитесь в метрики

После успешного развертывания агента Datadog метрики ресурсов и события из вашего кластера должны передаваться в Datadog. Вы можете просмотреть данные, которые вы уже собираете, на встроенной панели управления Kubernetes .

Вы, возможно, помните из предыдущих статей этой серии, что некоторые метрики на уровне кластера, в частности, количество объектов Kubernetes, таких как количество желаемых, доступных в настоящее время и недоступных в настоящее время модулей, предоставляются необязательным надстройкой кластера под названием kube-state. -метрики. Если вы видите, что эти данные отсутствуют на панели мониторинга, это означает, что вы не развернули службу kube-state-metrics. Чтобы добавить эту статистику к метрикам ресурсов более низкого уровня, уже собираемым агентом, вам просто нужно развернуть kube-state-metrics в своем кластере.

Развертывание kube-state-metrics

Как описано в части 3 этой серии, вы можете использовать набор манифестов из официального проекта kube-state-metrics для быстрого развертывания надстройки и связанных с ней ресурсов. Чтобы загрузить манифесты и применить их к кластеру, выполните следующую серию команд:

git clone https://github.com/kubernetes/kube-state-metrics.git
cd kube-state-metrics
kubectl apply -f examples/standard

Затем вы можете проверить развертывание, чтобы убедиться, что kube-state-metrics запущены и доступны:

kubectl get deploy kube-state-metrics --namespace kube-system

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
kube-state-metrics   1/1     1            1           42m

Как только kube-state-metrics будет запущен, метрики состояния вашего кластера начнут автоматически загружаться в Datadog без какой-либо дополнительной настройки. Это связано с тем, что функция автообнаружения агента Datadog, которую мы рассмотрим в следующем разделе, определяет, когда запущены определенные службы, и автоматически включает сбор метрик из этих служб. Поскольку kube-state-metrics входит в число интеграций, автоматически включенных Autodiscovery , вам больше ничего не нужно делать, чтобы начать собирать метрики состояния вашего кластера в Datadog.

Автообнаружение

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

Автообнаружение означает, что Datadog может автоматически настраивать многие из своих интеграций , например kube-state-metrics (как описано выше ), без какой-либо пользовательской настройки. Другие автоматически настраиваемые службы включают общие компоненты кластера, такие как сервер API Kubernetes, Consul, CoreDNS и т. д., а также инфраструктурные технологии, такие как Apache (httpd), Redis и Apache Tomcat. Когда агент Datadog обнаружит эти контейнеры, работающие в любом месте кластера, он попытается применить стандартный шаблон конфигурации к контейнеризованному приложению и начнет сбор данных мониторинга.

Для служб в вашем кластере, которым требуются данные конфигурации, предоставляемые пользователем (например, учетные данные аутентификации для базы данных), вы можете использовать аннотации модуля Kubernetes, чтобы указать, какую проверку Datadog применять к этому модулю, а также любые сведения, необходимые для настройки проверки мониторинга. . Например, чтобы настроить агент Datadog для сбора метрик из вашей базы данных MySQL с использованием авторизованного datadogпользователя, вы должны добавить следующие аннотации модуля в свой манифест модуля MySQL:

annotations:
  ad.datadoghq.com/mysql.check_names: '["mysql"]'
  ad.datadoghq.com/mysql.init_configs: '[{}]'
  ad.datadoghq.com/mysql.instances: '[{"server": "%%host%%", "user": "datadog","pass": "<UNIQUEPASSWORD>"}]'

Эти аннотации предписывают Datadog применять проверку мониторинга MySQL к любым mysqlконтейнерам и подключаться к экземплярам MySQL, используя динамически предоставляемый IP-адрес хоста и учетные данные аутентификации для пользователя datadog.

Получите представление о своей плоскости управления

Datadog включает интеграцию с отдельными компонентами Control Plane вашего кластера , включая сервер API, планировщик и кластер etcd. После того как вы развернете Datadog в своем кластере, автоматически появятся показатели этих компонентов, чтобы вы могли легко визуализировать и отслеживать общее состояние и рабочую нагрузку вашего кластера.

См. нашу документацию для получения дополнительной информации о нашей интеграции с сервером API , диспетчером контроллеров , планировщиком и т.д.

Мониторинг Kubernetes с помощью тегов

Datadog автоматически импортирует метаданные из Kubernetes, Docker, облачных сервисов и других технологий и создает теги, которые можно использовать для сортировки, фильтрации и объединения данных. Теги (и их эквивалент в Kubernetes, метки ) необходимы для мониторинга динамической инфраструктуры, где имена хостов, IP-адреса и другие идентификаторы постоянно меняются. С помощью тегов в Datadog вы можете фильтровать и просматривать свои ресурсы по развертыванию Kubernetes ( kube_deployment) или сервису ( kube_service) или по образу Docker ( image_name). Datadog также автоматически получает теги от вашего облачного провайдера, поэтому вы можете просматривать свои узлы или контейнеры по зоне доступности, типу экземпляра и т. д.

В манифесте агента Datadog на основе узла вы можете добавить настраиваемые теги с переменной среды DD_TAGS, за которой следуют пары ключ:значение, разделенные пробелами. Например, вы можете применить следующие теги к своим агентам на основе узлов, чтобы указать кодовое имя кластера Kubernetes и команду, ответственную за него:

        env:
        [...]
          - name: DD_TAGS
            value: cluster-codename:melange team:core-platform

Вы также можете импортировать метки подов Kubernetes в виде тегов , которые собирают метаданные на уровне подов, которые вы определяете в своих манифестах как теги, поэтому вы можете использовать эти метаданные для фильтрации и агрегирования данных телеметрии в Datadog.

Помимо метрик: собирайте журналы, трассировки и многое другое

Агент Datadog автоматически собирает метрики с ваших узлов и контейнеров. Чтобы получить еще больше информации о вашем кластере, вы также можете настроить Datadog для сбора журналов и распределенных трассировок из приложений в вашем кластере. Вы можете легко включить сбор журналов и распределенную трассировку, изменив несколько конфигураций в манифесте агента на основе узла.

Собирайте и анализируйте журналы Kubernetes

Datadog может автоматически собирать журналы из Kubernetes, Docker и многих других технологий, которые вы можете использовать в своем кластере. Журналы могут быть незаменимы для устранения неполадок, выявления ошибок и предоставления более подробной информации о поведении вашей инфраструктуры и приложений.

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

        env:
        [...]
          - name: DD_LOGS_ENABLED
            value: "true"
          - name: DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
            value: "true"
          - name: DD_AC_EXCLUDE
            value: "name:datadog-agent"

Переменная DD_AC_EXCLUDEсреды указывает агенту Datadog исключить определенные контейнеры из сбора журналов, чтобы уменьшить объем собираемых данных — в этом случае агент пропустит свои собственные журналы. Вы можете пропустить этот элемент конфигурации, если хотите, чтобы агент отправлял собственные журналы в Datadog.

Затем добавьте следующее к volumeMountsи volumes:

        volumeMounts:
        [...]
          - name: pointdir
            mountPath: /opt/datadog-agent/run
        [...]
      volumes:
      [...]
        - hostPath: 
            path: /opt/datadog-agent/run
          name: pointdir

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

kubectl apply -f datadog-agent.yaml

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

Обратите внимание, что в некоторых контейнерных средах, включая Google Kubernetes Engine, /optдоступ только для чтения, поэтому агент не сможет выполнять запись по указанному выше стандартному пути. В качестве обходного пути вы можете заменить /opt/datadog-agent/runего /var/lib/datadog-agent/logsна в своем манифесте, если вы столкнетесь с ошибками только для чтения.

Просмотр журналов аудита вашего кластера

Журналы аудита Kubernetes предоставляют ценную информацию о запросах к вашим API-серверам. Они записывают данные, например, какие пользователи или службы запрашивают доступ к ресурсам кластера и почему сервер API разрешает или отклоняет эти запросы. Поскольку журналы аудита записываются в формате JSON, служба мониторинга, такая как Datadog, может легко анализировать их для фильтрации и анализа. Это позволяет настраивать оповещения о необычном поведении и устранять потенциальные проблемы с проверкой подлинности API, которые могут повлиять на доступ пользователей или служб к вашему кластеру.

См. нашу документацию , чтобы узнать, как настроить сбор журналов аудита с помощью Datadog.

Классифицируйте свои журналы

Datadog автоматически получает , обрабатывает и анализирует все журналы из вашего кластера Kubernetes для анализа и визуализации . Чтобы получить максимальную отдачу от ваших журналов, убедитесь, что к ним прикреплен sourceтег и serviceтег. Для журналов, поступающих из одной из интеграций журналов Datadog , sourceзадается контекст для журнала (например nginx), что позволяет переключаться между показателями инфраструктуры и соответствующими журналами из той же системы. Тег sourceтакже сообщает Datadog, какой конвейер обработки журналов следует использовать для правильного анализа этих журналов, чтобы извлечь структурированные аспекты и атрибуты. Точно так же serviceтег (который является основным тегом в Datadog APM) позволяет плавно переходить от журналов к метрикам на уровне приложений и запрашивать трассировки из той же службы для быстрого устранения неполадок.

Агент Datadog попытается автоматически сгенерировать эти теги для ваших журналов из имени образа. Например, журналы из контейнеров Redis будут помечены source:redisи service:redis. Вы также можете указать пользовательские значения, включив их в аннотации Kubernetes в манифестах развертывания:

  annotations:
    ad.datadoghq.com/<CONTAINER_IDENTIFIER>.logs: '[{"source":"<SOURCE>","service":"<SERVICE>"}]'

Отслеживайте производительность приложений

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

Datadog APM автоматически настраивает ряд языков и сред приложений; обратитесь к документации по поддерживаемым языкам и подробностям о том, как начать инструментирование вашего языка или фреймворка.

Включите APM в своем кластере Kubernetes.

Чтобы включить трассировку в вашем кластере, сначала убедитесь, что для агента Datadog переменная среды DD_APM_ENABLED имеет значение , как в приведенном вышеtrue манифесте агента на основе узла Datadog . Если вы используете другой манифест агента, вы можете добавить следующую конфигурацию, чтобы установить переменную среды:

        env:
        [...]
          - name: DD_APM_ENABLED
            value: "true"

Затем раскомментируйте hostPortагент трассировки, чтобы ваш манифест включал:

          - containerPort: 8126
            hostPort: 8126
            name: traceport
            protocol: TCP

Примените изменения:

kubectl apply -f datadog-agent.yaml

Затем укажите IP-адрес хост-узла в качестве переменной среды, чтобы убедиться, что контейнеры приложений отправляют трассировку экземпляру агента Datadog, работающему на правильном узле. Этого можно добиться, настроив манифест развертывания приложения для предоставления IP-адреса хост-узла в качестве переменной среды с помощью Kubernetes Downward API . Установите DATADOG_TRACE_AGENT_HOSTNAMEпеременную среды в манифесте для приложения, которое нужно отслеживать:

spec:
      containers:
      - name: <CONTAINER_NAME>
        image: <CONTAINER_IMAGE>:<TAG>
        env:
          - name: DATADOG_TRACE_AGENT_HOSTNAME
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP

Когда вы развертываете инструментированное приложение, оно автоматически начинает отправлять трассировки в Datadog. На вкладке APM вашей учетной записи Datadog вы можете увидеть разбивку ключевых показателей производительности для каждой из ваших инструментальных служб с информацией о пропускной способности запросов, задержке, ошибках и производительности любых зависимостей службы.

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

Все ваши данные Kubernetes в одном месте

Если вы следили за этой статьей, вы уже начали собирать огромное количество данных из своего кластера Kubernetes:

• Развертывание агента кластера Datadog и агента на основе узла для сбора метрик и других данных телеметрии из вашего кластера.
• Добавление kube-state-metrics в ваш кластер для предоставления высокоуровневой статистики по количеству и статусу объектов кластера.
• Включение автообнаружения для беспрепятственного мониторинга новых контейнеров по мере их развертывания в вашем кластере.
• Сбор журналов из вашего кластера и выполняемых на нем рабочих нагрузок
• Настройка распределенной трассировки для ваших приложений, работающих в Kubernetes

Datadog предоставляет еще больше функций мониторинга Kubernetes, выходящих за рамки этого поста. Мы рекомендуем вам ознакомиться с документацией Datadog по Kubernetes , чтобы узнать, как настроить мониторинг процессов, мониторинг производительности сети и сбор пользовательских метрик в Kubernetes.

Если у вас еще нет учетной записи Datadog, вы можете начать мониторинг кластеров Kubernetes с помощью бесплатной пробной версии .

Статья является переводом www.datadoghq.com