Мониторинг: Prometheus, Grafana и CBA — где смотреть метрики

1. Три слоя и кто что рисует

Важно: GUI — потребитель, а не источник. Пустая плитка в интерфейсе чаще означает «нет данных в Prometheus», чем «сломан GUI». Поэтому диагностика идёт снизу вверх: экспортёр → Prometheus → панель.

2. Экспортёр на ноде

Экспортёр — обычный systemd-юнит activescaleexporter.service. Он собирает метрики из локальных источников (например, температуру диска — из вывода smartctl) и складывает их в /opt/ampli/var/run/activescaleexporter/*.json, а также отдаёт по HTTP на порт 1234.

Проверка (read-only):

systemctl status activescaleexporter
curl -s localhost:1234/metrics | grep as_temperature_disk_celsius
ls -la /opt/ampli/var/run/activescaleexporter/temperature_metric.json
grep -i 'Failed getting' /opt/ampli/var/log/activescaleexporter/*.log

Ожидается: юнит active (running), метрика в ответе, mtime JSON свежий, ошибок сбора нет.

Три типовых состояния:

1. Юнит не поднялся после ребута — inactive/failed, JSON не обновляется, метрики нет.
2. Процесс жив, но завис — active, а JSON старый и :1234 не отвечает.
3. Сбор падает на конкретном диске — метрика есть не для всех дисков; ошибка только в логе экспортёра, в GUI — пустая коробочка без сообщения.

Отдельный класс — упор в лимит файловых дескрипторов. В журнале это выглядит как as-exporter-fd: restarting the activescaleexporter service: 129 >= 128; служба перезапускается сама, метрики на время пропадают.

3. Prometheus

Prometheus забирает :1234/metrics с каждой ноды и хранит ряды. Порт и адрес локальные — наружу его не публикуют. В наших сборках встречались и 9091, и 9090; хардкодить номер в чужом окружении нельзя, его надо смотреть по факту (конфиг Prometheus/юнита) или через GUI.

Проверка целей (read-only, с management-ноды):

curl -s localhost:<PROM_PORT>/api/v1/targets | python3 -m json.tool | grep -A5 "<NODE>"

Ожидается: все ноды в состоянии up, без down/unknown. Если одна нода down — её метрики пропали из всех панелей, включая витрину durability и температуру дисков.

PromQL-запрос по конкретной метрике можно выполнить тем же API:

curl -s 'localhost:<PROM_PORT>/api/v1/query?query=as_policy_blockstore_disk_safety_configured_min'

4. Grafana и витрина durability

Часть дашбордов открывается как отдельная Grafana, часть встроена в samurai через iframe. Витрина durability (Data Safety) на странице ресурсов — именно iframe Grafana; GUI лишь передаёт ссылку на дашборд.

Ключевые панели:

Пара чисел вида «2 / 4» читается как минимум по политикам / максимум по политикам, а не «деградация / норма». Если в DSS две политики — большая с safety 4 и small-files с safety 2, — минимум даёт 2, максимум 4. Объекты при этом лежат каждый на своей полной safety, repair = 0, событий DSS_STORAGEPOOL_DISK_SAFETY нет. Жёлтый цвет панели тоже штатный: порог привязан к вендорскому порогу события, и для политик с safety ≤ 2 он равен max(safety−1, 1).

Практический вывод: прежде чем объявлять деградацию, сверить …_configured_min с фактическим значением на панели. Совпало — деградации нет, это арифметика по политикам.

5. Что изменилось в 7.3 и рядом

• Метрики S3 перестроены. В релиз-нотах 7.3 прямо сказано: Prometheus-метрики S3 изменены — другие лейблы и единицы. Кастомные дашборды, собранные под 7.1/7.2, после апгрейда могут показывать не то или пустоту. Это не поломка сбора, а смена контракта метрик: дашборды надо править по новым лейблам.
• Метрики ленты уточнялись в 7.2: появились счётчики «байт ждёт восстановления» и «байт восстанавливается», ограничение ремонта при де-коммишне. Если панель ленты «не сходится» с реальностью — сверить, что дашборд читает актуальные имена.
• 7.3: Cold Storage QoS — резервирование приводов под archive/restore; настраивается через поддержку, не через GUI-тумблер.
• 7.0: в GUI появились метрики длительности S3-запросов (System Overview → System Performance → Objects).
• 7.1: продукт предупреждает об истечении SSL-сертификата за 6 месяцев — тоже наблюдаемая величина, а не событие «в момент отказа».

6. CBA: облачная аналитика

Cloud-Based Analytics (CBA) — облачный сервис Quantum для мониторинга и диагностики: сбор метрик и логов, удалённый доступ поддержки. Доступен с 6.2. Это не замена локальному Prometheus: CBA отвечает на вопрос «что видит вендор», локальный мониторинг — «что происходит у нас сейчас».

Штатное включение:

1. Configuration > Cloud Analytics > Cloud-Based Analytics.
2. Включить основной тумблер CBA.
3. Выбрать функции: Metrics and log upload и/или Remote access.
4. При необходимости — proxy-настройки для SSL-прокси.
5. Проверить на портале insight.quantum.com (дата доступа 2026-11-07), что система видна в разделе Solutions.

При включённой выгрузке метрик и логов версия ActiveScale фиксируется на стороне CBA — это удобно при разборе с поддержкой. Remote access регулируется с двух сторон: на портале и локально; для работы должны быть включены обе.

Серверное состояние читается через marvin.getCBAStatus / marvin.setCBAStatus; UI-тумблер cbaEnabled — локальный $scope формы callhome, при выключении он сбрасывает прокси и логин.

7. Диагностика «в GUI пусто»

Порядок, который отсекает лишнее:

1. Юнит экспортёра → active (running).
2. JSON-файл метрики → mtime свежий.
3. :1234/metrics → нужная метрика присутствует.
4. Лог экспортёра → нет Failed getting ….
5. Prometheus target → нода up.
6. PromQL → значение есть и не NaN.
7. Панель/витрина → рисуется; для durability — selectedstoragepolicy не null.

Если первые пять пунктов в порядке, а панель пустая — смотреть модель: витрина durability не рисуется, когда GET /model/environment/<ENV_GUID>/selectedstoragepolicy/ возвращает null. Это не проблема метрик, а незаписанное поле выбора политики.

Встроенный health check запускается из GUI: Configuration > System > General Info > Health Check → Run; статус задания — в панели Jobs. Это штатный сводный отчёт, его полезно снимать до и после изменений.

8. Границы и профилактика

• Метрика ≠ событие. Панель показывает числовой ряд, событие — состояние с severity. Растущий график и LIVE-событие могут говорить об одном, но проверяются по-разному.
• Самоотчёт Mona/Taskmanager о памяти — известный недо-баг платформы. Их числам верим примерно на 99 %; независимо смотрим ps -eo pid,user,rss,args --sort=-rss. Живой случай: наш собственный долгоживущий скрипт держал десятки гигабайт RSS, а события выглядели как проблемы дисков и падение mona — это были разные классы.
• Не строить алерты на «шумных» чекерах. NIC_DOWN на неподключённых портах и PSU/FAN NOT_FOUND при живом железе — фон, а не сигнал.
• Регламент: раз в сутки сверять LIVE-события, up цели Prometheus и свежесть JSON экспортёра на всех нодах; после апгрейда — пересмотреть кастомные дашборды под новые лейблы.
• Не публиковать Prometheus наружу. Он локальный; внешний доступ к нему — отдельное решение безопасности, а не «удобство».

Источники

• Quantum, Manage System Settings (дата доступа 2026-11-07): CBA, health check, портал CBA.
• Quantum, ActiveScale Software Release Notes (дата доступа 2026-11-07): перестройка Prometheus-метрик S3 в 7.3, метрики ленты, QoS.
• Quantum, Z200 datasheet (дата доступа 2026-11-07): CBA, Prometheus, экспорт в Grafana.
• Наша практика (обезличено): разбор витрины durability «2 / 4» на кластере из трёх нод, версия 7.3.1; метрики as_policy_blockstore_disk_safety_configured_min/max.
• Обновлено: 2026-11-07.