85 lines
7.1 KiB
Markdown
85 lines
7.1 KiB
Markdown
# Архитектура Server Monitor Manager
|
||
|
||
## 1. Компоненты
|
||
|
||
Для первого тестирования используется переходный режим **SSH pull**: Windows-клиент вызывает на сервере ограниченный forced-command и получает snapshot. Постоянный агент и control node ниже описывают следующий этап после проверки UX на трёх серверах.
|
||
|
||
### Desktop client
|
||
|
||
Windows-first приложение на WinUI 3. Оно показывает состояние всех серверов, графики, события, терминалы и связи. Клиент хранит пользовательские секреты в Windows Credential Locker/DPAPI и не передаёт приватные SSH-ключи control node.
|
||
|
||
### Control node
|
||
|
||
Небольшой координационный сервис, который можно установить на одном из своих серверов. Он принимает исходящие mTLS-соединения агентов, хранит инвентарь, короткую историю метрик, правила оповещений, команды и аудит. Для одного пользователя достаточно SQLite; внешний PostgreSQL не является требованием MVP.
|
||
|
||
Control node не становится обязательным маршрутизатором трафика между серверами. При возможности соединение идёт напрямую. Relay добавляется позже как явно включаемый режим для узлов за NAT.
|
||
|
||
### Linux agent
|
||
|
||
Один статически собранный бинарный файл. Агент читает `/proc`, `/sys` и разрешённые systemd-состояния, агрегирует метрики локально и отправляет их наружу. По умолчанию он запускается непривилегированным пользователем и не открывает входящих портов.
|
||
|
||
Привилегированные операции выносятся в маленький отдельный helper с белым списком действий. Агент мониторинга не должен постоянно иметь `root` или `CAP_NET_ADMIN`.
|
||
|
||
## 2. Потоки данных
|
||
|
||
### Метрики
|
||
|
||
Агент отправляет компактный snapshot каждые 5–15 секунд. Control node сохраняет сырые точки недолго, затем выполняет downsampling. При потере сети агент держит ограниченный дисковый буфер и не заполняет диск.
|
||
|
||
Минимальный snapshot:
|
||
|
||
- load average и использование CPU;
|
||
- использованная/доступная память и swap;
|
||
- заполнение и inode выбранных файловых систем;
|
||
- сетевые счётчики интерфейсов;
|
||
- uptime, температура при наличии датчиков;
|
||
- состояние выбранных systemd units;
|
||
- только метаданные процессов, разрешённые политикой.
|
||
|
||
### Команды и терминал
|
||
|
||
Произвольная shell-команда не является обычной командой агента. Для безопасных операций используются типизированные действия: перезапуск разрешённой службы, чтение журнала с ограничением, получение списка процессов. Полный терминал создаётся как отдельная SSH-сессия от desktop client.
|
||
|
||
### Links между серверами
|
||
|
||
Link — отдельный ресурс, а не свойство группы серверов:
|
||
|
||
```text
|
||
Draft -> Connecting -> Active -> Disconnecting -> Disabled
|
||
\-> Failed
|
||
Active -> Expired -> Disabled
|
||
```
|
||
|
||
Каждый Link содержит:
|
||
|
||
- source и destination;
|
||
- разрешённые IP/CIDR и TCP/UDP-порты;
|
||
- режим `manual` или TTL;
|
||
- WireGuard peer identities;
|
||
- владельца, причину и запись аудита;
|
||
- фактическое состояние обоих узлов.
|
||
|
||
Control node передаёт каждому узлу только его часть конфигурации. Приватный WireGuard-ключ никогда не покидает узел. `Disconnect` удаляет peer и маршруты с обеих сторон; при недоступности одного узла команда остаётся обязательной и применяется при его следующем подключении.
|
||
|
||
## 3. Сценарий Hermes
|
||
|
||
1. На домашнем сервере создаётся отдельный пользователь, например `hermes-dev`, без root-доступа.
|
||
2. Рабочие каталоги и разрешённые команды ограничиваются Unix-правами, группами, контейнером или sandbox-профилем.
|
||
3. В Server Monitor Manager создаётся Link от сервера с Hermes к домашнему серверу только для адреса домашнего узла и SSH-порта.
|
||
4. Hermes использует собственный SSH-ключ или короткоживущий SSH-сертификат.
|
||
5. Пользователь нажимает `Connect`; после разработки — `Disconnect`.
|
||
6. Отключение Link разрывает сетевую достижимость, а отзыв SSH-сертификата/ключа остаётся вторым независимым барьером.
|
||
|
||
## 4. Режимы развёртывания
|
||
|
||
- **Single owner:** один control node, один пользователь, SQLite. Основной MVP.
|
||
- **Family/team:** несколько пользователей, роли и подтверждения. После MVP.
|
||
- **Direct local:** desktop подключается к агентам внутри одной сети без публичного control node. Возможен позже, но использует тот же протокол идентичности.
|
||
|
||
## 5. Целевые ограничения MVP
|
||
|
||
- агент: один бинарник, idle RAM до 50 МБ, CPU в простое менее 1%;
|
||
- control node: запуск без Kubernetes и обязательного Docker;
|
||
- отсутствие открытого agent API в интернет;
|
||
- работа при 50–100 серверах на одном небольшом control node;
|
||
- деградация без потери управления: графики могут иметь пробелы, но команды не выполняются повторно без idempotency key.
|