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

  • Статья

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

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

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

Примечание.

Ни один из четырех конфигураций по умолчанию не существует в кластере при включении Управляемого Prometheus. В зависимости от того, что необходимо настроить, необходимо развернуть любой или все эти четыре конфигурации с тем же именем, указанным в kube-system пространстве имен. Модули pod AMA-Metrics будут собирать эти конфигурационные карты после их развертывания в kube-system пространстве имен и перезапуститься через 2–3 минуты, чтобы применить параметры конфигурации, указанные в configmap(s).

  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.

Ключ Тип Включен Объект pod Description
kubelet bool true Linux DaemonSet Скребите kubelet на каждом узле в кластере K8s без дополнительной конфигурации слома.
cadvisor bool true Linux DaemonSet Скребите cadvisor на каждом узле в кластере K8s без дополнительной конфигурации скребка.
Только для Linux.
kubestate bool true Реплика Linux Скребите метрики kube-state-metrics в кластере K8s (устанавливается как часть надстройки) без дополнительной конфигурации слома.
nodeexporter bool true Linux DaemonSet Очистка метрик узлов без дополнительной конфигурации скребка.
Только для Linux.
coredns bool false Реплика Linux Очистка службы coredns в кластере K8s без дополнительной конфигурации слома.
kubeproxy bool false Linux DaemonSet Скребите kube-proxy на каждом узле Linux, обнаруженном в кластере K8s без дополнительной конфигурации скребка.
Только для Linux.
сервер API bool false Реплика Linux Скребите сервер API Kubernetes в кластере K8s без дополнительной конфигурации скребка.
windowsexporter bool false Windows DaemonSet Отмена экспорта окон в каждом узле в кластере K8s без дополнительной конфигурации слома.
Только для Windows.
windowskubeproxy bool false Windows DaemonSet Скребите windows-kube-proxy на каждом узле в кластере K8s без дополнительной конфигурации скребка.
Только для Windows.
prometheuscollectorhealth bool false Реплика Linux Скребите сведения о контейнере сборщика prometheus, например объем и размер временных рядов, сломанных.

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

Включение очистки на основе заметок на основе заметок 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 = ".*"

Предупреждение

Удаление заметок pod из многих пространств имен может создать очень большой объем метрик в зависимости от количества модулей pod с заметками.

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

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

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

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

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

Примечание.

Если в регрессии используются кавычки или обратные косые черты, их необходимо экранировать с помощью обратной косой черты, например примеров "test\'smetric\"s\"" и testbackslash\\*.

Чтобы дополнительно настроить задания по умолчанию для изменения свойств, таких как частота сбора или метки, отключите соответствующий целевой объект по умолчанию, задав значение конфигурации для целевого объекта 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-modetrue Этот файл конфигурации можно создать или изменить существующий. Дополнительные сведения см. в разделе "Режим отладки" в разделе "Устранение неполадок" метрик 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 и примеры

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

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

Примечание.

Если настраиваемая конфигурация скребка не применяется из-за ошибок проверки, конфигурация слома по умолчанию продолжает использоваться.

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

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

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

Мониторы pod и службы

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

Ознакомьтесь с примерами pod и мониторов служб pod и служб.

Переназначения

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

Добавление метки

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

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

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

Целевые объекты, обнаруженные с помощью мониторов pod и служб, имеют разные __meta_* метки в зависимости от используемого монитора. Метки __* удаляются после обнаружения целевых объектов. Чтобы отфильтровать их на уровне метрик, сначала сохраните их, relabelings назначив имя метки. Затем используется metricRelabelings для фильтрации.

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

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

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

# 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

Переназначения метрик

Изменения метрик применяются после слома и перед приемом. metricRelabelings Используйте раздел для фильтрации метрик после слома. В следующих примерах показано, как это сделать.

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

# 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: '.+'

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

Если у вас есть экземпляр Prometheus, обслуживающий протокол TLS, и вы хотите сломать метрики из него, необходимо задать схему https и задать параметры TLS в конфигурации или соответствующем CRD. Для настройки параметров TLS можно использовать tls_config свойство конфигурации внутри настраиваемого задания очистки, чтобы настроить параметры TLS с помощью CRD или конфигурации. Чтобы проверить сертификат сервера API, необходимо предоставить сертификат ЦС. Сертификат ЦС используется для проверки подлинности сертификата сервера при подключении Prometheus к целевому объекту по протоколу TLS. Это помогает убедиться, что сертификат сервера подписан доверенным центром.

Секрет должен быть создан в пространстве имен kube-system, а затем configmap/CRD должен быть создан в пространстве имен kube-system. Порядок создания секретов имеет значение. Если нет секрета, но допустимой карты CRD/config, вы найдете ошибки в журнале сборщика —>no file found for cert....

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

  • Чтобы предоставить параметр конфигурации TLS в конфигурации конфигурации, создайте самозаверяющий сертификат и ключ в приложении с поддержкой mtls. Пример tlsConfig в карте конфигурации должен выглядеть следующим образом:
tls_config:
    ca_file: /etc/prometheus/certs/client-cert.pem
    cert_file: /etc/prometheus/certs/client-cert.pem
    key_file: /etc/prometheus/certs/client-key.pem
    insecure_skip_verify: false
  • Чтобы указать параметр конфигурации TLS в CRD, создайте самозаверяющий сертификат и ключ в приложении с поддержкой mtls. Пример tlsConfig внутри podmonitor должен выглядеть следующим образом:
tlsConfig:
    ca:
        secret:
        key: "client-cert.pem" # since it is self-signed
        name: "ama-metrics-mtls-secret"
    cert:
        secret:
        key: "client-cert.pem"
        name: "ama-metrics-mtls-secret"
    keySecret:
        key: "client-key.pem"
        name: "ama-metrics-mtls-secret"
    insecureSkipVerify: false

Примечание.

Убедитесь, что имя файла сертификата и имя ключа внутри приложения mtls находится в следующем формате в случае слом на основе CRD. Например: secret_kube-system_ama-metrics-mtls-secret_cert-name.pem и secret_kube-system_ama-metrics-mtls-secret_key-name.pem. CrD необходимо создать в пространстве имен kube-system. Имя секрета должно быть точно ama-metrics-mtls-secret в пространстве имен kube-system. Пример команды для создания секрета: kubectl create secret generic ama-metrics-mtls-secret -from-file=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem --from-file=secret_kube-system_ama-metrics-mtls-secret_client-key.pem=secret_kube-system_ama-metrics-mtls-secret_client-key.pem -n kube-system

Дополнительные сведения о проверке подлинности TLS могут оказаться полезными в следующих документах.

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

Если вы используете basic_auth параметр в конфигурации prometheus, выполните действия.

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

Значение пароля1 — base64encoded : ключ password1 может быть любым, но просто необходимо соответствовать конфигурации скребка password_file filepath.

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>
  1. В конфигурации конфигурации настраиваемого фрагмента в конфигурации настраиваемого фрагмента используйте следующий параметр:
basic_auth:
  username: admin
  password_file: /etc/prometheus/certs/password1

Примечание.

Убедитесь, что имя — ama-metrics-mtls-secret , и оно находится в пространстве имен kube-system .

Путь /etc/prometheus/certs/certs/ является обязательным, но пароль1 может быть любой строкой и должен соответствовать ключу для данных, созданных выше. Это связано с тем, что секрет ama-metrics-mtls-secret подключен в пути /etc/prometheus/certs/ в контейнере.

Значение в кодировке Base64 автоматически декодируется модулями pod агента при подключении секрета в виде файла.

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

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

Настройка оповещений для метрик Prometheus
Запрос метрик Prometheus
Дополнительные сведения о сборе метрик Prometheus