Как настроить алертинг в кластере

В Комплексе для клиентских кластеров по умолчанию реализован централизованный алертинг с размещением метрик и правил оповещения в кластере управления. При использовании централизованного алертинга доступна настройка правил оповещения из интерфейса кластера (см. соответствующий раздел Руководства).

В случае недоступности кластера управления, выключенного централизованного алертинга или отсутствия необходимости работы централизованного алертинга можно настроить локальный алертинг в клиентском кластере. Графический интерфейс настройки правил оповещения, маршрутов и блокировок будет недоступен.

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

Для настройки локального алертинга в клиентском кластере нужно выполнить следующие шаги:

  1. в кластере в боковом меню открыть раздел "Сервисы и репозитории", перейти на страницу "Установленные сервисы", найти компонент управления модуля мониторинга (shturval-metrics-collector) (рисунок 124);

Рисунок 124 ‒ Компонент управления модуля мониторинга

  1. открыть карточку модуля и в блоке "Спецификация сервиса" включить локальную базу данных хранения метрик vmsingle и необходимые компоненты, как показано в customvalues (описание параметров ‒ в таблице 18):
alertmanager:
enabled: true
defaultRules:
create: true
vmagent:
additionalRemoteWrites:
‒ url: <ваше значение параметра>
vmalert:
enabled: true
vmsingle:
enabled: true

Параметр "additionalRemoteWrites.url" необходимо указывать, чтобы метрики направлялись не только в локальную базу кластера, но и централизовано в кластер управления.

  1. сохранить внесенные изменения для модуля.

В результате:

  • метрики будут направлены в локальную базу VM Single и, если централизованное хранение доступно, то дополнительно в кластер управления;
  • в клиентском кластере будут добавлены кастомные ресурсы API-группы "operator.victoriametrics.com": VMAlertmanager, VMAlert, VMSingle и системные правила VMRule;
  • появится возможность настроить конфигурацию локального алертинга.

Следует обратить внимание:

  • В графическом интерфейсе из раздела "Оповещения" можно настроить только централизованный алертинг.
  • Конфигурация локального алертинга должна быть настроена в SSC (спецификации) shturval-metrics-collector.
  • При необходимости создания нового правила для локального алертинга необходимо добавить правило в клиентский кластер с помощью импорта манифеста объекта VMRule.
  1. чтобы настроить маршруты, получателей, блокировку оповещений, в блоке "Спецификация сервиса" компонента управления модуля мониторинга (shturval-metrics-collector) задать требуемую конфигурацию в alertmanager.

Пример конфигурации в customvalues, где получатель ‒ webhook (описание параметров ‒ в таблице 19):

alertmanager:
enabled: true
config:
receivers:
‒ name: blackhole # Получатель по умолчанию. Должен быть обязательно указан
‒ name:  <ваше значение параметра>
webhook_configs:
‒ max_alerts:  <ваше значение параметра>
send_resolved: false
url: <ваше значение параметра>
route:
routes:
‒ matchers:
‒ <ваше значение параметра>
receiver: <ваше значение параметра>
  1. сохранить внесенные изменения.

Решение проблем

Чтобы проверить настройку работы локального алертинга необходимо проверить состояние локального хранилища экземпляра VM Single и состояния VMAlertManager. Для этого нужно (рисунки 125, 126, 127):

  1. в неймспейсе "victoria-metrics" проверить статус "Statefulset vmalertmanager-shturval-metrics-collector". Если статус неактивный, посмотреть логи подов этого Statefulset.
  2. в неймспейсе "victoria-metrics" проверить статус "Deployment vmalert-shturval-metrics-collector". Если статус неактивный, посмотреть логи подов этого Deployment.
  3. в неймспейсе "victoria-metrics" проверить статус "Deployment vmsingle-shturval-metrics-collector". Если статус неактивный, посмотреть логи подов этого Deployment.
  4. в разделе "Администрирование" бокового меню кластера перейти на страницу "Кастомные ресурсы". В API-группе "operator.victoriametrics.com" найти ресурс VMAlertmanager и проверить, что он имеет updateStatus: operational.
  5. в разделе "Администрирование" бокового меню кластера перейти на страницу "Кастомные ресурсы". В API-группе "operator.victoriametrics.com" найти ресурс VMAlert и проверить, что он имеет статус updateStatus: operational.

Рисунок 125 ‒ Неймспейс "victoria-metrics"

Рисунок 126 ‒ Проверка статуса

Рисунок 127 ‒ Просмотр статуса

Алертинг заполненности пространства Opensearch

В кластере управления можно настроить оповещение (алертинг) о заполненности дискового пространства под хранение логов в OpenSearch. Это может быть полезно для своевременного информирования, когда требуется освободить место или увеличить объем пространства OpenSearch.

В Комплексе по умолчанию реализован централизованный алертинг с размещением метрик и правил оповещения в кластере управления всех клиентских кластеров и кластера управления. Можно настроить как централизованный, так и локальный алертинг заполненности пространства OpenSearch.

Централизованный алертинг

Для настройки централизованного алертинга нужно выполнить следующие шаги:

  1. в графическом интерфейсе кластера управления в разделе "Администрирование" перейти на страницу "Кастомные ресурсы", найти группу "operator.victoriametrics.com", перейти к списку кастомных ресурсов VMRule, открыть манифест кастомного ресурса "vmrule-user-0" и добавить правило проверки в блок "groups".

Правило проверки заполненности пространства OpenSearch:

spec:
groups:
‒ name: opensearch-disk-space
rules:
‒ alert: OpenSearchLowDiskSpace
annotations:
description: |-
На кластере OpenSearch осталось менее 10% свободного места.
Узел: {{ $labels.node }}
Использовано: {{ $value }}%
summary: На кластере OpenSearch осталось мало дискового пространства
expr: >
100 * (1 ‒ (opensearch_fs_total_free_bytes / opensearch_fs_total_total_bytes)) > 90
for: 5m
labels:
cluster: opensearch
severity: warning

Согласно установленному правилу в expr алертинг сработает, когда дисковое пространство будет заполнено более чем на 90% (рисунок 128).

Рисунок 128 ‒ Манифест кастомного ресурса "vmrule-user-0"

  1. нажать Проверить и сохранить внесенные изменения;
  2. настроить конфигурацию алертинга, например, маршрут и получателя.

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

Для настройки локального алертинга нужно выполнить следующие шаги:

  1. в графическом интерфейсе кластера управления в боковом меню открыть раздел "Сервисы и репозитории",** перейти на страницу "Установленные сервисы", найти компонент управления модуля мониторинга (shturval-metrics-collector), открыть карточку модуля, в блоке "Спецификация сервиса" включить локальную базу данных хранения метрик "vmsingle" и необходимые компоненты, как показано в customvalues:
defaultRules:
create: true
vmalert:
enabled: true
vmsingle:
enabled: true
  1. загрузить кастомный ресурс VMRule в кластер управления с помощью импорта манифеста. VMRule с правилом проверки заполненности дискового пространств OpenSearch:
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMRule
metadata:
name: opensearchcluster-disk
namespace: shturval-logging
spec:
groups:
‒ name: opensearch-disk-space
rules:
‒ alert: OpenSearchLowDiskSpace
annotations:
description: |-
На кластере OpenSearch осталось менее 10% свободного места.
Узел: {{ $labels.node }}
Использовано: {{ $value }}%
summary: На кластере OpenSearch осталось мало дискового пространства
expr: >
100 * (1 ‒ (opensearch_fs_total_free_bytes / opensearch_fs_total_total_bytes)) > 90
for: 5m
labels:
cluster: opensearch
severity: warning

Согласно установленному правилу в expr алертинг сработает, когда дисковое пространство будет заполнено более чем на 90%.

  1. загрузить VMRule;
  2. настроить конфигурацию алертинга, например, маршрут и получателя.

Настройка маршрута и получателя для алертинга

Настройка правил оповещения, маршрутов и получателей в графическом интерфейсе кластера управления недоступна. Конфигурирование алертинга необходимо выполнять в customvalues модуля мониторинга (shturval-metrics-collector) кластера управления.

После добавления правила заполненности пространства OpenSearch в кластер управления в боковом меню открыть раздел "Сервисы и репозитории", перейти на страницу "Установленные сервисы", найти компонент управления модуля мониторинга (shturval-metrics-collector), открыть карточку модуля и в блоке "Спецификация сервиса" указать необходимую конфигурацию.

Пример конфигурации в customvalues, где получатель ‒ webhook (описание параметров ‒ в таблице 20):

alertmanager:
enabled: true
config:
receivers:
‒ name: blackhole # Получатель по умолчанию. Должен быть обязательно указан
‒ name: <ваше значение параметра>
webhook_configs:
‒ max_alerts: <ваше значение параметра>
send_resolved: false
url: <ваше значение параметра>
route:
routes:
‒ matchers:
‒ <ваше значение параметра>
receiver: <ваше значение параметра>
  1. сохранить внесенные изменения.

Проверка локального алертинга

Проверить работу локального алертинга в клиентском кластере или кластере управления можно, например, с помощью webhook, который записывает входящие сообщения в логи контейнера:

  1. загрузить в кластер манифесты объектов "Deployment", "Service", "VMRule" с помощью импорта манифестов:
  • Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-webhook
namespace: monitoring
labels:
app: demo-webhook
spec:
replicas: 1
selector:
matchLabels:
app: demo-webhook
template:
metadata:
creationTimestamp: null
labels:
app: demo-webhook
spec:
terminationGracePeriodSeconds: 30
automountServiceAccountToken: false
containers:
‒ name: demo-webhook
image: quay.io/mgoerens/demo-webhook-receiver-alertmanager:0.0.1
imagePullPolicy: IfNotPresent
env:
‒ name: PORT
value: "8080"
livenessProbe:
httpGet:
path: /healthz
port: 8080
readinessProbe:
httpGet:
path: /healthz
port: 8080
resources:
limits:
cpu: 10m
memory: 30Mi
requests:
cpu: 10m
memory: 30Mi
securityContext:
capabilities:
drop:
‒ ALL
allowPrivilegeEscalation: false
  • Service:
apiVersion: v1
kind: Service
metadata:
name: demo-webhook
namespace: monitoring
labels:
app: demo-webhook
spec:
ports:
‒ port: 80
targetPort: 8080
protocol: TCP
name: http
selector:
app: demo-webhook
  • VMRule:
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMRule
metadata:
labels:
app: demo-webhook
role: user
name: example-alert
namespace: victoria-metrics
spec:
groups:
‒ concurrency: 1
interval: 1m
labels:
ruletype: alert
name: example
rules:
‒ alert: ExampleAlert
expr: vector(1)
type: prometheus
  1. в кластере в боковом меню открыть раздел "Сервисы и репозитории", перейти на страницу "Установленные сервисы", найти компонент управления модуля мониторинга (shturval-metrics-collector), в блоке "Спецификации сервиса" настроить demo-webhook как получателя и указать его в маршрутах для отправки алертов;

Пример customvalues:

alertmanager:
enabled: true
config:
receivers:
‒ name: blackhole
‒ name: demo-webhook
webhook_configs:
‒ max_alerts: 5
send_resolved: false
url: http://demo-webhook.monitoring.svc/webhook
route:
routes:
‒ matchers:
‒ app = "demo-webhook"
receiver: demo-webhook
  1. сохранить внесенные изменения;
  2. в неймспейсе "monitoring" кластера перейти к просмотру пода с именем demo-webhook, открыть окно просмотра логов контейнера. В логах будут присутствовать сообщения сработавших алертов в кластере (рисунки 129‒130).

Рисунок 129 ‒ Переход к сообщениям сработавших алертов в кластере

Рисунок 130 ‒ Сообщения сработавших алертов в кластере