События и задачи: что значит LIVE, ARCHIVED и QUEUED

Коротко. В ActiveScale два независимых журнала: события (modeldb.event) говорят о состоянии системы, задачи (modeldb.task) — о выполненных работах. LIVE — событие открыто сейчас; ARCHIVED/HANDLED_AUTO — закрыто, но это не значит «здорово». SUCCESS у задачи не доказывает результат. QUEUED — очередь установщика, а не статус задачи в модели.

1. Два журнала, которые не заменяют друг друга

	События	Задачи
Коллекция	`modeldb.event`	`modeldb.task`
О чём	состояние узла, диска, ленты, шлюза	что система делала и чем кончилось
Кто пишет	чекеры `mona`, плагины продукта	taskmanager (Celery)
Ключевые поля	`eventtype`, `severity`, `status`	`action`, `status`, `finished`
Вопрос	«что сейчас не так»	«что запускали и почему не вышло»

Разбор начинается с событий. Задачи нужны, когда событие ссылается на неудачную работу — TASK_FAILED, TASKMANAGER_STALLED, пустая витрина durability.

2. Поля события

Поле	Смысл
`eventtype`	имя события, по нему группируют (`NIC_DOWN`, `MONA_DOWN`, `TASK_FAILED`)
`severity`	`CRITICAL`, `ERROR`, `WARNING`, `INFO`
`status`	`LIVE`, `HANDLED_AUTO`, `HANDLED_MANUAL`, `ARCHIVED`
`message`	текст; часто с конкретным портом, кулером, кассетой
`details`	машинные подробности (PID, объём, диск); у части событий пустой — норма
`hostname`, `machine`	узел, где поднялось
`occurrences`	сколько раз повторилось в окне дедупликации
`first_occurrence`, `last_occurrence`	первое и последнее срабатывание, микросекунды
`actions[]`	готовые ссылки штатных действий, например `ignore`

Полей code и description в модели нет. Чтение их даёт молчаливые None по всем событиям и выглядит как «модель отдала пустоту». Группировать нужно по eventtype.

Пустой details у FAN_NOT_FOUND/NIC_NOT_FOUND — штатно: содержание в message, там назван конкретный кулер или порт. Не делать из этого вывод «данных нет».

3. Severity: что требует действия

Severity	Трактовка	Реакция
`CRITICAL`	возможна потеря данных или недоступность сервиса	немедленно
`ERROR`	компонент отказывает, влияния на данные нет	в рабочее окно
`WARNING`	требует внимания, не срочно	в наблюдение
`INFO`	информационное	действий не требует

Вендор требует реагировать на CRITICAL сразу и настраивать почтовое уведомление. «Сразу» — значит сначала понять, живая ли причина, а не погасить событие.

4. Статусы событий и дедупликация

LIVE — открыто. Единственный статус, означающий «прямо сейчас».
HANDLED_AUTO — продукт закрыл сам (условие ушло). Может вернуться следующим циклом.
HANDLED_MANUAL — закрыто оператором через ignore.
ARCHIVED — в архиве.

Дедупликация: новое событие не создаётся, если совпали тип, severity, источник и текст и прошло меньше dedupe_period (например, 15 минут; у части типов — сутки). Растут occurrences и last_occurrence; отсчёт идёт от первого срабатывания.

Правило чтения: растущий occurrences — активный цикл, а не старый мусор. Если last_occurrence свежее интервала чекера (у части событий ~10 минут) и occurrences 2–3 — событие поднимается сейчас. Исторический остаток выглядит иначе: occurrences == 1 и last_occurrence старше часа.

5. Как смотреть события

GUI. Раздел Events: список почти реального времени. Фильтры Severity, Active, Sites, Racks, Machines, Time range, Date range, затем Apply. Двойной клик — детали. Есть Download Report и колонка Ignore с крестиком.

Model API (mTLS). Сертификаты продукта root-only, с ноды — под sudo -n:

sudo -n curl -sk \
  --cert /opt/ampli/cfg/marvin/ssl/machine.cert \
  --key  /opt/ampli/cfg/marvin/ssl/machine.key \
  "https://127.0.0.1:8443/model/event/?query=status=LIVE" | head -c 2000

Ожидается 200 и JSON. Без клиентского сертификата модель отвечает 400 мгновенно — это норма mTLS, а не поломка.

Прямое чтение модели. Быстрее и полнее GUI, но нужен venv продукта (python2) и PEM (/opt/ampli/cfg/mongo/ssl/management_model/mongodb_node1.pem, root-only):

sudo /opt/ampli/apps/marvintaskmgr/venv/bin/python - <<'PY'
import ssl, pymongo
c = pymongo.MongoClient('127.0.0.1', 27017, ssl=True, ssl_cert_reqs=ssl.CERT_NONE,
                        ssl_certfile='/opt/ampli/cfg/mongo/ssl/management_model/mongodb_node1.pem',
                        serverSelectionTimeoutMS=10000, directConnection=True)
for e in c['modeldb'].event.find({'status': 'LIVE'}).sort('last_occurrence', -1):
    print(e['eventtype'], e['severity'], e.get('hostname'), e.get('occurrences'))
PY

Что печатать, чтобы вывод был полезен. Итоги по status × severity; все LIVE с текстом и details; события за 24 часа (видно регулярный шум); статусы машин; последние FAILED задачи.

6. Задачи: статусы, расписание, retention

Статус	Смысл
`PENDING`, `STARTING`, `STARTED`	ждёт воркера или в работе
`SUCCESS`	воркер отчитался об успехе
`FAILURE`	упало, смотреть `error_text`/`traceback`
`REVOKED`	отменено (часто — перезапуск воркера или terminate)
`SUCCESS` не равен «получилось»: задача может успешно завершиться, ничего не сделав (например,
`column.update_all_buckets` при пустом списке бакетов). Рядом смотрят эффект — витрину durability,
барометр, `current_policy_id_stats`.

Расписание. modeldb.taskschedule: name, task, enabled, last_run_at, total_run_count. Штатная проверка — GET /model/taskschedule/ и enabled=True у периодических работ. Если после оборванного install-ng задачи column_bucket_update, logs_pruner, reconcile_federateddata остались выключенными — это следствие, а не отдельная поломка: установщик выключает их в начале и включает только в конце успешного прогона.

Чистка. internal.cleanup удаляет события и задачи по retention_config документа environment, по умолчанию — 30 дней на коллекцию.

Раздутый modeldb.task — не блокер. Видели ~40 тысяч документов и ~27 секунд на GET /model/task/ без limit (~40 МБ). Продукт читает задачи по guid и с фильтрами; такие запросы укладываются в 0.1–0.4 с. Полный список без limit в горячий путь не входит. Если нужно сократить — штатно уменьшить retention_config и дать internal.cleanup пройти.

Залипшая задача. 423 LOCKED на configure означает, что держит задача. Штатное действие — снять: POST /model/task/<guid>/action/terminate/.

7. `QUEUED` — не статус задачи в модели

QUEUED и RUNNING инженер видит в выводе install-ng и в очереди установки. Это внутренние состояния установщика: если фаза упала, узел остаётся NOTCONFIGURED, остальные подзадачи — QUEUED. В modeldb.task таких статусов нет: там PENDING/STARTING/STARTED.

Вывод: QUEUED после установки — «работа не доведена», а не «система работает». Проверять нужно маркер /tmp/.unattended_install_finished и taskmgr/playbooks.log, а не список задач в GUI.

8. Как читать картину целиком

LIVE = 0, но за сутки 22 события. Штатно: чекеры отработали, условия ушли, события закрылись сами. Смотреть, какие типы повторяются.
Пачка CRITICAL с одним временем и occurrences = 1. Обычно остаток сборочного времени, а не действующая поломка. Доказательство — прогнать ту же проверку, что гоняет продукт, и увидеть ноль расхождений и SUCCESS.
MACHINE_DOWN при живой ноде. Не «нода выключена». Сначала сверить часы по всем нодам, потом сеть: узел выпал из связности кластера, а не из питания.
NIC_DOWN на неподключённых портах. Вендорский фон: чекер проверяет UP/DOWN/BONDED, а NOTMANAGED пропускает. Порт без кабеля стоит DOWN — событие поднимается каждый цикл.
Совпадение по времени — не цепочка. Прежде чем писать «A из-за B», найти эмиттера каждого события (grep -rn "<EVENTTYPE>" /opt/ampli/plugins) либо помечать вывод как гипотезу.

ignore — не лечение. Он переводит событие в HANDLED_MANUAL, причину не убирает и через цикл чекера событие вернётся. Применять в двух случаях: снять шум на ограниченное время или закрыть заведомо историческое событие с occurrences = 1. В отчёте формулировать честно: «погашено штатным ignore, вернётся через ~N минут, причина не устранена».

9. Мини-чек-лист ежедневного обхода

Все LIVE — по строке: тип, severity, узел, возраст, что значит.
События за 24 часа — какие типы повторяются и с какой периодичностью.
Статусы машин и расхождения модель↔система по nic[].
Периодические задачи: последний прогон coldstorage.*, dss.*, internal.* → SUCCESS.
Последние FAILED: action, finished, error_text.
Аптайм нод: события «каждые N часов» при up 11 days — интервал чекера, а не ребуты.

Источники

Quantum, Manage Events (дата доступа 2026-11-07): severity, фильтры, дедупликация, Download Report, Ignore.
Наша практика (обезличено): read-only разборы ленты событий на кластерах из трёх нод, версия 7.3.1.
Обновлено: 2026-11-07.