Поделиться через

Настройка очистки метрик 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-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 = ".*"

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

Удаление заметок 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-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 и примеры

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

Используйте шаблоны 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: '.+'

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

Если вы используете 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>

Секрет секрета ama-metrics-mtls-secret подключается к контейнерам ama-metrics по пути - /etc/prometheus/certs/ и становится доступным для процесса, который удаляет метрики prometheus. Ключ (например, пароль1) в приведенном выше примере будет именем файла, а значение декодировано и добавлено в содержимое файла в контейнере, а скребок prometheus использует содержимое этого файла для получения значения, используемого в качестве пароля, используемого для извлечения конечной точки.

  1. В конфигурации конфигурации настраиваемого фрагмента в конфигурации настраиваемого фрагмента используйте следующий параметр:
basic_auth:
  username: admin
  password_file: /etc/prometheus/certs/password1

Предоставив путь к приведенному выше password_file, скребок prometheus использует содержимое файла с именем password1 в пути /etc/prometheus/certs в качестве значения пароля для базовой очистки на основе проверки подлинности.

Если вы используете обычную проверку подлинности и проверку подлинности 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 в карте конфигурации, выполните приведенный ниже пример.
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

Базовая проверка подлинности и 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

Примечание.

Примечание.

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

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

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

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

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

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

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