# Архитектура 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. Сценарий AI-агента

1. На домашнем сервере создаётся отдельный пользователь, например `ai-agent-dev`, без root-доступа.
2. Рабочие каталоги и разрешённые команды ограничиваются Unix-правами, группами, контейнером или sandbox-профилем.
3. В Server Monitor Manager создаётся Link от сервера с AI-агентом к домашнему серверу только для адреса домашнего узла и SSH-порта.
4. AI-агент использует собственный 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.