Как настроить алертинг в кластере
В Комплексе для клиентских кластеров по умолчанию реализован централизованный алертинг с размещением метрик и правил оповещения в кластере управления. При использовании централизованного алертинга доступна настройка правил оповещения из интерфейса кластера (см. соответствующий раздел Руководства).
В случае недоступности кластера управления, выключенного централизованного алертинга или отсутствия необходимости работы централизованного алертинга можно настроить локальный алертинг в клиентском кластере. Графический интерфейс настройки правил оповещения, маршрутов и блокировок будет недоступен.
Локальный алертинг в клиентском кластере
Для настройки локального алертинга в клиентском кластере нужно выполнить следующие шаги:
- в кластере в боковом меню открыть раздел "Сервисы и репозитории", перейти на страницу "Установленные сервисы", найти компонент управления модуля мониторинга (shturval-metrics-collector) (рисунок 124);

Рисунок 124 ‒ Компонент управления модуля мониторинга
- открыть карточку модуля и в блоке "Спецификация сервиса" включить локальную базу данных хранения метрик
vmsingleи необходимые компоненты, как показано в customvalues (описание параметров ‒ в таблице 18):
alertmanager:
enabled: true
defaultRules:
create: true
vmagent:
additionalRemoteWrites:
‒ url: <ваше значение параметра>
vmalert:
enabled: true
vmsingle:
enabled: true
Параметр "additionalRemoteWrites.url" необходимо указывать, чтобы метрики направлялись не только в локальную базу кластера, но и централизовано в кластер управления.
- сохранить внесенные изменения для модуля.
В результате:
- метрики будут направлены в локальную базу VM Single и, если централизованное хранение доступно, то дополнительно в кластер управления;
- в клиентском кластере будут добавлены кастомные ресурсы API-группы "operator.victoriametrics.com": VMAlertmanager, VMAlert, VMSingle и системные правила VMRule;
- появится возможность настроить конфигурацию локального алертинга.
Следует обратить внимание:
- В графическом интерфейсе из раздела "Оповещения" можно настроить только централизованный алертинг.
- Конфигурация локального алертинга должна быть настроена в SSC (спецификации) shturval-metrics-collector.
- При необходимости создания нового правила для локального алертинга необходимо добавить правило в клиентский кластер с помощью импорта манифеста объекта VMRule.
- чтобы настроить маршруты, получателей, блокировку оповещений, в блоке "Спецификация сервиса" компонента управления модуля мониторинга (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: <ваше значение параметра>
- сохранить внесенные изменения.
Решение проблем
Чтобы проверить настройку работы локального алертинга необходимо проверить состояние локального хранилища экземпляра VM Single и состояния VMAlertManager. Для этого нужно (рисунки 125, 126, 127):
- в неймспейсе "victoria-metrics" проверить статус "Statefulset vmalertmanager-shturval-metrics-collector". Если статус неактивный, посмотреть логи подов этого Statefulset.
- в неймспейсе "victoria-metrics" проверить статус "Deployment vmalert-shturval-metrics-collector". Если статус неактивный, посмотреть логи подов этого Deployment.
- в неймспейсе "victoria-metrics" проверить статус "Deployment vmsingle-shturval-metrics-collector". Если статус неактивный, посмотреть логи подов этого Deployment.
- в разделе "Администрирование" бокового меню кластера перейти на страницу "Кастомные ресурсы". В API-группе "operator.victoriametrics.com" найти ресурс VMAlertmanager и проверить, что он имеет
updateStatus: operational. - в разделе "Администрирование" бокового меню кластера перейти на страницу "Кастомные ресурсы". В API-группе "operator.victoriametrics.com" найти ресурс VMAlert и проверить, что он имеет статус
updateStatus: operational.

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

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

Рисунок 127 ‒ Просмотр статуса
Алертинг заполненности пространства Opensearch
В кластере управления можно настроить оповещение (алертинг) о заполненности дискового пространства под хранение логов в OpenSearch. Это может быть полезно для своевременного информирования, когда требуется освободить место или увеличить объем пространства OpenSearch.
В Комплексе по умолчанию реализован централизованный алертинг с размещением метрик и правил оповещения в кластере управления всех клиентских кластеров и кластера управления. Можно настроить как централизованный, так и локальный алертинг заполненности пространства OpenSearch.
Централизованный алертинг
Для настройки централизованного алертинга нужно выполнить следующие шаги:
- в графическом интерфейсе кластера управления в разделе "Администрирование" перейти на страницу "Кастомные ресурсы", найти группу "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"
- нажать
Проверитьи сохранить внесенные изменения; - настроить конфигурацию алертинга, например, маршрут и получателя.
Локальный алертинг
Для настройки локального алертинга нужно выполнить следующие шаги:
- в графическом интерфейсе кластера управления в боковом меню открыть раздел "Сервисы и репозитории",** перейти на страницу "Установленные сервисы", найти компонент управления модуля мониторинга (shturval-metrics-collector), открыть карточку модуля, в блоке "Спецификация сервиса" включить локальную базу данных хранения метрик "vmsingle" и необходимые компоненты, как показано в customvalues:
defaultRules:
create: true
vmalert:
enabled: true
vmsingle:
enabled: true
- загрузить кастомный ресурс 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%.
- загрузить VMRule;
- настроить конфигурацию алертинга, например, маршрут и получателя.
Настройка маршрута и получателя для алертинга
Настройка правил оповещения, маршрутов и получателей в графическом интерфейсе кластера управления недоступна. Конфигурирование алертинга необходимо выполнять в 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: <ваше значение параметра>
- сохранить внесенные изменения.
Проверка локального алертинга
Проверить работу локального алертинга в клиентском кластере или кластере управления можно, например, с помощью webhook, который записывает входящие сообщения в логи контейнера:
- загрузить в кластер манифесты объектов "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
- в кластере в боковом меню открыть раздел "Сервисы и репозитории", перейти на страницу "Установленные сервисы", найти компонент управления модуля мониторинга (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
- сохранить внесенные изменения;
- в неймспейсе "monitoring" кластера перейти к просмотру пода с именем
demo-webhook, открыть окно просмотра логов контейнера. В логах будут присутствовать сообщения сработавших алертов в кластере (рисунки 129‒130).

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

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