Пример: матрица эскалации по ёмкости Ceph-кластера

Обновлено 02.07.2026

Сквозной пример настройки многоуровневой эскалации оповещений в Proto Observability Platform на сценарии мониторинга ёмкости Ceph-кластера: уровни L1/L2/L3, маршрутизация по лейблам в разные каналы (email/Telegram/Webhook) и предиктивное правило исчерпания ёмкости.

Tags:

На этой странице — практический пример матрицы эскалации: как направить оповещения о состоянии Ceph-кластера на разные уровни и каналы коммуникации в зависимости от критичности и предиктивного прогноза. Пример опирается на штатную связку платформы Правило → Политика → Канал (см. Настройка оповещений) и использует метрики интеграции ceph (см. Мониторинг Ceph).

Задача

Ёмкость Ceph-кластера постепенно расходуется по мере роста данных. Нужно:

наблюдать общую заполненность, состояние OSD, объекты в пулах, IOPS/пропускную способность и задержки;
уведомлять при достижении пороговых значений;
при устойчивом росте заполнения предиктивно эскалировать уведомление на верхний уровень — пока место ещё не закончилось.

Метрики

Все показатели поставляет интеграция ceph (точки в именах метрик становятся подчёркиваниями в хранилище — например, ceph.aggregate_pct_used → ceph_aggregate_pct_used):

Показатель	Метрика	Разрез (тег)
Общая заполненность кластера, %	`ceph_aggregate_pct_used`	— (весь кластер)
Заполненность OSD, %	`ceph_osd_pct_used`	`ceph_osd` (нет на Ceph luminous и новее)
Full / near-full OSD	`ceph_num_full_osds`, `ceph_num_near_full_osds`	—
OSD всего / online / участвующих	`ceph_num_osds`, `ceph_num_up_osds`, `ceph_num_in_osds`	—
Объекты в пуле	`ceph_num_objects`	`ceph_pool`
IOPS (чтение/запись/всего)	`ceph_read_op_per_sec`, `ceph_write_op_per_sec`, `ceph_op_per_sec`	`ceph_pool`
Пропускная способность (чтение/запись)	`ceph_read_bytes_sec`, `ceph_write_bytes_sec`	`ceph_pool`
Задержки apply / commit	`ceph_apply_latency_ms`, `ceph_commit_latency_ms`	`ceph_osd`

Метрики размечены тегами ceph_pool:<имя>, ceph_osd:osd<id>, а также ceph_mon_state и ceph_fsid на уровне кластера.

Уровни эскалации и каналы

Матрица связывает критичность/прогноз с уровнем и каналом доставки:

Уровень	Когда	Канал (тип)	Получатель	Лейблы маршрутизации
L1 — Предупреждение	заполнение 80–90%; появился near-full OSD; рост задержек commit	Электронная почта	Команда хранилища	`severity=WARNING`
L2 — Критично	заполнение > 90%; появился full OSD; задержка commit > 1000 мс	Telegram	Дежурный инженер	`severity=CRITICAL`
L3 — Эскалация (предиктив)	прогноз заполнения 100% в течение часа	Webhook (ITSM) + Telegram	Руководитель / ITSM + дежурный	`escalation_level=L3`

Уровень несут лейблы правила: критичность (severity) задаётся полем «Критичность», а escalation_level — обычным лейблом в блоке «Лейблы».

Шаг 1. Каналы

Создайте три канала (Алерты → Каналы → Добавить), по одному на уровень:

ceph-team — Электронная почта: адрес команды хранилища;
ceph-oncall — Telegram: чат/бот дежурного;
ceph-itsm — Webhook: эндпоинт ITSM / инцидент-менеджмента.

Поля форм для каждого типа описаны в разделе Каналы оповещений.

Шаг 2. Правила

Создайте правила (Алерты → Правила → Добавить), выставив Критичность и лейбл escalation_level. Ключевые выражения (PromQL/MetricsQL):

Заполнение > 80% (WARNING, escalation_level=L1):

max(ceph_aggregate_pct_used) > 80
  and max(ceph_aggregate_pct_used) <= 90

Заполнение > 90% (CRITICAL, escalation_level=L2):

max(ceph_aggregate_pct_used) > 90

Прогноз заполнения 100% в течение часа (CRITICAL, escalation_level=L3):

max(ceph_aggregate_pct_used) > 85
  and predict_linear(max(ceph_aggregate_pct_used)[30m:1m], 3600) >= 100

Функция predict_linear экстраполирует тренд за короткое окно [30m:1m] на час вперёд: правило срабатывает предиктивно, ещё на росте, до фактического исчерпания ёмкости. Для долгосрочного планирования полезно второе предиктивное правило с окном [7d:1h] и горизонтом в сутки/недели.

Состояние OSD и задержки — по аналогии:

# появился near-full OSD (WARNING, L1)
max(ceph_num_near_full_osds) > 0

# появился full OSD (CRITICAL, L2)
max(ceph_num_full_osds) > 0

# задержка commit по любому OSD > 1000 мс (CRITICAL, L2)
max(ceph_commit_latency_ms) > 1000

Шаг 3. Политики

Свяжите лейблы с каналами (Алерты → Политики → Добавить). Политики проверяются по возрастанию поля «Порядок»; на первой совпавшей обработка останавливается, если не включено «Продолжение».

Порядок	Матчер	Канал(ы)	Продолжение
10	`escalation_level = L3`	`ceph-itsm`	Вкл.
11	`escalation_level = L3`	`ceph-oncall`	Выкл.
20	`severity = CRITICAL`	`ceph-oncall`	Выкл.
30	`severity = WARNING`	`ceph-team`	Выкл.
100	`alertname =~ .*`	`ceph-team`	Выкл.

Две политики уровня L3 (порядок 10 и 11) с «Продолжением» на первой направляют предиктивный алерт сразу в два канала — ITSM и дежурному. Более высокий приоритет L3 (порядок 10) перехватывает его раньше общей критичной политики (порядок 20).

После изменений нажмите «Применить».

Что произойдёт при исчерпании ёмкости

По мере расходования ёмкости кластера срабатывают и маршрутизируются:

заполнение проходит 80% → правило L1 → политика severity=WARNING → email команде хранилища;
заполнение проходит 90% (или появляется full OSD) → правило L2 → политика severity=CRITICAL → Telegram дежурному;
тренд указывает на 100% в течение часа → предиктивное правило L3 → политика escalation_level=L3 → Webhook (ITSM) и Telegram — эскалация на верхний уровень ещё до физического исчерпания ёмкости.

Жизненный цикл алерта (pending → firing → resolved) и формат уведомлений для каждого канала описаны в разделе Диагностика и формат уведомлений.

Что дальше

Настройка оповещений — подробное описание полей каналов, политик и правил.
Метрики и выражения для правил — синтаксис выражений и аннотации со ссылками на дашборды.
Мониторинг Ceph — сбор метрик и логов кластера, полный список метрик интеграции ceph.