Создание настраиваемого задания очистки Prometheus из кластера Kubernetes с помощью ConfigMap

Настройка коллекции метрик Prometheus из кластера Kubernetes описывает, как использовать ConfigMap для настройки срезов метрик Prometheus из целевых объектов по умолчанию в кластере Kubernetes. В этой статье описывается, как использовать ConfigMap для создания пользовательских заданий сбора данных для дальнейшей настройки и добавления дополнительных целевых назначений.

ConfigMaps

В следующей таблице описаны ConfigMaps, используемые для создания пользовательских заданий сбора данных. Эти ConfigMaps по умолчанию не существуют в кластере, если включен управляемый Prometheus.

Создание файла конфигурации Prometheus

Вместо прямого изменения ama-metrics-prometheus-configпроще создать файл конфигурации, а затем преобразовать его в ConfigMap. Дополнительные сведения о разных разделах этого файла см. в разделе Параметры конфигурации сбора данных ниже.

Создайте файл конфигурации Prometheus с именем prometheus-config в следующем формате. В этом списке перечислены конфигурации сбора данных в разделе scrape_configs и по желанию можно использовать глобальный раздел для настройки глобальных scrape_interval, scrape_timeout, а также external_labels. Дополнительные сведения о параметрах настройки снятия метрик см. на Prometheus.io в справочнике по настройке снятия метрик.

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

Ниже приведен пример файла конфигурации Prometheus scrape:

global:
  scrape_interval: 30s
scrape_configs:
- job_name: my_static_config
  scrape_interval: 60s
  static_configs:
    - targets: ['my-static-service.svc.cluster.local:1234']
- job_name: prometheus_example_app
  scheme: http
  kubernetes_sd_configs:
    - role: service
  relabel_configs:
    - source_labels: [__meta_kubernetes_service_name]
      action: keep
      regex: "prometheus-example-service"

Проверка файла конфигурации скребка

Агент использует настраиваемое promconfigvalidator средство для проверки конфигурации Prometheus, предоставленной ему с помощью ConfigMap. Если конфигурация недействительна, пользовательская конфигурация отклоняется агентом. После создания файла конфигурации Prometheus этот инструмент можно использовать для проверки конфигурации перед созданием ConfigMap для агента.

Средство promconfigvalidator поставляется в модуле надстройки метрик Azure Monitor. Вы можете использовать любой из ama-metrics-node-* pods в kube-system namespace в вашем кластере, чтобы скачать инструмент проверки. Используйте kubectl cp, чтобы скачать инструмент и его конфигурацию с помощью следующей команды.

for podname in $(kubectl get pods -l rsName=ama-metrics -n=kube-system -o json | jq -r '.items[].metadata.name'); do kubectl cp -n=kube-system "${podname}":/opt/promconfigvalidator ./promconfigvalidator;  kubectl cp -n=kube-system "${podname}":/opt/microsoft/otelcollector/collector-config-template.yml ./collector-config-template.yml; chmod 500 promconfigvalidator; done

После копирования исполняемого файла и yaml найдите путь к файлу конфигурации Prometheus. Затем замените <config path> в команде и запустите валидатор с помощью следующей команды.

./promconfigvalidator/promconfigvalidator --config "<config path>" --otelTemplate "./promconfigvalidator/collector-config-template.yml"

При запуске валидатора создается объединенный файл конфигурации merged-otel-config.yaml, если не задан путь с помощью необязательного параметра output. Не используйте этот автоматически созданный объединенный файл, так как он используется только для проверки и отладки инструментов.

Развертывание файла конфигурации в виде ConfigMap

Пользовательский файл конфигурации Prometheus используется в качестве поля, именуемого prometheus-config внутри ama-metrics-prometheus-config, ama-metrics-prometheus-config-node или ama-metrics-prometheus-config-node-windows ConfigMap в kube-system пространстве имен. Создайте ConfigMap из файла конфигурации scrape, переименовав файл конфигурации Prometheus в prometheus-config без расширения и выполнив одну или несколько приведенных ниже команд в зависимости от того, какой ConfigMap вы хотите создать для вашей настраиваемой конфигурации scrape job.

Создайте ConfigMap для использования с помощью набора реплик:

kubectl create ConfigMap ama-metrics-prometheus-config --from-file=prometheus-config -n kube-system

При этом создается ConfigMap с именем ama-metrics-prometheus-config в kube-system пространстве имен. Чтобы узнать, возникли ли проблемы с проверкой конфигурации, обработкой или слиянием, можно просмотреть ama-metrics реплицированные поды.

Создайте ConfigMap для использования в Linux DaemonSet:

kubectl create ConfigMap ama-metrics-prometheus-config-node --from-file=prometheus-config -n kube-system

При этом создается ConfigMap с именем ama-metrics-prometheus-config-node в kube-system пространстве имен. Чтобы узнать, возникли ли проблемы с проверкой конфигурации, обработкой или слиянием, можно просмотреть ama-metrics-node поды DaemonSet для Linux.

Создайте ConfigMap для использования Windows DaemonSet

kubectl create ConfigMap ama-metrics-prometheus-config-node-windows --from-file=prometheus-config -n kube-system

При этом создается ConfigMap с именем ama-metrics-prometheus-config-node-windows в kube-system пространстве имен. Чтобы узнать, возникли ли проблемы с проверкой конфигурации, обработкой или слиянием, можно просмотреть ama-metrics-win-node модули daemonset для Windows.

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

Если вы успешно создали ConfigMap в пространстве имен kube-system и по-прежнему не видите, что пользовательские целевые объекты собираются, проверьте наличие ошибок в журналах реплики pod для ama-metrics-prometheus-config ConfigMap или в журналах pod для DaemonSetama-metrics-prometheus-config-node ConfigMap, используя kubectl logs, и убедитесь, что в разделе "Запуск слияния по умолчанию и настраиваемая конфигурация Prometheus" с префиксом prometheus-config-merger нет ошибок.

Очистка конфигураций

В настоящее время поддерживаемые методы обнаружения целевых объектов для конфигурации scrape config это либо static_configs, либо kubernetes_sd_configs для указания или обнаружения целевых объектов.

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

scrape_configs:
  - job_name: example
    - targets: [ '10.10.10.1:9090', '10.10.10.2:9090', '10.10.10.3:9090' ... ]
    - labels: [ label1: value1, label1: value2, ... ]

Целевые объекты, обнаруженные с помощью kubernetes_sd_configs, имеют разные метки __meta_* в зависимости от указанной роли. Метки в relabel_configs разделе можно использовать для фильтрации целевых объектов или замены меток для целевых объектов.

Перенастроители конфигураций

Раздел relabel_configs применяется во время обнаружения целевого объекта и применяется к каждому целевому объекту для задания. В следующих примерах показаны способы использования relabel_configs.

Добавление метки Добавьте новую метку, названную example_label, со значением example_value, для каждой метрики задания. Используйте __address__ в качестве исходной метки только потому, что эта метка всегда существует и добавляет метку для каждого целевого объекта задания.

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

Использование меток обнаружения служб Kubernetes

Если задание использует kubernetes_sd_configs для обнаружения целей, с каждой ролью связаны метки __meta_* для метрик. Метки __* удаляются после обнаружения целевых объектов. Чтобы фильтровать по ним на уровне метрик, сначала сохраните их с помощью relabel_configs, присвоив имя метки. Затем используется metric_relabel_configs для фильтрации.

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
  action: replace
  target_label: kubernetes_namespace

# Keep only metrics with the kubernetes namespace 'default'
metric_relabel_configs:
- source_labels: [kubernetes_namespace]
  action: keep
  regex: 'default'

Перемаркировка заданий и экземпляров

Вы можете изменить значения меток job и instance на основе исходной метки, как и значения любых других меток.

# Replace the job name with the pod label 'k8s app'
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_k8s_app]
  target_label: job

# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabel_configs:
- source_labels: [__meta_kubernetes_node_name]
  target_label: instance

Конфигурации перемаркировки метрик

Конфигурации перемаркировки метрик применяются после сбора и перед приемом. Используйте раздел metric_relabel_configs для фильтрации метрик после сбора. См. следующие примеры.

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

# Drop the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
  action: drop
  regex: 'example_metric_name'

Сохранение только определенных метрик по имени

# Keep only the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
  action: keep
  regex: 'example_metric_name'

# Keep only metrics that start with 'example_'
metric_relabel_configs:
- source_labels: [__name__]
  action: keep
  regex: '(example_.*)'

Фильтрация метрик по меткам

# Keep metrics only where example_label = 'example'
metric_relabel_configs:
- source_labels: [example_label]
  action: keep
  regex: 'example'

# Keep metrics only if `example_label` equals `value_1` or `value_2`
metric_relabel_configs:
- source_labels: [example_label]
  action: keep
  regex: '(value_1|value_2)'

# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metric_relabel_configs:
- source_labels: [example_label_1, example_label_2]
  separator: ';'
  action: keep
  regex: 'value_1;value_2'

# Keep metrics only if `example_label` exists as a label
metric_relabel_configs:
- source_labels: [example_label_1]
  action: keep
  regex: '.+'

Переименование метрик Переименование метрик не поддерживается.

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

Базовая аутентификация и Bearer-токены

Если вы используете имя пользователя, пароль или учетные данные в качестве незашифрованного текста в конфигурации парсинга, дополнительные изменения не требуются. Значения, указанные в конфигурации, будут использоваться для очистки. Если вы используете username_file или password_file (или какие-либо _file параметры конфигурации) для параметров basic_auth или bearer_token в конфигурации prometheus, выполните следующие действия:

1. Создайте секрет в пространстве имен kube-system с именем ama-metrics-mtls-secret.

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

   apiVersion: v1
   kind: Secret
   metadata:
     name: ama-metrics-mtls-secret
     namespace: kube-system
   type: Opaque
   data:
     password1: <base64-encoded-string>
   

   Секрет ama-metrics-mtls-secret монтируется в ama-metrics pod’ы по пути /etc/prometheus/certs/ и становится доступным для средства сбора метрик Prometheus. Ключ (password1 в приведенном выше примере) будет именем файла. Это значение декодируется из Base64 и добавляется как содержимое файла в контейнере.

2. Укажите файловый путь в настраиваемой конфигурации скребка в ConfigMap:

   Базовая проверка подлинности Поле username должно содержать фактическую строку имени пользователя. Поле password_file должно содержать путь к файлу, который содержит пароль.

   # Sets the `Authorization` header on every scrape request with the
   # configured username and password.
   basic_auth:
     username: <username string>
     password_file: /etc/prometheus/certs/password1
   

   Маркер носителя Поле bearer_token_file должно содержать путь к файлу, содержаму маркер.

   # Sets the `Authorization` header on every scrape request with the bearer token
   # read from the configured file. It is mutually exclusive with `bearer_token`.
   bearer_token_file: /etc/prometheus/certs/password1
   

Дополнительные сведения об этих параметрах см. в документации по Prometheus scrape_config.

Очистка на основе TLS

Если вы хотите собирать метрики Prometheus с HTTPS-эндпоинта, в конфигурации Prometheus, PodMonitor или ServiceMonitor параметр scheme должен быть установлен в значение https, а также должны быть заданы дополнительные настройки TLS.

1. Создайте секрет с именем ama-metrics-mtls-secret в пространстве имен kube-system. Каждая пара «ключ-значение», указанная в секции data объекта Secret, будет смонтирована в каталоге /etc/prometheus/certs в виде отдельного файла, имя которого будет совпадать с соответствующим ключом, указанным в секции data. Значения секретов должны быть закодированы в кодировке Base64.

   Ниже приведен пример YAML секрета:

   apiVersion: v1
   kind: Secret
   metadata:
     name: ama-metrics-mtls-secret
     namespace: kube-system
   type: Opaque
   data:
     <certfile>: base64_cert_content    
     <keyfile>: base64_key_content 
   

   Секрет ama-metrics-mtls-secret монтируется в поды ama-metrics по пути /etc/prometheus/certs/ и становится доступным средству сбора метрик Prometheus. Ключ будет именем файла. Это значение декодируется из Base64 и добавляется в файл в контейнере в качестве его содержимого.

2. Укажите файловый путь в конфигурации Prometheus, PodMonitor или ServiceMonitor:

   • Используйте следующий пример, чтобы указать параметр конфигурации TLS в ConfigMap:

   tls_config:
      # CA certificate to validate API server certificate with.
      ca_file: /etc/prometheus/certs/<certfile>
   
      # Certificate and key files for client cert authentication to the server.
      cert_file: /etc/prometheus/certs/<certfile>
      key_file: /etc/prometheus/certs/<keyfile>
   
      # Disable validation of the server certificate.
      insecure_skip_verify: false
   

Базовая проверка подлинности и TLS

Если вы хотите использовать базовый маркер проверки подлинности или маркер носителя (учетные данные на основе файлов) и параметры проверки подлинности TLS в ConfigMap, убедитесь, что секрет ama-metrics-mtls-secret включает все ключи в разделе данных с соответствующими значениями в кодировке Base64, как показано в следующем примере:

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  certfile: base64_cert_content    # used for TLS
  keyfile: base64_key_content      # used for TLS
  password1: base64-encoded-string # used for basic auth
  password2: base64-encoded-string # used for basic auth

Расширенная настройка: Настройка пользовательских заданий выборки Prometheus для DaemonSet

Модуль ama-metrics pod реплики использует настраиваемую конфигурацию Prometheus и удаляет указанные целевые объекты. Для кластера с большим количеством узлов, подов и значительным объемом метрик для сбора, часть пользовательских целевых объектов может быть разгружена с одного модуля реплики ama-metrics на pod DaemonSet ama-metrics.

ama-metrics-prometheus-config-node ConfigMap аналогичен реплика-сету ConfigMap и может быть создан для настройки статических конфигураций сбора метрик на каждом узле. Конфигурация сбора данных должна быть нацелена только на один узел и не должна использовать службу обнаружения и аннотации pod. В противном случае каждый узел пытается сломать все целевые объекты и выполняет много вызовов к серверу API Kubernetes.

Пользовательские цели сбора данных могут следовать тому же формату, используя static_configs с целями и $NODE_IP переменную среды, и указывая порт для сбора. Каждый pod DaemonSet принимает конфигурацию, собирает метрики и отправляет их для данного узла.

Следующая конфигурация node-exporter является одной из целевых конфигураций по умолчанию для подов DaemonSet. Она использует $NODE_IP переменную среды, которая уже задана для каждого ama-metrics контейнера надстроек для назначения определенного порта на узле.

- job_name: nodesample
  scrape_interval: 30s
  scheme: http
  metrics_path: /metrics
  relabel_configs:
  - source_labels: [__metrics_path__]
    regex: (.*)
    target_label: metrics_path
  - source_labels: [__address__]
    replacement: '$NODE_NAME'
    target_label: instance
  static_configs:
  - targets: ['$NODE_IP:9100']

Очистка параметров конфигурации

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

Глобальные параметры

Формат конфигурации для глобальных параметров совпадает с конфигурацией OSS prometheus.

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

Параметры, указанные в глобальном разделе, применяются ко всем заданиям сбора метрик (как к заданиям в ConfigMap, так и к заданиям в пользовательских ресурсах), но переопределяются, если заданы в отдельных заданиях.

Дальнейшие шаги

• Дополнительные сведения о сборе метрик Prometheus.