Серверы (временные ряды нагрузки)

Обзор — что делает этот экран

Инфраструктура ▸ Серверы (/infra/servers) показывает среднюю нагрузку · ЦП · память для каждого зарегистрированного узла-сервера во временном разрезе. Если экран Состояние фиксирует «состояние каждого узла прямо сейчас» с помощью живых проверок, то экран «Серверы» сосредоточен на том, «как нагрузка менялась за последние часы или дни». Это переработанная реализация monitoring/part из stats-design (load_average · cpu_usage · memory_usage).

По одной карточке на узел:

• Три кольцевых индикатора (текущие значения Load / CPU / MEM) — серьёзность ситуации с первого взгляда.
• SVG-спарклайн — предпросмотр недавнего тренда.
• [Подробнее] → комбинированный линейный график ECharts (CPU% · MEM% по левой оси + Load по правой оси) и таблица статистики (текущее / среднее / минимум / максимум + время пика).

Метрики берутся из унаследованной таблицы server_status (только чтение). Построитель ServerMetricService сужает запрос до недавнего окна seq (избегая медленного полного сканирования) и применяет 20-секундный кэш. Сетка карточек поддерживает перетаскивание для изменения порядка + masonry и обновляется автоматически по опросу каждые 30 секунд.

Таблицу server_status наполняет Node-коллектор run_report.js, работающий вне Laravel с циклом примерно в 5 минут. Поэтому разрешение временной оси составляет около 5 минут, а экран обновляется опросом (а не push-уведомлениями в реальном времени / Reverb).

Когда использовать

• Чтобы сравнить по всему парку, какие серверы несут устойчиво высокую нагрузку.
• Чтобы пересмотреть точки перегиба кривых нагрузки / ЦП / памяти вокруг момента, когда произошёл инцидент или сработало оповещение (время пика также показывается).
• Чтобы проверить тренд использования памяти или насыщение ЦП после развёртывания или всплеска трафика.
• Как последующее расследование, когда Оповещения срабатывают по условиям средней нагрузки или свободного места на диске — подтвердите проблемный узел по временному ряду.

Живой мониторинг сессий (с индикаторами служб nginx/php/mysql) находится на экране Состояние, графики байтов/пакетов сетевого ввода-вывода — в разделе Трафик, а состояние дисков и RAID — в разделе Хранилище и RAID.

Компоновка

Верхняя панель KPI

Рассчитывается методом ServerMetricService::kpi().

Переключатель range

Выбирает окно отображения (число точек окна seq). Выбор сохраняется в localStorage (infr:range:infra-servers) и сохраняется между визитами.

range преобразуется в «последние N циклов сбора» (а не в абсолютный интервал времени). При цикле в 5 минут 24h ≈ 288 точкам. Узел, который сообщает данные нечасто, при том же range может показать более короткое фактическое окно — подпись окна внизу сообщает реальный интервал в виде 24h/6h/45m/2d.

Карточка узла

┌──────────────────────────────────────────────┐
│ label · alias · IP           online / last Nm │   ← шапка (подпись обогащена из infr_instance)
│  ( Load )   ( CPU )   ( MEM )                    │   ← 3 кольцевых индикатора (текущее значение)
│  ▁▂▅▇▅▃  спарклайн (SVG polyline)               │
│  peak · disk 42% · net out 1,234   [Подробнее] │   ← подвал
└──────────────────────────────────────────────┘

Рамка карточки и индикаторы окрашиваются тоном порога; общая серьёзность карточки определяется худшей из трёх метрик.

Кольцо Load нормировано так, что оно заполняется при нагрузке 8 (LOAD_FULL=8) — в соответствии с порогом warn. На машине с большим числом ядер нагрузка 8 не обязательно опасна, поэтому всегда считывайте также абсолютное значение из числа в центре кольца.

Развёрнутые подробности (ECharts + статистика)

Нажатие [Подробнее] увеличивает карточку по вертикали; masonry автоматически перестраивает раскладку под изменившуюся высоту.

• Комбинированный линейный график: CPU% · MEM% (левая ось 0–100%) + Load (правая ось, автоматический масштаб). По оси x — последняя метка времени каждого цикла сбора (HH:MM), с всплывающей подсказкой по перекрестью.
• Таблица статистики: для каждой метрики (нагрузка / ЦП / память) — текущее · среднее · минимум · максимум, а также когда произошёл пик (например, «пик 12 мин назад»).

Как пользоваться

1. Откройте /infra/servers → карточки узлов выстраиваются по возрастанию алиаса.
2. Выберите окно наблюдения переключателем range (1h/6h/24h/3d). Запрос выполняется заново немедленно, независимо от опроса.
3. Откройте график временного ряда и таблицу статистики для узла кнопкой [Подробнее].
4. Наведите курсор на график, чтобы по перекрестью считать значения CPU/MEM/Load в конкретный момент времени.
5. Перетащите карточки, чтобы поднять наверх узлы, за которыми следите чаще всего, — порядок сохраняется в localStorage (infr:order:infra-servers).
6. Используйте кнопку полноэкранного режима в шапке, чтобы скрыть верхнюю навигацию и работать в режиме дашборда.

Экран автоматически обновляется каждые 30 секунд опросом /infra/servers/live (никаких действий не требуется). На этом экране нет действий записи или управления — он исключительно наблюдательный.

Опрашивающий фронтенд решает, нужно ли обновление, по дешёвому токену изменений rev (= последний seq в server_status). Пока не придёт новый цикл сбора, экран остаётся неизменным — это не «зависание», просто новых снимков ещё нет.

Источники данных

Источник — унаследованная таблица server_status (БД MAIN, схема «ключ-значение» через part, только чтение). Она напрямую интерпретирует соглашение о хранении, принятое в run_report.js.

Дисциплина запросов и формирования данных:

• Окно seq: SELECT DISTINCT seq ORDER BY seq DESC LIMIT N (сканирование по индексу) отбирает только последние N циклов сбора, после чего эти значения seq/part используются в запросе whereIn — поэтому даже таблица на 200 млн строк сканируется лишь в узком окне. Та же дисциплина, что и в OverviewService / HealthService.
• seq = идентификатор пакета снимка по всему парку. Ряды всегда упорядочены от прошлого к настоящему.
• Перенос пропущенных значений: если part отсутствует в каком-то цикле, переносится предыдущее значение (чтобы на графике не было разрывов).
• Решение о состоянии «в сети»: узел считается в сети, если loadavg присутствует в последних 2 циклах (один пропущенный цикл допускается). last_seen = метка времени последнего цикла, в котором был сообщён loadavg.
• 20-секундный кэш: Cache::remember("infr:srvmetric:v1:{points}", 20, …). Поэтому даже при 30-секундном опросе фактический запрос к БД выполняется не чаще одного раза в 20 секунд.
• Обогащение подписи/IP: алиас или имя хоста (в нижнем регистре) сопоставляется с name и ip_public/ip_private из раздела Инстансы (infr_instance), кэш 60 с. Незарегистрированные узлы отображают свой исходный алиас.

Регистрация и учётные данные коллектора run_report.js, наполняющего server_status, управляются в разделе Администрирование ▸ Коллекторы.

Доступ

• Экран только для чтения. Его может просматривать любой пользователь, прошедший аутентификацию консоли (infr.auth) (минимальный user_level для ролевой области «Инфраструктура» равен 1, то есть demo=1 и выше).
• Действий записи или управления нет — здесь отсутствуют кнопки блокировки или перезапуска.
• Порядок карточек и выбор range не сохраняются на сервере; они живут только в localStorage браузера (для каждого пользователя и каждого браузера).

Схема уровней: demo=1 · staff=5 · admin=10 (см. Уровни RBAC).

Диагностика и частые вопросы

Я вижу только «Нет метрик серверов.» В server_status нет свежего снимка. Проверьте, что коллектор run_report.js запущен и зарегистрирован в разделе Коллекторы. Также проверьте подключение к унаследованной БД (MAIN).

Узел отображается как не в сети. Это означает, что за последние 2 цикла сбора не было сообщено ни одного loadavg. Проверьте состояние выполнения run_report на этом узле, его часы (расхождение) и сеть. Относительная подпись last_seen подскажет, когда он сообщал данные в последний раз.

На карточке показан алиас (например, sol), а не понятное имя. Этот алиас не зарегистрирован в разделе Инстансы (infr_instance). Зарегистрируйте инстанс, и его name станет подписью, а в качестве IP будут показаны ip_public/ip_private.

Значок диска пуст. Этот узел не сообщил ни одного из df-data/df-/df-home в формате JSON {p,u,a}. Для подробного использования дисков и состояния RAID воспользуйтесь разделом Хранилище и RAID.

Кольцо Load всегда выглядит заполненным. Кольцо Load нормировано с потолком в нагрузку 8. На серверах с большим числом ядер нагрузка 8 может быть нормой, поэтому судите по абсолютному значению в центре кольца. Не делайте вывод об опасности только по порогам цветового тона (warn 8 / crit 16).

Опрос идёт каждые 30 с, но ничего не меняется. Либо (1) новый цикл сбора (~5 мин) ещё не наступил, либо (2) вы находитесь внутри окна 20-секундного кэша. Подтвердите реальные обновления через stamp, подпись окна и rev (последний seq).

Я задал range = 3d, но окно выглядит коротким. range означает «последние N циклов», поэтому у узла, который собирает данные редко, реальный интервал времени короткий. Нижняя подпись окна показывает фактический интервал (45m/6h/2d). Верхний предел числа точек — 1000.

Смежные материалы

• Состояние — живой статус и индикаторы служб (nginx/php/mysql) для тех же узлов.
• Хранилище и RAID — использование дисков, состояние RAID-контроллера, карта физических дисков.
• Трафик — временные ряды байтов/пакетов сетевого ввода-вывода.
• Оповещения — SMS/письма получателям по условиям средней нагрузки и свободного места на диске.
• Инстансы — источник обогащения алиас→подпись/IP (реестр активов).
• Коллекторы — реестр коллектора run_report, наполняющего server_status.