Что такое Zabbix
Централизованная система мониторинга с архитектурой сервер-агент, собирает метрики и уведомляет о проблемах.
Современная IT-инфраструктура — это сотни серверов, сетевое оборудование, базы данных и микросервисы. Удерживать всё под контролем вручную невозможно. Когда один сервис падает, а второй перегружен, без автоматизированной системы мониторинга вы узнаете о проблеме слишком поздно. Zabbix — это корпоративное решение с открытым кодом, которое собирает метрики со всей инфраструктуры, проверяет их по правилам и уведомляет команду при отклонениях. По данным SkillStat, Zabbix указан в 321 активных IT-вакансиях, что составляет 4.6% текущего среза.
Zabbix — централизованная система мониторинга (ЦСМ) с архитектурой «сервер-агент». Она собирает метрики с хостов, хранит их в базе данных и проверяет на соответствие пороговым значениям (триггерам). При срабатывании триггера система отправляет уведомления или запускает скрипты.
Zabbix подходит для мониторинга серверов, сетевого оборудования, баз данных и веб-приложений. Инструмент поддерживает прокси для работы в изолированных сетях, автообнаружение и гибкие сценарии эскалации. Это один из ключевых навыков для DevOps и SRE-инженеров в московском IT-срезе.
Централизованная система мониторинга с архитектурой сервер-агент, собирает метрики и уведомляет о проблемах.
Хосты, элементы данных, триггеры, действия, шаблоны, прокси — основа для работы с системой.
Один из главных инструментов для DevOps и SRE в московском IT-срезе, особенно востребован при импортозамещении.
Представьте, что вы — диспетчер на крупном заводе. В цехе сотни станков, каждый издаёт свой звук, мигает лампочками. Вы не можете уследить за всеми одновременно. Zabbix — это ваш умный пульт: он подключается к каждому станку, считывает показатели температуры, вибрации, скорости и показывает на едином экране. Если что-то выходит за норму — пульт пищит и показывает, где именно проблема.
Zabbix работает по архитектуре «сервер-агент». Сервер собирает данные с агентов, установленных на наблюдаемых хостах, хранит их в базе данных (PostgreSQL, MySQL, TimescaleDB) и проверяет на соответствие пороговым значениям — триггерам. При срабатывании триггера система генерирует событие и выполняет действие: отправляет уведомление в Telegram, Slack, email или запускает скрипт автоматического восстановления.
Не система логирования — он не предназначен для анализа логов (для этого есть Grafana + Loki или ELK). Не APM-решение — не отслеживает производительность кода на уровне транзакций (для этого нужны Datadog, New Relic). Не облачный SaaS «из коробки» — хотя есть Zabbix Cloud, основная модель — self-hosted. Не замена ping-утилите — Zabbix делает гораздо больше: собирает метрики, строит графики, хранит историю.
Рабочая цепочка Zabbix начинается с объекта наблюдения и заканчивается действием команды. Система получает значение, сохраняет историю, сравнивает его с правилом, создаёт событие, выбирает получателей и помогает инженеру понять, что именно изменилось в инфраструктуре. В хорошей настройке каждое звено объяснимо: зачем собирается показатель, почему выбран интервал, кто владеет узлом, какой текст увидит ответственный человек и что произойдёт после подтверждения проблемы. Без такой цепочки Zabbix остаётся установленной системой, но не становится рабочим мониторингом.
Узел и интерфейс
Сначала описывают сервер, устройство или сервис: адрес, группу, интерфейс, теги и способ связи с сервером Zabbix или прокси.
Элемент данных
Элемент данных определяет, какое значение получать: нагрузку процессора, свободное место, ответ сайта, SNMP-показатель, состояние службы или пользовательскую проверку.
История и тренды
Zabbix хранит сырые значения и агрегированные тренды. От срока хранения зависит размер базы, скорость анализа и возможность смотреть проблему задним числом.
Триггер
Триггер описывает условие проблемы: значение выше порога, нет данных, сервис недоступен, показатель изменился слишком резко или вернулся в норму.
Событие и действие
После срабатывания появляется событие, а действие решает, кому отправить уведомление, какую эскалацию применить и какой скрипт можно запустить.
Разбор причины
Инженер смотрит последние данные, очередь проверок, историю события, связанные узлы, время изменения и соседние сигналы, чтобы не лечить симптом вместо причины.
Zabbix переносится между ролями: Системный администратор, DevOps-инженер, Сетевой инженер. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Системный администратор держит 84.7% вакансий по навыку.
Ещё 7 ролей используют Zabbix
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
Zabbix ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
Установить Zabbix-агент
Установите пакет zabbix-agent2 и настройте подключение к серверу.
apt install zabbix-agent2
systemctl start zabbix-agent2
systemctl enable zabbix-agent2 Проверить сбор метрик
Используйте zabbix_get для проверки, что агент возвращает данные.
zabbix_get -s 192.168.1.101 -p 10050 -k "system.cpu.load[all,avg1]" Добавить хост через веб-интерфейс
Создайте хост с IP-адресом и портом агента, привяжите шаблон.
Data collection → Hosts → Create host Настроить триггер
Создайте триггер на превышение загрузки CPU > 90%.
Data collection → Hosts → Triggers → Create trigger Отправить уведомление в Telegram
Настройте медиатип Telegram и действие для отправки уведомления.
Alerts → Media types → Telegram
Alerts → Actions → Trigger actions → Create action Проверить лог агента
Просмотрите лог агента для диагностики проблем подключения.
tail -f /var/log/zabbix/zabbix_agent2.log Создание десятков триггеров на один хост без шаблонов ведёт к хаосу в настройках и лавине уведомлений. Используйте шаблоны и групповые привязки.
Уведомления только одному человеку. Если он не ответил — проблема остаётся незамеченной. Настройте цепочку эскалации с разными уровнями серьёзности.
Хардкод значений порогов в каждом триггере затрудняет изменение. Выносите настройки в макросы: {$CPU_WARN}, {$DISK_CRIT}.
Потеря базы данных Zabbix означает потерю всей истории и конфигурации. Делайте регулярные дампы БД и экспорт шаблонов в XML.
Агенты без пароля, открытый порт сервера в интернет, пароль по умолчанию — частые уязвимости. Всегда включайте TLS для агентов и HTTPS для веб-интерфейса.
Zabbix — одна из самых популярных систем мониторинга в корпоративном сегменте. Она востребована в legacy-инфраструктуре, государственных организациях и компаниях, где важна безопасность данных и работа в изолированных сетях. Навык Zabbix входит в топ-5 требований для DevOps и SRE-инженеров в московском IT-срезе. Тренд на импортозамещение и усложнение инфраструктуры делает Zabbix одним из ключевых инструментов для карьеры в IT.
Zabbix востребован там, где инструмент реально ускоряет повторяемые задачи команды, а не существует отдельной теорией.
Спрос держится дольше, когда навык нужен не эпизодически, а как часть ежедневного цикла разработки, проверки или доставки.
Zabbix чаще ищут там, где процесс уже стандартизирован и без этого инструмента команда теряет скорость и предсказуемость.
Zabbix формирует устойчивый спрос внутри своего рабочего сегмента.
Zabbix сохраняет устойчивый прикладной спрос на рынке: 321 активных вакансий, #46 по рынку, 4.6% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
#46 по рынку • 4.6% IT-вакансий
-68 вакансий и -14% к предыдущему месяцу.
Zabbix-специалисты: от — до — в зависимости от региона. SRE и DevOps с Zabbix + Kubernetes + Ansible — топ по ставкам в московском IT-срезе.
75 вакансий с зарплатой в расширенной зарплатной выборке
Коридор появится, когда по грейдам наберётся достаточная выборка.
Senior - основной уровень рынка (58%)
Zabbix редко живёт изолированно: чаще всего рынок видит его рядом с Linux, Grafana, Python. Самая плотная связка сейчас - Linux: оба навыка встречаются вместе в 72% вакансий.
Главная связка: Linux • 72% вакансий. Показываем общерыночные связки Zabbix: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
навыки, которые рынок чаще всего видит рядом в одной вакансии
не базовый минимум, а более сильные комбинации стека
Сейчас на рынке 20 активных junior-вакансий с Zabbix. Это 8.4% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
8.4% всех вакансий по навыку • Senior / Junior 6.9x
Вход возможен, но рынок ждёт уже собранный стартовый стек.
Медианная вакансия с Zabbix ожидает около 18 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
навыки из junior-вакансий, где встречается Zabbix
Умение работать с Zabbix добавляет ценность вашему резюме. Вот что это означает на каждом уровне владения и что стоит показать.
Выбор зависит от того, что именно нужно контролировать: классическую инфраструктуру, метрики приложений или просто панели. Zabbix особенно силён там, где нужен готовый контур с шаблонами, SNMP, триггерами и оповещениями. Prometheus чаще берут для метрик сервисов, а Grafana — для визуализации.
Мониторинг инфраструктуры, сетевых устройств, шаблонов и оповещений.
Подходит для серверов, сетей, SNMP и сред с готовым эксплуатационным контуром.
Требует аккуратной настройки базы, шаблонов и правил.
Сбор и запрос метрик приложений и инфраструктуры.
Уместен в Kubernetes и системах, где сервисы сами отдают метрики.
Не заменяет весь классический мониторинг и управление уведомлениями.
Панели и единая точка просмотра разных источников.
Нужна, когда команда собирает данные из Prometheus, SQL или Zabbix.
Без источника данных и правил реакции сама по себе мониторинг не решает.
Проверки доступности и состояния сервисов.
Встречается в старых инфраструктурах и простых сценариях контроля.
Сложнее масштабируется как современный контур метрик и панелей.
Zabbix — универсальный инструмент, но его применение зависит от вашей роли в IT.
Мониторинг парка из 200 серверов в нескольких дата-центрах. Установка прокси в каждом ЦОДе, шаблоны для Linux/Windows, автообнаружение, триггеры на загрузку CPU,...
Мониторинг микросервисной архитектуры на Kubernetes. Агент на нодах кластера, веб-мониторинг health-эндпоинтов, триггеры на 5xx ошибки, время ответа > 500ms,...
Обеспечение SLA 99.9% для платёжного шлюза. Комплексные триггеры с зависимостями, эскалация: дежурный → тимлид → руководитель. Дашборды для отчётов по доступности,...
Мониторинг тестовых стендов после деплоя. Веб-мониторинг критических сценариев (логин, поиск, заказ). Сбор метрик производительности до и после релиза, сравнение...
Zabbix заметен в 1 направлениях рынка с долей выше 5%.
В Zabbix важны сервер, агент, прокси, SNMP, элементы данных, триггеры и шаблоны. Рабочий уровень появляется тогда, когда человек умеет связать сигнал, оповещение и действие команды.
Нужно понимать роли сервера Zabbix, прокси, агента, базы данных и веб-интерфейса, а также влияние сети и задержек на сбор данных.
Шаблоны уменьшают ручную работу: один набор элементов, триггеров, графиков и правил можно применить к группе похожих узлов.
Низкоуровневое обнаружение помогает автоматически находить диски, интерфейсы, файловые системы и другие повторяющиеся сущности.
Важны условия срабатывания, подавление шума, расписания, эскалации, получатели и понятный текст события.
Нужно следить за очередью проверок, производительностью базы, сроком хранения истории, прокси, синхронизацией времени и резервным копированием.
API, webhooks и внешние системы помогают связывать Zabbix с чатами, сервис-деском, CMDB и внутренними операционными процессами.
Когда понятна внутренняя цепочка сигнала, легче сравнить Zabbix с соседними инструментами наблюдаемости. Zabbix часто сравнивают с другими инструментами наблюдаемости, но задачи у них разные. Zabbix даёт готовый мониторинг узлов, шаблоны и оповещения. Prometheus силён в метриках приложений. Grafana чаще отвечает за панели. Nagios остаётся классическим вариантом проверок доступности. Выбор обычно зависит от команды и объекта наблюдения. Если нужно быстро покрыть серверы и сетевое оборудование, Zabbix часто закрывает задачу целиком. Если всё строится вокруг метрик приложения и облачной наблюдаемости, Zabbix становится частью стека.
Готовый мониторинг инфраструктуры с узлами, шаблонами, агентами, SNMP, триггерами, событиями, оповещениями и веб-интерфейсом.
Система метрик, где сервисы обычно отдают показатели сами, а сервер опрашивает их и строит запросы через PromQL.
Платформа визуализации и панелей, которая чаще работает поверх Prometheus, Loki, Elasticsearch, SQL-баз и других источников.
Классический подход к проверкам доступности и состояниям сервисов, часто встречается в старых эксплуатационных контурах.
При проблеме в Zabbix смотрят не только на красный статус. Нужны хост, элемент данных, последние значения, выражение триггера, история события, очередь проверок и доступность агента или SNMP. Дальше важно отделить три случая: источник правда сломан, мониторинг не смог снять данные или правило шумит само по себе. Для этого проверяют ключ элемента, порог триггера, шаблон, зависимость и текст уведомления. Так инженер быстрее находит причину и не уходит в ложный след.
Показывает последние значения, время получения, единицы измерения и то, продолжает ли источник отдавать данные.
Нужно читать выражение срабатывания: порог, окно времени, функцию nodata, усреднение и условие восстановления.
Очередь проверок показывает, не отстаёт ли сам мониторинг. Если очередь растёт, проблема может быть в Zabbix, прокси или базе.
Проверяют доступность агента, ключ элемента, права, community, версию SNMP, timeout и сетевой путь до устройства.
История событий помогает понять, проблема новая, повторяющаяся, подавленная окном обслуживания или связанная с другой аварией.
После изменения шаблона, макроса или группы узлов нужно проверить, не изменились ли правила для слишком большого числа объектов.
Zabbix можно развернуть через Docker Compose — это удобно для тестовых и продуктивных сред. Полный стек включает сервер, веб-интерфейс, базу данных и агент.
Основной компонент, собирает данные с агентов, хранит в БД и проверяет триггеры. Использует образ zabbix/zabbix-server-pgsql.
Веб-панель для настройки хостов, шаблонов, триггеров и просмотра дашбордов. Использует образ zabbix/zabbix-web-apache-pgsql.
PostgreSQL 15 с отдельным томом для данных. Хранит историю метрик, конфигурацию и события.
Демон на наблюдаемом хосте для сбора метрик. Использует host network mode для доступа к локальным интерфейсам.
Том alertscripts — для кастомных скриптов уведомлений. Том pgdata — для персистентности базы данных.
Используйте отдельный сервер PostgreSQL с репликацией, настройте резервное копирование томов и ограничьте доступ к порту 10051 через firewall.
Группируйте хосты по типу (Linux, Windows), проекту и критичности. Назначайте хостам несколько групп для гибкого управления правами доступа.
Привязывайте шаблоны на уровне группы, а не отдельного хоста. Кастомизируйте через макросы: {$CPU_WARN}, {$DISK_CRIT}.
Экспортируйте шаблоны в XML и храните в Git. Это позволяет отслеживать изменения и откатывать конфигурацию.
Определите глобальные макросы для общих порогов ({$SNMP_COMMUNITY}) и храните чувствительные данные в макросах уровня хоста или шаблона.
Используйте уровни: Information, Warning, Average, High, Disaster. Настройте эскалацию: дежурный → старший инженер → руководитель.
Если упала БД — не шуметь про приложение. Используйте зависимости триггеров, чтобы избежать лавины уведомлений.
Настройте политику хранения: 90 дней для истории, 365 дней для трендов. Это предотвращает рост базы данных и замедление сервера.
Используйте внутренние шаблоны для проверки производительности сервера, очереди данных и доступности базы данных.
Установите сложный пароль для пользователя Admin и отключите стандартного гостя в настройках веб-интерфейса.
Настройте сертификат или reverse proxy (Nginx, Apache) для шифрования трафика между браузером и веб-интерфейсом.
Ограничьте доступ к порту 10051 (сервер) правилами firewall — только с доверенных IP-адресов.
Включите аутентификацию через LDAP/AD для корпоративных пользователей, чтобы не хранить учётные записи в Zabbix.
Используйте TLS для шифрования трафика между агентом и сервером (параметры TLSConnect, TLSAccept).
Назначайте каждому агенту уникальный pre-shared key (PSK) и храните их в макросах, а не в конфигурационных файлах.
Запускайте агент с минимальными привилегиями (не root), используйте AllowRoot=0 и ограничьте список команд через UserParameter.
Не используйте root-пользователя СУБД для Zabbix — создайте отдельного. Настройте SSL/TLS для соединения между сервером и базой данных.
Следите за CVE на официальном сайте Zabbix. Обновляйте до последней стабильной версии (текущий LTS — 7.0).
Перспективы Zabbix завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Zabbix развивает поддержку eBPF для сбора метрик производительности ядра без установки агента — это расширит возможности мониторинга без модификации хостов.
Ожидается внедрение алгоритмов ML для автоматического обнаружения аномалий в метриках, что снизит количество ложных тревог и упростит настройку порогов.
В разработке находится Zabbix 7.0 LTS, который принесёт улучшенную производительность, новую архитектуру алертинга и более глубокую интеграцию с облачными платформами.
Разверните Zabbix 6.4 Server + PostgreSQL + Web + Agent через Docker Compose. Настройте первый хост и триггер на загрузку CPU > 90%. Критерий готовности: дашборд показывает загрузку CPU с графика.
Установите Zabbix-агент на сервер PostgreSQL и привяжите шаблон PostgreSQL by Zabbix agent. Настройте триггер на replication lag > 10 секунд. Критерий: при остановке реплики приходит уведомление в Telegram.
Разверните Zabbix-прокси на отдельном сервере в изолированной сети. Настройте передачу данных на центральный сервер. Добавьте 3 хоста через прокси. Критерий: все метрики доступны на центральном дашборде.
Создайте веб-сценарий для проверки логина, поиска и оформления заказа. Настройте триггер на время загрузки > 2 секунд. Критерий: при падении скорости отправляется уведомление с кодом ошибки.
Чтобы освоить Zabbix с нуля, нужно пройти путь от базовых понятий до продуктивной эксплуатации. Вот пошаговый план обучения.
Понять принципы мониторинга
Изучите, что такое метрики, пороговые значения, алерты, pull vs push, архитектура агент-сервер.
Развернуть тестовый Zabbix
Установите Zabbix через Docker Compose или пакеты на Ubuntu. Зайдите в веб-интерфейс и добавьте первый хост.
Настройка шаблонов и триггеров
Привяжите шаблон «Linux by Zabbix agent active», настройте триггер на загрузку CPU > 90%. Создайте действие для отправки уведомления в Telegram.
Прокси, макросы, безопасность
Разверните Zabbix-прокси для удалённой сети, настройте макросы и включите TLS для шифрования агентов.
Соответствие — доля тем навыка, которые охватывает программа курса
Начинать лучше с небольшой лаборатории: сервер Zabbix, один Linux-хост с агентом и один полезный триггер. Цель первого шага не в красивой панели, а в понятном сигнале: что измеряем, когда считаем это проблемой и кто получит уведомление. После первого срабатывания специально разберите отказ. Выключите агент, измените порог, создайте окно обслуживания и посмотрите историю события. Потом проверьте, понятно ли сообщение дежурному, где смотреть очередь проверок и можно ли быстро найти причину дальше. Такой сценарий учит Zabbix лучше, чем простое хождение по меню.
Разверните сервер Zabbix с базой и веб-интерфейсом, проверьте вход, время системы и доступность основных процессов.
Подключите Linux-сервер через агент, убедитесь, что последние данные обновляются и значения выглядят правдоподобно.
Используйте готовый шаблон, затем посмотрите, какие элементы данных и триггеры он добавил.
Сделайте простое правило по месту на диске, доступности службы или отсутствию данных и проверьте восстановление.
Настройте канал уведомлений и убедитесь, что сообщение понятно человеку, который будет реагировать ночью.
Zabbix — это система мониторинга IT-инфраструктуры. Она собирает показатели с серверов, сетевого оборудования и приложений, проверяет их по заданным правилам и уведомляет администратора, если что-то идёт не так. Это как центральный пульт диспетчера, который показывает состояние всех устройств.
Zabbix использует pull + push через траппер, хранит данные в SQL (PostgreSQL/MySQL) и поддерживает прокси для изолированных сетей. Prometheus — это pull-модель с TSDB, оптимизированная для Kubernetes и микросервисов. Zabbix лучше подходит для корпоративной legacy-инфраструктуры, Prometheus — для cloud-native.
Zabbix — полноценная система мониторинга: собирает, хранит, проверяет и уведомляет. Grafana — это инструмент визуализации, который требует внешнего источника данных (Prometheus, InfluxDB, Zabbix). Grafana не собирает метрики, только показывает дашборды.
Добавьте репозиторий Zabbix 7.0 LTS (текущий Long-Term Support), установите пакеты zabbix-server-pgsql, zabbix-frontend-php, zabbix-agent2, создайте базу данных PostgreSQL и настройте конфигурацию. После этого запустите сервисы и войдите в веб-интерфейс по адресу http://your-server-ip. Актуальные инструкции — на официальной странице zabbix.com/download.
Это лёгкий демон, который устанавливается на наблюдаемый хост и собирает метрики: загрузку CPU, использование памяти, состояние дисков, работающие процессы. Агент передаёт данные на сервер Zabbix по протоколу Zabbix.
Это промежуточный сервер, который собирает данные с агентов в удалённых сетях и передаёт их на основной сервер Zabbix. Прокси снижает нагрузку на центральный сервер и позволяет мониторить хосты в изолированных сегментах.
Это конкретная метрика, которую Zabbix собирает с хоста. Например: system.cpu.load[all,avg1] — средняя загрузка CPU за минуту, vfs.fs.size[/,pfree] — свободное место на корневом разделе.
Это логическое условие, которое определяет проблемную ситуацию. Например, если загрузка CPU превышает 90% в течение 5 минут, триггер срабатывает и генерирует событие PROBLEM.
В веб-интерфейсе перейдите в Alerts → Media types → Telegram. Укажите токен бота и ID чата. Затем создайте действие в Alerts → Actions → Trigger actions, привязав его к нужному триггеру и медиатипу Telegram.
Это механизм push-отправки данных в Zabbix. Скрипт или приложение может отправить метрику на сервер Zabbix через протокол траппер (по порту 10051). Это полезно для кастомных метрик, которые не собираются агентом.
Установите Zabbix-агент на хост Docker и используйте UserParameter для вызова docker stats или используйте шаблон Docker by Zabbix agent из репозитория шаблонов.
Это набор предопределённых элементов данных, триггеров, графиков и действий для типовой сущности. Например, шаблон «Linux by Zabbix agent active» содержит метрики и триггеры для мониторинга Linux-сервера.
Перейдите в Data collection → Templates → Create template. Добавьте в него элементы данных, триггеры и графики. Затем экспортируйте шаблон в XML и сохраните в Git для версионирования.
Это переменная, которая подставляет значение в шаблонах и триггерах. Например, макрос {$CPU_WARN} может содержать порог 90. Макросы бывают глобальные, на уровне шаблона и на уровне хоста.
Это проверка HTTP/HTTPS-эндпоинтов: Zabbix отправляет запрос на URL, проверяет код ответа (например, 200), время загрузки и содержимое страницы. Веб-сценарии могут имитировать действия пользователя.
В каждой изолированной сети устанавливается Zabbix-прокси, который собирает данные с агентов и периодически передаёт их на центральный сервер. Это позволяет мониторить хосты без прямого доступа к серверу.
PostgreSQL (рекомендуемая), MySQL, TimescaleDB (как экстеншн для PostgreSQL). TimescaleDB повышает производительность при работе с временными рядами и позволяет хранить больше данных.
Это автоматический поиск новых хостов, сервисов, файловых систем или сетевых интерфейсов. Zabbix сканирует сеть и добавляет новые объекты в мониторинг без ручного ввода.
Используйте внутренние метрики Zabbix: количество событий в секунду, очередь данных (values), время выполнения запросов к БД. Для больших инсталляций настройте TimescaleDB и используйте прокси для распределения нагрузки.
Да, Zabbix-агент доступен для Windows (Zabbix agent 2). Он собирает метрики: загрузка CPU, память, диски, процессы, события. Также есть WMI-мониторинг и шаблоны для Windows.
Официальный репозиторий шаблонов: https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates. Также шаблоны публикуются на GitHub и в сообществе Zabbix Share.
Зайдите в веб-интерфейс (Admin/пароль). Создайте хост для самого сервера, привяжите шаблон Linux by Zabbix agent active. Настройте медиатип Telegram и действие для отправки уведомлений.
Используйте готовый шаблон PostgreSQL by Zabbix agent. Он собирает метрики: количество соединений, размер БД, replication lag, количество транзакций. Требуется установить агент на сервер БД.
Проверьте лог агента (/var/log/zabbix/zabbix_agent2.log). Убедитесь, что в конфиге указан правильный Server и ServerActive. Проверьте файрвол на порты 10050 и 10051. Используйте zabbix_get для диагностики с сервера.
В зависимости от нагрузки и конфигурации — до 10 000 хостов при использовании TimescaleDB и прокси. Для масштабирования используются HA-кластер и несколько прокси.