Мониторинг Ceph с помощью Proto Observability

На этой странице:

• Сбор метрик Ceph
  • Конфигурация Ceph
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
    • Если агент запускается в Kubernetes
  • Проверка
  • Собираемые метрики
    • Лейблы
      • Общие (на всех метриках)
      • Специфичные для Ceph
    • Метрики уровня кластера
      • Мониторы
      • OSD (сводно по кластеру)
      • Placement groups
      • Ёмкость и объекты
      • Пулы (количество)
    • Метрики уровня OSD
    • Метрики уровня пула
      • Поток клиентского ввода-вывода
      • Восстановление (recovery)
      • Ёмкость и объекты пула
  • Ключевые метрики для дашбордов и алертов
• Сбор логов Ceph
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка

Сбор метрик Ceph

Интеграция ceph — CLI-ориентированная: на каждом цикле проверки агент запускает бинарь ceph и парсит JSON-вывод. Под капотом выполняются команды (все с флагом -fjson):

ceph --cluster ceph mon_status
ceph --cluster ceph status
ceph --cluster ceph df detail
ceph --cluster ceph osd pool stats
ceph --cluster ceph osd perf
ceph --cluster ceph osd metadata
ceph --cluster ceph health detail

Из этого складываются метрики уровня кластера (мониторы, OSD, PG, ёмкость, пулы), уровня OSD (латентности), уровня пула (клиентский ввод-вывод, объекты, утилизация) и service-check’и по health-проверкам Ceph.

ceph mgr module enable prometheus
# метрики становятся доступны на http://<mgr>:9283/metrics

Конфигурация Ceph

Со стороны самого Ceph дополнительной настройки не требуется — нужен лишь доступ к кластеру с хоста агента. Проверьте, что команды отрабатывают из-под пользователя, от которого работает агент:

ceph --cluster ceph status
ceph --cluster ceph health detail

Если они работают, интеграция соберёт метрики. Если у вашего кластера имя отличное от ceph — задайте его в конфиге проверки параметром ceph_cluster. Если бинарь ceph доступен только через sudo — добавьте в sudoers строку

pobp-agent ALL=(ALL) NOPASSWD:/usr/bin/ceph

и включите use_sudo: true в конфиге проверки.

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

1. Установите пакет ceph-common, если его ещё нет (он даёт бинарь ceph):

   # Debian/Ubuntu
   apt-get install -y ceph-common
   # RHEL/CentOS
   yum install -y ceph-common
   

2. Убедитесь, что /etc/ceph/ceph.conf и /etc/ceph/ceph.client.admin.keyring присутствуют и доступны пользователю агента на чтение.

3. Создайте файл /etc/protoobp-agent/conf.d/ceph.d/conf.yaml:

   init_config:
   
   instances:
     - ## Бинарь ceph (по умолчанию /usr/bin/ceph) и имя кластера (по
       ## умолчанию `ceph`) определяются автоматически — задавайте только
       ## при отклонении от дефолтов:
       # ceph_cmd: /usr/bin/ceph
       # ceph_cluster: ceph
       # use_sudo: false           # true, если ceph доступен только через sudo
   
       ## проверка ceph — cluster-level: метрики кластера/OSD/пулов не привязаны
       ## к хосту, на котором работает агент.
       empty_default_hostname: true
   
       ## Дополнительные теги на всех метриках, событиях и service-check'ах.
       tags:
         - ceph_cluster:ceph
   

4. Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

В отличие от большинства интеграций, у ceph нет смысла навешивать autodiscovery-лейблы на контейнер с Ceph — проверка работает не «по сети к сервису», а через локальный бинарь ceph и файлы в /etc/ceph. Поэтому схема такая:

1. Соберите образ агента с ceph-common. Стоковый образ его не содержит.

   # agent/Dockerfile
   FROM registry.git.proto.group/protoobp/protoobp-artifacts/protoobp-agent:7.40.3
   USER root
   RUN DEBIAN_FRONTEND=noninteractive apt-get update \
    && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
         -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold \
         ceph-common \
    && rm -rf /var/lib/apt/lists/*
   

   (Базовый образ агента — Ubuntu 22.04; опции --force-conf* нужны, чтобы установка ceph-common не споткнулась на интерактивном вопросе про openssl.cnf.)

2. Прокиньте в агента бинарь (через образ выше), conf.yaml и /etc/ceph. Конфиг кластера + keyring проще всего отдать из контейнера с Ceph через общий named volume:

   services:
     ceph:
       image: quay.io/ceph/demo:latest-reef
       # … (mon/mgr/osd; пишет ceph.conf + keyring'и в /etc/ceph) …
       volumes:
         - ceph-etc:/etc/ceph          # общий с агентом том
   
     protoobp-agent:
       build:
         context: ./agent             # Dockerfile из шага 1
       image: my-protoobp-agent-ceph:7.40.3
       pid: host
       volumes:
         - /var/run/docker.sock:/var/run/docker.sock:ro
         - /var/lib/docker/containers:/var/lib/docker/containers:ro
         - ./agent-conf/ceph.d/conf.yaml:/etc/protoobp-agent/conf.d/ceph.d/conf.yaml:ro
         - ceph-etc:/etc/ceph:ro       # ceph.conf + ceph.client.admin.keyring
       environment:
         - POBP_API_KEY=<ваш ключ>
         - POBP_POBP_URL=<backend>
         # … остальное по обычной схеме …
   
   volumes:
     ceph-etc:
   

   Содержимое ./agent-conf/ceph.d/conf.yaml — тот же conf.yaml, что в варианте «служба на хосте» (см. выше).

Если агент запускается в Kubernetes

В отличие от большинства интеграций, у ceph нельзя использовать annotation-based autodiscovery (ad.proto.group/<container>.checks): проверка работает не «по сети к сервису», а через локальный бинарь ceph и файлы в /etc/ceph. Поэтому агент с интеграцией ceph ставится отдельным sidecar-контейнером в том же Pod’е, что и Ceph, чтобы:

• видеть мониторы на общем сетевом namespace Pod’а (localhost / pod IP);
• читать ceph.conf + admin keyring, которые Ceph пишет в общий том /etc/ceph.

Образ агента — с ceph-common (тот же Dockerfile, что для Docker выше). Контейнер агента работает под root: admin keyring имеет права 0600 (ceph:ceph), читать его может только root. Конфиг проверки отдаётся через ConfigMap. Логи демонов Ceph при этом собирает кластерный агент (DaemonSet с POBP_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true) — на Pod навешивается аннотация ad.protoobp.com/ceph.logs с правилом multi_line (см. раздел «Сбор логов»).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ceph
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ceph
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ceph
      annotations:
        # логи демонов Ceph собирает кластерный агент (container_collect_all)
        ad.protoobp.com/ceph.logs: |-
          [{"source":"ceph","service":"ceph","log_processing_rules":[{"type":"multi_line","name":"log_start_with_date","pattern":"\\d{4}-\\d{2}-\\d{2}"}]}]          
    spec:
      containers:
        # --- сам кластер Ceph; пишет ceph.conf + keyring в общий /etc/ceph ---
        - name: ceph
          image: quay.io/ceph/demo:latest-reef
          securityContext:
            privileged: true
          env:
            - name: MON_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            - name: CEPH_PUBLIC_NETWORK
              value: "10.0.0.0/8"      # ОБЯЗАН содержать pod IP (MON_IP)
            # ... DEMO_DAEMONS, OSD_TYPE, RGW_NAME=ceph и т.д.
          volumeMounts:
            - name: ceph-etc
              mountPath: /etc/ceph
        # --- sidecar: агент с ceph-common, гоняет CLI-интеграцию `ceph` -------
        - name: protoobp-agent
          image: <ваш-образ-агента-с-ceph-common>
          securityContext:
            runAsUser: 0                # чтобы прочитать admin keyring (0600)
          env:
            - name: POBP_API_KEY
              valueFrom:
                secretKeyRef:
                  name: protoobp
                  key: api-key
            - name: POBP_POBP_URL
              value: http://<backend>
            - name: POBP_LOGS_ENABLED
              value: "false"            # логи собирает кластерный агент
          volumeMounts:
            - name: ceph-etc
              mountPath: /etc/ceph
              readOnly: true            # root читает keyring и из ro-тома
            - name: ceph-config
              mountPath: /etc/protoobp-agent/conf.d/ceph.d/conf.yaml
              subPath: conf.yaml
      volumes:
        - name: ceph-etc
          emptyDir: {}                  # ceph.conf + keyring; общий для Pod'а
        - name: ceph-config
          configMap:
            name: ceph-config           # тот же conf.yaml, что и выше

Проверка

Убедитесь, что проверка запустилась и собирает метрики:

docker exec protoobp-agent agent status | grep -A 12 "^    ceph"

Ожидаемый вывод — Instance ID … [OK] и ненулевой Metric Samples (на одно-OSD кластере Reef с CephFS, RGW и клиентским трафиком — порядка 124 сэмплов за прогон):

    ceph (2.7.0)
    ------------
      Instance ID: ceph:56ca34131c0cb58a [OK]
      Configuration Source: file:/etc/protoobp-agent/conf.d/ceph.d/conf.yaml
      Total Runs: 6
      Metric Samples: Last Run: 124, Total: 662
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 19, Total: 114
      Average Execution Time : 3.2s
      Last Successful Execution Date : <дата>

Список найденных метрик за один прогон:

docker exec protoobp-agent agent check ceph --check-rate | grep -oE '"ceph\.[a-z_.]+"' | sort -u

Что отдаёт проверка прямо сейчас, можно посмотреть и напрямую:

docker exec ceph ceph -s            # общее состояние кластера
docker exec ceph ceph df detail     # ёмкость и пулы
docker exec ceph ceph osd perf      # латентности OSD

Собираемые метрики

Все метрики — типа gauge (мгновенное значение), кроме per-pool ceph_read_bytes / ceph_write_bytes, которые интеграция считает как rate в секунду из накопительных rd_bytes / wr_bytes пула.

Лейблы

Общие (на всех метриках)

Добавляются агентом и ProtoOBP backend’ом. Поскольку в конфиге обычно стоит empty_default_hostname: true, лейбл host у метрик кластера может быть пустым.

Дополнительно проверка пытается добавить лейблы ceph_fsid (UUID кластера) и ceph_mon_state (leader / peon / …) — но обе берутся из вывода команды ceph mon_status, которой в современных Ceph (Quincy, Reef и новее) нет как cluster-команды (она доступна только через admin-socket). Поэтому на этих версиях эти лейблы не появляются — ceph_fsid см. в ceph fsid.

Специфичные для Ceph

Метрики уровня кластера

Мониторы

OSD (сводно по кластеру)

Placement groups

Ёмкость и объекты

Пулы (количество)

Метрики уровня OSD

Несут лейбл ceph_osd:osd<N>. Источник — ceph osd perf и (для osd_pct_used) ceph health detail.

Метрики уровня пула

Несут лейбл ceph_pool:<имя пула>.

Поток клиентского ввода-вывода

Источник — ceph osd pool stats (поле client_io_rate по каждому пулу).

Восстановление (recovery)

Источник — ceph osd pool stats (поля recovery / recovery_rate по пулу).

(Эти метрики обычно нулевые — становятся значимы при ребалансе/деградации.)

Ёмкость и объекты пула

Источник — ceph df detail (секция pools).

Ключевые метрики для дашбордов и алертов

Здоровье и доступность кластера

• Service check ceph_overall_status — основной индикатор. CRITICAL (HEALTH_ERR) — авария; WARNING на одно-OSD/малом кластере — норма.
• Отсутствие свежих серий по ceph_num_mons / ceph_fsid — агент не получает данные кластера (упал ceph-CLI, недоступен /etc/ceph, кластер не отвечает).
• ceph_num_mons_active < ceph_num_mons — мониторы потеряли кворум (или часть мониторов недоступна).

OSD

• ceph_num_up_osds < ceph_num_osds или ceph_num_in_osds < ceph_num_osds — есть выпавшие/выведенные OSD; service check ceph_osd_down.
• ceph_num_near_full_osds > 0 / ceph_num_full_osds > 0 — OSD заполняются; ceph_osd_pct_used per ceph_osd — насколько; алерт сильно заранее (при full Ceph блокирует запись).

Ёмкость

• ceph_aggregate_pct_used — алерт при > 75–85 % (после nearfull/full ratio запись блокируется).
• ceph_pct_used per ceph_pool — какой пул растёт; ceph_num_objects per пул — динамика числа объектов.

Placement groups

• ceph_num_pgs ≠ ceph_pgstate_active_clean — часть PG не в норме. Алерт на ненулевые «плохие» состояния: ceph_pgstate_* с down, incomplete, stale, inconsistent, degraded, undersized, backfill*, recovery* в имени.
• Service check’и ceph_pg_availability / ceph_pg_degraded / ceph_pg_damaged.

Производительность и латентность

• ceph_commit_latency_ms / ceph_apply_latency_ms per ceph_osd — рост = «больной» диск/OSD; алерт по абсолютному порогу (десятки–сотни мс) или по выбросу относительно остальных OSD.
• ceph_op_per_sec / ceph_read_op_per_sec / ceph_write_op_per_sec per ceph_pool, ceph_read_bytes / ceph_write_bytes per ceph_pool — профиль клиентской нагрузки; используется для capacity-планирования и для контекста к латентностям.

Восстановление / деградация

• ceph_misplaced_objects / ceph_recovering_objects_per_sec устойчиво > 0 — идёт ребаланс/recovery (после падения OSD, изменения crush map, добавления диска). Долго не сходящийся к нулю misplaced — проблема с PG/OSD.

Сбор логов Ceph

Логи демонов Ceph собираются ProtoOBP агентом и отправляются в бэкенд ProtoOBP. Здесь — только специфичные для Ceph настройки. Включение логов на стороне агента (logs_enabled, logs_pobp_url) описано в Получение данных логов.

Записи в логах Ceph начинаются с ISO-метки времени — в файлах /var/log/ceph/*.log это

2026-05-12T10:00:00.123456+0000 7f1234567890  0 mon.ceph@0(leader) e1 handle_command ...

(дата, поток, уровень/субсистема, сообщение), в clog-выводе на stdout —

2026-05-12T10:00:00.123456+0000 mon.ceph [WRN] Health check update: ... (PG_DEGRADED)

Оба варианта склеиваются правилом multi_line с якорем pattern: \d{4}-\d{2}-\d{2} («строка начинается с даты») — без него каждая строка многострочной записи (stack trace, дамп admin-сокета) попадёт в ProtoOBP отдельно.

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

При обычной установке Ceph демоны пишут логи в /var/log/ceph/ (ceph-mon.<id>.log, ceph-osd.<id>.log, ceph-mgr.<id>.log, ceph-mds.<id>.log, client.rgw.<name>.log и т.д.). Дополните уже существующий /etc/protoobp-agent/conf.d/ceph.d/conf.yaml (тот же файл, в котором лежит instances:) блоком logs::

logs:
  - type: file
    path: /var/log/ceph/*.log
    source: ceph
    service: ceph
    log_processing_rules:
      - type: multi_line
        name: log_start_with_date
        pattern: \d{4}-\d{2}-\d{2}

Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Шаг 1 — включите сбор логов в самом агенте через переменные окружения и смонтируйте директорию JSON-логов docker-демона:

services:
  protoobp-agent:
    environment:
      POBP_LOGS_ENABLED: "true"
      POBP_LOGS_CONFIG_USE_HTTP: "true"
      POBP_LOGS_CONFIG_LOGS_POBP_URL: <protoobp-backend>:<port>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # Прямое чтение JSON-лог файлов docker-демона быстрее,
      # чем тянуть их через Docker socket API.
      - /var/lib/docker/containers:/var/lib/docker/containers:ro

Шаг 2 — выберите, откуда брать логи Ceph:

• Если демоны логируют в stdout контейнера (например, запущены с --default-log-to-stderr=true) — навесьте на контейнер с Ceph autodiscovery-лейбл com.protoobp.ad.logs:

  services:
    ceph:
      labels:
        com.protoobp.ad.logs: '[{"source": "ceph", "service": "ceph", "log_processing_rules": [{"type": "multi_line", "name": "log_start_with_date", "pattern": "\\d{4}-\\d{2}-\\d{2}"}]}]'
  

• Если демоны пишут в файлы /var/log/ceph/*.log — прокиньте этот каталог в агента (например, через общий named volume) и добавьте logs: блок в bind-mount’нутый agent-conf/ceph.d/conf.yaml (тот же блок, что в варианте «служба на хосте» выше), смонтировав /var/log/ceph:ro.

Проверка

В выводе agent status должен быть раздел Logs Agent со статусом running и источник ceph с ненулевым BytesRead:

docker exec protoobp-agent agent status \
  | sed -n '/^==== Logs Agent ====/,/^====/p'