Пока не мониторишь - не управляешь: первые графики нагрузки

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

Как жили без графиков

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

На самом деле промежуточное состояние существует всегда, и именно там всё интересное. Диск забит на 85% и растёт. Интерфейс начал дропать пакеты. Загрузка процессора с 9 до 11 утра каждый день скачет к 100% и возвращается - потому что в это время все открывают 1С и вся сеть разом поднимает сессии. Это не катастрофа прямо сейчас, но через неделю-другую - будет. И узнаем мы об этом от пользователя, когда станет уже катастрофой.

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

Что стало возможным сейчас

Инструменты снятия метрик сети и нагрузки существовали давно, но сейчас они стали устроены так, что их реально можно настроить и оставить работать без постоянного присмотра. MRTG - Multi Router Traffic Grapher - рисует графики трафика по SNMP прямо в HTML, и это уже не эксперимент для энтузиастов, а рабочий инструмент. RRDtool снимает метрики и складывает их в базу данных с автоматическим прореживанием: свежие данные хранятся с минутным разрешением, месячные - с дневным. База не растёт бесконечно, что важно, когда дискового пространства не то чтобы завались.

На каналах и маршрутизаторах это уже работает у половины наших клиентов. Теперь добрались до самих серверов.

Первые графики и что они сразу показали

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

Первое - утренний пик. Каждый день с 8:50 до 9:15 нагрузка на файловый сервер уходила в потолок. Потом возвращалась к норме. Пользователи приходят, Windows монтирует сетевые диски, все одновременно открывают вчерашние документы. Это не баг, это штатное поведение, но оно создавало такую нагрузку, что в эти 25 минут сервер отвечал в несколько раз медленнее. Жалоб не поступало - люди просто думали, что компьютеры "тормозят с утра". Теперь мы хотя бы знаем, что это не выдумка.

Второе - канал. Интернет-канал клиента выглядел просторным по ощущениям, но график показал, что по вечерам он забит примерно наполовину. Кто-то качает что-то большое. Без графика это ощущение ни во что не превращается - "кажется, интернет медленнее по вечерам". С графиком это конкретная полоска в 20:00-23:00.

Третье - дисковое пространство. Не трафик, не нагрузка - просто объём занятого места. Один из серверов рос по полтора гигабайта в неделю. При текущем объёме - месяца три до проблемы. Без графика мы бы узнали об этом, когда диск уже заполнится и сервис ляжет. С графиком - видим тренд и можем что-то сделать заранее.

Что изменилось в работе

Не так уж много, если честно. Мы не превратились в команду, которая 24 часа смотрит в мониторы. Инструментов для нормальных алертов, которые сами звонили бы при проблеме, у нас пока немного - это отдельная задача.

Но изменилось главное: теперь есть данные, с которыми можно прийти к клиенту и сказать "у вас дисковое пространство заканчивается, надо расширить" - и это не предположение, а факт с графиком. Или объяснить, почему утром медленно - не потому что сервер плохой, а потому что 30 человек одновременно открывают сетевые папки.

Uptime - это не просто "работает или нет". Это процент времени, когда система работает нормально под реальной нагрузкой. И пока нет графиков нагрузки, слово uptime - это просто слово.

Что дальше

Сейчас графики смотрим руками, примерно раз в день или когда есть жалоба. Это уже лучше, чем ничего - хотя бы есть история, можно посмотреть, что происходило до жалобы и во время. Разница между "сервер лежит" и "сервер лежит, а вот что ему предшествовало" - принципиальная.

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

Главный урок этих нескольких месяцев простой: данные не решают проблемы сами по себе, но без данных управление инфраструктурой - это не управление, а угадывание. А управляемая инфраструктура - это именно про управление, не угадывание.