Единая система мониторинга распределённой инфраструктуры: архитектура и масштабирование без единой точки отказа в 2026 году

Единая система мониторинга распределённой инфраструктуры в 2026 году собирается по одной из трёх схем: федерация Prometheus, прокси-серверы Zabbix или многоуровневая иерархия с централизованной агрегацией метрик. Выбор диктуют три параметра: количество площадок, качество каналов между ними и требуемая глубина детализации по каждой метрике.

Короткий ориентир. Одна-две площадки с устойчивым VPN: хватает центрального Prometheus с remote_write в долговременное хранилище. От пяти до двадцати площадок: нужна двухуровневая схема, где локальные серверы собирают данные, а наверх уходят только агрегаты через recording rules, плюс Zabbix proxy для сети и SNMP. Больше двадцати площадок или несколько регионов: Thanos, VictoriaMetrics или Grafana Mimir с дедупликацией, шардированием и мультитенантностью.

Ниже разобраны архитектура, отказоустойчивость, стратегии хранения, права доступа и масштабирование с конкретными конфигурациями, расчётами и проверками, которые можно повторить в своей инфраструктуре.

Почему распределённой инфраструктуре нужна единая система мониторинга

Инфраструктура растёт быстрее, чем процессы вокруг неё. Сначала есть один ЦОД со своим Prometheus, потом команда разработки поднимает кластер в облаке и ставит туда отдельную Grafana, затем присоединяется филиал с локальным железом, которое когда-то завели в Zabbix. Три контура работают параллельно, и цельной картины не видит никто.

Проблемы разрозненного мониторинга: слепые зоны и дублирование

Типовой сценарий: на основной площадке работает Prometheus с Grafana, в облаке живёт второй Prometheus, а удалённый офис покрыт Zabbix. У каждого контура свои пороги алертов, свои retention и свой дежурный. Инцидент начинается в 02:40, пользователи жалуются на медленный отклик API. Дежурный открывает три вкладки, вручную сопоставляет графики по времени, и только к 03:30 выясняется, что причина в деградации канала между площадками, а не в приложении. Обнаружение растягивается на 40-60 минут, восстановление занимает часы.

Дублирование данных стоит денег и внимания. Одна и та же метрика CPU собирается агентом на хосте и SNMP-поллером с коммутатора, значения расходятся, алерты срабатывают дважды. Разные системы хранения дают разную детализацию: в одном контуре история живёт 15 дней, в другом 90, и при разборе инцидента недельной давности половина графиков уже недоступна.

Слепые зоны появляются незаметно. Инвентаризация перед централизацией обычно показывает, что 5-15% хостов не в мониторинге вообще: стенды, тестовые кластеры, сетевые устройства, которые настраивал уволившийся инженер. Отдельная проблема - расхождение часов между площадками. Если NTP работает плохо, метки времени двух Prometheus расходятся на десятки секунд, и корреляция метрик при разборе инцидента становится ручной работой с калькулятором.

Что даёт централизованный мониторинг нескольких площадок

Единый контур наблюдения решает четыре задачи сразу.

• Сквозная корреляция. Метрики приложения, узла, сети и балансировщика лежат в одном хранилище с общей шкалой времени, поэтому зависимость видна на одном дашборде.
• Одно окно оповещений. Дедупликация и группировка в Alertmanager или Zabbix снижают шум: вместо 200 писем приходит одно уведомление с 30 затронутыми хостами.
• Единые политики хранения. Downsampling и retention настраиваются один раз для всех площадок, поэтому стоимость хранения предсказуема.
• Единая аутентификация. Доступ через LDAP или OAuth, персональные учётные записи и аудит действий вместо набора локальных паролей.

Практический эффект измерим. Среднее время обнаружения (MTTD) при централизованном сборе падает с часов до 2-5 минут для инфраструктурных сбоев. Диагностика сетевой деградации между площадками занимает минуты, если рядом на дашборде лежат `probe_duration_seconds` от blackbox_exporter и задержки RTT с маршрутизаторов. Планирование ёмкости перестаёт быть упражнением по сбору CSV из разных систем.

Какой инструмент взять за основу, зависит от масштаба и уже накопленного опыта команды. Подробное сравнение Zabbix, Prometheus, Nagios и Grafana по масштабируемости и стоимости владения помогает выбрать базу до того, как начнётся интеграция площадок.

Архитектурные подходы: федерация Prometheus, прокси Zabbix и иерархия серверов

Три подхода решают одну задачу разными средствами. Федерация Prometheus собирает агрегаты между серверами, Zabbix proxy переносит сбор данных ближе к объектам наблюдения, иерархия серверов с общим хранилищем даёт глобальный запрос и долговременную историю.

Федерация Prometheus: настройка и сценарии использования

Федерация использует штатный endpoint /federate, который отдаёт текущее состояние head-блока в текстовом формате Prometheus. Вышестоящий сервер работает как обычный скрейпер и забирает выборку по параметру match[]. Есть два режима.

Иерархическая федерация: центральный Prometheus раз в 60-120 секунд забирает с периферийных серверов только агрегированные ряды, заранее подготовленные recording rules. Это основной рабочий вариант.

Кросс-федерация: равноправные серверы в разных регионах обмениваются узкими наборами метрик, например статусами кластеров баз данных. Применяется редко, потому что легко получить циклические зависимости и дубли.

Пример задания федерации на центральном сервере:

scrape_configs:
  - job_name: federate-edge
    scrape_interval: 60s
    honor_labels: true
    metrics_path: /federate
    params:
      match[]:
        - '{__name__=~"job:node_cpu:rate5m|job:http_errors:ratio5m|up"}'
    static_configs:
      - targets: ['prom-edge-msk:9090', 'prom-edge-spb:9090']
    relabel_configs:
      - source_labels: [__address__]
        target_label: site

Ключевые ограничения, о которых узнают уже в продакшене. Федерация отдаёт только текущее содержимое head-блока, поэтому пропущенный скрейп означает потерянную точку без возможности дозагрузки. Через match[] уходит выборка по всем совпадениям, и запрос вида {__name__=~".+"} превращает центральный сервер в узкое место. Федерация не хранит долговременную историю и не занимается дедупликацией: если два источника отдают одинаковые ряды, они сложатся в базе дважды.

Рабочее правило: федерация годится для десятков метрик на площадку и интервала от 60 секунд, а не для тысяч сырых рядов каждые 15 секунд. Если нужен глобальный запрос по всей истории, вместо федерации ставят Thanos Query или Mimir.

Технику записи агрегатов через recording rules и визуализацию сводных дашбордов разбирает материал про мониторинг кластерной инфраструктуры с Prometheus и Grafana.

Прокси-серверы Zabbix для распределённых сетей

Zabbix proxy собирает данные на удалённой площадке и передаёт их на центральный сервер, поэтому между площадками идёт один сжатый поток вместо сотен соединений от агентов. Прокси хранит данные локально в собственной базе и переживает обрыв канала: накопленные значения уходят на сервер после восстановления связи.

Режимы работы различаются направлением соединения. Активный прокси сам подключается к серверу на порт 10051, забирает конфигурацию с частотой ProxyConfigFrequency и отправляет данные с частотой DataSenderFrequency. Пассивный прокси ждёт подключения сервера, поэтому подходит для площадок без исходящего доступа, но требует открытого порта извне.

Практика для двенадцати площадок: восемь прокси работают в активном режиме, четыре в пассивном там, где сеть за NAT и исходящие соединения запрещены политикой. Для площадок до 300-500 хостов хватает прокси с базой SQLite на SSD; при более высокой нагрузке переходят на MySQL или PostgreSQL, потому что запись в SQLite при тысячах новых значений в секунду упирается в блокировки файла.

Ограничения, которые лучше узнать до развёртывания:

• Прокси не запускает действия и эскалации. Оповещения формирует сервер, поэтому логика алертов остаётся централизованной.
• SNMP-трапы принимает только активный прокси.
• Проверки, которым нужны данные со всей инфраструктуры (внутренние метрики сервера, агрегаты zabbix[...]), на прокси не работают.
• Мажорная версия прокси должна совпадать с версией сервера, иначе прокси не подключится к обмену данными.

Прямое подключение агентов к серверу оставляют для площадок, где хостов меньше десяти и канал стабилен. Прокси оправдан при 30+ хостах на удалённой площадке, нестабильном канале или требовании не открывать порты в центральный ЦОД.

Иерархия серверов мониторинга и агрегация метрик

Иерархия разделяет роли: пограничный уровень собирает данные, промежуточный агрегирует, верхний отдаёт глобальный запрос и визуализацию. Границы уровней задают по сетевой топологии, чтобы между площадками ходил минимальный трафик.

Агрегация выполняется в двух точках. На уровне записи recording rules считают, например, среднюю загрузку CPU по всем узлам площадки каждые 5 минут. На уровне хранения downsampling снижает детализацию старых данных: в Thanos это уровни 5 минут и 1 час, которые строятся автоматически из сырых блоков.

Комбинированная схема встречается чаще всего: локальные Prometheus пишут через remote_write в центральный Thanos Receive, Zabbix proxy закрывает сеть, а Grafana работает с единым источником данных. Такой вариант даёт и детализацию на площадке, и глобальную историю.

Обеспечение отказоустойчивости: как избежать единой точки отказа

Мониторинг отказывает в тот момент, когда нужнее всего. Единая точка отказа есть на каждом уровне: сбор, хранение, визуализация, оповещение. Проверка простая: если выключение одного компонента приводит к потере данных или тишине в алертах, резервирование неполное.

Резервирование Prometheus и Zabbix: практические схемы

Для Prometheus базовый вариант - пара экземпляров с одинаковым scrape-конфигом. Оба скрейпят одни и те же цели, оба пишут в удалённое хранилище, различаясь меткой replica. Thanos Query при запросе дедуплицирует ряды по этой метке, поэтому двойных данных в выдаче нет. Второй сервер при этом не простаивает: он держит горячую копию TSDB и данные в head-блоке.

Тяжёлый вариант для крупных инсталляций - VictoriaMetrics Cluster с replicationFactor 2, где vminsert распределяет данные между vmstorage, а vmselect объединяет ответы. Потеря одной ноды хранилища не приводит к пробелам в метриках.

Оповещения резервируются кластером Alertmanager: два и три узла связываются по gossip-протоколу через параметры --cluster.listen-address и --cluster.peer, обмениваются списком активных алертов и подавлений (silences), а отправку уведомлений координируют, чтобы не дублировать письма. При падении одного узла второй продолжает работать с тем же состоянием.

Zabbix с версии 6.0 поддерживает штатный HA-кластер без внешних менеджеров. Несколько серверных узлов подключаются к одной базе данных, один из них активен, остальные в режиме standby и переключаются автоматически. В конфигурации сервера задаются два параметра:

HANodeName=zabbix-node-01
NodeAddress=10.20.0.11:10051

Все узлы используют одну и ту же базу: шардирование данных между серверами Zabbix не поддерживается, масштабирование идёт через прокси и мощность СУБД. Переключение на резервный узел занимает около минуты, состояние кластера видно в веб-интерфейсе в разделе с узлами HA.

Резервирование хранилища и сети

Для Zabbix критичен уровень базы данных. PostgreSQL с потоковой репликацией и автоматическим переключением через Patroni даёт вторую копию данных и предсказуемый failover. Синхронную репликацию включают осторожно: она повышает задержку записи, что при тысячах значений в секунду заметно сказывается на очереди сервера.

Для Prometheus роль резервного хранилища выполняет S3-совместимый бакет с версионированием объектов и репликацией в другой регион. Thanos Sidecar загружает туда блоки каждые 2 часа, поэтому потеря локального диска означает потерю максимум нескольких часов свежих данных, которые остались в head-блоке и WAL.

Сеть между площадками резервируется двумя независимыми провайдерами и проверяется активными пробами. blackbox_exporter с проверкой ICMP и TCP даёт метрику недоступности, а задержку и потери измеряют с обоих концов канала. Полезно отдельно отслеживать MTU: туннель с заниженным MTU ломает крупные пакеты и вызывает плавающие таймауты, которые выглядят как проблема приложения.

Если второго ЦОД нет, инфраструктуру мониторинга размещают в облаке: серверы под Thanos, Grafana и Alertmanager, объектное хранилище для блоков и базы данных удобно поднимать на облачной платформе Timeweb Cloud, где ресурсы меняются под рост числа активных серий без замены железа. Метрики самой системы хранения, включая latency, IOPS и заполнение, разбираются в материале про мониторинг систем хранения: метрики, алерты и регламентные работы.

Стратегии хранения и агрегации метрик

Объём данных считают до развёртывания, иначе диск заканчивается в самый неподходящий момент. Формула простая: число активных серий, делённое на интервал сбора, даёт поток сэмплов, который после сжатия превращается в гигабайты на диске.

Выбор между локальным и удалённым хранилищем

Локальный TSDB Prometheus хранит данные по умолчанию 15 дней, срок меняется флагом --storage.tsdb.retention.time. Один миллион активных серий при интервале 15 секунд даёт около 5 000 сэмплов в секунду, это примерно 1 ГБ сжатых блоков в сутки плюс WAL и незакрытые блоки. Тридцать дней истории на такой нагрузке требуют диска около 40-50 ГБ с запасом на компакцию, память сервера при этом измеряется гигабайтами: практическое правило - порядка 8 ГБ RAM на миллион активных серий.

Локальное хранилище удобно до тех пор, пока сервер один и запросы не выходят за пределы retention. Дальше нужен удалённый слой: Thanos с бакетом S3, VictoriaMetrics или Grafana Mimir. Общее хранилище снимает привязку данных к конкретному серверу, позволяет держать годы истории и отвечать на запросы по всем площадкам сразу.

Zabbix хранит данные иначе. Сырая история идёт в таблицы history, агрегированные часовые значения складываются в trends, которые занимают в разы меньше места. Практика: история 7-30 дней, тренды год и больше. Для растущих инсталляций таблицы history и trends партиционируют по времени, а старые партиции удаляют целиком вместо построчного housekeeping, который создаёт лишнюю нагрузку на диск.

Выбор стека под конкретный профиль нагрузки, включая расчёт retention и кардинальности, разобран в руководстве про выбор стека мониторинга в 2026 году.

Настройка retention и downsampling

Downsampling снижает детализацию старых данных без потери формы графика. Thanos строит два уровня агрегации: 5-минутный и часовой. Рабочая политика для инфраструктуры среднего размера выглядит так.

Важный нюанс Thanos: он не удаляет блоки из объектного хранилища самостоятельно. Срок хранения задаётся политикой жизненного цикла бакета (lifecycle policy) или настройками compaction, иначе история растёт бесконечно, а счёт за хранилище увеличивается каждый месяц.

В Zabbix аналог downsampling - таблицы trends, которые строятся для числовых элементов данных. Включение trends там, где они не нужны, увеличивает объём базы, а отключение ломает графики за длинный период. Проверяйте, что для критичных метрик trends собираются.

Разграничение прав доступа между командами

Единая система мониторинга часто становится местом, где все видят всё. Это создаёт лишний риск: изменение чужого дашборда, удаление источника данных, случайная правка порога алерта. Разграничение строят на уровне интерфейса и на уровне хранилища.

Настройка RBAC в Grafana и Zabbix

В Grafana базовая схема опирается на организации и папки. Каждая команда получает свою папку с дашбордами и роль: Viewer для чтения, Editor для правок, Admin для управления правами внутри папки. Аутентификацию подключают через LDAP, OAuth или SAML, а членство в командах синхронизируют с группами каталога, чтобы доступ не выдавали вручную. Отдельно проверяют права на источники данных: в открытой версии Grafana они не ограничиваются, поэтому изоляция между tenants через один и тот же источник данных не работает.

В Zabbix доступ строится на ролях и группах пользователей. Роль задаёт набор разрешений, группа определяет видимость: какие группы узлов, шаблоны и экраны доступны. Начиная с 6.0 группы можно ограничивать по тегам узлов, что удобно для схемы, где команда разработки видит только свои сервисы, помеченные тегом team:backend, а дежурная смена - всю инфраструктуру.

Рабочее разделение ролей выглядит так:

• NOC и дежурные: чтение всех узлов, управление проблемами, без правки шаблонов и элементов данных.
• DevOps-платформа: полный доступ к шаблонам, прокси и настройкам оповещений.
• Команды разработки: чтение своей группы узлов и своих дашбордов, запись в свои папки Grafana.
• Аудит и безопасность: только чтение плюс доступ к журналу действий.

Сервисные учётные записи и API-токены выпускают персонально под задачу, с ограниченным сроком жизни. Общий токен администратора в CI-пайплайне означает, что любая утечка даёт полный контроль над мониторингом.

Мультитенантность в Prometheus и Thanos

Prometheus не поддерживает мультитенантность из коробки: любой пользователь с доступом к API видит все метрики. Вариантов два.

Первый: Thanos с внешней меткой tenant и Query Frontend, который подставляет фильтр по арендатору в каждый запрос. Данные разных команд лежат в одном или разных бакетах, а доступ к API ограничивается на прокси-слое.

Второй: Grafana Mimir или Cortex, где tenant задаётся заголовком X-Scope-OrgID при записи и чтении. Модель встроенная, но появляется отдельная система с собственным хранением и эксплуатацией.

Изоляция через отдельные экземпляры Prometheus и отдельные бакеты проще в понимании, дороже в обслуживании и оправдана для команд с требованиями по регуляторике. Для большинства инфраструктур достаточно разграничения на уровне Grafana и Zabbix плюс единая аутентификация.

Масштабирование системы мониторинга при росте инфраструктуры

Масштабирование начинается не с железа, а с решения о том, что именно будет собираться. Кардинальность метрик растёт быстрее числа хостов: метка с идентификатором запроса превращает 10 000 серий в 10 000 000, и никакой кластер это не переварит.

Шардирование Prometheus и масштабирование Zabbix

Прометей масштабируют двумя способами. Функциональное шардирование делит цели по смыслу: отдельные серверы под Kubernetes, под базы данных, под сеть. Горизонтальное шардирование распределяет цели по хешу имени. Функциональный вариант предпочтительнее, потому что границы отказа совпадают с границами ответственности команд, а запросы остаются осмысленными.

Типовой рост выглядит так: до 300 хостов хватает одного сервера Prometheus, при 800-1000 хостах добавляют второй сервер и настраивают федерацию для сбора агрегатов, дальше переходят на Thanos Receive или Mimir и делят поток по тенантам. Глобальные запросы в такой схеме выполняет верхний слой, а периферийные серверы отвечают только за свой сегмент.

Zabbix масштабируется добавлением прокси: каждый новый прокси снимает часть нагрузки по сбору данных с сервера. Сервер и база данных остаются центральными точками, поэтому их ресурсы планируют с запасом. Ориентир для расчёта: сервер на 8 vCPU и 32 ГБ RAM с PostgreSQL на NVMe обрабатывает порядка 3 000 новых значений в секунду, дальше узким местом становится диск базы, а не CPU.

Планирование ёмкости и прогнозирование роста

Система мониторинга обязана наблюдать за собой. Без этих метрик рост упирается в тихую деградацию: растёт очередь, увеличивается время скрейпа, увеличивается лаг записи.

Прогноз строят по линейному тренду числа серий или NVPS за 30-60 дней и добавляют запас 30-40%. Дисковое пространство под TSDB планируют с учётом сжатия старых блоков: свежие блоки занимают больше места из-за неполной компакции, поэтому расчёт по среднему размеру блока завышает оценку свободного места.

Типичные ошибки и как их избежать

Большая часть проблем в распределённом мониторинге связана не с выбором инструмента, а с настройками, которые работали на одном сервере и перестали работать на десяти.

Ошибки при настройке федерации Prometheus

Самая дорогая ошибка - собирать через федерацию все метрики. Конфигурация с match[] вида {__name__=~".+"} или пустым списком приводит к тому, что центральный сервер тянет миллионы рядов раз в 15 секунд, скрейпы уходят в таймаут, а данные приходят с пропусками. Федерация рассчитана на выборку, а не на копирование.

Вторая ошибка - отсутствие recording rules. Без них агрегировать нечего, и через match[] приходится выбирать сырые ряды. Третья - неверный honor_labels: при значении false конфликтующие метки переименовываются с префиксом exported_, и дашборды, рассчитанные на исходные метки, показывают пустые графики.

Ещё один антипаттерн - федерация с интервалом 15 секунд на медленном канале между площадками. Скрейп не успевает завершиться, и в истории появляются дыры, которые потом не восстановить. Ставьте 60-120 секунд и отдельный сервер под федерацию, чтобы нагрузка от периферии не влияла на оперативные скрейпы.

Проблемы с Zabbix proxy и правами доступа

Частая ошибка - использовать прокси для проверок, которые он не выполняет, и потом искать причину в шаблоне. Проверки, зависящие от данных всего сервера, и действия с эскалациями остаются на центральном узле. Второй источник проблем - версии: прокси предыдущей мажорной ветки не подключится к обновлённому серверу, а рассинхронизация проявляется как отсутствие данных с площадки.

Пассивный прокси за NAT требует проброса порта и часто приводит к тому, что площадка оказывается без мониторинга после смены адресации. Активный режим надёжнее, но требует исходящего доступа на порт сервера.

С правами доступа типичны две крайности. Все пользователи входят под учётной записью из группы Zabbix Administrators, что делает аудит бессмысленным. Либо, наоборот, права выдают точечно и вручную, и через полгода никто не помнит, почему у пяти инженеров есть доступ к продакшен-шаблонам. Решение одно: роли через группы каталога, регулярный пересмотр состава групп и журнал действий, который реально читают.

Отдельная задача - шум в оповещениях. Сгруппировать входящие алерты и получить краткую сводку с вероятной причиной помогает ИИ: AiTunnel даёт единый API к более чем 200 моделям, включая GPT, Gemini и Claude, с оплатой в рублях и управлением бюджетами по ключам, поэтому разбор потока уведомлений можно автоматизировать без отдельной инфраструктуры под каждую модель.

Чек-лист внедрения и проверки системы мониторинга

Последовательность шагов, которая покрывает и первый запуск, и проверку уже работающего контура.

1. Соберите инвентарь: площадки, облака, число хостов, сетевые устройства, каналы связи между ними.
2. Определите, какие метрики нужны глобально, а какие достаточно смотреть локально. Это решение определяет архитектуру сильнее, чем выбор инструмента.
3. Выберите схему: один Prometheus с удалённым хранилищем, федерация, прокси Zabbix или иерархия с Thanos и Mimir.
4. Настройте сбор и проверьте кардинальность: число активных серий на сервер, метрики с неограниченными значениями меток, дублирующиеся источники.
5. Ограничьте retention для сырых данных и включите downsampling для агрегатов.
6. Разнесите хранение и сбор: удалённое объектное хранилище или реплика базы данных на отдельной площадке.
7. Настройте оповещения с группировкой и дедупликацией, проверьте доставку в дежурный канал.
8. Разграничьте доступ по группам и ролям, подключите единую аутентификацию, выдайте API-токены под задачи.
9. Включите мониторинг самой системы: head_series, scrape_duration, лаг remote_write, очередь Zabbix, рост партиций.
10. Проверьте отказоустойчивость на практике: остановите один сервер Prometheus и убедитесь, что данные продолжают поступать, а алерты приходят; выключите активный узел Zabbix и зафиксируйте время переключения; разорвите канал между площадками и проверьте буферизацию.
11. Проверьте восстановление базы данных и загрузку блоков из объектного хранилища в тестовом контуре.
12. Задокументируйте конфигурацию и держите её в Git: scrape-конфиги, recording rules, шаблоны Zabbix, дашборды как JSON.

Дальше система живёт по циклу: раз в квартал пересматривают пороги и права, раз в полгода проверяют прогноз роста диска и числа серий, раз в год тестируют полное восстановление. Такая дисциплина даёт предсказуемый результат: инциденты обнаруживаются за минуты, история доступна за годы, а добавление новой площадки занимает часы, а не недели.