Версия: 9.3

Мониторинг инфраструктуры Monq

Чарт monq-infra-mon разворачивает в Kubernetes-кластере стек мониторинга для Monq-инфраструктуры: сбор метрик (Prometheus), алертинг (Alertmanager) и визуализация (Grafana).

Версия чарта: 1.1.1

1. Описание

Monq — это .NET-приложение, работающее в Kubernetes и оперирующее распределёнными данными: PostgreSQL, ClickHouse, Redis, ArangoDB, RabbitMQ и другими компонентами. Общая структура решения описана в документации: Структура Monq.

Ни один из перечисленных компонентов не является простой зависимостью: через них проходят данные, которые приложение читает и записывает в штатном режиме работы. Следовательно, состояние каждого компонента напрямую определяет производительность и корректность работы приложения.

1.1. Задачи мониторинга

Контроль «жив ли под» — лишь самая поверхностная часть задачи. При эксплуатации инфраструктуры Monq необходимо:

оценка производительности — длительность запросов к ClickHouse, загрузка PostgreSQL, состояние очередей сообщений RabbitMQ, использование памяти Redis.
прогнозирование отказов — заполнение дисков, исчерпание памяти, рост очередей, увеличение числа новых временных рядов (time series) в VictoriaMetrics. По этим метрикам можно спрогнозировать момент исчерпания ресурса и заблаговременно принять меры.
диагностика инцидентов — при снижении производительности, устанавливаемый стек мониторинга позволяет определить источник проблемы: кластер, базы данных или брокер сообщений.

Приложение не может работать корректно при деградации компонентов, обеспечивающих хранение и доставку данных: СУБД, брокера сообщений, объектного хранилища. Чарт автоматизирует сбор всех перечисленных метрик и предоставляет готовый алертинг по ним.

1.2. Состав стека

Компонент	Назначение
Prometheus Operator	Управление ресурсами Prometheus, ServiceMonitor, PrometheusRule и Alertmanager через CRD
Prometheus v3.15.0	Сбор и хранение метрик, генерация алертов по правилам
node-exporter v1.12.1	Метрики узлов (CPU, память, диски, сеть)
kube-state-metrics v2.17.0	Метрики объектов Kubernetes (поды, deployment'ы, PVC, узлы и другие)
blackbox-exporter v0.29.1	TCP-пробы доступности портов инфраструктурных сервисов (Consul, Garage, registry)
Alertmanager v0.34.1	Группировка, маршрутизация и дедупликация алертов, доставка уведомлений
Grafana 13.2.3	Визуализация: дашборды компонентов разворачиваются автоматически (состав — раздел 6)

1.3. Область применения и ограничения

В идеале мониторинг должен быть вынесен за пределы наблюдаемой системы (отдельный кластер/ноды), а каждый компонент мониторинга должен быть развёрнут в отказоустойчивой конфигурации (несколько реплик Prometheus, Alertmanager и Grafana, отдельное хранилище и другие меры).

В настоящем документе этот аспект не рассматривается: чарт разворачивает минимально работоспособную конфигурацию (по одной реплике каждого компонента в одном кластере). Реализация мониторинга в нужном виде и с нужной степенью надёжности остаётся на стороне клиента.

2. Архитектура сбора метрик

Краткое описание источников метрик:

Сбор метрик с компонентов СПО Monq включается флагом monitoring.enable в чартах самих компонентов: запускается exporter (postgresql, redis) либо включается встроенный эндпоинт, создаётся соответствующий сервис <имя>-monitoring, на который нацелен ServiceMonitor чарта (раздел 4.9).

Что мониторится	Источник метрик	Values-ключ
Узлы (CPU, память, диски, сеть, conntrack)	node-exporter (DaemonSet)	— (собственный ServiceMonitor, см. раздел 4.5)
Объекты Kubernetes (pods, deployments, PVC, nodes)	kube-state-metrics + ServiceMonitors для apiserver и kubelet	`kubeStateMetrics`
Ingress-nginx (5xx/404, SSL-сертификаты, reload)	Встроенный Prometheus-эндпоинт ingress-nginx	`serviceMonitors.ingressNginx`
PostgreSQL	postgresql exporter	`serviceMonitors.postgresql`
Redis	redis exporter	`serviceMonitors.redis`
ArangoDB	arangodb exporter (basic auth)	`serviceMonitors.arangodb`
ClickHouse	Встроенный Prometheus-эндпоинт ClickHouse	`serviceMonitors.clickhouse`
RabbitMQ	Встроенный Prometheus-эндпоинт RabbitMQ	`serviceMonitors.rabbitmq`
VictoriaMetrics	Встроенный `/metrics` (basic auth)	`serviceMonitors.victoriaMetrics`
Порты инфраструктурных сервисов (Consul, Garage, registry)	blackbox-exporter (TCP-пробы, ресурсы `Probe`)	`tcpProbes` (см. раздел 4.11)

В Grafana развёрнуты дашборды для каждого из перечисленных компонентов (см. раздел 6).

Важно: неймспейсы и лейблы.

По умолчанию компоненты Monq ожидаются в неймспейсе infra (ingress-nginx — в ingress-nginx) с лейблами app: <имя-компонента>:
serviceMonitors:
  clickhouse:
    enabled: true
    namespace: infra        # <-- неймспейс, в котором развёрнут компонент
    matchLabels:            # <-- лейблы Service, для которого настраивается сбор
      app: clickhouse
    port: metrics           # <-- имя порта в Service
Если компонент развёрнут в другом неймспейсе, с другими лейблами или другим именем порта — скорректируйте namespace / matchLabels / port соответствующего ключа. Если компонент не используется — установите enabled: false (аналогично отключаются связанные дашборды и правила, см. разделы 4.7 и 4.10).

node-exporter и kube-state-metrics могут быть как развёрнуты самим чартом, так и уже существовать в кластере (развёрнуты другим чартом). В последнем случае собственное развёртывание чарта отключается, а ServiceMonitor нацеливается на существующий Service (см. разделы 4.5, 4.6 и примеры в разделе 5).

Общие параметры сбора:

интервал сбора — 1m (задан в шаблоне Prometheus, не настраивается через values)
retention Prometheus — 14d (раздел 4.3)
удалённая запись во внешнее хранилище выключена по умолчанию

3. Alertmanager и правила алертинга

3.1. Группы алертов

Правила алертинга разворачиваются как ресурсы CRD PrometheusRule (файлы templates/rules/). Все правила несут метку severity (critical / warning / info), на которой базируются маршруты Alertmanager (см. 3.2). Каждый файл правил включается отдельным флагом в alertRules (раздел 4.10). Полный реестр правил — наименование, назначение, пороговые значения, таймауты for и примечания — изложен в справке RULES.md.

Инфраструктурные группы (состояние кластера и узлов):

Файл правил	Флаг	Содержимое
`main.yaml`	— (всегда, кроме agent-режима)	`Instance down` — целевая система недоступна (`up != 1`)
`node-exporter.yaml`	`nodeExporter.enabled`	Узлы: заполнение дисков и inode (`NodeFilesystemSpaceFillingUp`, `NodeFilesystemAlmostOutOfSpace`, `NodeFilesystemFilesFillingUp` и другие), сетевые ошибки (RX/TX), conntrack, сдвиг или остановка синхронизации часов (`NodeClockSkewDetected`, `NodeClockNotSynchronising`), деградация/отказ RAID, превышение лимита файловых дескрипторов
`kubernetes.yaml`	—	Стандартный набор kube-prometheus: CrashLoopBackOff, NotReady поды и ноды, рассинхронизация replicas, необновлённые DaemonSet, HPA на максимальном значении, избыточное выделение CPU/памяти (overcommit), заполнение PVC, ошибки API-сервера, истечение срока действия сертификатов и другие
`kubernetes-additional.yaml`	—	`KubePodTerminated` — контейнеры, перешедшие в состояние terminated с причиной, отличной от Completed (ошибка, OOMKilled и другие)
`kube-state-metrics.yaml`	— (следует за `kubeStateMetrics.enabled`)	Контроль состояния kube-state-metrics

Прикладные (компонентные) группы (состояние подсистем данных и брокеров сообщений, с которыми работает Monq):

Файл правил	Флаг	Примеры алертов
`rabbitmq.yaml`	`alertRules.rabbitmq.enabled`	`OutOfMemory` (память брокера > 90%), `TooManyMessagesInQueue` (> 300 / > 1000 сообщений), `NoConsumer`
`postgresql.yaml`	`alertRules.postgresql.enabled`	`PostgresqlDown`, `TooManyConnections`, `DeadLocks`, `SlowQueries`
`redis.yaml`	`alertRules.redis.enabled`	`RedisDown`, `NoClientConnection`, `OutOfMemory` (> 90%)
`clickhouse.yaml`	`alertRules.clickhouse.enabled`	`ClickHouseDown`, `ClickHouseTooManyFailedQueries`, `ClickHouseSlowQueries`, `ClickHouseHighMemoryUsage`, `ClickHouseMergeQueueBacklog`, `ClickHouseDiskAlmostFull`, `ClickHouseZooKeeperErrors`
`arangodb.yaml`	`alertRules.arangodb.enabled`	`ArangoDbDown`, `ArangoDbQueryMemoryLimitReached`, `ArangoDbSchedulerQueueFull`, `ArangoDbHeartbeatFailures`, `ArangoDbSlowQueries`, `ArangoDbRequestTimeouts`, `ArangoDbDiskAlmostFull`
`victoriaMetrics.yaml`	`alertRules.victoriaMetrics.enabled`	`VictoriaMetricsDown`, `VictoriaMetricsTooManyRestarts`, `VictoriaMetricsUncleanShutdown`, `VictoriaMetricsDiskRunsOutOfSpace`, `VictoriaMetricsTooHighChurnRate`, `VictoriaMetricsTooHighSlowInsertsRate`, `VictoriaMetricsRequestErrorsToAPI`, `VictoriaMetricsTooHighMemoryUsage`, `VictoriaMetricsTooManyErrorLogs`
`ingress-nginx.yaml`	`alertRules.ingressNginx.enabled`	`reload failed`, `High error rate with 500`, `High error rate with 404`, `SSL cert expire` (< 7 дней)

3.2. Настройка получателей (receivers) и маршрутов (routes)

Конфигурация Alertmanager целиком задаётся в values: alertmanager.specConfig (раздел 4.4) и преобразуется в ресурс CRD AlertmanagerConfig.

По умолчанию чарт разворачивает конфигурацию без каналов доставки: единственный receiver — null, алерты генерируются и отображаются в UI Alertmanager, но никуда не доставляются. Перед вводом в эксплуатацию необходимо настроить получателей, в первую очередь для алертов с severity: critical (падение БД/брокера, заполнение дисков).

Обратите внимание: specConfig использует схему CRD prometheus-operator (camelCase: groupBy, groupInterval, repeatInterval, matchers), а не нативный YAML Alertmanager (snake_case). matchers — это объекты {name, value, isRegex/matchType}, например {name: severity, value: warning|critical, matchType: "=~"}.

UI Alertmanager: http://alertmanager.<domain> (по умолчанию http://alertmanager.in.monq.local).

4. Справочник по values

Способ конфигурации: собственный файл values (helm upgrade --install monq-infra-mon ./monq-infra-mon -n monitoring -f values-prod.yaml) или точечные --set (примеры — в разделе 5). Все ключи, описанные ниже, присутствуют в values.yaml со значениями по умолчанию.

4.1. Глобальные ключи

Ключ	Значение по умолчанию	Назначение
`domain`	`in.monq.local`	Базовый домен инфраструктуры, из него формируются хосты ingress и `externalUrl` Prometheus/Alertmanager: `<компонент>.<domain>`
`imagePullSecrets`	`[]`	Список имён imagePullSecrets, добавляемых ко всем подам, развёртываемым чартом
`nodeSelector`	`kubernetes.io/os: linux`	Node selector для всех подов чарта
`imagePullPolicy`	`IfNotPresent`	Политика загрузки контейнерных образов

4.2. `prometheusOperator`

Ключ	Значение по умолчанию	Назначение
`prometheusOperator.version`	`v0.94.1`	Версия оператора (один и тот же тег используется для образов `prometheus-operator` и `prometheus-config-reloader`)
`prometheusOperator.image.registry` / `.repository`	`quay.io` / `prometheus-operator/prometheus-operator`	Адрес реестра и имя образа оператора
`prometheusOperator.configReloader.image.registry` / `.repository`	`quay.io` / `prometheus-operator/prometheus-config-reloader`	Адрес реестра и имя образа config-reloader

CRD оператора (crds/operatorCrd.yaml) входят в пакет: при helm install Helm применяет их автоматически до шаблонов (каталог crds/ — стандартный механизм Helm). При желании их можно применить вручную заранее (идемпотентно):

kubectl apply -f crds/operatorCrd.yaml

4.3. `prometheus`

Ключ	Значение по умолчанию	Назначение
`prometheus.agent`	`false`	Режим работы. `false` — классический Prometheus: локальное хранилище, правила алертинга, интеграция с Alertmanager. `true` — `PrometheusAgent`: только сбор и удалённая запись, без локального хранилища, правил и Alertmanager (в этом режиме файлы `prometheus.yaml`, `alertmanager/`, `rules/` не разворачиваются. Пример — раздел 5.4)
`prometheus.image.registry` / `.repository`	`quay.io` / `prometheus/prometheus`	Образ Prometheus
`prometheus.version`	`v3.15.0`	Версия Prometheus
`prometheus.retention`	`14d`	Период хранения метрик в TSDB (применяется только в классическом режиме, `agent: false`)
`prometheus.ingress.enabled`	`true`	Разворачивать ли ingress на UI Prometheus
`prometheus.ingress.className`	`nginx`	ingressClassName
`prometheus.externalLabels`	`dc: monq`	Метки, добавляемые ко всем метрикам (используются для идентификации источника при удалённой записи в централизованное хранилище)
`prometheus.remoteWrite.enabled`	`false`	Включить удалённую запись
`prometheus.remoteWrite.url` / `.path`	`http://127.0.0.1` / `/api/v1/write`	Адрес удалённого хранилища (обычно VictoriaMetrics)
`prometheus.remoteWrite.headers`	`[]`	Дополнительные заголовки
`prometheus.remoteWrite.basicAuth`	—	`username`/`password` — создаются в секрете `prometheus-remote-write`
`prometheus.storageSpec`	`{}`	Спецификация хранилища Prometheus (см. ниже). Используется только при `localStorage.prometheus.enable: false` (раздел 4.8). При пустом значении данные хранятся во временном томе пода (emptyDir) и теряются при пересоздании пода

Пример storageSpec (100 GiB на указанном storageClass):

prometheus:
  storageSpec:
    volumeClaimTemplate:
      spec:
        storageClassName: fast-ssd
        accessModes: [ ReadWriteOnce ]
        resources:
          requests:
            storage: 100Gi

4.4. `alertmanager`

Ключ	Значение по умолчанию	Назначение
`alertmanager.enabled`	`true`	Разворачивать ли Alertmanager (недоступен в agent-режиме)
`alertmanager.image.registry` / `.repository`	`quay.io` / `prometheus/alertmanager`	Образ
`alertmanager.version`	`v0.34.1`	Версия
`alertmanager.retention`	`120h`	Период хранения данных об алертах (состояния и silences)
`alertmanager.ingress.enabled` / `.className`	`true` / `nginx`	Ingress на UI Alertmanager (хост — `alertmanager.<domain>`)
`alertmanager.specConfig`	receiver `null`	Полная конфигурация Alertmanager в схеме CRD `AlertmanagerConfig` (receivers, route, routes, groupBy и другие) — см. раздел 3.2

4.5. `nodeExporter`

Ключ	Значение по умолчанию	Назначение
`nodeExporter.enabled`	`true`	Разворачивать ли ServiceMonitor для сбора метрик узлов. Оставьте включенным при наличии node-exporter в кластере или если планируется его установка данным чартом
`nodeExporter.deploy.enabled`	`true`	Разворачивать ли DaemonSet + Service node-exporter при помощи этого чарта. Установите `false` — если node-exporter уже существует в кластере и сбор нужно настроить на него
`nodeExporter.serviceMonitor.namespace`	`""`	Неймспейс, в котором расположен Service node-exporter. Пустое значение — неймспейс релиза
`nodeExporter.serviceMonitor.matchLabels`	`app.kubernetes.io/name: node-exporter`	Лейблы-селектор Service
`nodeExporter.image`	`quay.io/prometheus/node-exporter`	Образ
`nodeExporter.version`	`v1.12.1`	Версия

4.6. `kubeStateMetrics`

Структура идентична nodeExporter (та же логика: собственное развёртывание чартом либо уже существующее в кластере):

Ключ	Значение по умолчанию	Назначение
`kubeStateMetrics.enabled`	`true`	Разворачивать ли ServiceMonitor (и правила) для kube-state-metrics
`kubeStateMetrics.deploy.enabled`	`true`	Разворачивать ли Deployment + Service + RBAC kube-state-metrics самим этим чартом
`kubeStateMetrics.serviceMonitor.namespace`	`""`	Неймспейс Service KSM (пустое значение — неймспейс релиза)
`kubeStateMetrics.serviceMonitor.matchLabels`	`app.kubernetes.io/name: kube-state-metrics`	Лейблы-селектор Service
`kubeStateMetrics.image`	`registry.k8s.io/kube-state-metrics/kube-state-metrics`	Образ
`kubeStateMetrics.version`	`v2.17.0`	Версия — зафиксирована под версию Kubernetes кластера (1.33) согласно compatibility matrix

4.7. `grafana`

Ключ	Значение по умолчанию	Назначение
`grafana.enabled`	`true`	Разворачивать ли Grafana (включая автоматическую настройку дашбордов и datasource)
`grafana.image.registry` / `.repository`	`docker.io` / `grafana/grafana`	Образ
`grafana.version`	`13.2.3`	Версия
`grafana.adminPassword`	`monq-infra-mon`	Пароль пользователя `admin`. Хранится в секрете `grafana` и передаётся через переменную окружения `GF_SECURITY_ADMIN_PASSWORD`. В рабочей среде необходимо изменить.
`grafana.ingress.enabled` / `.className`	`true` / `nginx`	Ingress на UI Grafana (хост — `grafana.<domain>`)
`grafana.persistence.enabled`	`false`	Создавать ли PVC под домашний каталог Grafana (`/var/lib/grafana`) — пользовательские дашборды и datasource, созданные в UI, сохранятся после перезапуска пода. При включённом `localStorage.grafana` (раздел 4.8) этот параметр не используется
`grafana.persistence.size`	`5Gi`	Размер тома
`grafana.persistence.accessModes`	`[ReadWriteOnce]`	Режимы доступа тома
`grafana.persistence.storageClassName`	`""`	Storage class (пустое значение — storage class по умолчанию)
`grafana.datasources`	`[]`	Дополнительные datasource, провижинируемые в `datasources/prometheus.yaml` (дополняют datasource Prometheus по умолчанию)
`grafana.alertmanager.enabled`	`false`	Интеграция Grafana с Alertmanager: datasource Alertmanager (uid `alertmanager`), плагин Prometheus AlertManager Datasource и дашборд «Alerts». Выключено по умолчанию: при первом старте пода плагин скачивается с grafana.com (`GF_PLUGINS_PREINSTALL_SYNC`), и под не поднимется без доступа к нему
`grafana.dashboards.<имя>.enabled`	см. раздел 6	Разворачивать ли указанный дашборд

Datasource Prometheus разворачивается всегда: имя Prometheus, uid prometheus, http://prometheus:9090. Все дашборды чарта ссылаются на него через переменную datasource, по умолчанию в этой переменной выбран данный datasource.

Datasource Alertmanager (http://alertmanager.<неймспейс-релиза>.svc.cluster.local:9093, uid alertmanager, тип camptocamp-prometheus-alertmanager-datasource) разворачивается только при grafana.alertmanager.enabled: true (по умолчанию — выключено, чтобы под стартовал без доступа к grafana.com в изолированных окружениях). Плагин Prometheus AlertManager Datasource при включённой интеграции устанавливается из маркетплейса grafana.com. После первой установки плагин хранится на томе /var/lib/grafana. Вместе с datasource добавляется дашборд «Alerts» (files/dashboards/prometheus-alerts.json): его переменная datasource перечисляет datasource'ы этого типа плагина.

Дашборды (раздел 6) и ключи в grafana.dashboards совпадают по именам: node-exporter, rabbitmq, k8s-basic-metrics, k8s-ingress-nginx, clickhouse-metrics, rabbitmq-internal, arangodb, redis, postgresql, clickhouse, victoriametrics. Дашборд «Alerts» (prometheus-alerts.json) разворачивается вместе с интеграцией Alertmanager (ключ grafana.alertmanager.enabled).

4.8. `localStorage` — локальное хранилище Prometheus и Grafana

Чарт создаёт PersistentVolume типа local-storage: данные размещаются на дисках узлов, размеченных меткой nodeSelectorName, а под компонента закрепляется за тем же узлом (через nodeSelector). Оба PV используют один и тот же StorageClass, поэтому каждый явно прикреплён к своему PVC через claimRef.

Ключ	Значение по умолчанию	Назначение
`localStorage.nodeSelectorName`	`monitoring`	Имя метки, которой отмечен узел, на котором создаётся хранилище
`localStorage.nodeSelectorValue`	`""`	Значение метки узла (пустое значение — штатный для Monq способ разметки узлов)
`localStorage.storageClassName`	`local-storage`	Storage class для PV и PVC
`localStorage.prometheus.enable`	`true`	Создать PV для Prometheus и использовать его для хранилища (в этом случае `prometheus.storageSpec` игнорируется). В agent-режиме PV не создаётся
`localStorage.prometheus.storageSize`	`50Gi`	Размер тома Prometheus
`localStorage.prometheus.storagePath`	`/storage/prometheus`	Каталог на узле, в который размещаются данные
`localStorage.grafana.enable`	`true`	Создать PV для Grafana и использовать его для домашнего каталога (в этом случае `grafana.persistence` игнорируется)
`localStorage.grafana.storageSize`	`5Gi`	Размер тома Grafana
`localStorage.grafana.storagePath`	`/storage/grafana`	Каталог на узле, в который размещаются данные

Требования к узлу:

на узле, отведённом под хранилище, должна присутствовать метка <nodeSelectorName> (по умолчанию monitoring)
каталоги storagePath создаются на узле заранее — при отсутствии каталога монтирование локального тома завершится ошибкой

При отключении локального хранилища для компонента (enable: false) в действие вступают штатные параметры: prometheus.storageSpec (раздел 4.3) и grafana.persistence (раздел 4.7).

4.9. `serviceMonitors` — настройка сбора метрик компонентов

Общая форма каждого блока:

serviceMonitors:
  <компонент>:
    enabled: true|false        # разворачивать ли ServiceMonitor
    namespace: <неймспейс>     # неймспейс, в котором расположен Service компонента
    matchLabels: { ... }         # лейблы Service
    port: <имя порта>          # имя порта (не номер!) в Service

Ключ	Неймспейс (по умолчанию)	Порт	Особые поля
`serviceMonitors.ingressNginx`	`ingress-nginx`	`metrics`	—
`serviceMonitors.postgresql`	`infra`	`metrics`	—
`serviceMonitors.arangodb`	`infra`	`http`	`username`, `password` (basic auth для exporter'а)
`serviceMonitors.clickhouse`	`infra`	`metrics`	— (встроенный эндпоинт ClickHouse)
`serviceMonitors.redis`	`infra`	`metrics`	—
`serviceMonitors.rabbitmq`	`infra`	`prometheus`	— (встроенный эндпоинт RabbitMQ)
`serviceMonitors.victoriaMetrics`	`infra`	`http`	`username`, `password` — создаются в секрете `victoria-auth`

Помимо них чарт содержит ServiceMonitors, не настраиваемые через values (компоненты самого стека мониторинга): kube-state-metrics (см. 4.6), node-exporter (см. 4.5), kubelet, apiserver, blackbox-exporter (см. 4.11).

Согласованность ключей.

При отключении компонента в serviceMonitors необходимо также отключить его дашборд (grafana.dashboards.<имя>) и правила алертинга (alertRules.<имя>).

4.10. `alertRules` — флаги правил алертинга

Ключ	Значение по умолчанию	Файл правил
`alertRules.ingressNginx.enabled`	`true`	`rules/ingress-nginx.yaml`
`alertRules.postgresql.enabled`	`true`	`rules/postgresql.yaml`
`alertRules.redis.enabled`	`true`	`rules/redis.yaml`
`alertRules.rabbitmq.enabled`	`true`	`rules/rabbitmq.yaml`
`alertRules.arangodb.enabled`	`true`	`rules/arangodb.yaml`
`alertRules.clickhouse.enabled`	`true`	`rules/clickhouse.yaml`
`alertRules.victoriaMetrics.enabled`	`true`	`rules/victoriaMetrics.yaml`
`alertRules.blackbox.enabled`	`true`	`rules/blackbox.yaml`

Файлы main.yaml, kubernetes*.yaml, node-exporter.yaml не имеют отдельных флагов (разворачиваются вместе со стеком; kube-state-metrics.yaml следует за kubeStateMetrics.enabled). Все правила алертинга разворачиваются только в классическом режиме (prometheus.agent: false). Файл blackbox.yaml дополнительно разворачивается только при tcpProbes.enabled: true (см. 4.11): при отсутствии проб нечего и алертить.

4.11. `blackboxExporter` и `tcpProbes` — TCP-пробы доступности портов

blackbox-exporter — пробник (prober) prometheus-operator'а: Prometheus опрашивает его, а он выполняет TCP-соединение к указанному host:port. Это проверка «порт слушает» без взаимодействия по протоколу сервиса (используется только модуль tcp_connect). Результат — метрики probe_success (1/0), probe_duration_secs, probe_failure_reason; алертинг — rules/blackbox.yaml (TcpProbeFailed, TcpProbeNoData, TcpProbeSlow, см. 4.10 и справку RULES.md).

blackboxExporter:
  enabled: true               # ServiceMonitor для самого blackbox-exporter
  deploy:
    enabled: true             # Deployment/Service/конфиг blackbox-exporter
  image: quay.io/prometheus/blackbox-exporter
  version: v0.29.1

tcpProbes:
  enabled: true               # создавать ресурсы Probe (+ правила при alertRules.blackbox)
  interval: 30s               # интервал пробы
  timeout: 10s                # таймаут пробы и скрейпа (не больше interval)
  targets:
    - name: consul-http       # имя входит в имя Probe-ресурса: tcp-probe-<name>
      target: consul.infra.svc.cluster.local:8500
    - name: garage-s3
      target: garage.infra.svc.cluster.local:3900
    - name: garage-api
      target: garage.infra.svc.cluster.local:3903
    - name: registry
      target: registry.in.monq.local:5000

Цели по умолчанию и что они проверяют:

Probe-ресурс	Цель	Проверяется
`tcp-probe-consul-http`	`consul.infra.svc.cluster.local:8500`	Consul client API (порт `http`)
`tcp-probe-garage-s3`	`garage.infra.svc.cluster.local:3900`	Garage S3 API (порт `s3`)
`tcp-probe-garage-api`	`garage.infra.svc.cluster.local:3903`	Garage admin API (порт `api`)
`tcp-probe-registry`	`registry.in.monq.local:5000`	Реестр образов

Как получить/уточнить список целей по конкретному кластеру:

Consul и Garage — адреса берутся из их Service в неймспейсе infra в форме <имя-svc>.<неймспейс>.svc.cluster.local:<порт> (clusterIP фиксировать не нужно, он меняется):
```
kubectl get svc -n infra consul garage -o yaml   # порты: http 8500; s3 3900, api 3903
```
Реестры образов — полный список уникальных адресов реестров, реально используемых в кластере, извлекается из образов запущенных подов (включая init-контейнеры):
```
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.initContainers[*]}{.image}{"\n"}{end}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | awk -F/ '$1 ~ /[.:]/ {print $1}' | sort -u
```
Дополнительно адреса реестров видны в конфиге CoreDNS (kubectl -n kube-system get cm coredns -o yaml) и в конфиге containerd на нодах (/etc/containerd/certs.d/*/hosts.toml). Каждый адрес, отличный от дефолтного, добавляется в tcpProbes.targets отдельной целью.

Отключение и переиспользование пробника.

tcpProbes.enabled: false — Probe-ресурсы и правила blackbox.yaml не разворачиваются. blackboxExporter.deploy.enabled: false — собственный Deployment не создаётся (пробник поставляется другим чартом); имена Probe тогда должны указывать на существующий сервис пробника blackbox-exporter в неймспейсе релиза. При выключении tcpProbes.enabled выключайте и alertRules.blackbox.enabled (см. согласованность ключей в 4.10).

5. Примеры конфигурации

5.1. Базовая конфигурация (все компоненты по умолчанию)

helm upgrade --install monq-infra-mon ./monq-infra-mon \
  -n monitoring --create-namespace

5.2. Конфигурация файлом values

helm upgrade --install monq-infra-mon ./monq-infra-mon \
  -n monitoring -f values-prod.yaml

values-prod.yaml — файл, содержащий только отличия от значений по умолчанию, например:

# Хосты ingress: <компонент>.<domain>
domain: monq.example.local

grafana:
  adminPassword: "CHANGE_ME"
  persistence:
    enabled: true
    size: 10Gi
prometheus:
  retention: 7d
  storageSpec:
    volumeClaimTemplate:
      spec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi
serviceMonitors:
  clickhouse:
    namespace: bigdata        # ClickHouse развёрнут не в неймспейсе infra
alertmanager:
  specConfig:
  # ... receivers/routes, см. раздел 3.2

5.3. Переиспользование кластерных node-exporter / kube-state-metrics

Если node-exporter и kube-state-metrics уже развёрнуты другим чартом (например, в неймспейсе monitoring), достаточно в values-файле отключить собственное развёртывание чарта и нацелить ServiceMonitor на существующие Service:

# values-reuse-exporters.yaml
nodeExporter:
  deploy:
    enabled: false
  serviceMonitor:
    namespace: monitoring
    matchLabels:
      app.kubernetes.io/name: node-exporter
kubeStateMetrics:
  deploy:
    enabled: false
  serviceMonitor:
    namespace: monitoring
    matchLabels:
      app.kubernetes.io/name: kube-state-metrics

helm upgrade --install monq-infra-mon ./monq-infra-mon -n monitoring \
  -f values-reuse-exporters.yaml

При этом сбор метрик и алерты сохраняются — чарт перестаёт создавать собственные развёртывания и нацеливает ServiceMonitor на существующие Service.

5.4. Режим агента (сбор + удалённая запись в централизованное хранилище)

prometheus:
  agent: true
  remoteWrite:
    enabled: true
    url: http://victoriametrics.infra.svc:8428
    path: /api/v1/write

В этом режиме создаётся ресурс PrometheusAgent (имя monq-infra-mon) — без локального хранилища, без Alertmanager и без правил алертинга. Grafana при этом разворачивается, однако datasource по умолчанию указывает на agent, который данные не хранит, — настройте datasource на фактическое хранилище через grafana.datasources (раздел 4.7).

6. Grafana: дашборды и доступ

UI: http://grafana.<domain>, пользователь admin, пароль — grafana.adminPassword.

Дашборды добавляются при старте (защищены от редактирования в UI, allowUiUpdates: false), у встроенных uid — monq-<имя>, кастомные сохраняют свой исходный uid:

Ключ `grafana.dashboards`	Дашборд	По умолчанию
`node-exporter`	Node Exporter (grafana.com #1860)	включён
`rabbitmq`	RabbitMQ Overview (официальный, из rabbitmq-server)	включён
`k8s-basic-metrics`	Kubernetes (кастомный, базовые метрики узлов/подов)	включён
`k8s-ingress-nginx`	Ingress controller (nginx) (кастомный)	включён
`clickhouse-metrics`	ClickHouse (detailed) (кастомный, метрики ClickHouseMetrics_*)	включён
`rabbitmq-internal`	RabbitMQ Internal (кастомный)	включён
`arangodb`	ArangoDB (кастомный, метрики AQL-запросов)	включён
`redis`	Redis (grafana.com)	выключен
`postgresql`	PostgreSQL (кастомный)	выключен
`clickhouse`	ClickHouse (default) — дашборд, построенный на встроенных метриках ClickHouse	выключен
`victoriametrics`	VictoriaMetrics (grafana.com #10229)	выключен

Каждый дашборд разворачивается в отдельный ConfigMap grafana-dashboard-<имя> и монтируется в /var/lib/grafana/dashboards/.

7. Версии

Компонент	Версия
Chart	1.1.1
prometheus-operator	v0.94.1
Prometheus	v3.15.0
Alertmanager	v0.34.1
Grafana	13.2.3
node-exporter	v1.12.1
kube-state-metrics	v2.17.0
blackbox-exporter	v0.29.1

1. Описание​

1.1. Задачи мониторинга​

1.2. Состав стека​

1.3. Область применения и ограничения​

2. Архитектура сбора метрик​

3. Alertmanager и правила алертинга​

3.1. Группы алертов​

3.2. Настройка получателей (receivers) и маршрутов (routes)​

4. Справочник по values​

4.1. Глобальные ключи​

4.2. prometheusOperator​

4.3. prometheus​

4.4. alertmanager​

4.5. nodeExporter​

4.6. kubeStateMetrics​

4.7. grafana​

4.8. localStorage — локальное хранилище Prometheus и Grafana​

4.9. serviceMonitors — настройка сбора метрик компонентов​

4.10. alertRules — флаги правил алертинга​

4.11. blackboxExporter и tcpProbes — TCP-пробы доступности портов​

5. Примеры конфигурации​

5.1. Базовая конфигурация (все компоненты по умолчанию)​

5.2. Конфигурация файлом values​

5.3. Переиспользование кластерных node-exporter / kube-state-metrics​

5.4. Режим агента (сбор + удалённая запись в централизованное хранилище)​

6. Grafana: дашборды и доступ​

7. Версии​