На сервере установлен агент.
Хост в Zabbix зелёный.
Метрики приходят.
Графики строятся.
Триггеры существуют.
Можно ли после этого утверждать:
«Система нормально мониторится»?
Не обязательно.
Потому что наличие мониторинга ещё не означает, что мы действительно способны увидеть существенную неисправность, понять её влияние и достаточно быстро отреагировать.
мониторинг настроен
≠
отказ будет обнаружен
Что вообще значит «мониторинг есть»
На минимальном уровне это может означать:
Zabbix agent → available CPU → есть RAM → есть Filesystem → есть Ping → есть
Мы действительно получаем технические данные об узле.
Но представим, что на этом сервере работает приложение:
users ↓ nginx ↓ application ↓ PostgreSQL
А мониторинг проверяет только:
CPU RAM disk ping
Все четыре показателя могут оставаться нормальными в тот момент, когда пользователи уже получают:
HTTP 500
Инфраструктура отвечает.
Сервис — нет.
Первый уровень: доступен ли узел
Самая простая проверка:
ping → OK
или:
agent → available
Это полезно.
Мы подтвердили:
узел отвечает по сети или агент доступен.
Но:
host reachable
≠
service healthy
Сервер может прекрасно отвечать на ping, когда приложение полностью неработоспособно.
Второй уровень: работают ли процессы
Добавляем:
nginx active application active postgresql active
Картина становится лучше.
Теперь мы знаем, что соответствующие процессы запущены.
Но из предыдущих Фактоскопий уже понятно:
active ≠ исправно
Например:
nginx → active application → active database → active
а пользователь всё равно получает ошибку из-за некорректной конфигурации, зависшей очереди или проблем во взаимодействии компонентов.
Третий уровень: отвечает ли сервис
Теперь проверяем уже сам сервис.
Например:
GET /health → HTTP 200
Это гораздо сильнее.
Но и здесь возникает вопрос:
что именно проверяет /health?
Если endpoint отвечает:
200 OK
просто потому, что процесс приложения жив, а база данных при этом недоступна, такой health check даёт ложное чувство уверенности.
Полезная проверка должна соответствовать реальной зависимости сервиса.
Четвёртый уровень: работает ли пользовательский сценарий
Самая сильная проверка обычно ближе всего к тому, что реально делает пользователь.
Например:
DNS resolve
↓
HTTPS connection
↓
authentication
↓
application request
↓
database query
↓
expected response
Если такой сценарий проходит успешно, мы проверили значительно больше, чем состоянием одного процесса.
Это уже приближается к ответу на вопрос:
«Может ли пользователь сейчас воспользоваться системой?»
Но observability — это не только проверки доступности
Термин observability обычно используют шире обычного мониторинга.
Смысл не в количестве графиков.
Смысл в том, можем ли мы по имеющимся данным понять внутреннее состояние системы, когда происходит что-то неожиданное.
Для этого обычно используются несколько типов данных:
metrics logs traces events
Не обязательно внедрять всё сразу.
Но важно понимать ограничение каждого типа данных.
Метрики отвечают на вопрос «что изменилось?»
response time ↑ error rate ↑ CPU normal database connections ↑
Мы видим факт деградации.
Но причина пока неочевидна.
Логи помогают понять «что произошло внутри»
database connection timeout
authentication failed
Лог уже существенно сужает область поиска.
Но тысячи строк логов без контекста ещё не дают хорошей наблюдаемости.
Трассировка отвечает на вопрос «где задержался запрос»
Для распределённой системы путь может быть таким:
frontend ↓ API ↓ auth service ↓ database ↓ external API
Общее время ответа:
4.2 s
Само по себе оно мало что объясняет.
Трассировка может показать:
frontend 20 ms API 35 ms auth 40 ms database 75 ms external API 3950 ms
Теперь место задержки видно значительно лучше.