Бөлісу құралы:


Настройка коллекции с помощью CRD (мониторы службы и pod)

Примечание.

Поддержка CRD с управляемым Prometheus в настоящее время доступна в предварительной версии.

Включение Managed Prometheus автоматически развертывает пользовательские определения ресурсов (CRD) для мониторов pod и мониторов служб. Эти пользовательские определения ресурсов являются теми же пользовательскими определениями ресурсов (CRD), что и мониторы pod OSS и мониторы служб OSS для Prometheus, за исключением изменения имени группы. Если в кластере есть идентификаторы CRD Prometheus и пользовательские ресурсы, эти CRD не будут конфликтовать с crD, созданными надстройкой. В то же время управляемый надстройка Prometheus не выбирает crD, созданные для OSS Prometheus. Это разделение намеренно предназначено для изоляции заданий слома.

Создание модуля pod или монитора службы

Используйте шаблоны Pod и Service Monitor и следуйте спецификации API для создания пользовательских ресурсов (PodMonitor и монитора службы). Обратите внимание , что единственное изменение, необходимое для существующих ЦС OSS (настраиваемых ресурсов) для получения управляемым Prometheus является группой API - azmonitoring.coreos.com/v1.

Примечание. Обязательно используйте labelLimit, labelNameLengthLimit и labelValueLengthLimit , указанные в шаблонах, чтобы они не были удалены во время обработки.

Мониторы pod и службы должны выглядеть следующим образом:

Пример монитора pod

# Note the API version is azmonitoring.coreos.com/v1 instead of monitoring.coreos.com/v1
apiVersion: azmonitoring.coreos.com/v1
kind: PodMonitor

# Can be deployed in any namespace
metadata:
  name: reference-app
  namespace: app-namespace
spec:
  labelLimit: 63
  labelNameLengthLimit: 511
  labelValueLengthLimit: 1023

  # The selector specifies which pods to filter for
  selector:

    # Filter by pod labels
    matchLabels:
      environment: test
    matchExpressions:
      - key: app
        operator: In
        values: [app-frontend, app-backend]

    # [Optional] Filter by pod namespace
    namespaceSelector:
      matchNames: [app-frontend, app-backend]

  # [Optional] Labels on the pod with these keys will be added as labels to each metric scraped
  podTargetLabels: [app, region, environment]

  # Multiple pod endpoints can be specified. Port requires a named port.
  podMetricsEndpoints:
    - port: metrics

Пример монитора служб

# Note the API version is azmonitoring.coreos.com/v1 instead of monitoring.coreos.com/v1
apiVersion: azmonitoring.coreos.com/v1
kind: ServiceMonitor

# Can be deployed in any namespace
metadata:
  name: reference-app
  namespace: app-namespace
spec:
  labelLimit: 63
  labelNameLengthLimit: 511
  labelValueLengthLimit: 1023

  # The selector filters endpoints by service labels.
  selector:
    matchLabels:
      app: reference-app

  # Multiple endpoints can be specified. Port requires a named port.
  endpoints:
  - port: metrics

Развертывание pod или монитора службы

Затем можно развернуть модуль pod или монитор службы с помощью kubectl.

При применении все ошибки в пользовательских ресурсах должны отображаться, а мониторы pod или службы не должны применяться.
Успешное создание монитора pod выглядит следующим образом:

podmonitor.azmonitoring.coreos.com/my-pod-monitor created

Примеры

Создание примера приложения

Разверните пример приложения, предоставляющего метрики prometheus для настройки с помощью монитора pod/service.

kubectl apply -f https://github.com/Azure/prometheus-collector/blob/main/internal/referenceapp/prometheus-reference-app.yaml

Создание монитора pod и (или) монитора службы для очистки метрик

Разверните монитор pod, настроенный для извлечения метрик из примера приложения на предыдущем шаге.

Монитор pod
kubectl apply -f https://github.com/Azure/prometheus-collector/blob/main/otelcollector/deploy/example-custom-resources/pod-monitor/pod-monitor-reference-app.yaml
Монитор служб
kubectl apply -f https://github.com/Azure/prometheus-collector/blob/main/otelcollector/deploy/example-custom-resources/service-monitor/service-monitor-reference-app.yaml

Устранение неполадок

При успешном применении мониторов pod или служб надстройка должна автоматически начать сбор метрик из целевых объектов. Чтобы подтвердить это, следуйте инструкциям, приведенным здесь для общего устранения неполадок пользовательских ресурсов, а также для обеспечения того, чтобы целевые объекты отображались в 127.0.0.1/targets.

Снимок экрана: целевые объекты для монитора pod или службы

Следующие шаги