Автоматическая настройка системы мониторинга для сбора метрик с пользовательских приложений

Для мониторинга пользовательских приложений, запущенных в кластере, требуется дополнительная настройка. Этот модуль упрощает процесс настройки, сводя её к указанию для нужного приложения определённого лейбла.

Чтобы организовать сбор метрик с приложений модулем monitoring-custom, необходимо:

• Поставить лейбл prometheus.deckhouse.io/custom-target на Service или под. Значение лейбла определит имя в списке target’ов Prometheus.

  • В качестве значения лейбла prometheus.deckhouse.io/custom-target рекомендуется использовать название приложения (маленькими буквами, разделитель -), которое позволяет его уникально идентифицировать в кластере.

    Если приложение ставится в кластер больше одного раза (staging, testing и т. д.) или даже ставится несколько раз в одно пространство имён, достаточно одного общего названия, так как у всех метрик в любом случае будут лейблы namespace, pod и, если доступ осуществляется через Service, лейбл service. Это название, уникально идентифицирующее приложение в кластере, а не его единичную инсталляцию.

• Порту, с которого нужно собирать метрики, указать имя http-metrics и https-metrics для подключения по HTTP или HTTPS соответственно.

  Если это невозможно (например, порт уже определен и назван другим именем), необходимо воспользоваться аннотациями: prometheus.deckhouse.io/port: номер_порта — для указания порта и prometheus.deckhouse.io/tls: "true" — если сбор метрик будет проходить по HTTPS.

  При указании аннотации на Service в качестве значения порта необходимо использовать targetPort. То есть тот порт, что открыт и слушается приложением, а не порт Service’а.

  • Пример 1:

    ports:
    - name: https-metrics
      containerPort: 443

  • Пример 2:

    annotations:
      prometheus.deckhouse.io/port: "443"
      prometheus.deckhouse.io/tls: "true"  # Если метрики отдаются по HTTP, эту аннотацию указывать не нужно.

  Prometheus не проверяет сертификат HTTPS-таргета: приложения обычно отдают самоподписанный. Сам Prometheus аутентифицируется клиентским сертификатом, выписанным CA платформы kube-rbac-proxy, — см. как обеспечить безопасный доступ к метрикам.

• При использовании service mesh Istio в режиме STRICT mTLS указать для сбора метрик следующую аннотацию у Service или Pod: prometheus.deckhouse.io/istio-mtls: "true". Важно, что метрики приложения должны экспортироваться по протоколу HTTP без TLS.

  Аутентификацией на этом пути служит сам сертификат Istio, поэтому мигрировать ничего не нужно. Bearer-токен сюда больше не отправляется — см. что с таргетами, которые скрейпятся через Istio mTLS, если вы использовали этот токен для авторизации.

• (Необязательно) Укажите дополнительные аннотации для более тонкой настройки:

  • prometheus.deckhouse.io/path — путь для сбора метрик (по умолчанию: /metrics).
  • prometheus.deckhouse.io/query-param-$name — GET-параметры, будут преобразованы в map вида $name=$value (по умолчанию: ‘’):

    • возможно указать несколько таких аннотаций.

      Например, prometheus.deckhouse.io/query-param-foo=bar и prometheus.deckhouse.io/query-param-bar=zxc будут преобразованы в query: http://...?foo=bar&bar=zxc.

  • prometheus.deckhouse.io/allow-unready-pod — разрешает сбор метрик с подов в любом состоянии (по умолчанию метрики собираются только с подов в состоянии Ready). Эта опция полезна в редких случаях. Например, если ваше приложение запускается очень долго (при старте загружаются данные в базу или заполняются кеши), но в процессе запуска уже отдаются полезные метрики, которые помогают следить за запуском приложения.
  • prometheus.deckhouse.io/sample-limit — сколько семплов разрешено собирать с пода (по умолчанию 5000). Значение по умолчанию защищает от ситуации, когда приложение внезапно начинает отдавать слишком большое количество метрик, что может нарушить работу всего мониторинга. Аннотация должна быть размещена на том же ресурсе, на котором расположен лейбл prometheus.deckhouse.io/custom-target.

Пример: Service

apiVersion: v1
kind: Service
metadata:
  name: my-app
  namespace: my-namespace
  labels:
    prometheus.deckhouse.io/custom-target: my-app
  annotations:
    prometheus.deckhouse.io/port: "8061"                      # По умолчанию будет использоваться порт сервиса с именем http-metrics или https-metrics.
    prometheus.deckhouse.io/path: "/my_app/metrics"           # По умолчанию /metrics.
    prometheus.deckhouse.io/query-param-format: "prometheus"  # По умолчанию ''.
    prometheus.deckhouse.io/allow-unready-pod: "true"         # По умолчанию поды НЕ в Ready игнорируются.
    prometheus.deckhouse.io/sample-limit: "5000"              # По умолчанию принимается не больше 5000 метрик от одного пода.
spec:
  ports:
  - name: my-app
    port: 8060
  - name: http-metrics
    port: 8061
    targetPort: 8061
  selector:
    app: my-app

Пример: Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        prometheus.deckhouse.io/custom-target: my-app
      annotations:
        prometheus.deckhouse.io/sample-limit: "5000"  # По умолчанию принимается не больше 5000 метрик от одного пода.
    spec:
      containers:
      - name: my-app
        image: my-app:1.7.9
        ports:
        - name: https-metrics
          containerPort: 443

Переход HTTPS-таргетов на аутентификацию по сертификату

Раньше Prometheus аутентифицировался на HTTPS-таргетах bearer-токеном. По соображениям безопасности теперь используется клиентский сертификат.

На переходный период Prometheus продолжает отправлять токен рядом с сертификатом, поэтому настроенный по-старому kube-rbac-proxy продолжает работать. Этим управляет параметр sendLegacyBearerToken, по умолчанию true. Пока он включён, срабатывает алерт D8MonitoringCustomLegacyBearerTokenEnabled — напоминание о том, что токен всё ещё отправляется.

Как смигрировать:

1. Добавьте --client-ca-file=/etc/kube-rbac-proxy/ca.crt в каждый kube-rbac-proxy, который защищает ваши метрики, и смонтируйте ConfigMap prometheus-custom-scraper-ca.crt в /etc/kube-rbac-proxy. Этот ConfigMap создаётся автоматически в каждом namespace, где есть HTTPS-таргет с лейблом prometheus.deckhouse.io/custom-target; полный манифест — в разделе как обеспечить безопасный доступ к метрикам.

   Если ваш прокси уже запущен с --client-ca-file, не заменяйте файл, на который он указывает: флаг принимает связку, поэтому допишите содержимое prometheus-custom-scraper-ca.crt к тому CA, которому вы уже доверяете.

2. Убедитесь, что таргеты остались в состоянии UP в Prometheus. Больше менять ничего не нужно: сертификат выписан на ту же идентичность, поэтому ранее выданные права продолжают работать.

3. Выключите параметр:

   kubectl patch moduleconfig monitoring-custom --type merge \
     -p '{"spec":{"settings":{"sendLegacyBearerToken":false}}}'

   Алерт погаснет после переприменения настроек модуля. Если после этого таргет ушёл в down с ошибкой 401, значит его kube-rbac-proxy не смигрирован: включите параметр обратно, выполните для этого таргета шаг 1 и повторите.