Ceph - штука мощная. Пока работает - все счастливы. Как только начинает деградировать OSD, заполняться пул или сеть внезапно превращается в тыкву - начинается классический инфраструктурный квест:

«А что вообще происходит?»

Именно поэтому мониторинг Ceph - не роскошь, а средство сохранения нервной системы DevOps-инженера.

В этой статье разберем:

  • как быстро подключить мониторинг Ceph,
  • как собирать метрики через Prometheus,
  • как собирать метрики через VictoriaMetrics,
  • как визуализировать всё в Grafana,
  • какие метрики реально важны,
  • и почему Ceph без мониторинга - это как RAID без SMART: вроде работает… пока не стало поздно.

Что будем использовать

Наша схема будет выглядеть так:

Ceph Cluster
     ↓
Ceph Exporter / ceph mgr prometheus
     ↓
Prometheus или VictoriaMetrics
     ↓
Grafana

Используем:

  • Docker
  • Ceph Exporter или встроенный ceph mgr prometheus module
  • Prometheus или VictoriaMetrics
  • Grafana

И да - exporter мы будем запускать в Docker.
Потому что:

  • быстро,
  • удобно,
  • воспроизводимо,
  • и без «соберите мне тут вручную из исходников Boost 1.58 под луной в ретроградном Меркурии».

Что такое Ceph Exporter

Ceph сам по себе умеет отдавать огромное количество метрик:

  • состояние кластера,
  • состояние OSD,
  • usage,
  • latency,
  • PG,
  • recovery,
  • scrub,
  • network,
  • health,
  • replication,
  • и еще вагон всего.

Но системе мониторинга нужен endpoint с метриками в формате Prometheus.

Именно для этого используется exporter - прослойка, которая:

  1. забирает данные из Ceph,
  2. преобразует их в Prometheus format,
  3. отдает по HTTP.

Современный вариант - ceph mgr prometheus module

Если у вас Ceph Nautilus и новее - лучше вообще отказаться от отдельного exporter.

В Ceph уже встроен Prometheus endpoint.

Включаем:

ceph mgr module enable prometheus

Проверяем:

ceph mgr services

Обычно получаем:

{
  "prometheus": "http://10.10.10.20:9283/"
}

Метрики будут доступны:

http://CEPH_MGR:9283/metrics

Почему встроенный модуль лучше

Плюсы:

  • меньше компонентов,
  • меньше Docker-контейнеров,
  • меньше проблем совместимости,
  • проще обновления,
  • официальная поддержка Ceph.

Минусы:

  • зависимость от mgr,
  • меньше гибкости,
  • при проблемах mgr метрики тоже могут стать недоступны.

Но в production это сейчас стандартный вариант.

Вариант №1 - Prometheus

Добавляем Ceph в Prometheus

Открываем конфиг:

sudo nano /etc/prometheus/prometheus.yml

Добавляем job:

scrape_configs:
  - job_name: 'ceph'
    scrape_interval: 15s
    static_configs:
      - targets:
          - '10.10.10.20:9283'
        labels:
          cluster: ceph-prod
          role: storage

Перезапускаем Prometheus

sudo systemctl restart prometheus

Или если Docker:

docker restart prometheus

Проверяем targets

Переходим:

http://PROMETHEUS_IP:9090/targets

Должно быть:

ceph UP

Вариант №2 - VictoriaMetrics

Вот тут начинается реально интересная история.

VictoriaMetrics сейчас очень активно вытесняет Prometheus в больших инфраструктурах.

Почему?

  • меньше потребление памяти,
  • быстрее запросы,
  • лучше compression,
  • огромный retention,
  • проще эксплуатация,
  • меньше боли при большом количестве метрик.

Особенно это актуально для:

  • Ceph,
  • Kubernetes,
  • больших кластеров,
  • long-term storage.

Потому что Ceph генерирует очень много метрик.

Запускаем VictoriaMetrics

Самый простой single-node вариант:

docker run -d \
  --name victoriametrics \
  -p 8428:8428 \
  -v victoriametrics-data:/storage \
  victoriametrics/victoria-metrics

Что делает VictoriaMetrics

VictoriaMetrics:

  • принимает метрики,
  • хранит их,
  • умеет PromQL,
  • совместима с Grafana,
  • поддерживает Prometheus scraping.

То есть Grafana даже не заметит разницы.

И это одна из причин, почему VictoriaMetrics так быстро набрала популярность.

Добавляем scrape Ceph в VictoriaMetrics

Создаем конфиг:

sudo nano /opt/victoriametrics/prometheus.yml

Добавляем:

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'ceph'
    static_configs:
      - targets:
          - '10.10.10.20:9283'
        labels:
          cluster: ceph-prod

Запускаем vmagent

VictoriaMetrics обычно работает вместе с vmagent.

И это очень хорошая практика.

Запускаем:

docker run -d \
  --name vmagent \
  -p 8429:8429 \
  -v /opt/victoriametrics/prometheus.yml:/etc/prometheus/prometheus.yml \
  victoriametrics/vmagent \
  -promscrape.config=/etc/prometheus/prometheus.yml \
  -remoteWrite.url=http://victoriametrics:8428/api/v1/write

Почему vmagent лучше обычного Prometheus scrape

vmagent:

  • легче,
  • быстрее,
  • меньше RAM,
  • умеет buffering,
  • умеет репликацию,
  • умеет очереди,
  • лучше переносит сетевые проблемы.

Для больших Ceph-кластеров - очень хорошая история.

Проверяем метрики VictoriaMetrics

Переходим:

http://VICTORIA_IP:8428

Проверяем vmagent:

http://VMAGENT_IP:8429/targets

Подключаем Grafana

Добавляем datasource:

  • Prometheus

Да, именно Prometheus. Потому что VictoriaMetrics совместима с Prometheus API.

URL:

http://victoriametrics:8428

Grafana даже не поймет подвоха.

Добавляем Dashboard

Самый популярный:

  • Ceph Cluster Dashboard
  • ID: 917

Импорт:

  1. Dashboards
  2. Import
  3. Вводим 917
  4. Выбираем datasource

И получаем полноценный мониторинг Ceph.

Что важно мониторить в Ceph

Cluster Health

Самое главное:

ceph_health_status

Значения:

  • 0 - OK
  • 1 - WARN
  • 2 - ERR

Если увидели:

HEALTH_ERR

Значит у вас начинается маленькое инфраструктурное приключение.

OSD

Следим:

  • up/down,
  • latency,
  • utilization,
  • recovery,
  • nearfull.

Пример:

ceph_osd_up == 0

Заполненность OSD

(
  ceph_osd_stat_bytes_used /
  ceph_osd_stat_bytes
) * 100

Ceph очень плохо переносит переполнение.

После 85-90% начинаются:

  • massive rebalance,
  • recovery storms,
  • деградация производительности,
  • долгие операции.

PG (Placement Groups)

Одна из самых важных вещей в Ceph.

Следим:

  • degraded,
  • undersized,
  • remapped,
  • stuck PG.

Пример:

ceph_pg_degraded

Скорость операций

Чтение:

rate(ceph_pool_rd[5m])

Запись:

rate(ceph_pool_wr[5m])

Полезные алерты

OSD Down

- alert: CephOSDDown
  expr: ceph_osd_up == 0
  for: 2m
  annotations:
    summary: "OSD Down"

Ceph Health Error

- alert: CephHealthError
  expr: ceph_health_status == 2
  for: 1m
High Usage
- alert: CephHighUsage
  expr: (
    ceph_osd_stat_bytes_used /
    ceph_osd_stat_bytes
  ) * 100 > 85

Telegram уведомления

Мониторинг без уведомлений - это просто красивые графики.

Настраиваем Alertmanager:

receivers:
  - name: telegram
    telegram_configs:
      - bot_token: TOKEN
        chat_id: CHAT_ID

Что выбрать - Prometheus или VictoriaMetrics

Prometheus

Плюсы:

  • де-факто стандарт,
  • огромное сообщество,
  • куча документации,
  • совместимость почти со всем.

Минусы:

  • много RAM,
  • тяжело масштабируется,
  • long-term storage требует костылей,
  • retention может быстро съесть диск.

VictoriaMetrics

Плюсы:

  • очень быстро,
  • отличное сжатие,
  • низкое потребление RAM,
  • проще эксплуатация,
  • идеально для больших инфраструктур,
  • отлично подходит под Kubernetes и Ceph.

Минусы:

  • меньше документации,
  • меньше community tooling,
  • некоторые привыкли только к Prometheus.

Мой практический совет

Для:

  • небольшого кластера,
  • пары серверов,
  • домашней лаборатории,

хватит обычного Prometheus.

Для:

  • production,
  • Kubernetes,
  • Ceph на десятки узлов,
  • долгого хранения метрик,
  • большого количества OSD,

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

Production-рекомендации

Добавьте node_exporter

Ceph без системных метрик - это половина картины.

Нужны:

  • CPU,
  • RAM,
  • disk IO,
  • network,
  • filesystem latency.

Используйте retention

Ceph очень важно анализировать исторически.

Например:

  • рост данных,
  • деградации,
  • recovery,
  • network spikes,
  • latency.

Не храните всё 15 дней

Для Ceph очень полезен retention:

  • 90 дней,
  • 180 дней,
  • иногда год.

Особенно если:

  • анализируете деградации,
  • ищете плавающие проблемы,
  • планируете capacity.

Используйте отдельный monitoring node

Не надо размещать мониторинг:

  • на MON,
  • на OSD,
  • на production workload.

Иначе во время аварии:

  • Ceph умирает,
  • мониторинг умирает,
  • расследование превращается в гадание на логах.

Итог

Мониторинг Ceph - обязательная часть эксплуатации кластера.

Минимальный современный production-набор сегодня:

  • Grafana,
  • Alertmanager,
  • node_exporter,
  • ceph mgr prometheus module,
  • Prometheus или VictoriaMetrics,
  • Telegram alerting.

Если инфраструктура небольшая - Prometheus более чем хватит.

Если инфраструктура большая и метрик много - VictoriaMetrics часто оказывается намного приятнее в эксплуатации.

И самое главное:

Не ждите HEALTH_ERR, чтобы впервые открыть Grafana.

Потому что в этот момент мониторинг уже превращается в цифровую археологию с элементами хоррора.