Разворачиваем и настраиваем систему мониторинга на Zabbix, при необходимости добавляем Prometheus и Grafana. Ведём наблюдение за серверами, приложениями, сетью и резервными копиями: доступность, нагрузка, свободное место, состояние дисков, сроки сертификатов, события безопасности. Уведомления приходят в почту и мессенджеры, а логи собираются в одно место — чтобы разбор сбоя не начинался с поиска нужного сервера.
Без наблюдения инфраструктура работает по принципу «пока не жалуются — всё хорошо». Диск заполняется месяцами и однажды останавливает базу. Резервное копирование падает с ошибкой, но письмо об этом никто не читает. Сертификат истекает в субботу, и в понедельник сайт открывается с предупреждением. Каждая из этих ситуаций видна заранее — если есть кому смотреть.
Мониторинг нужен не для красивых графиков на экране в кабинете, а ровно для одного: узнавать о проблеме раньше пользователей и успевать её решить до того, как она станет остановкой работы. Всё остальное — приятные последствия: понятная история нагрузки, аргументы для планирования закупок и логи, по которым видно, что именно произошло ночью.
Проверяем, отвечает ли сервер, работают ли нужные службы: база данных, веб-сервер, файловый ресурс, сервер 1С, почтовые сервисы. Проверки идут постоянно, а не по расписанию рабочего дня.
Отдельно следим за самим фактом ответа и за корректностью ответа.
Смотрим загрузку процессора, использование оперативной памяти, очередь к дискам и свободное место на разделах. Данные копятся, поэтому видно не только текущее значение, но и тенденцию.
Заканчивающееся место — самая частая причина внезапной остановки.
Следим за состоянием дисков и массивов, температурой, работой блоков питания и вентиляторов там, где оборудование это сообщает. Отказ одного диска в массиве незаметен для пользователей — и это опасно.
Второй отказ подряд означает потерю данных, поэтому первый нельзя пропустить.
Контролируем доступность интернет-каналов, работу маршрутизаторов и коммутаторов, загрузку портов и туннели. Для оборудования MikroTik используем встроенные средства и SNMP.
Видно, какой канал упал и когда именно переключился резерв.
Проверяем не факт запуска задания, а его результат: завершилось ли копирование успешно, сколько заняло, появился ли новый файл нужного размера в хранилище.
Подробнее — на странице резервного копирования.
Отслеживаем сроки действия сертификатов и продления доменов, а также события в журналах: неудачные попытки входа, изменения прав, подключения из непривычных мест.
Об истечении сертификата предупреждаем заранее, а не в день блокировки.
Большинство серьёзных сбоев подаёт сигналы заранее. Ниже типичные ситуации и то, как они выглядят в мониторинге до момента остановки.
| Что происходит | Как это видно в мониторинге | Чем оборачивается без наблюдения |
|---|---|---|
| Заканчивается место на диске | Свободное место снижается, срабатывает предупреждение на пороге, виден прогноз по тенденции | База или файловый сервис останавливаются посреди рабочего дня |
| Отказал диск в массиве | Массив сообщает о деградации, приходит уведомление | Второй отказ приводит к потере данных, восстановление идёт из копии |
| Не выполняется резервное копирование | Задание завершилось с ошибкой или копия не появилась — уведомление приходит в тот же день | Выясняется в момент, когда копия действительно понадобилась |
| Пропал основной интернет-канал | Проверка канала не проходит, видно переключение на резервный | Работа замедляется, причину ищут по жалобам сотрудников |
| Истекает сертификат или домен | Уведомление приходит заранее, срок отслеживается автоматически | Сайт или почта перестают работать без всякой аварии на оборудовании |
| Сервис отвечает, но медленно | Растёт время ответа и нагрузка, история показывает, с какого момента | Разговор «стало тормозить» без данных о том, когда и почему |
Мониторинг не чинит инфраструктуру — он даёт время среагировать. Ценность появляется тогда, когда на уведомление есть кому ответить, поэтому наблюдение мы обычно связываем с сопровождением.
Разворачиваем сервер мониторинга на вашей инфраструктуре, подключаем узлы, настраиваем проверки и оповещения. Все данные остаются внутри компании, доступ к панели получают ваши администраторы.
Мониторинг работает на инфраструктуре Dinesco, вы получаете уведомления и отчёты, а разворачивать и обновлять систему не нужно. Удобно, когда своей серверной нет или администратор один.
Собираем журналы серверов, сервисов и сетевого оборудования в одно хранилище, задаём срок хранения и настраиваем поиск. При разборе инцидента не приходится подключаться к каждой машине отдельно.
Если система уже есть, но уведомления никто не читает, разбираем её: убираем шумные проверки, поправляем пороги, добавляем то, чего не хватает, и приводим оповещения к вменяемому виду.
Копии с проверкой восстановления и контролем результата каждого задания.
Подробнее →
Реакция на уведомления, разбор инцидентов и плановое обслуживание.
Подробнее →
Маршрутизаторы, каналы связи и резервирование, которые тоже под наблюдением.
Подробнее →Основной инструмент — Zabbix: он покрывает и серверы, и сетевое оборудование, работает по SNMP и через агентов, не требует лицензий. Для сетевого оборудования используем ещё и встроенные средства, например у MikroTik. Логи собираем отдельным хранилищем. Если у вас уже что-то настроено, чаще разумнее развить существующее, чем менять инструмент.
В почту и в мессенджеры — обычно в отдельный чат, чтобы сообщения не терялись среди рабочей переписки. Критичные события и информационные сводки разводим по разным каналам: первое требует реакции сразу, второе достаточно просмотреть раз в день. Список получателей задаём по группам, а не по одному человеку.
Наша цель — чтобы каждое уведомление означало действие. В первые недели после запуска их обычно больше: система показывает реальные значения, и по ним корректируются пороги. Дальше поток становится небольшим. Если сообщений много и на них перестали реагировать, это не «нормальный фон», а повод перенастроить проверки.
Да. Удалённые площадки подключаются через защищённый канал или через локальный узел сбора, который передаёт данные на основной сервер. Так видно состояние каждой точки: доступность канала, работу оборудования и локальных серверов. Для распределённых компаний это часто первое, ради чего мониторинг и внедряют.
Срок задаётся осознанно: метрики обычно держат дольше в усреднённом виде, а подробные логи — ограниченное время, потому что они занимают место. Мы обсуждаем, какая глубина нужна для разбора инцидентов и планирования, и подбираем объём хранилища под неё. Журналы, важные с точки зрения безопасности, хранят отдельно и дольше.
Разбираем, что именно настроено, какие проверки шумят и чего не хватает. Как правило, проблема не в инструменте: пороги взяты по умолчанию, половина узлов не подключена, уведомления идут одному человеку, а важные вещи вроде результата резервного копирования и сроков сертификатов не проверяются вовсе. Приводим систему в рабочее состояние и оставляем описание того, как она устроена.
Расскажите, какие серверы и сервисы критичны для работы и как вы узнаёте о сбоях сейчас. Предложим схему наблюдения и порядок оповещения.
Настроить сбор метрик несложно — сложнее сделать так, чтобы система реально влияла на работу. Разница между рабочим мониторингом и декоративным почти всегда не в инструментах, а в том, как заданы пороги и что происходит после уведомления.
Если уведомлений приходит слишком много, их перестают читать. Сначала письма фильтруются в отдельную папку, потом папка не открывается неделями, и в один момент среди сотни сообщений о кратковременном скачке нагрузки теряется единственное важное — о вышедшем из строя диске. Поэтому мы считаем настройку правильных порогов более важной задачей, чем охват «всего подряд». Лучше двадцать проверок, на которые реагируют, чем двести, которые молча удаляют.
Высокая загрузка процессора может быть нормой для сервера, который каждую ночь пересчитывает отчёты, и признаком беды для файлового сервера. Поэтому пороги мы задаём после наблюдения за реальными значениями, а не в первый день. Первые недели работы системы всегда идёт настройка: часть проверок отключается, часть получает другую чувствительность, часть переводится из уведомлений в разряд информации, которую смотрят при разборе.
События полезно делить хотя бы на две категории. Первая — то, что требует немедленной реакции: недоступен сервер, не работает сервис, отказал диск, не прошло резервное копирование. Вторая — то, что просто стоит знать: место закончится через месяц, память используется активнее обычного, сертификат истекает через несколько недель. Первая категория идёт в мессенджер, вторая — сводкой в почту. Такое разделение возвращает уведомлениям смысл.
Мониторинг сообщает, что стало плохо. Логи объясняют, почему. Когда журналы собираются в одно хранилище, разбор инцидента превращается в поиск по времени и узлу, а не в подключение к пяти серверам с надеждой, что записи ещё не перезаписались. Отдельная польза в том, что логи сохраняются, даже если сам узел вышел из строя или его пришлось переустановить. Для событий безопасности это принципиально: журналы, которые лежат только на скомпрометированной машине, доверия не заслуживают.
В офисных инфраструктурах значительная часть проблем возникает не на серверах, а между ними: перегруженный канал, порт коммутатора, отвалившийся туннель, точка доступа, ушедшая в перезагрузку. Оборудование MikroTik и управляемые коммутаторы отдают данные по SNMP, и подключить их к наблюдению обычно проще, чем кажется. Без этого мониторинг серверов показывает симптомы, не показывая причину.
Самая честная мысль про мониторинг: система уведомлений без дежурства — это просто архив сообщений о том, как всё сломалось. Поэтому мы либо настраиваем наблюдение и передаём его вашей команде вместе с регламентом реакции, либо берём реакцию на себя в рамках сопровождения ИТ. Мониторинг также входит в наши проекты по серверам и виртуализации и в работы по автоматизации — без него ни одно обновление нельзя считать успешно завершённым.
