Мониторинг

Rediacc предоставляет встроенные команды мониторинга для проверки состояния машин, запущенных контейнеров, сервисов, статуса репозиториев и системной диагностики.

Состояние машины

Получение полного отчёта о состоянии машины:

rdc machine health --name server-1

Отчёт включает:

• System: время работы, использование диска, использование хранилища
• Контейнеры: количество запущенных, исправных и неисправных
• Хранилище: состояние SMART
• Проблемы: обнаруженные проблемы

Используйте --output json для машиночитаемого вывода.

Список контейнеров

Просмотр всех запущенных контейнеров во всех репозиториях на машине:

rdc machine containers --name server-1

Столбец	Описание
Name	Имя контейнера
Status	Время работы или причина остановки
State	Запущен, остановлен и т.д.
Health	Исправен, неисправен, нет
CPU	Процент использования CPU
Memory	Использование памяти / лимит
Repository	Репозиторий, которому принадлежит контейнер

Параметры:

• --health-check, выполнить активные проверки состояния контейнеров
• --output json, машиночитаемый вывод в формате JSON

JSON-вывод включает полные сведения о контейнере (labels, port_mappings, image, id), а также repository (разрешённое имя), repository_guid (исходный GUID), domain и autoRoute.

Список сервисов

Просмотр systemd-сервисов, связанных с Rediacc, на машине:

rdc machine services --name server-1

Столбец	Описание
Name	Имя сервиса
State	Активен, неактивен, сбой
Sub-state	Запущен, остановлен и т.д.
Restarts	Количество перезапусков
Memory	Использование памяти сервисом
Repository	Связанный репозиторий

Параметры:

• --stability-check, пометить нестабильные сервисы (сбой, более 3 перезапусков, автоматический перезапуск)
• --output json, машиночитаемый вывод в формате JSON

JSON-вывод включает полные сведения о сервисе с repository (разрешённое имя) и repository_guid (исходный GUID).

Список репозиториев

Просмотр репозиториев на машине с подробной статистикой:

rdc machine repos --name server-1

Столбец	Описание
Name	Имя репозитория
Size	Размер образа диска
Mount	Смонтирован или размонтирован
Docker	Docker daemon запущен или остановлен
Containers	Количество контейнеров
Disk Usage	Фактическое использование диска внутри репозитория
Modified	Время последнего изменения

Параметры:

• --search <text>, фильтрация по имени или пути монтирования
• --output json, машиночитаемый вывод в формате JSON

JSON-вывод включает name (разрешённое) и guid (исходный GUID), а также содержит для каждого репозитория вложенные массивы containers (с domain, autoRoute, repository/repository_guid) и services.

Состояние хранилища

Проверка фрагментации BTRFS и совместного использования reflink во всех репозиториях на машине:

rdc machine query --name server-1 --storage-health

Столбец	Описание
Quota	Максимальный размер репозитория (потолок роста, установленный при создании или изменением размера/автоувеличением)
Allocated	Сколько разреженный образ фактически занимает в пуле в данный момент
Unique	Фактические уникальные данные, принадлежащие только этому репозиторию
Shared	Блоки данных, повторно используемые между репозиториями через BTRFS reflinks (бесплатные копии)
Reclaimable	Разница между выделенным и использованным, которую repo trim может вернуть в пул. Показывает - для размонтированных репозиториев
Discards	Пропускает ли зашифрованный том discards (on для любого репозитория, смонтированного текущей версией)
Divergence	Процент образа, уникального для данного репозитория, а не разделяемого (выше = больше освобождается при удалении)
Frag	Количество экстентов на ГБ в copy-on-write образе (только информационно)

Quota и Allocated намеренно различаются: репозиторий с квотой 20 ГБ, хранящий 6 ГБ данных, обходится пулу только тем, что он выделил. Пул поэтому может суммарно обещать больше квоты, чем физически имеет, а столбец Reclaimable показывает, какая доля выделения каждого репозитория уже не используется и может быть освобождена операцией trim.

Ниже таблицы сводка пула отображает уровень заполнения хранилища и сколько пространства удерживают снимки резервных копий:

Pool: 265.4 GB used, 95.2 GB free (73.6% full)
Backup snapshots pin 2.1 GB (1 active, 0 stale; stale ones are removed by 'rdc machine prune')

Пока выполняется резервное копирование, его снимок продолжает ссылаться на каждый блок, разделяемый с живыми репозиториями, поэтому удаления и операции trim освобождают меньше пространства в пуле до завершения этого цикла резервного копирования и удаления снимка. Устаревшие снимки от прерванных резервных копий автоматически удаляются обслуживающей службой хранилища в течение нескольких минут.

В сводке отображается общая экономия от BTRFS reflinks:

14 repos, 224.3 GB virtual size
Unique data: 323.7 MB | Shared: 224.0 GB | Efficiency: 99.9%

• Виртуальный размер: сумма размеров образов всех репозиториев. Именно так выглядят репозитории, однако блоки, используемые совместно через reflinks, учитываются дважды.
• Уникальные данные: фактически потреблённое хранилище данными репозитория, существующими только в одном репозитории. Именно это будет освобождено при удалении репозитория.
• Общие данные: данные, повторно используемые между репозиториями через BTRFS reflinks. При форке репозитория создаются reflink-копии, которые совместно используют блоки до тех пор, пока одна из сторон не запишет новые данные, после чего блоки расходятся.
• Эффективность: процент данных, повторно используемых через reflinks. Чем выше, тем лучше. Машина со множеством форков одного родительского репозитория будет показывать эффективность близкую к 100%.

Столбец Frag информационный. Он считает экстенты файла copy-on-write образа, а не файлы, которые читает ваше приложение внутри него, поэтому он высокий при обычных нагрузках со случайной записью (базы данных, слои контейнеров) и не предсказывает производительность чтения на SSD-хранилище. Rediacc намеренно не предлагает команду дефрагментации: btrfs filesystem defragment разрывает reflinks форков и снапшотов, что на почти заполненном пуле может резко увеличить использование пространства, тогда как бенчмарки не показывают ощутимого прироста скорости чтения. Полные измерения и обоснование см. в статье Ваш показатель фрагментации выглядит пугающе. Я замерил, чего он стоит..

Сканирование выполняется параллельно и занимает 5-15 секунд в зависимости от количества и размера репозиториев. Если --storage-health не указан, после вывода запроса появляется однострочная подсказка в качестве напоминания.

Скраб BTRFS

Rediacc автоматически планирует еженедельный скраб BTRFS на каждой машине. Скраб читает каждый блок данных в хранилище, проверяет контрольные суммы и сообщает о любом повреждении. Это позволяет обнаружить скрытое повреждение данных (битрот) до того, как оно распространится на резервные копии и форки.

Скраб выполняется каждое воскресенье в 02:00 местного времени (часовой пояс машины) со случайной задержкой до 1 часа. Он работает с наименьшим приоритетом ввода-вывода (ionice idle, nice 19), поэтому не мешает работающим сервисам. На машинах с SSD ожидайте приблизительно 8 минут на каждые 100 ГБ хранилища.

Таймер скраба устанавливается автоматически при первом запуске демона после обновления renet. Когда политика скраба изменится в будущей версии renet, она обновляется сама при следующем запуске демона без каких-либо действий со стороны пользователя.

Статус скраба

Результат последнего скраба сохраняется за пределами тома BTRFS (в /var/lib/rediacc/scrub-last-result.json), чтобы он оставался доступным для чтения, даже если у тома есть проблемы. Вывод rdc machine query --system включает поле scrub_status:

"scrub_status": {
  "last_run_human": "3 days ago",
  "status": "ok",
  "total_errors": 0,
  "uncorrectable": 0,
  "duration_seconds": 312
}

Статус	Значение
ok	Последний скраб завершён без ошибок
never_run	Скраб ещё не выполнялся (таймер только что установлен)
overdue	Последний скраб был более 14 дней назад
errors_found	Скраб обнаружил несоответствия контрольных сумм (проверьте счётчики total_errors и uncorrectable)
failed	Процесс скраба завершился с ненулевым кодом

Если uncorrectable больше нуля, повреждённые блоки нельзя восстановить автоматически (однодисковый BTRFS не имеет избыточной копии). Восстановите затронутый репозиторий из последней резервной копии.

Ручной скраб

Для немедленного запуска скраба (например, после перебоя питания или миграции диска):

rdc term connect -m server-1 -c "sudo renet maintenance scrub --datastore /mnt/rediacc"

Результат сохраняется в тот же JSON-файл и сразу становится видимым при следующем вызове rdc machine query --system.

Статус Vault

Получение полного обзора машины, включая информацию о развёртывании:

rdc machine vault-status --name server-1

Предоставляет:

• Имя хоста и время работы
• Использование памяти, диска и хранилища
• Общее количество репозиториев, количество смонтированных и запущенных Docker
• Подробную информацию по каждому репозиторию

Используйте --output json для машиночитаемого вывода.

Проверка соединения

Только для облачного адаптера. При использовании локального адаптера используйте rdc term connect -m server-1 -c "hostname" для проверки подключения.

Проверка SSH-подключения к машине:

rdc machine test-connection --ip 203.0.113.50 --user deploy

Отчёт включает:

• Статус соединения (успешно/неудачно)
• Используемый метод аутентификации
• Конфигурацию SSH-ключа
• Статус развёртывания публичного ключа
• Запись в Known hosts

Параметры:

• --port <number>, SSH-порт (по умолчанию: 22)
• --save -m server-1, сохранить проверенный ключ хоста в конфигурации машины

Диагностика (doctor)

Запуск полной диагностической проверки среды Rediacc:

rdc doctor

Категория	Проверки
Окружение	Версия Node.js, версия CLI, режим SEA, установка Go, доступность Docker
Renet	Расположение бинарного файла, версия, CRIU, rsync, встроенные ресурсы SEA
Конфигурация	Активная конфигурация, адаптер, машины, SSH-ключ
Виртуализация	Проверяет, может ли система запускать локальные виртуальные машины (rdc ops)

Каждая проверка сообщает OK, Предупреждение или Ошибка. Используйте это как первый шаг при устранении любых неполадок.

Коды выхода: 0 = всё пройдено, 1 = предупреждения, 2 = ошибки.

Проверки готовности сервисов

В процессе repo up renet ожидает, пока HTTP-сервисы начнут принимать соединения, и лишь после этого объявляет их готовыми. Ожидание учитывает состояние проверки здоровья:

• Контейнеры, которые Docker сообщает как healthy, принимаются сразу, TCP-опрос не выполняется.
• Контейнеры, находящиеся в пределах start_period своей проверки состояния, записывают информационную запись, а не предупреждение; прокси продолжает попытки подключения до их готовности.
• Compose-сервисы без запущенного контейнера (например, скрытые за неактивным профилем) пропускаются.
• Все остальные сервисы опрашиваются по TCP не более 15 секунд (задайте REDIACC_READINESS_TIMEOUT в секундах, чтобы изменить это значение).

Если определить проверку состояния Docker для медленно запускающихся сервисов, renet получит авторитетный сигнал о готовности и устранит лишние записи опроса из вывода деплоя.