Мониторинг своего приложения

Что нужно знать перед уроком

M9 урок 7 — финальный чеклист приёмки. M1 урок 6 — Kubernetes Probes. Этот урок открывает M10 — модуль о том, что происходит с Application-пакетом после установки в реальном production-кластере.

Теория

PodMonitor — сбор метрик из подов приложения

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: { { .Application.Instance.Name } }
  namespace: { { .Release.Namespace } }
  labels:
    prometheus: main
spec:
  selector:
    matchLabels:
      app: { { .Application.Instance.Name } }
  podMetricsEndpoints:
    - port: metrics
      interval: 30s
      path: /metrics
      metricRelabelings:
        - targetLabel: application
          replacement: { { .Application.Instance.Name } }
          action: Replace

Критично: лейбл prometheus: main на самом объекте PodMonitor обязателен — без него Prometheus платформы Deckhouse не увидит этот ресурс вообще, поскольку встроенный Prometheus настроен на поиск PodMonitor/ServiceMonitor/Probe/ScrapeConfig именно с этим лейблом (стандартный prometheus-operator-паттерн селекции ресурсов по лейблу). Забыть этот лейбл — самая частая ошибка при первой настройке мониторинга Application.

metricRelabelings — добавление кастомных лейблов к собранным метрикам уже после сбора (в отличие от relabelings, работающего до сбора и определяющего, какие target’ы вообще опрашивать) — используется, например, для добавления метки application со значением имени конкретного инстанса, что позволяет отличать метрики разных инстансов одного и того же Application-пакета в общем Prometheus.

ScrapeConfig — альтернатива для нестандартных target’ов

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
  name: {{.Application.Instance.Name}}-external
  namespace: {{.Release.Namespace}}
  labels:
    prometheus: main
spec:
  honorLabels: true
  staticConfigs:
    - targets: ['{{.Application.Instance.Name}}.{{.Release.Namespace}}.svc.{{ .Values.global.discovery.clusterDomain }}.:8080']
  metricsPath: '/metrics'

ScrapeConfig используется вместо PodMonitor/ServiceMonitor, когда target — не обычный под, управляемый селектором лейблов внутри кластера (например, статический внешний endpoint или сервис, для которого неудобно/невозможно использовать podSelector).

Probe — проверка доступности через blackbox-exporter

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: monitoring.coreos.com/v1
kind: Probe
metadata:
  labels:
    prometheus: main
  name: {{.Application.Instance.Name}}-availability
  namespace: {{.Release.Namespace}}
spec:
  interval: 30s
  jobName: httpGet
  module: http_2xx
  prober:
    path: /probe
    scheme: http
    url: blackbox-exporter.blackbox-exporter.svc.cluster.local:9115
  targets:
    staticConfig:
      static:
      - https://{{.Application.Instance.Name}}.example.com/status

Probe принципиально отличается от PodMonitor: PodMonitor собирает метрики, которые приложение само экспонирует на /metrics (внутренняя инструментация приложения), тогда как Probe — это внешняя проверка доступности через blackbox-exporter, симулирующая реальный HTTP-запрос клиента к приложению, независимо от того, инструментировано ли само приложение метриками вообще. blackbox-exporter не входит в поставку Deckhouse по умолчанию и требует отдельной установки в кластер.

Частые ошибки и подводные камни

• Забыть лейбл prometheus: main на PodMonitor/ScrapeConfig/Probe. Самая частая и самая незаметная ошибка — ресурс создаётся успешно (валиден с точки зрения Kubernetes API), но платформенный Prometheus его просто не замечает, и метрики никогда не появляются, без какой-либо явной ошибки в логах.
• Путать metricRelabelings (после сбора) и relabelings (до сбора, определяет сам факт опроса target’а). Использование не того механизма может привести либо к отсутствию нужных лейблов, либо к неожиданному исключению target’ов из сбора.
• Использовать Probe там, где достаточно PodMonitor, и наоборот. Probe не заменяет внутреннюю инструментацию метриками — она проверяет только внешнюю доступность конкретного endpoint’а, не даёт данных о внутреннем состоянии приложения (используемая память, число активных соединений и т.д.).

Практика в кластере

1
2

d8 k get podmonitor -n course-m10-umami -o yaml | grep -A1 "prometheus:"
d8 k -n d8-monitoring exec -it prometheus-main-0 -- wget -qO- localhost:9090/api/v1/targets | grep umami

Убедитесь, что PodMonitor пакета Umami действительно распознан платформенным Prometheus как активный target.

Практика разработки

Добавьте в шаблоны пакета Umami PodMonitor для сбора внутренних метрик приложения и Probe для внешней HTTP-проверки доступности публичного endpoint’а, используя .Application.Instance.Name для параметризации имён под множественные инстансы (M5 урок 7).

Шпаргалка команд урока

1

d8 k get podmonitor,probe,scrapeconfig -n <namespace>

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — Мониторинг приложений

Статьи и блоги

• Deckhouse Prom++: оптимизация Prometheus — Flant на Habr.
• Deckhouse Prom++: как мы посадили Prometheus на RAM-диету — Flant на Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий модуль: M9.07 — Чеклист приёмки приложения и oss.yaml.
• Следующий урок: M10.02 — Кастомные дашборды и алерты.

✓ Урок пройден — все вопросы самопроверки отвечены верно