UNF86

Инфраструктурный портал и мониторинг — план работ

7 min read

Инфраструктурный портал и мониторинг — план работ

Идея

Построить единый инфраструктурный портал на базе dash.unf86.org, который совмещает:

  • оперативную сводку по 3 серверам: assist, assistai, api;
  • мониторинг ресурсов и истории метрик;
  • кликабельную карту инфраструктуры: серверы, диски, разделы, сервисы, контейнеры, порты, reverse proxy, публичные домены, цепочки маршрутизации;
  • инвентарные данные по VPS: провайдер, тариф, дата/остаток оплаты, назначение, заметки.

Целевой принцип ролей

  • dash.unf86.org — единый операционный web-портал / front door.
  • Grafana — исторические графики, drill-down и аналитика.
  • VictoriaMetrics — backend-хранилище метрик.
  • node_exporter на каждом сервере — источник host-метрик.
  • Ручные inventory-данные храним отдельно и подмешиваем в портал как metadata.

Лист задач

1. Зафиксировать целевую архитектуру мониторинга и портала

Цель: формально утвердить роли dash, Grafana, VictoriaMetrics, node_exporter, inventory-слоя.

Подзадачи:

  • 1.1. Зафиксировать, что центр мониторинга — assist.
  • 1.2. Зафиксировать набор monitored nodes: assist, assistai, api.
  • 1.3. Утвердить роли компонентов (dash / Grafana / VictoriaMetrics).
  • 1.4. Зафиксировать отказ от SSH-pull как основной модели мониторинга.
  • 1.5. Определить MVP и следующие очереди.

2. Спроектировать модель данных инфраструктурного портала

Цель: понять, какие сущности есть в системе и какие из них live-discovered, а какие ручные.

Подзадачи:

  • 2.1. Определить сущности: сервер, диск, раздел, сервис, контейнер, порт, route, домен, volume, сеть, VPS metadata.
  • 2.2. Разделить поля на автоматически собираемые и ручные inventory-поля.
  • 2.3. Определить связи между сущностями.
  • 2.4. Определить формат хранения inventory (yaml/json/md).
  • 2.5. Продумать canonical naming для всех хостов и сущностей.

3. Собрать и оформить инвентарный слой по VPS и серверам

Цель: создать ручной источник правды по провайдерам, тарифам, оплате и назначению серверов.

Подзадачи:

  • 3.1. Создать inventory-файл по всем 3 серверам.
  • 3.2. Для каждого сервера собрать: provider, hostname, public IP, роль, тариф, оплачено до, остаток дней, заметки.
  • 3.3. Добавить поля ownership / account / billing note при необходимости.
  • 3.4. Определить процесс обновления inventory без бардака.

4. Развернуть системный стек метрик

Цель: получить нормальный, не самописный мониторинг ресурсов по хостам.

Подзадачи:

  • 4.1. Установить node_exporter на assist, assistai, api.
  • 4.2. Развернуть VictoriaMetrics на assist.
  • 4.3. Развернуть Grafana на assist.
  • 4.4. Настроить сбор метрик со всех 3 нод.
  • 4.5. Настроить базовый retention и storage policy.
  • 4.6. Проверить, что мониторинг не конфликтует с текущими сервисами.

5. Определить набор метрик, статусов и графиков

Цель: убрать мусор и оставить реально полезный контур наблюдаемости.

Подзадачи:

  • 5.1. Зафиксировать обязательные host-метрики: CPU, Load, RAM, Swap, Disk, Inodes, Uptime, Network, Disk I/O.
  • 5.2. Зафиксировать сервисные статусы: systemd units, docker containers, restart/problem states.
  • 5.3. Зафиксировать, что показывается как single-value summary в dash.
  • 5.4. Зафиксировать, что уходит в исторические графики в Grafana.
  • 5.5. Определить warning/critical thresholds.

6. Спроектировать UX и IA единого портала

Цель: не сделать кашу, а развести summary / drill-down / topology.

Подзадачи:

  • 6.1. Определить верхнеуровневые разделы портала.
  • 6.2. Спроектировать fleet overview по 3 серверам.
  • 6.3. Спроектировать server detail page.
  • 6.4. Спроектировать topology / route view.
  • 6.5. Определить, как и куда встраиваются ссылки/врезки из Grafana.
  • 6.6. Определить, где живут алерты верхнего уровня.

7. Построить auto-discovery слоя инфраструктуры

Цель: автоматически собирать актуальную структуру хостов и маршрутов.

Подзадачи:

  • 7.1. Собрать discovery по systemd services.
  • 7.2. Собрать discovery по docker containers, binds, volumes, networks.
  • 7.3. Собрать discovery по listening ports.
  • 7.4. Собрать discovery по Caddy routes и TLS.
  • 7.5. Собрать discovery по disks / partitions / mountpoints.
  • 7.6. Нормализовать данные в единый JSON-слой для фронтенда.

8. Реализовать topology graph / layered map

Цель: графически показать связи от публичного домена до сервиса/контейнера и хранилища.

Подзадачи:

  • 8.1. Определить формат визуализации (SVG/HTML/Cytoscape/другой JS graph).
  • 8.2. Реализовать fleet topology view.
  • 8.3. Реализовать server topology view.
  • 8.4. Реализовать route chain view: domain -> caddy -> localhost port -> service/container.
  • 8.5. Реализовать кликабельные sidebar/detail panels.
  • 8.6. Добавить фильтры по серверу / домену / сервису / контейнеру.

9. Переделать dash.unf86.org под роль front door

Цель: превратить существующий дашборд из локальной панели в единый инфраструктурный портал.

Подзадачи:

  • 9.1. Упростить и почистить текущие вкладки.
  • 9.2. Добавить summary по 3 серверам.
  • 9.3. Добавить links / embeds в Grafana.
  • 9.4. Добавить inventory-метаданные в UI.
  • 9.5. Добавить topology-раздел.
  • 9.6. Убрать неактуальные и слабополезные блоки.

10. Настроить проверку, эксплуатацию и поддержание актуальности

Цель: чтобы портал не умер через неделю из-за рассинхрона.

Подзадачи:

  • 10.1. Определить, какие данные обновляются автоматически, а какие руками.
  • 10.2. Описать процедуру добавления нового сервера / домена / контейнера.
  • 10.3. Настроить health-check самих компонентов мониторинга.
  • 10.4. Продумать резервирование/бэкапы конфигов и inventory.
  • 10.5. Завести checklist актуализации после инфраструктурных изменений.

Укрупнённый план реализации

Этап A — Архитектура и inventory

Сначала зафиксировать целевую архитектуру, роли компонентов, сущности и inventory-слой. Это убирает хаос в голове и не даёт строить UI без модели данных.

Этап B — Базовый мониторинговый контур

Поднять node_exporter + VictoriaMetrics + Grafana, собрать базовые метрики со всех 3 серверов и получить рабочую observability-базу.

Этап C — Discovery и нормализация структуры

Собрать автоматически структуру серверов, дисков, сервисов, контейнеров, портов и proxy routes; свести в единый нормализованный слой данных.

Этап D — Новый dash как front door

Перестроить dash.unf86.org в портал: summary по 3 серверам, инвентарь, topology, переходы в Grafana.

Этап E — Полировка и эксплуатация

Завести процедуры обновления inventory, правила поддержки актуальности, health-check самого стека и документацию по эксплуатации.

Детализация по этапам

Этап A — Архитектура и inventory

Результат этапа: есть согласованная модель системы и ручной inventory-файл.

Задачи этапа:

  • Утвердить центр мониторинга: assist.
  • Утвердить состав monitored nodes: assist, assistai, api.
  • Зафиксировать роли dash / Grafana / VictoriaMetrics.
  • Выбрать схему хранения inventory.
  • Создать файл инвентаря с обязательными полями.

Артефакты:

  • архитектурная заметка;
  • inventory-файл;
  • список сущностей и связей.

Этап B — Базовый мониторинговый контур

Результат этапа: метрики 3 серверов видны в Grafana через VictoriaMetrics.

Задачи этапа:

  • Установить exporters на все 3 ноды.
  • Поднять TSDB и UI на assist.
  • Настроить источники данных и dashboards.
  • Проверить загрузку, порты, безопасность и влияние на текущие сервисы.

Артефакты:

  • работающий стек мониторинга;
  • доступная Grafana;
  • первичный dashboard по серверам.

Этап C — Discovery и нормализация структуры

Результат этапа: есть автоматически собираемый JSON/структура для серверного topology-view.

Задачи этапа:

  • Сбор systemd / docker / ports / caddy / disks.
  • Нормализация имен и связей.
  • Построение модели цепочек domain -> proxy -> port -> service/container.
  • Сшивка live discovery и ручного inventory.

Артефакты:

  • JSON-схема данных;
  • endpoint(ы) для topology/discovery;
  • тестовый набор данных по всем 3 серверам.

Этап D — Новый dash как front door

Результат этапа: dash.unf86.org становится единым порталом входа.

Задачи этапа:

  • Редизайн структуры вкладок.
  • Добавление fleet overview.
  • Добавление server detail и topology view.
  • Добавление ссылок / iframe / deep-link в Grafana.
  • Чистка старых слабополезных блоков.

Артефакты:

  • обновлённый UI dash;
  • summary по 3 серверам;
  • кликабельная карта слоёв.

Этап E — Полировка и эксплуатация

Результат этапа: система не только работает, но и поддерживается без ручного хаоса.

Задачи этапа:

  • Добавить эксплуатационные инструкции.
  • Описать процесс актуализации inventory.
  • Продумать backup/restore конфигов.
  • Добавить self-monitoring для monitoring stack.
  • Сформировать checklist для изменений инфраструктуры.

Артефакты:

  • ops-note / runbook;
  • checklist актуализации;
  • правила сопровождения.

Предлагаемый MVP

MVP-1

  • Inventory по 3 серверам
  • node_exporter на всех нодах
  • VictoriaMetrics + Grafana на assist
  • Host dashboards по CPU/RAM/Disk/Network

MVP-2

  • Fleet overview в dash
  • Summary-карточки по 3 серверам
  • Ссылки на соответствующие dashboards Grafana

MVP-3

  • Auto-discovery containers / services / ports / Caddy routes
  • Server detail pages
  • Топология и route chains

MVP-4

  • Полный кликабельный infrastructure atlas
  • Inventory + live discovery + drill-down

Открытые вопросы

  • Где именно хранить inventory: отдельный .yaml рядом с hermes-dash или note-ориентированно в Vault + экспорт?
  • Какой домен использовать для Grafana?
  • Нужен ли public access к Grafana или только через auth / VPN / basic auth?
  • Нужен ли отдельный слой для billing/reminders по оплате VPS?
  • Нужна ли визуализация volumes и bind mounts уже в MVP или это вторая очередь?

Следующий логичный шаг

  1. Завести inventory-структуру по серверам в Vault.
  2. Утвердить формат хранения metadata.
  3. После этого переходить к развёртыванию monitoring stack.

Backlinks