У вас есть Zabbix. Но есть ли у вас мониторинг?

Это первая статья из серии «Как построить систему мониторинга, которая действительно работает. Опыт, ошибки и взросление».

Вы можете скормить эту серию своему ИИ. Уверен, он найдёт в ней полезные идеи и сможет предложить, как применить их к вашей инфраструктуре. Но сначала я попробую объяснить всё человеку — без трёх экранов определений перед первым практическим примером.

С мониторингом обычно всё начинается одинаково

Появляется новый сервер. На него устанавливают агент Zabbix, подключают стандартный шаблон — и через несколько минут на экране уже появляются графики.

CPU работает. Память занята. Место на диске постепенно заканчивается. Интерфейс передаёт какие-то байты. Если сервер перестанет отвечать на ping, администратор получит уведомление.

Первое время это даже производит впечатление. Вместо десятка открытых консолей появляется единый экран, на котором видна вся инфраструктура. Можно открыть график за неделю, найти момент перезагрузки или показать руководителю красивую картинку с загрузкой процессора.

Формально мониторинг уже есть.

Проблема выясняется позже — обычно во время первой настоящей аварии.

Первый неприятный звонок

Представим обычный файловый сервер. Он добавлен в Zabbix, агент доступен, данные поступают. Настроены стандартные пороги: высокая загрузка CPU, недостаточно свободной памяти, заканчивается место на диске, сервер недоступен по сети.

На дашборде всё зелёное.

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

Администратор заходит на сервер и действительно не видит ничего страшного. CPU загружен на 20%, несколько гигабайт памяти свободно, на диске осталось ещё 300 ГБ.

Через некоторое время выясняется, что дисковая система почти не отвечает. Один из накопителей начал сыпать ошибками, контроллер повторяет операции, очередь запросов растёт. Место на диске есть, но пользоваться им почти невозможно.

Мониторинг контролировал ёмкость диска, но не контролировал его работу.

Это важный момент. Мы не допустили ошибку, когда поставили стандартный шаблон. Ошибка была бы решить, что этого достаточно.

Типовые шаблоны нужны

После подобных случаев иногда впадают в другую крайность: начинают говорить, что CPU, RAM и свободное место — бесполезные метрики.

Это не так.

Типовой шаблон — нормальная отправная точка. Он быстро закрывает очевидные проблемы и позволяет увидеть инфраструктуру целиком. Если на сервере осталось 2% свободного места, не нужно строить распределённую трассировку, чтобы понять причину ошибки записи.

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

Но каждый из этих вопросов немного сложнее, чем кажется.

CPU: 100% — не единственная проблема

Самый очевидный триггер выглядит примерно так: загрузка CPU больше 90% в течение пяти минут.

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

Однопоточное приложение может упереться в одно ядро. Общая загрузка 16-ядерного сервера при этом останется небольшой, а приложение уже перестанет справляться.

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

Короткий всплеск до 100% может быть совершенно нормальным: началось резервное копирование, антивирус проверяет файлы, приложение выполняет тяжёлую задачу. Постоянные 70% иногда опаснее, чем единичный пик до 100%.

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

Мониторинг начинается с порогов, но становится полезным, когда мы понимаем нормальное поведение системы.

Память: «занято» ещё не означает «закончилась»

С памятью происходит похожая история.

Администратор видит, что занято 90% RAM, и увеличивает объём памяти. После перезагрузки система снова занимает большую её часть. Возникает ощущение, что памяти постоянно не хватает.

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

Поэтому алерт только на процент занятой RAM часто создаёт шум. Полезнее смотреть на доступную память, использование swap или pagefile, ошибки выделения памяти, интенсивность вытеснения страниц и поведение конкретного приложения.

Суть та же: нас интересует не просто большая цифра, а нехватка ресурса, которая уже мешает работе.

Диск: свободное место — только начало

Контроль свободного места обязателен. Но даже здесь одного фиксированного порога недостаточно.

Десять процентов на диске объёмом 100 ГБ и десять процентов на массиве объёмом 20 ТБ — очень разные ситуации. Не менее важно понимать скорость заполнения.

Если свободно 500 ГБ, но за последние сутки исчезло 400 ГБ, сообщение «места пока достаточно» звучит неубедительно.

Кроме свободного места стоит контролировать задержку дисковых операций, длину очереди, ошибки накопителей и контроллера, состояние RAID, файловую систему в режиме read-only и количество inode в Linux.

Особенно полезен прогноз времени до заполнения. Уведомление «осталось 10%» сообщает о факте. Уведомление «при текущей скорости диск заполнится примерно через 18 часов» помогает планировать действие.

Сервер отвечает — приложение нет

Ping проверяет, что до узла, скорее всего, проходит сеть и его операционная система способна ответить на ICMP.

Он не проверяет, что пользователи могут работать.

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

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

Для веб-сервера это может быть HTTP-запрос и ожидаемый код ответа. Для базы — возможность установить соединение. Для почтового сервера — доступность SMTP и состояние очереди. Для Windows-сервера — работа обязательных служб. Для файлового сервера — доступность общей папки с точки зрения клиента.

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

Следить нужно и за свежестью данных

Есть ещё один случай, который встречается чаще, чем хотелось бы.

На дашборде последняя полученная загрузка CPU равна 15%. Значение нормальное, индикатор зелёный. Только метрика была получена три часа назад.

Сам сервер может быть доступен. Возможно, остановился агент, завис proxy, сломался exporter или перестал выполняться конкретный item. Если мониторинг не контролирует свежесть собственных данных, старое хорошее значение легко принять за текущее.

Поэтому вопрос «сервер работает?» должен дополняться вопросом «мы действительно знаем, что с ним происходит сейчас?».

Это первый шаг к мониторингу самого мониторинга. Подробно к нему ещё вернёмся в одной из следующих статей.

Не нужно сразу мониторить всё

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

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

Через несколько недель почта заполняется предупреждениями. Администраторы привыкают к постоянному шуму. Большая часть уведомлений удаляется не читая. В этом потоке теряется действительно важная проблема.

Хорошая проверка должна отвечать на вопрос: что мы собираемся делать, когда она сработает?

Если ответ неизвестен, возможно, это полезная диагностическая метрика, но пока не повод будить человека.

График и аварийное уведомление — не одно и то же. Данных можно собирать много. Срочных сообщений должно быть мало.

Как я бы начал мониторинг нового сервера

Сначала я подключил бы стандартный шаблон. Это быстрый и разумный способ получить базовые метрики.

Затем выяснил бы назначение сервера. Не его имя и операционную систему, а именно назначение: зачем он нужен пользователям или другим системам.

После этого добавил бы несколько проверок, связанных с этим назначением.

Для файлового сервера — доступность общей папки, задержки диска, состояние RAID и скорость заполнения хранилища.

Для контроллера домена — обязательные службы, DNS, репликация и проверка времени.

Для почтового сервера — SMTP, очередь, возраст самого старого сообщения и тест доставки.

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

Это ещё не совершенная система мониторинга. Но она уже знает не только характеристики компьютера, а причину его существования.

Маленькая проверка после настройки

После добавления мониторинга полезно устроить ему простой экзамен.

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

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

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

Что изменилось в моём понимании

На первом этапе мониторинг кажется системой сбора метрик. Чем больше графиков — тем лучше он выглядит.

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

CPU, память и место на диске остаются важными. Просто это первый слой, а не вся система.

Следующий слой появляется после неприятного вопроса:

Почему мониторинг был зелёным, когда пользователи уже не могли работать?

Именно с этого вопроса начнётся следующая статья.

Практическая памятка

Этот раздел можно не читать подряд. Он нужен как краткая проверка своей системы и как структурированная выжимка для ИИ.

Минимум для нового узла

Доступность узла и агента.
Свежесть поступающих данных.
Загрузка CPU и очереди выполнения.
Доступная память, swap или pagefile.
Свободное место и скорость его уменьшения.
Задержки и ошибки дисковой подсистемы.
Состояние RAID и физических накопителей.
Сетевые ошибки и потери пакетов.
Обязательные службы.
Как минимум одна проверка назначения сервера.
Синхронизация времени.
Контроль перезагрузок.
Доставка тестового уведомления ответственному инженеру.

Вопросы к каждой проверке

Какую реальную проблему она обнаруживает?
Кто получит уведомление?
Что этот человек должен сделать?
Сколько времени проблема должна существовать до срабатывания?
Как проверить работоспособность самой проверки?
Когда правило последний раз пересматривали?

Признаки слабого базового мониторинга

Ping считается проверкой приложения.
Наличие процесса считается проверкой сервиса.
Контролируется только процент занятой памяти.
Для всех дисков используется один порог.
Не проверяется скорость заполнения.
Старые данные выглядят как нормальное текущее состояние.
Любая необычная метрика создаёт аварийное уведомление.
После настройки проверки ни разу не тестировались.
Неизвестно, кто отвечает за конкретный сервер или сервис.

Выжимка для ИИ

article_stage: infrastructure_baseline

goal:
  Detect obvious host and resource failures.
  Establish a baseline before moving to service monitoring.

core_principles:
  - Standard templates are a starting point, not a complete monitoring system.
  - Availability of a host does not prove availability of its service.
  - Resource capacity and resource performance must be monitored separately.
  - Metric freshness must be checked.
  - Every paging alert must imply a human action.
  - Monitoring checks should be tested by controlled failure.

minimum_signal_groups:
  - host_availability
  - telemetry_freshness
  - cpu_and_run_queue
  - available_memory_and_paging
  - disk_capacity_growth_latency_and_errors
  - network_errors_and_loss
  - required_services
  - one_check_of_server_purpose
  - time_synchronization
  - monitoring_delivery_path

next_maturity_question:
  Why can all infrastructure indicators be green
  while users are already unable to work?

Источники и дальнейшее чтение

Подход к ресурсам хорошо систематизирован в USE Method Брендана Грегга: utilization, saturation и errors.

Разницу между внутренними причинами и симптомами, заметными пользователю, подробно разбирает глава Monitoring Distributed Systems из Google SRE Book.

В следующей статье: почему «всё зелёное» не означает, что сервис работает и как перейти от CPU, RAM и дисков к задержкам, очередям и пользовательским операциям.