Мониторинг в Bootsman

Общее требование

Внимание!

StorageClass (например, Longhorn, Ceph CSI) — обязателен для хранения метрик. Один из выбранных стореджей должен быть установлен в качестве StorageClass по умолчанию (default) для корректной работы мониторинга.

Внимание!

Это требование относится ко всем сценариям развертывания, где устанавливаются VictoriaMetrics (в качестве хранилища метрик) или Grafana

Варианты установки

Локальный мониторингЦентрализованный мониторинг

В данном сценарии каждый Kubernetes-кластер разворачивает собственный стек мониторинга.

Преимущества:
- Полная автономность: сбой одного кластера не влияет на работу мониторинга в других.
- Простота настройки локальных метрик и оповещений.
- Возможность отдельной конфигурации для различных окружений (dev, stage, prod).

Недостатки:
- Повышенные требования к ресурсам: каждый кластер содержит полный стек мониторинга.

Обязательные компоненты:
- @storage (Longhorn, Ceph CSI и т.п.)
- victoria-metrics
- grafana-operator (опционально, для визуализации метрик)

Схема потока метрик:

В этом случае весь стек мониторинга разворачивается исключительно в управляющем (management) кластере, а в остальных кластерах только компонент отправки метрик в управляющий кластер.

Преимущества:
- Единое централизованное хранилище метрик.
- Упрощённый доступ к дашбордам и оповещениям.
- Экономия ресурсов за счёт одного экземпляра стека мониторинга.

Недостатки:
- Потенциальный сбой сбора метрик при недоступности связи с подчиненными кластерами - Более сложная настройка сетевого доступа и безопасности.

Обязательные модули в управляющем кластере: - @storage (Longhorn, Ceph CSI и т.п.)
- victoria-metrics
- grafana-operator (опционально, для визуализации)
- kube-vip
- kube-vip-cloud-provider

Обязательные модули в подчиненных кластерах:
- victoria-metrics (включенный компонент vmagent, kube-state-metrics, prometheus-node-exporter, victoria-metrics-operator, vmpushproxy-controller-manager, vmpushproxy-etcd, vmpushproxy-scheduler)
- Включение дополнительных модулей не требуется

Схема потока метрик:

Сравнение реализаций

Характеристика	Локальный мониторинг	Централизованный мониторинг
Автономность	Присутствует	Отсутствует
Масштабирование ресурсов	Линейный рост потребления	Незначительный рост
Сложность настройки	Легко	Сложнее (сеть, безопасность)
Дашборды	Независимые	Единые для всех подключенных кластеров
Оповещения	Независимые	Единые для всех подключенных кластеров

Установка

Локальный мониторинг

Подсказки

В подсказках (1) содержится команда команда kubectl patch

Пример подсказки

В кластере, где требуется сбор метрик, необходимо включить модули:

victoria-metrics (1)
grafana-operator (2)

Дополнительная настройка модулей не требуется

kubectl patch Config.addon.bootsman.tech CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"enabled\": true}}"

kubectl patch Config.addon.bootsman.tech CLUSTER_NAME-grafana-operator \
--type=merge --patch="{\"spec\": {\"enabled\": true}}"

Кнопки для перехода в компоненты мониторинга появятся в в разделе Monitoring

Централизованный мониторинг в управляющем кластере

Подсказки

В подсказках (1) содержится команда команда kubectl patch

Пример подсказки

Настройка центрального узла на управляющем кластере

Для работы потребуются настройки:

Требуется externalIP на ingress.
Для получения externalIP можно настроить модуль kube-vip-cloud-provider
Или воспользоваться другим сервисом получения externalIP.
В конфигурации модуля victoria-metrics изменить тип сервиса с ClusterIP на LoadBalancer (vmsingle.spec.serviceSpec.spec.type). (1)
Включить victoria-metrics (2)

Это обеспечит доступ к VictoriaMetrics из подчиненных кластеров.

kubectl patch Config.addon.bootsman.tech MGMT_CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"values\": {\"vmsingle\": {\"spec\": {\"serviceSpec\": {\"spec\": {\"type\": \"LoadBalancer\"}}}}}}}"

kubectl patch Config.addon.bootsman.tech MGMT_CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"enabled\": true}}"

Настройка узлов сбора метрик на подчиненных кластерах

Для работы потребуются настройки:

В конфигурации модуля victoria-metrics отключить часть компонентов (заменить true на false):
- alertmanager.enabled (1)
- defaultRules.create (2)
- vmalert.enabled (3)
- vmsingle.enabled (4)
Чтобы отправлять метрики в управляющий кластер, необходимо задать параметр vmagent.additionalRemoteWrites.
Укажите External IP от сервиса vmsingle-victoria-metrics-additional-service управляющего кластера.
Пример
```
...
vmagent:
    additionalRemoteWrites: (5)
    - url: http://ExternalIP:8428/api/v1/write
...
```
Включить victoria-metrics (6)

kubectl patch Config.addon.bootsman.tech SUB_CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"values\": {\"alertmanager\": {\"enabled\": false}}}}"

kubectl patch Config.addon.bootsman.tech SUB_CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"values\": {\"defaultRules\": {\"create\": false}}}}"

kubectl patch Config.addon.bootsman.tech SUB_CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"values\": {\"vmalert\": {\"enabled\": false}}}}"

kubectl patch Config.addon.bootsman.tech SUB_CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"values\": {\"vmsingle\": {\"enabled\": false}}}}"

Узнать External IP в управляющем кластере можно c помощью команды:

kubectl get svc vmsingle-victoria-metrics-additional-service -n monitoring \
-o jsonpath='{.status.loadBalancer.ingress[0].ip}' | awk -F% '{print $1}'

kubectl patch Config.addon.bootsman.tech SUB_CLUSTER_NAME-victoria-metrics \
--type=merge --patch="{\"spec\": {\"enabled\": true}}"