Настройка очистки метрик Prometheus в управляемой службе Azure Monitor для Prometheus

В этой статье приведены инструкции по настройке метрики для кластера Kubernetes с надстройкой метрик в Azure Monitor.

Конфигурации

Четыре разных конфигурационных карты можно настроить для предоставления конфигурации слома и других параметров надстройки метрик. Все карты конфигурации должны применяться к пространству kube-system имен для любого кластера.

1. ama-metrics-settings-configmap Эта карта конфигурации содержит ниже простых параметров, которые можно настроить. Вы можете использовать конфигурацию из приведенного выше репозитория концентратора Git, изменить параметры и применить или развернуть конфигурацию в kube-system пространстве имен для кластера.
   • псевдоним кластера (чтобы изменить значение cluster метки во всех временных рядах или метриках, полученных из кластера)
   • включение и отключение целевых объектов слома по умолчанию — включение и отключение очистки по умолчанию на основе целевых объектов. Конфигурация очистки для этих целевых объектов по умолчанию уже предварительно определена или встроенная
   • включение очистки на основе заметок pod для каждого пространства имен
   • Списки хранимых метрик — этот параметр используется для управления тем, какие метрики будут разрешены из каждого целевого объекта по умолчанию, а также для изменения поведения по умолчанию
   • Интервалы слома для стандартных или предопределенных параметров. 30 secs — это частота слома по умолчанию, и ее можно изменить на целевой объект по умолчанию с помощью этой конфигурации.
   • режим отладки— включение этой функции помогает отлаживать отсутствующие проблемы с метрикой и приемом. Дополнительные сведения об устранении неполадок см. в статье об устранении неполадок
2. ama-metrics-prometheus-config Эту карту конфигурации можно использовать для предоставления конфигурации Prometheus слома для реплики надстройки. Addon запускает одну реплику, и любые службы уровня кластера можно обнаружить и отменить, предоставив задания слома в этом файле конфигурации. Пример конфигурации можно получить из приведенного выше репозитория концентратора Git, добавить задания слома, которые потребуются, и применить или развернуть карту конфигурации к kube-system пространству имен для кластера. Хотя это поддерживается, обратите внимание, что рекомендуемый способ очистки пользовательских целевых объектов использует пользовательские ресурсы.
3. ama-metrics-prometheus-config-node (Дополнительно) Эта карта конфигурации может использоваться для предоставления конфигурации prometheus скребка для надстройки DaemonSet, которая выполняется на каждом узле Linux в кластере, и любые целевые объекты уровня узлов на каждом узле можно сломать, предоставив задания слома в этом файле конфигурации. При использовании этой конфигурации можно использовать $NODE_IP переменную в конфигурации слома, которая заменяется IP-адресом соответствующего узла в pod DaemonSet, работающем на каждом узле. Таким образом вы получаете доступ к удалению всего, что выполняется на этом узле из надстройки DaemonSet метрик. Будьте осторожны при использовании обнаружений в конфигурации слома в карте конфигурации уровня узла, так как каждый узел в кластере будет настраивать и обнаруживать целевые объекты и собирать избыточные метрики. Пример конфигурации можно получить из приведенного выше репозитория концентратора Git, добавить задания слома, которые потребуются, и применить или развернуть карту конфигурации к kube-system пространству имен для кластера.
4. ama-metrics-prometheus-config-node-windows (Дополнительно) Эта карта конфигурации может использоваться для предоставления конфигурации Prometheus слома для надстройки DaemonSet, которая выполняется на каждом узле Windows в кластере, а целевые объекты уровня узлов на каждом узле можно сломать, предоставив задания слома в этом файле конфигурации. При использовании этой конфигурации можно использовать $NODE_IP переменную в конфигурации слома, которая будет заменена ip-адресом соответствующего узла в pod DaemonSet, работающем на каждом узле. Таким образом вы получаете доступ к удалению всего, что выполняется на этом узле из надстройки DaemonSet метрик. Будьте осторожны при использовании обнаружений в конфигурации слома в карте конфигурации уровня узла, так как каждый узел в кластере будет настраивать и обнаруживать целевые объекты и собирать избыточные метрики. Пример конфигурации можно получить из приведенного выше репозитория концентратора Git, добавить задания слома, которые потребуются, и применить или развернуть карту конфигурации к kube-system пространству имен для кластера.

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

Надстройка метрик Azure Monitor поддерживает удаление метрик Prometheus с помощью Prometheus — мониторов pod и мониторов служб, аналогичных оператору OSS Prometheus. Включение надстройки будет развертывать пользовательские определения ресурсов Pod и Service Monitor, чтобы позволить создавать собственные пользовательские ресурсы. Следуйте инструкциям по созданию и применению пользовательских ресурсов в кластере.

Метрики надстройки параметров конфигурации

Ama-metrics-settings-configmap можно скачать, изменить и применить к кластеру, чтобы настроить встроенные функции надстройки метрик.

Включение и отключение целевых объектов по умолчанию

В следующей таблице содержится список всех целевых объектов по умолчанию, которые надстройка метрики Azure Monitor может сломить по умолчанию и включить ли она изначально. Целевые объекты по умолчанию удаляются каждые 30 секунд. Реплика развертывается для отказоустойчивых целевых объектов кластера, таких как метрики kube-state-metrics. DaemonSet также развертывается для удаления целевых объектов на уровне узла, таких как kubelet.

Если вы хотите включить очистку целевых объектов по умолчанию, которые не включены по умолчанию, измените конфигурациюama-metrics-settings-configmap, чтобы обновить целевые объекты, перечисленные в списке default-scrape-settings-enabled true. Примените конфигурацию к кластеру.

Включение очистки на основе заметок на основе заметок pod

Чтобы создавать пользовательские конфигурации prometheus, заметки можно добавлять в модули pod. Заметка prometheus.io/scrape: "true" требуется для очистки модуля pod. Заметки prometheus.io/path и prometheus.io/port указание пути и порта, в котором размещены метрики в модуле pod. Заметки для модуля pod, на котором размещаются метрики <pod IP>:8080/metrics , будут:

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

Очистка этих модулей pod с определенными заметками по умолчанию отключена. Чтобы включить, ama-metrics-settings-configmapдобавьте regex для пространств имен модулей pod с заметками, которые нужно отменить в качестве значения поля podannotationnamespaceregex.

Например, следующий параметр ломает модули pod с заметками только в пространствах kube-system имен и my-namespace:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

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

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

Настройка метрик, собранных целевыми объектами по умолчанию

По умолчанию для всех целевых объектов по умолчанию используются только минимальные метрики, используемые в правилах записи по умолчанию, оповещениях и панелях мониторинга Grafana, как описано в минимальном режиме приема данных. Чтобы собрать все метрики из целевых объектов по умолчанию, обновите списки хранения в конфигурации параметров в разделе default-targets-metrics-keep-listи задайте для falseнее значениеminimalingestionprofile.

Чтобы разрешить список дополнительных метрик в дополнение к метрикам по умолчанию, которые должны быть разрешены, для любых целевых объектов по умолчанию измените параметры в default-targets-metrics-keep-list соответствии с соответствующим заданием, которое вы хотите изменить.

Например, kubelet это параметр фильтрации метрик для целевого kubelet по умолчанию. Используйте следующий скрипт, чтобы отфильтровать метрики, собранные для целевых объектов по умолчанию, с помощью регулярной фильтрации.

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

Чтобы дополнительно настроить задания по умолчанию для изменения свойств, таких как частота сбора или метки, отключите соответствующий целевой объект по умолчанию, задав значение конфигурации для целевого объекта false. Затем примените задание с помощью пользовательской конфигурации. Дополнительные сведения о настраиваемой конфигурации см. в разделе "Настройка очистки метрик Prometheus" в Azure Monitor.

Псевдоним кластера

Метка кластера, добавленная к каждому временному ряду, использует последнюю часть полного идентификатора ресурса Azure Resource Manager кластера AKS. Например, если идентификатор ресурса указан /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername, метка кластера имеет значение myclustername.

Чтобы переопределить метку кластера в сломе временных рядов, обновите параметр cluster_alias до любой строки prometheus-collector-settings в конфигурацииama-metrics-settings-configmap. Этот файл конфигурации можно создать, если он не существует в кластере или изменить существующий, если он уже существует в кластере.

Новая метка также отображается в раскрывающемся списке параметров кластера на панелях мониторинга Grafana вместо стандартного.

Режим отладки

Чтобы просмотреть все метрики, которые удаляются в целях отладки, агент надстроек метрик можно настроить для запуска в режиме отладки, обновив параметр enabled до параметра в файле конфигурацииama-metrics-settings-configmap.debug-mode true Этот файл конфигурации можно создать или изменить существующий. Дополнительные сведения см. в разделе "Режим отладки" в разделе "Устранение неполадок" метрик Prometheus.

Параметры интервала слома

Чтобы обновить параметры интервала слома для любого целевого объекта, можно обновить длительность в параметре default-targets-scrape-interval-settings для этого целевого объекта в конфигурационном рисункеama-metrics-settings-configmap. Необходимо задать интервалы слома в правильном формате, указанном на этом веб-сайте. В противном случае значение по умолчанию 30 секунд применяется к соответствующим целевым объектам. Например, если вы хотите обновить интервал слома для kubelet задания, чтобы 60s затем можно было обновить следующий раздел в YAML:

default-targets-scrape-interval-settings: |-
    kubelet = "60s"
    coredns = "30s"
    cadvisor = "30s"
    kubeproxy = "30s"
    apiserver = "30s"
    kubestate = "30s"
    nodeexporter = "30s"
    windowsexporter = "30s"
    windowskubeproxy = "30s"
    kappiebasic = "30s"
    prometheuscollectorhealth = "30s"
    podannotations = "30s"

и примените YAML с помощью следующей команды: kubectl apply -f .\ama-metrics-settings-configmap.yaml

Настройка пользовательских заданий prometheus скребка

Вы можете сломать метрики Prometheus с помощью Prometheus — pod Monitors и Service Monitors(Рекомендуется), аналогично оператору OSS Prometheus. Следуйте инструкциям по созданию и применению пользовательских ресурсов в кластере.

Кроме того, вы можете следовать инструкциям по созданию , проверке и применению конфигурации для кластера. Формат конфигурации аналогичен файлу конфигурации Prometheus.

Советы по настройке Prometheus и примеры

Ознакомьтесь с некоторыми советами из примеров в этом разделе.

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

Если вы хотите использовать глобальные параметры, которые применяются ко всем заданиям слома, и у вас есть только настраиваемые ресурсы , вам по-прежнему потребуется создать конфигурацию только с глобальными параметрами (параметры для каждого из них в пользовательских ресурсах переопределяют те, которые в глобальном разделе)

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

relabelings:
- sourceLabels: [__address__]
  targetLabel: example_label
  replacement: 'example_value'

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  action: replace
  targetLabel: kubernetes_namespace

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

# Replace the job name with the pod label 'k8s app'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
  targetLabel: 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
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
  targetLabel: instance

# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: drop
  regex: 'example_metric_name'

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

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

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

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

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

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

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, ... ]

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

# 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'

# 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

# 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'

Обычная проверка подлинности

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

basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

Если вы используете обычную проверку подлинности и проверку подлинности tls, обратитесь к приведенному ниже разделу. Дополнительные сведения см. в разделе заметки ниже.

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

Если у вас есть экземпляр Prometheus, обслуживающий протокол TLS, и вы хотите сломать метрики из него, необходимо задать схему https и задать параметры TLS в конфигурации или соответствующем CRD. Пожалуйста, следуйте приведенным ниже инструкциям.

1. Создайте секрет в пространстве имен kube-system с именем ama-metrics-mtls-secret. Каждая пара "ключ-значение", указанная в разделе данных секретного объекта, будет подключена в виде отдельного файла в этом расположении /etc/prometheus/certs с именами файлов, указанными в разделе данных. Значения секретов должны быть закодированы в кодировке 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. Ключ (например, certfile) в приведенном выше примере будет именем файла и значением является декодирование base64 и добавлено в содержимое файла в контейнере, а скребок prometheus использует содержимое этого файла для получения значения, используемого в качестве пароля, используемого для удаления конечной точки.

2. Ниже приведены сведения о том, как предоставить параметры конфигурации TLS с помощью карты конфигурации или CRD.

tls_config:
    ca_file: /etc/prometheus/certs/<certfile> # since it is self-signed
    cert_file: /etc/prometheus/certs/<certfile>
    key_file: /etc/prometheus/certs/<keyfile>
    insecure_skip_verify: false

 tlsConfig:
   ca:
     secret:
       key: "<certfile>" # since it is self-signed
       name: "ama-metrics-mtls-secret"
   cert:
     secret:
       key: "<certfile>"
       name: "ama-metrics-mtls-secret"
   keySecret:
       key: "<keyfile>"
       name: "ama-metrics-mtls-secret"
   insecureSkipVerify: false

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

Если вы хотите использовать базовые параметры проверки подлинности и tls в конфигурации или CRD, просто убедитесь, что секрет ama-metrics-mtls-secret включает все файлы (ключи) в разделе данных с соответствующими значениями в кодировке base 64, как показано ниже.

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
Запрос метрик Prometheus
Дополнительные сведения о сборе метрик Prometheus