Зачем два стека
Мониторинг — это область с двумя индустриальными стандартами: Zabbix (классический, push-ориентированный) и Prometheus + Grafana (облачно-нативный, pull-модель). Я развернул оба для одной инфраструктуры — чтобы на практике понять разницу, а не по статьям. Мониторю реальный парк: облачный сервер в Москве, домашний гипервизор Proxmox VE и несколько виртуальных машин.
Стек первый: Zabbix + собственный дашборд на Vue/Nuxt
Поднял Zabbix 7.0 LTS с PostgreSQL в отдельном LXC-контейнере на Proxmox. Агенты собирают полные метрики со всех узлов — процессор, память, диски, сеть. Готовый веб-интерфейс Zabbix меня не устроил как витрина, поэтому я написал собственный дашборд на Vue 3 / Nuxt 3 — без сторонних UI-библиотек, с живыми графиками на чистом SVG. Ключевое решение — архитектура BFF (Backend-for-Frontend): браузер обращается только к моему Nuxt-серверу, а токен доступа к Zabbix живёт исключительно в серверном окружении и наружу не выходит. Сам Zabbix в интернет не выставлен.
Живое демо: johngorn.store
Стек второй: Prometheus + node_exporter + Grafana
Во втором контейнере — Prometheus, опрашивающий node_exporter на каждом узле, и Grafana поверх него. Принципиально другая модель: pull вместо push, запросы на языке PromQL, вся конфигурация — текстом (инфраструктура как код). Дашборды Grafana настроены через provisioning — декларативно, файлами, а не кликами.
Живое демо: grafana.johngorn.store
Связь облака и дома через WireGuard
Облачный сервер и домашняя лаборатория соединены через WireGuard — mesh-сеть из пяти узлов. Мониторинг облачного сервера идёт через зашифрованный туннель: агенты и экспортеры слушают только на VPN-интерфейсе и недоступны из интернета. Никаких открытых наружу портов мониторинга.
Самое интересное — безопасная публикация
Оба дашборда я хотел показывать открыто. Но публичный мониторинг — риск утечки карты инфраструктуры: внутренние IP, имена серверов, топология. Решал слоями.
Для Zabbix-дашборда сделал два режима: публичный (только роли узлов плюс метрики) и приватный по логину (реальные данные). Главное — фильтрация на уровне API, а не косметика в интерфейсе: неавторизованному запросу сервер физически не отдаёт внутренних адресов, их нет даже в сыром ответе.
Для Grafana задача оказалась хитрее. Анонимный доступ дал только на просмотр одного дашборда, без раздела Explore. Внутренние адреса замаскировал ролями на уровне сбора метрик (relabel в Prometheus — IP не попадает в хранилище вообще). А потом нашёл неочевидный канал утечки: через datasource-proxy Grafana аноним мог дотянуться до служебных эндпоинтов Prometheus, где видны реальные адреса. Закрыл их на уровне обратного прокси. Урок: обезличивание мониторинга — это не «спрятать один IP», а аудит всех каналов, через которые инфраструктура может проявиться.
Что в итоге
Две полноценные системы мониторинга одного парка, обе с живыми публичными демо и без утечки внутренних данных. По дороге — WireGuard, обратный прокси с Let’s Encrypt, systemd, контейнеризация, и понимание, чем pull-модель отличается от push не в теории, а на своих серверах.
Технологии: Zabbix 7.0, Prometheus, Grafana, node_exporter, Vue 3 / Nuxt 3, WireGuard, nginx, Let’s Encrypt, Proxmox VE, Docker.