Zabbix и мониторинг доступности: в чём разница
Зачем вообще нужен мониторинг
Прежде чем сравнивать инструменты, полезно зафиксировать, какую задачу решает мониторинг. Сайт или сервис работает, когда совпадают несколько условий: сервер отвечает, приложение не падает, сеть до него доходит, сертификат действует, DNS резолвится. Сбой любого звена — и для пользователя «сайт не работает».
Мониторинг — это способ узнавать о таких сбоях не от пользователя, а от системы, причём заранее или хотя бы быстро. Но здесь есть важное различие, которое часто упускают: смотреть на систему можно изнутри и снаружи, и это две разные задачи с разными инструментами.
- Изнутри — это глаза администратора: что с CPU, памятью, дисками, процессами, сетью внутри дата-центра. Это внутренний мониторинг инфраструктуры.
- Снаружи — это глаза пользователя: открывается ли сайт, отдаёт ли он нужный код, действует ли сертификат, резолвится ли домен из интернета. Это мониторинг доступности.
Обе задачи важны, но решаются по-разному. Дальше разберём, где проходит граница и почему это не «одно вместо другого», а дополняющие друг друга вещи.
Zabbix: что это и что он умеет
Zabbix — зрелая система мониторинга, которую разворачивают на собственной инфраструктуре. Её сильная сторона — наблюдение за тем, что происходит внутри серверов и сети: нагрузка на процессор, потребление оперативной памяти, свободное место на дисках, состояние сервисов и демонов, трафик на интерфейсах, температура оборудования.
Zabbix работает по классической схеме: на наблюдаемые хосты ставится агент, который собирает метрики и отдаёт их серверу. Сервер хранит историю, строит графики и шлёт алерты при выходе метрик за пороги. Для администратора дата-центра это рабочий инструмент номер один: он видит, что диск на сервере БД заполнился на 90%, что на одном из нод нагрузка выросла, что процесс веб-сервера перезапускался.
Zabbix умеет и так называемый веб-мониторинг: сценарии, которые ходят по URL и проверяют, что страница отдаёт ожидаемый код или содержит нужный текст. Это удобно, когда нужно следить за каким-то внутренним эндпоинтом. Но ключевой момент здесь вот какой: Zabbix по своей природе смотрит на инфраструктуру изнутри, из той же сети, где она работает.
Что Zabbix видит хорошо
- Нагрузку и состояние железа: CPU, RAM, диски, SMART, температуру.
- Состояние ОС и сервисов: занятость портов, статусы демонов, логи.
- Внутренние сетевые параметры: трафик, доступность соседних хостов.
- Накопление метрик во времени и построение графиков.
Это отличный инструмент для тех, кто управляет серверами. Вопрос лишь в том, что из этого списка — не про то, видит ли сайт конечный пользователь.
Внешний мониторинг доступности: другой класс задач
Мониторинг доступности сайта решает противоположную задачу: проверить, как ресурс выглядит снаружи, из интернета, глазами реального пользователя из другой точки мира. Разница принципиальная, и вот почему.
Когда Zabbix проверяет сайт изнутри, он обращается к серверу по внутренней сети или через loopback. Это не то, что видит пользователь. Классический сценарий, который внутренний мониторинг не замечает: сайт лежит для всех, кроме самого сервера. Упал внешний канал, неправильно настроен DNS, сертификат истёк — а внутри всё «зелёное», сервер отвечает, приложение работает. Администратор смотрит в Zabbix и видит норму, а клиенты в это время не могут открыть сайт.
Внешний мониторинг доступности проверяет ровно те вещи, которые отделяют пользователя от сайта:
| Проверка | Что показывает | Пример инцидента |
|---|---|---|
| Доступность по HTTP/HTTPS | Отвечает ли сайт на запрос из интернета | Упал канал, сайт недоступен снаружи |
| Код ответа и контент | 200 или ошибка, не заглушка ли это | 500 после неудачного деплоя |
| SSL-сертификат | Действует ли сертификат, когда истекает | Сертификат истёк, браузер показывает ошибку |
| DNS | Резолвится ли домен в правильный адрес | Запись изменили, домен ведёт в пустоту |
| Скорость/TTFB | Как быстро отвечает сервер | Сайт жив, но грузится 10 секунд |
| Порт | Открыт ли нужный порт снаружи | Файрвол закрыл 443 после обновления |
Отдельный класс проблем — SSL и DNS. Это вообще «слепые зоны» для внутреннего мониторинга: сертификат живёт на границе между сайтом и браузером пользователя, и что он истёк, узнаёшь только когда пользователь напишет «сайт ругается на безопасность». То же с DNS — он живёт на стороне регистратора и публичных серверов имён, а не внутри дата-центра.
Проверка из разных точек
Ещё одно отличие — география. Пользователи сайта находятся в разных городах и странах, и доступность может различаться от точки к точке: у одного провайдера сайт открывается, у другого — нет, один регион видит обновлённый DNS, другой ещё держит кеш. Внешний мониторинг, который опрашивает ресурс из нескольких точек, ловит такие расхождения. Внутренняя проверка из самого дата-центра по определению этого не покажет.
Почему внутренний веб-мониторинг — это не то же самое
Отдельно стоит разобрать частое возражение: «у нас в Zabbix уже настроена проверка по HTTP, зачем ещё что-то». Проверка по URL изнутри и внешний мониторинг доступности отличаются не только точкой запуска, но и тем, что именно они проверяют.
Внутренняя HTTP-проверка, запущенная из той же сети, обращается к серверу по кратчайшему маршруту и минует всё, что стоит между пользователем и сайтом:
- DNS-резолвинг. Внутренняя проверка может ходить на IP напрямую или резолвить домен во внутреннем DNS, где запись всегда актуальна. Пользователь резолвит через публичные серверы имён — и там запись может быть устаревшей или вовсе отсутствовать.
- Внешний канал. Если у дата-центра упал апстрим, внутренняя проверка этого не видит: сервер-то отвечает. А пользователь в этот момент получает «сайт не открывается».
- Сертификат с точки зрения браузера. Внутри можно проверить, что сертификат установлен и формально действует. Но цепочка доверия, которую проверяет браузер пользователя, зависит от корневых и промежуточных сертификатов — и если промежуточный не отдаётся, браузер покажет ошибку, хотя «внутри» сертификат выглядит валидным.
- Географию и CDN. Если сайт раздаётся через CDN, внутренняя проверка может попадать на ближайший edge-узел, а пользователь из другого региона — на другой узел с иным состоянием кеша.
Итог: внутренняя HTTP-проверка полезна как быстрый индикатор «приложение вообще живо», но она не отвечает на вопрос, который волнует бизнес, — работает ли сайт для пользователя. Это разные проверки, и одна не заменяет другую.
Типичные сценарии, где граница видна на практике
| Сценарий | Что показывает Zabbix | Что показывает внешний мониторинг |
|---|---|---|
| Упал внешний канал провайдера | Всё зелёное, сервер отвечает | Сайт недоступен снаружи |
| Истёк SSL-сертификат | Сертификат установлен, метрики в норме | Браузеры показывают ошибку безопасности |
| DNS-запись изменена на неверный IP | Проверка идёт на IP, всё работает | Домен ведёт не туда, сайт «пропал» |
| Файрвол закрыл 443 после обновления | Порт открыт изнутри | Снаружи порт закрыт, сайт недоступен |
| CDN отдаёт устаревший контент или ошибку | Сервер-оригинал в норме | Пользователь видит ошибку edge-узла |
| База данных перегружена | Виден рост метрик, причина найдена | Виден симптом — 502 или медленный ответ |
Заметьте закономерность: в левой колонке «внутри в порядке», в правой — «снаружи проблема». Именно эти расхождения и закрывает внешний мониторинг доступности.
Где проходит граница: не «или», а «и»
Здесь важно убрать ложное противопоставление. Zabbix и внешний мониторинг доступности — не конкуренты и не взаимозаменяемы, они отвечают на разные вопросы и дополняют друг друга.
| Вопрос | Кто отвечает |
|---|---|
| Почему сервер тормозит? | Zabbix (метрики CPU/RAM/дисков) |
| Доступен ли сайт для пользователя? | Внешний мониторинг доступности |
| Что с базой данных внутри? | Zabbix |
| Действует ли SSL-сертификат для браузера? | Внешний мониторинг |
| Не перегревается ли железо? | Zabbix |
| Резолвится ли домен у провайдеров? | Внешний мониторинг |
Типичная картина в зрелой компании такая: Zabbix смотрит внутрь, а внешний мониторинг — наружу, и вместе они закрывают полную картину. Внутренние метрики объясняют, почему сайт стал отвечать медленно; внешние проверки сообщают, что сайт перестал отвечать пользователю. Это два уровня одной системы наблюдения, а не два способа решить одну задачу.
Пример, который показывает связку. Внешний мониторинг фиксирует: сайт начал отвечать с задержкой 15 секунд и кодом 502. Администратор открывает Zabbix и видит: на сервере приложений выросла нагрузка, упал свободный объём памяти, процесс перезапускается. Первый инструмент сказал «снаружи проблема», второй — «вот где именно внутри». Один без другого даёт либо панику без причины, либо слепое пятно.
Самопроверка доступности извне: curl и openssl
Чтобы почувствовать разницу между взглядом изнутри и снаружи, полезно проверить сайт руками теми же командами, которыми пользуется внешний мониторинг. Это особенно наглядно, если запускать их не с самого сервера, а с обычной рабочей машины или из другого региона.
Доступность и код ответа
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com
Построчно:
-s— тихий режим;-o /dev/null— отбросить тело ответа;-w "%{http_code} %{time_total}s\n"— вывести HTTP-код и общее время.
200 0.38s — сайт доступен и отвечает быстро. 502 — сайт «достучался», но сервер приложений отдаёт ошибку. Ошибка соединения — сайт недоступен с той точки, откуда запущена команда.
SSL-сертификат
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
-servername задаёт имя для SNI, x509 -noout -dates выводит сроки действия. Вывод:
notBefore=Jan 10 00:00:00 2026 GMT
notAfter=Jan 10 23:59:59 2027 GMT
notAfter — дата, после которой браузеры начнут показывать пользователям ошибку безопасности. Если до неё меньше двух недель, сертификат пора перевыпускать.
DNS
dig +short example.com A
Пустой вывод означает, что запись пропала или домен не резолвится. Сравните адрес с реальным сервером: если dig отдаёт не тот IP, что ожидался, — запись изменена или ещё не обновилась у провайдера.
Эти команды — мгновенный снимок «снаружи». Именно такую логику повторяет автоматизированная проверка доступности: опрашивать ресурс из интернета и алертить, когда что-то перестаёт отвечать. Автоматическая версия этой самопроверки — проверка доступности сайта.
Как совмещать Zabbix и внешний мониторинг
Если у вас уже развёрнут Zabbix, внешний мониторинг не отменяет его — он закрывает то, что Zabbix по своей архитектуре не видит. Практический набор для полного покрытия выглядит так.
Оставьте в Zabbix внутреннее наблюдение. Нагрузка, память, диски, сервисы, сеть внутри дата-центра — это его территория, и там он силён.
Добавьте внешние проверки доступности. Для каждого публичного ресурса — проверка доступности из интернета, проверка SSL и DNS. Это следит за тем, что отделяет пользователя от сайта.
Настройте превентивные алерты. Предупреждение об истекающем сертификате или домене приходит заранее, а не в момент падения. Проверить, что сейчас с сертификатом, можно проверкой SSL, а срок действия — отдельной проверкой срока.
Проверяйте порты снаружи. Внутренний мониторинг видит порт открытым, даже если внешний файрвол его закрыл. Проверка порта из интернета показывает реальную картину для пользователя: проверка порта.
Свяжите уровни между собой. Когда внешний мониторинг сообщает «сайт не отвечает», а Zabbix показывает «внутри всё в порядке» — это сигнал, что проблема на границе: канал, DNS, файрвол, балансировщик. Когда оба молчат, но сайт медленный — смотрите скорость ответа: проверка скорости.
Итог простой: Zabbix — хороший инструмент для своего класса задач, и для администратора инфраструктуры он остаётся основным. Мониторинг доступности сайта — отдельный класс, который смотрит на ресурс снаружи, глазами пользователя, и ловит то, что изнутри не видно. Начать можно с простого: запустить проверку доступности сайта и посмотреть, что видит внешний наблюдатель, — это первая точка, с которой появляется полная картина «снаружи и изнутри».
