Мониторинг кластеров серверов: развертывание Prometheus+Grafana и работа со специализированными инструментами

Мониторинг кластерной инфраструктуры требует особого подхода. Недостаточно просто отслеживать состояние отдельных узлов - нужно видеть целостность кластера, состояние его специфичных служб и ресурсов. Эта статья предоставляет готовое, проверенное решение для построения такой системы. Вы развернете универсальный стек Prometheus и Grafana для контроля базовых метрик и научитесь интегрировать в него данные из специализированных инструментов, таких как Pacemaker для кластеров высокой доступности и Ceph для распределенных хранилищ. Результат - единая операционная панель, которая позволяет оперативно обнаруживать аномалии, прогнозировать проблемы и поддерживать стабильную работу всей среды.

Архитектура мониторинга кластера: от общих метрик к специализированным

Эффективный мониторинг кластера строится на двух слоях: инфраструктурном и сервисном. Инфраструктурный слой охватывает базовые параметры каждого узла - загрузку CPU, использование памяти, состояние дисков и сетевых интерфейсов. Сервисный слой контролирует специфичные для кластера состояния: кворум, статус ресурсов высокой доступности, репликацию данных в распределенном хранилище.

Prometheus и Grafana служат универсальным каркасом для обоих слоев. Prometheus собирает и хранит временные ряды метрик. Его агент, Node Exporter, предоставляет данные об инфраструктурном состоянии каждого узла. Grafana превращает эти данные в наглядные дашборды, создавая единую операционную консоль. Их преимущества - гибкость, богатая экосистема экспортеров и активное сообщество, предлагающее готовые шаблоны визуализации.

Для глубокого контроля кластерных систем иногда необходимы специализированные инструменты. Например, состояние ресурсов в Pacemaker или детали здоровья пулов в Ceph часто доступны только через их нативные CLI или API. Эти данные критически важны для понимания целостности кластера, и их необходимо интегрировать в общую панель мониторинга.

Роль стека Prometheus и Grafana в экосистеме мониторинга кластера

Prometheus - это система сбора и хранения временных рядов метрик. Она работает по модели pull, периодически запрашивая данные с экспортеров, установленных на целевых узлах. Для базового мониторинга инфраструктуры используется Node Exporter, который предоставляет сотни метрик о системе.

Grafana - платформа для визуализации. Она подключается к Prometheus как источнику данных и позволяет строить сложные, информативные дашборды. В контексте кластера это дает возможность сравнивать метрики разных узлов на одном графике, быстро оценивать балансировку нагрузки и выявлять аномалии.

Этот стек решает задачу универсального мониторинга инфраструктуры. Однако для полного контроля кластера его необходимо дополнять.

Когда и зачем нужны специализированные инструменты: Pacemaker и Ceph

Pacemaker, управляющий кластером высокой доступности, имеет внутренние состояния, которые не видны через стандартные системные метрики. Ключевые параметры включают состояние каждого ресурса (запущен/остановлен), правила размещения (location constraints), наличие кворума и историю fencing - процедуры изоляции неисправного узла. Мониторинг этих параметров позволяет предупредить сбой сервиса до его фактической остановки.

Ceph, как распределенное хранилище, предоставляет метрики, непосредственно отражающие здоровье данных. Это статус OSD (Object Storage Daemon - in/up), состояние Placement Groups (PG - active+clean, degraded, recovering), использование пространства в пулах и задержки операций ввода-вывода. Значение ceph_pg_degraded > 0 сигнализирует о деградации данных и требует немедленного вмешательства.

Интеграция этих специфичных данных в общую систему мониторинга через Prometheus дает оператору полную картину.

Пошаговая настройка стека Prometheus и Grafana на узлах кластера

Эта инструкция позволяет быстро внедрить основу системы мониторинга. Предполагается, что Prometheus Server установлен на выделенном узле управления, а Node Exporter - на каждом узле кластера.

Установка Prometheus Server и настройка таргетов для сбора метрик

Установка на системах с RHEL/CentOS или аналогичных:

# Добавление репозитория и установка Prometheus
sudo yum install -y prometheus

# Установка Node Exporter на каждый узловой сервер
sudo yum install -y prometheus-node-exporter
sudo systemctl enable --now prometheus-node-exporter

Основная конфигурация Prometheus находится в файле /etc/prometheus/prometheus.yml. Пример для кластера с двумя узлами:

global:
  scrape_interval: 15s
  evaluation_interval: -15s

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node1.cluster.local:9100', 'node2.cluster.local:9100']
    # Для динамического добавления узлов можно использовать DNS discovery:
    # dns_sd_configs:
    #   - names: ['node-exporter.cluster.local']
    #     type: 'A'
    #     port: 9100

Параметр scrape_interval определяет частоту сбора метрик. После изменения конфигурации проверьте ее синтаксис и перезапустите сервис:

promtool check config /etc/prometheus/prometheus.yml
sudo systemctl restart prometheus

Убедитесь, что firewall разрешает трафик на портах Prometheus (9090) и Node Exporter (9100). Для SELinux могут потребоваться дополнительные разрешения.

Развертывание Grafana и подключение источника данных

Установка Grafana на том же или отдельном сервере:

sudo yum install -y grafana
sudo systemctl enable --now grafana-server

После запуска сервиса Grafana доступна по адресу http://your-server:3000. Первый вход выполняется с учетными данными admin/admin. Сразу измените пароль администратора в разделе профиля.

Для подключения Prometheus как источника данных:

В левом меню выберите «Configuration» (знак шестеренки) -> «Data Sources».
Нажмите «Add data source» и выберите «Prometheus».
В поле «URL» введите адрес вашего Prometheus Server, например, http://prometheus-server.cluster.local:9090.
Оставьте другие параметры по умолчанию или настроите согласно вашей политике аутентификации.
Нажмите «Save & Test». Успешное подключение подтвердит сообщение «Data source is working».

Теперь вы можете создавать дашборды или импортировать готовые из библиотеки.

Готовые дашборды Grafana для контроля ключевых метрик кластера

Использование готовых дашбордов экономит время и дает сразу работающую визуализацию. Официальная библиотека Grafana содержит множество шаблонов.

Дашборд для контроля доступности сервисов и нагрузки на узлы

Для базового мониторинга узлов импортируйте дашборд «Node Exporter Full» по ID 15143. Он предоставляет полный набор панелей:

Uptime узлов: Показывает время работы системы. Его резкое изменение может указывать на перезагрузку.
Загрузка CPU: Графики разделяют нагрузку на user, system и iowait. В кластерной среде важно отслеживать не только общую загрузку, но и высокий iowait, который может сигнализировать о проблемах с дисками.
Использование памяти: Отображает available, cached и buffered память. Критически низкое значение available на нескольких узлах одновременно может привести к свопингу и снижению производительности кластера.

Тревожными порогами для кластера можно считать: загрузка CPU выше 80% продолжительное время, available память менее 10% от общей, наличие процессов в состоянии D (uninterruptible sleep).

Мониторинг дискового пространства и сетевых интерфейсов

Дашборд «Node Exporter Full» также включает ключевые панели для дисков и сети:

Дисковое пространство: Графики показывают использование и свободное место на каждой файловой системе. Особое внимание уделите дискам, используемым для данных кластера (например, для Ceph OSD) или журналов транзакций.
Сетевые интерфейсы: Мониторинг трафика (bytes sent/received), ошибок (packets dropped) и состояния канала (up/down). Для кластеров критически важна сеть, используемая для репликации (например, кластерная сеть Corosync в Pacemaker или сеть для репликации данных Ceph). Рост ошибок или падение интерфейса в этой сети приводит к потере связи между узлами.

Для импорта дашборда в Grafana: в меню «Create» -> «Import», введите ID 15143 и выберите подключенный источник данных Prometheus.

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

Специализированный мониторинг для Pacemaker (кластеры высокой доступности)

Для интеграции данных Pacemaker в Prometheus есть два основных метода: использование специализированного экспортера или текстового файлового коллектора (textfile collector).

Сбор метрик состояния ресурсов и узлов кластера

Метод с textfile collector часто более гибкий. Создайте скрипт, который периодически собирает статус кластера и записывает метрики в файл в формате Prometheus. Пример скрипта на bash:

#!/bin/bash
OUTPUT_FILE=/var/lib/prometheus/node-exporter/pacemaker.prom

# Получение статуса узлов и ресурсов
PCS_STATUS=$(pcs status --full)

# Парсинг и формирование метрик
# Пример: метрика состояния кворума (1 - есть, 0 - нет)
if echo "$PCS_STATUS" | grep -q "Quorate: Yes"; then
  echo "pacemaker_quorum 1" > "$OUTPUT_FILE"
else
  echo "pacemaker_quorum 0" > "$OUTPUT_FILE"
fi

# Добавление метрик состояния ресурсов (пример для ресурса 'virtual_ip')
if echo "$PCS_STATUS" | grep -q "virtual_ip.*Started"; then
  echo "pacemaker_resource_virtual_ip_active 1" >> "$OUTPUT_FILE"
else
  echo "pacemaker_resource_virtual_ip_active 0" >> "$OUTPUT_FILE"
fi

# Можно добавить метрику количества узлов в кластере
NODE_COUNT=$(echo "$PCS_STATUS" | grep -c "Online:")
echo "pacemaker_nodes_online $NODE_COUNT" >> "$OUTPUT_FILE"

Запускайте этот скрипт по cron каждую минуту. Затем настроите Node Exporter на чтение этого файла, добавив в его конфигурацию параметр --collector.textfile.directory=/var/lib/prometheus/node-exporter/. Prometheus автоматически будет собирать эти метрики вместе с другими данными Node Exporter.

Визуализация кворума и истории fencing в Grafana

Метрика pacemaker_quorum (1 или 0) должна быть выделена на дашборде. Используйте панель «Stat» или «Gauge» с красным/зеленым цветом для мгновенной оценки состояния. Потеря кворума (значение 0) - аварийная ситуация, требующая немедленного алерта.

Историю событий fencing сложно отобразить как временной ряд, но можно использовать аннотации в Grafana или создать отдельную таблицу, парсящую журналы. Эти данные критически важны для пост-мортем анализа сбоев, чтобы понять последовательность событий изоляции узлов.

Для более глубокого мониторинга Pacemaker можно использовать готовые решения, такие как pacemaker-exporter. Настройка подобных экспортеров описана в нашей статье о построении отказоустойчивого кластера на Linux с Corosync.

Специализированный мониторинг для Ceph (распределенное хранилище)

Ceph имеет встроенный модуль мониторинга для Prometheus, который предоставляет все необходимые метрики через менеджер (MGR) кластера.

Настройка экспорта метрик Ceph в Prometheus

Активация модуля выполняется одной командой на любом узле с доступом к кластеру Ceph:

ceph mgr module enable prometheus

После этого каждый активный MGR будет отдавать метрики на порту 9283 (по умолчанию). Проверить доступность можно, запросив URL одного из менеджеров: http://ceph-mgr-host:9283/metrics.

Для сбора этих метрик добавьте в prometheus.yml новый job:

scrape_configs:
  - job_name: 'ceph'
    static_configs:
      - targets: ['ceph-mgr-01.cluster.local:9283', 'ceph-mgr-02.cluster.local:9283']
    # Сбор с нескольких MGR обеспечивает отказоустойчивость мониторинга.

После перезагрузки Prometheus метрики Ceph станут доступны для визуализации в Grafana.

Критические метрики здоровья кластера: OSD, PG и состояние пулов

Среди сотен метрик Ceph выделяются несколько ключевых групп:

OSD (Object Storage Daemon): Метрики ceph_osd_up и ceph_osd_in показывают, соответственно, работает ли OSD и включен он в кластер. Значение 0 для любой из этих метрик требует проверки.
PG (Placement Groups): Метрики ceph_pg_active, ceph_pg_degraded, ceph_pg_recovering отражают состояние групп размещения. ceph_pg_degraded > 0 указывает на деградацию данных (не все объекты имеют достаточное количество копий). Это состояние требует немедленного вмешательства.
Пуллы: Метрика ceph_pool_bytes_used показывает использование пространства в каждом пуле. Мониторинг приближения к лимиту помогает планировать расширение.
Задержки: Метрики типа ceph_osd_apply_latency_ms помогают оценить производительность.

Для визуализации рекомендуется импортировать официальный дашборд Grafana для Ceph, например, из библиотеки по соответствующему ID.

Интеграция, алертинг и поддержание системы мониторинга

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

Настройка алертов на критические события в кластере

Prometheus Alertmanager обрабатывает правила алертинга, заданные в PromQL. Примеры критических правил для кластера:

# Потеря кворума в Pacemaker
- alert: ClusterQuorumLost
  expr: pacemaker_quorum == 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Кворум кластера Pacemaker потерян"

# Деградация данных в Ceph
- alert: CephPGDegraded
  expr: ceph_pg_degraded > 0
  for: 30s
  labels:
    severity: critical
  annotations:
    summary: "Наблюдаются деградированные Placement Groups в Ceph"

# Недоступность узла кластера
- alert: NodeDown
  expr: up{job="node-exporter"} == 0
  for: 3m
  labels:
    severity: warning
  annotations:
    summary: "Узел кластера недоступен для мониторинга"

# Нехватка дискового пространства на критическом диске
- alert: DiskSpaceCritical
  expr: (node_filesystem_free_bytes / node_filesystem_size_bytes) < 0.1
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Критически мало свободного места на диске"

Настройте Alertmanager для отправки этих алертов в нужные каналы: Email, Slack, Telegram. Детальная инструкция по настройке алертов и интеграции с популярными мессенджерами доступна в статье о стеке мониторинга серверов.