Коротко. Имя события в ActiveScale — это имя чекера, а не приговор железу. Часть CRITICAL-событий означает разрыв сети или ошибку конфигурации (MACHINE_DOWN, HAPROXY_DOWN), часть — ложную тревогу инвентаризатора (DISK_NOT_FOUND, PSU_NOT_FOUND, FAN_NOT_FOUND, NIC_DOWN). Порядок разбора всегда один: что проверял чекер → что показывает живое железо/сеть → только потом действие.
1. Как читать событие
В списке событий GUI и в базе событий есть поля, по которым видно больше, чем по тексту:
| Поле | Что говорит |
|---|---|
имя (MACHINE_DOWN) |
какой чекер сработал |
severity (CRITICAL/ERROR/WARNING/INFO) |
насколько чекер уверен, что это проблема |
состояние (LIVE/ARCHIVED) |
LIVE — держится сейчас; ARCHIVED — уже закрылось |
occ |
сколько раз повторялось |
details |
что именно нашёл чекер (у части событий пустой — это норма) |
HANDLED_AUTO |
событие закрыто само, без оператора |
Три практических правила:
ARCHIVED+HANDLED_AUTO— эпизод закончился. Разбирать стоит, только если повторяется.LIVE+ ростocc— процесс идёт прямо сейчас; смотреть железо и сеть, а не лог.detailsважнее текста. ВDISK_NOT_FOUNDтамdiskid,device,buslocation; в ленточных —missing_tapes,max_tape_allowed.
Часть событий закрывается действием ignore вручную; часть — сама, на следующем цикле чекера
(типовой цикл mona — 600 секунд). Поэтому «событие висит» и «проблема есть» — не одно и то же.
2. Платформа, нода, железо
| Событие | Severity | Смысл | Действие |
|---|---|---|---|
MACHINE_DOWN |
CRITICAL | нода недоступна по storage-кольцу; поднимается раз в час | проверить ping по <STORAGE_NET> со всех нод → replSetGetStatus (все члены healthy) → MAC-таблицу свича по MAC storage-портов |
MONA_DOWN |
ERROR | супервизор data-path (iamd, compactord, dss-ng-client, hekad) не отвечает; вачдог перезапускает | проверить, что mona поднялась сама; occ=3 и рост — разбирать память/диск ноды |
HAPROXY_DOWN |
CRITICAL | чекер haproxy_process_count не нашёл процесс («expected 1, found 0»); S3-трафик без фронта |
haproxy -c -f по конфигам; проверить, что конфиги не переписаны битым рендером; после починки — 307 на 443 |
HAPROXY_RECOVERED |
INFO | фронт снова поднялся | признак, что лечение сработало |
IAMD_HEALTH_FAILURE |
CRITICAL | IAM-сервер недоступен для запросов на этой ноде | чаще краткое окно; закрывается HANDLED_AUTO; повтор — к вендору |
ARAKOON_NODE_UNRESPONSIVE |
CRITICAL | инстансы arakoon не отвечают на ping дольше 30 с | проверять метаданные и связность; одиночный эпизод — наблюдение |
METADATA_ISSUE |
CRITICAL | проблема метаданных; обычно пара к предыдущему | разбирать вместе с ARAKOON_*, не по отдельности |
TASKMANAGER_STALLED |
CRITICAL | воркеры taskmgr встали | догон прерванной фазы reconfigure; после — закрывается авто |
TASK_FAILED |
CRITICAL | задача упала (failed= в taskmgr/playbooks.log) |
смотреть имя задачи; column.update_all_buckets — таймаут SDB |
MONGO_REPLICA_STATUS_FAILED |
CRITICAL | нет доступного PRIMARY в кластере модели | проверить storage-кольцо и pgrep -c mongod; часто след разрыва сети |
MODEL_MARVINWEB / MODEL_MARVINTASKMGR / MODEL_MGMTSERVERS |
CRITICAL | модель не видит службу | следствие обрыва фазы; догон reconfigure |
DSS_STORAGEPOOL_NOT_UPDATED |
— | пул хранения не обновлялся (у колонки resources=0) |
проверить сеть storage и скан железа; не «инъектить» ёмкость руками |
NIC_DOWN |
ERROR | порт в модели есть, линка нет; чекер проверяет {UP, DOWN, BONDED} |
увести лишние порты в NOTMANAGED через Model API (PUT .../nic/<NGUID>/ → 200) |
NIC_NOT_FOUND |
— | порт без кабеля или без распознанного имени | шум чекера; статус NOTMANAGED/NOTFOUND, лечится моделью, а не железом |
DISK_NOT_FOUND |
CRITICAL | чекер model_disk не нашёл диск по buslocation |
проверить smartctl -H, mdstat, статус в модели; чаще ложная тревога |
PSU_NOT_FOUND |
ERROR | инвентаризатор не нашёл БП штатным IPMI-типом | сверить ipmitool датчики; в модели БП обычно ONLINE |
FAN_NOT_FOUND |
ERROR | то же для вентиляторов; часть платформ отдаёт «no reading» | фильтр ignore_fans_regex в профиле железа + реальный осмотр |
3. Холодное хранение и лента
| Событие | Severity | Смысл | Действие |
|---|---|---|---|
COLD_STORAGE_TAPE_CONNECTOR_UNAVAILABLE |
CRITICAL, каждые ~4 ч | проверки коннектора уходят на 443 (продукт строит URL без порта) и получают 501, хотя коннектор жив |
проверить адрес коннектора: он должен быть отдельным, где 443 не занят фронтом S3; после правки — новых событий нет |
COLD_STORAGE_TAPE_SAFETY_EQUALS_ZERO |
WARNING, раз в час | в группах ленты меньше кассет, чем требуют spread и safety | довести группы до нужного числа кассет либо согласованно снизить ожидание в модели |
COLD_STORAGE_TAPE_AUTODECOMMISSION_BACKOFF |
ERROR | «пропавших» кассет больше max_tape_allowed, предохранитель держит де-коммишн |
сверить форму штрихкода в реестре: продукт отбрасывает LTO-суффикс, полная форма не совпадает |
COLD_STORAGE_TAPE_DECOMMISSIONED |
INFO, barcode="" |
запись о кассете снята | признак записи без штрихкода; чинить реестр, а не библиотеку |
COLD_STORAGE_INVALID_BARCODE_DETECTED |
— (появилось в 7.1) | штрихкод не по формату LTO | привести штрихкод к валидной форме; до 7.1 такое просто ломало архивацию |
INSUFFICIENT_FREE_TAPE_MEDIA |
— | свободных кассет не хватает для архивации | добавить кассеты или освободить занятые |
Общее правило по ленте: библиотека и реестр продукта — разные вещи. Событие обычно говорит
о расхождении между ними, а не о поломке кассеты. Сначала сверяют каталог библиотеки
(/sws/v2/media/fsmedlist/state?format=JSON) с записями продукта.
4. Ложные тревоги: механизм
DISK_NOT_FOUND
Чекер model_disk перебирает типы buslocation (enc, ses, nvme, sled, pno, sas,
lun), потому что предпочитаемый тип ему не задан. Если диск описан, например, как pno-1:N,
совпадения может не быть — и чекер рапортует «диск не найден». Живая проверка тех же дисков
показывает ONLINE в модели, md1..md4 в состоянии [UU], smartctl -H → PASSED. Диски не
меняют; событие разбирают как шум чекера.
PSU_NOT_FOUND / FAN_NOT_FOUND
Механизм (гипотеза: модуль-эмиттер не найден): инвентаризатор перечисляет датчики по штатному
IPMI-типу. Если платформа не отдаёт тип
Power Supply (пусто в ipmitool sdr type), он ничего не находит и эмитит NOT_FOUND. В модели БП и вентиляторы ONLINE, ipmitool показывает живые обороты и напряжения. Лечится
профилем: фильтр ignore_fans_regex, затем «перезапуск mona → удаление orphan-доков → скан».
NIC_DOWN
Порт, у которого в модели статус DOWN/UP, а линка нет, репортится как «down». Это не поломка
сети. Лишние порты уводят в NOTMANAGED; чекер пропускает все статусы, кроме
{UP, DOWN, BONDED}, и событие закрывается на следующем цикле.
MACHINE_DOWN
Самая дорогая ложная тревога: нода ONLINE, диски ONLINE, службы живы, а событие приходит
раз в час. Причина — разорванное storage-кольцо (порт свича в чужой VLAN, кабель, ошибка
адресации). Порядок: ping по storage-сети со всех нод → replSetGetStatus → MAC-таблица
свича по MAC storage-портов. Описания портов на свиче проверять нельзя — они не совпадают с
фактическими VLAN.
5. Минимальные проверки перед действием
smartctl -H /dev/<DEV> # PASSED или FAILED
cat /proc/mdstat # [UU] или degraded
ipmitool sdr type "Power Supply"
ipmitool sdr type "Fan"
ping <STORAGE_IP> # storage-кольцо
pgrep -c mongod # число процессов на ноде
Все — только чтение. Действие (смена статуса в модели, правка VLAN, замена диска) — после того, как проверка объяснила событие.
6. Где смотреть
- GUI → события: фильтр
LIVE/ARCHIVED, сортировка по времени и severity. - База событий (mTLS, с ноды): выборка по типу, например
db.event.find({eventtype:/TAPE/}). - Логи чекеров:
mona.log— причина срабатывания;taskmgr/playbooks.log—TASK [...],PLAY RECAP,failed=для задач.
7. Источники
- Software Documentation Center (7.3) (дата доступа 2026-11-07)
- ActiveScale Software 7.3 Release Notes (дата доступа 2026-11-07)
- Наша практика (обезличено): разборы событий на 3-нодных стендах и стенде с лентой.