Эксперты в подборе IT-оборудования
5:47 утра, понедельник, телефон разрывается. Корпоративный портал лежит второй час, и всё потому, что никто не заметил, как на основном сервере кончилось место на системном диске.
Знакомо? Обиднее всего, что такие катастрофы предотвращаются одним графиком и правильно настроенным уведомлением. Про мониторинг все знают, что он нужен, и почти все откладывают его на «когда будет время» - где-то между «навести порядок в серверной» и «обновить документацию». Ирония в том, что настроенный мониторинг это самое время и возвращает.
Разберёмся, что отслеживать, с какими порогами и как часто.
Если совсем некогда. Минимум, который закрывает большинство аварий: загрузка CPU, память и swap, свободное место на дисках и inode, доступность ключевых сервисов, температура процессора, сетевая активность. Настроили - можно читать дальше спокойно. Как именно ловить последнее и чем смотреть трафик руками, разобрано в материале про мониторинг сетевой активности сервера.
Если вы пришли сюда после внезапного отказа и настраиваете мониторинг прямо сейчас, вот экспресс-набор.
Этого хватит, чтобы поймать типовые аварии. Дальше - то, что отличает работающий мониторинг от формального.
Работающий сервер выглядит здоровым ровно до момента, когда перестаёт. Внутри при этом может происходить многое. В список проверок стоит добавить и часы: расхождение времени между серверами ломает авторизацию в домене и путает логи, а держит его в порядке сервер точного времени.
Высокая загрузка процессора сама по себе не проблема - вы за это и платите. Проблема начинается, когда загрузка держится долго и нетипично для вашей системы.
Важнее общего процента - характер нагрузки. Высокий iowait, то есть время ожидания операций ввода-вывода, говорит не о процессоре, а о медленной дисковой подсистеме. Высокая загрузка системными процессами намекает на драйверы или ядро.
И обязательно смотрите на ядра по отдельности. Ситуация, когда общая загрузка 25%, а одно ядро упёрлось в 100% - обычное дело для однопоточных приложений, и это настоящая проблема, невидимая в усреднённом графике.
С памятью интуиция подводит чаще всего. Многие пугаются высокого потребления RAM, хотя неиспользуемая память - это просто зря потраченные деньги: система сама пускает её под кэш.
Настораживать должно другое - активное использование swap при наличии свободной физической памяти. Это признак фрагментации или утечки. Второй сигнал: график потребления растёт без периодических спадов.
Отдельная категория - когда памяти на сервере достаточно, но приложение до неё не дотягивается из-за собственных ограничений. Классика жанра: 32 ГБ на машине и Java-процесс, запущенный с лимитом в 512 МБ, который исправно падает с OutOfMemoryError.
Помимо очевидной проверки свободного места отслеживайте темпы заполнения. Резкое изменение скорости расхода - почти всегда признак проблемы: кто-то включил подробное логирование и забыл, перестали ротироваться бэкапы, или база начала бесконтрольно расти из-за ошибки в приложении.
И проверяйте inode. В Linux бывает ситуация, когда места на диске полно, а файл создать нельзя, потому что закончились inode. Особенно актуально для систем с миллионами мелких файлов - почтовых серверов, логов, кэшей.
Отдельно от свободного места стоит следить за здоровьем самих накопителей: атрибуты SMART предупреждают об отказе заранее, и мониторинг SMART-атрибутов дисков - тема отдельного разбора.
Мониторинг сети сводить к скорости передачи не стоит. Смотрите на количество соединений, чтобы не упереться в лимиты, на статус интерфейсов и на ошибки передачи.
Отдельное внимание - состоянию TCP-стека. Большое количество соединений в TIME_WAIT указывает на проблемы с закрытием соединений в приложении, а высокое число повторных передач - на перегрузку или проблемы в сети.
И не забудьте про файрвол: странная недоступность сервиса нередко оказывается баном на уровне iptables из-за слишком агрессивных правил fail2ban.
Уровнем выше железа живут метрики, которые ловят проблемы, невидимые в графиках CPU и памяти.
Типовой сценарий: сервер с 16 ядрами и 128 ГБ памяти падает под нагрузкой всего в сотню пользователей. CPU загружен на 20%, память свободна, все метрики железа в норме. А причина - забытый лимит на количество открытых файлов: процесс упирается в исторический дефолт в 1024 дескриптора, и никакие аппаратные метрики этого не покажут.
Поэтому отслеживайте не одни ресурсы, а ещё и то, как близко система подошла к собственным ограничениям.
Мониторинг процессов - это больше, чем проверка «работает ли сервис». Отслеживайте количество процессов и потоков, потребление ресурсов конкретными процессами - CPU, память, дескрипторы, сокеты - и время работы.
Внезапные рестарты сервисов - признак нестабильности, даже когда они происходят автоматически и незаметно для пользователей. Сервис поднялся сам, пользователи ничего не заметили, но причина осталась.
И настройте мониторинг логов ключевых сервисов с упором на ошибки и предупреждения: логи расскажут о проблеме задолго до того, как её увидят пользователи. Где их искать и что в них смотреть - в разборе как смотреть логи сервера.
Отслеживайте попытки авторизации, особенно неудачные, изменения в конфигурационных файлах, появление подозрительных процессов и нетипичную сетевую активность.
Стоит помнить, что большинство успешных атак идёт не через изощрённые эксплойты, а через словарные пароли, незакрытые порты и непропатченные уязвимости. Базовый мониторинг этих вещей даёт больше, чем сложная аналитика. Если нужен уровень выше - мониторинг безопасности через SIEM и IDS.
Здесь технические показатели превращаются в то, что понятно бизнесу.
Бывает, что мощный сервер с десятками ядер тормозит на простейших операциях, а все системные метрики в норме. Разгадка обычно на уровне приложения: например, сессии пользователей хранятся в базе без индексов, и каждый запрос вызывает сканирование таблицы с миллионами записей.
Для веб-приложений начните с времени отклика, количества запросов в секунду и статусов HTTP - особенно ошибок 4xx и 5xx. Дальше: время выполнения разных типов операций (так находятся узкие места), количество активных сессий, соотношение чтения и записи, процент попаданий в кэш.
Для баз данных ключевое - время выполнения запросов, количество активных соединений, размер и фрагментация, показатели репликации. Плюс более специфичное: медленные запросы, блокировки таблиц, статистика по индексам.
Бизнес-метрики - то, что интересно руководству. Загрузка CPU в 78% ему ни о чём не говорит, а вот время загрузки сайта, доля успешных транзакций, доступность платёжного шлюза - вполне. Такие метрики нагляднее всего показывают ценность инфраструктуры и проще всего конвертируются в бюджет.
Главный вопрос после «что мониторить» - «а когда считать это проблемой». Универсальных чисел нет: нормальная загрузка для сервера баз данных и для файлового сервера различается радикально. Поэтому ниже - ориентиры, от которых стоит отталкиваться, а дальше подстраивать под свою систему.
| Метрика | Ориентир «норма» | Когда тревожить | Как часто опрашивать |
|---|---|---|---|
| Загрузка CPU | зависит от роли; важна не величина, а нетипичность | держится высоко дольше 10-15 минут без объяснения | 1 минута |
| iowait | единицы процентов | стабильно двузначный при живых дисках | 1 минута |
| Загрузка одного ядра | равномерно по ядрам | одно ядро в полке при низкой общей | 1 минута |
| Свободная память | чем меньше свободной, тем лучше - она под кэшем | swap активно используется при свободной физической | 1 минута |
| Свободное место на диске | запас под рост и под бэкапы | осталось меньше недели по текущим темпам роста | 5-15 минут |
| inode | обычно расходуются медленно | израсходовано больше 80% | 1 час |
| Температура CPU | в пределах, заданных вендором | приближение к порогу троттлинга | 1-5 минут |
| Доступность сервиса | отвечает | две-три неудачные проверки подряд | 30-60 секунд |
| Ошибки HTTP 5xx | единичные | резкий рост доли относительно обычного фона | 1 минута |
| Повторные передачи TCP | близко к нулю в локальной сети, по внешним каналам - выше | заметный устойчивый рост относительно вашего обычного фона | 5 минут |
Обратите внимание на колонку частоты. Доступность критичных сервисов и всплески нагрузки нужно ловить за секунды. Дисковое пространство за минуту драматически не меняется - если только у вас не идёт заполнение логов, - и часового интервала обычно достаточно. Долгосрочные тренды и планирование ёмкости вообще анализируют раз в неделю или месяц.
Отсюда же практика многоуровневого хранения: подробные метрики с секундным интервалом держат одну-две недели для оперативного разбора, агрегированные часовые - несколько месяцев, суточные сводки можно хранить годами.
Оповещения - самая тонкая часть. Слишком много, и вы начнёте их игнорировать; слишком мало, и пропустите критичное. Рабочая схема - три уровня.
Главное правило одно: каждое оповещение должно требовать конкретного действия. Если вы не знаете, что делать с уведомлением, оно не нужно.
Настройте сторожевой механизм. Он должен оповещать, если от системы мониторинга долго не приходят данные. Классическая ситуация: мониторинг упал, но никто не знает - сообщить-то некому. Пожарная сигнализация, которая перестала работать, обнаруживается во время пожара.
Выбор зависит от размера инфраструктуры, бюджета и того, сколько времени вы готовы вложить в освоение.
Когда серверов немного или вы только начинаете, хватает встроенных средств ОС - Windows Performance Monitor, htop, nmon. Рядом живут лёгкие агенты вроде Netdata, Monit и Glances и облачные пинговалки с бесплатными планами, UptimeRobot и Freshping. Глубокой аналитики они не дадут, зато вы увидите, что вообще происходит.
Базового перестаёт хватать быстро. Следующая ступень - Zabbix, мощный и гибкий, но требующий погружения; связка Prometheus с Grafana, удобная для современной инфраструктуры; Checkmk как компромисс между простотой и возможностями. Здесь появляются централизованный сбор, визуализация, гибкие оповещения и базовая автоматизация реакций.
По обоим главным вариантам у нас есть отдельные практические разборы: установка Zabbix и контроль CPU и памяти и сбор и визуализация метрик в Prometheus и Grafana. Данные с самого железа такие системы чаще всего снимают по стандартным протоколам - мониторинг оборудования по SNMP. Ещё один выбор, который придётся сделать на старте, - ставить агенты на серверы или обойтись без них: агентный или безагентный мониторинг.
Для крупных инфраструктур с сотнями серверов и требованиями к SLA существуют Datadog, New Relic, Dynatrace, Splunk для анализа логов и событий, ServiceNow для встраивания мониторинга в управление IT-сервисами. Они добавляют корреляцию событий, предиктивную аналитику и глубокий разбор производительности приложений. Когда тормозит не сервер, а приложение, нужен уже мониторинг производительности приложений (APM), о нём у нас отдельная статья.
Не привязывайтесь к одному инструменту. Комбинация под разные задачи обычно работает лучше универсального решения: Prometheus для метрик, ELK для логов, отдельное APM для приложений. Универсальные системы редко бывают лучшими во всём.
Три часа ночи, мониторинг обнаружил проблему и разбудил вас звонком. Вы встаёте, смотрите логи и выполняете стандартную процедуру - перезапускаете сервис, чистите временные файлы, поднимаете резерв. Вопрос: почему это не сделала система?
Для типовых проблем автоматическое восстановление настраивается без экзотики: перезапуск зависшего сервиса, очистка временных файлов при нехватке места, блокировка подозрительного трафика, добавление ресурсов при росте нагрузки в облаке. Следующий уровень - связка с системами управления конфигурациями (Ansible, Puppet, Chef), когда отклонение от эталона исправляется само. Самые простые сценарии самолечения не требуют вообще никакой платформы - хватает запуска скриптов по расписанию.
Границы у этого подхода есть, и их стоит держать в голове. Для критичных систем любое автоматическое изменение требует осторожности, все действия автоматики должны логироваться, а часть проблем всё равно нуждается в человеческом решении. Разумный путь - начать с простых понятных сценариев и расширять область по мере накопления опыта.
Более продвинутая ветка - предсказание отказов по накопленным данным: алгоритмы ловят аномалии и тренды раньше, чем метрика упрётся в порог. Как это устроено, разбираем в статье про предиктивный мониторинг.
Мониторинг - это ещё одна поверхность атаки. Агенты обычно имеют привилегированный доступ к системам, а центральный сервер хранит подробную карту вашей инфраструктуры. Бывает, что взлом происходит не через изощрённую уязвимость, а через веб-интерфейс мониторинга с дефолтными учётными данными: система, которая должна была защищать, сама становится входной дверью.
Базовые меры здесь те же, что и везде: сложные пароли, многофакторная аутентификация, шифрование при передаче, регулярные обновления всех компонентов и ограничение сетевого доступа к серверу мониторинга.
Универсальных цифр по стоимости простоя нет, но порядок величин полезно представлять. Долгие годы отрасль ссылалась на оценку Gartner 2014 года - около $5 600 за минуту незапланированного простоя. Цифру до сих пор цитируют как актуальную, хотя ей больше десяти лет: исследования 2024-2025 годов дают уже порядка $12 900 в среднем и до $23 750 для крупных предприятий.
К любым таким оценкам стоит относиться как к ориентиру: они усредняют компании разного размера и отрасли. Куда полезнее посчитать свои: час простоя вашего основного сервиса в вашей выручке - число, которое обычно закрывает вопрос о бюджете на мониторинг быстрее любой внешней статистики.
Хорошая новость: настраивать идеально с первого раза не нужно и не получится.
Начните с базовых проверок доступности, основных аппаратных метрик и двух-трёх по-настоящему критичных оповещений. Даже такой минимум предотвращает большинство серьёзных аварий. Дальше расширяйте: добавляйте метрики, уточняйте пороги под свою систему, подключайте автоматизацию там, где сценарий понятен.
Смысл всей затеи простой. Мониторинг переводит работу из режима тушения пожаров в режим планового обслуживания - и это меняет разом надёжность инфраструктуры и качество жизни тех, кто её обслуживает.
Собираете инфраструктуру, которую потом придётся обслуживать?
Подберём конфигурацию под вашу нагрузку и проследим, чтобы у железа было всё нужное для нормального мониторинга - от полноценного BMC до датчиков и резервирования. Соберём и протестируем под задачу перед отгрузкой, с гарантией и поддержкой после продажи. 11+ лет на рынке серверов.
Серверы под вашу нагрузку · +7 (800) 551-80-12 · info@ittelo.ru
