Мониторинг серверов и сетей — обзор бесплатных программ

Идеальных систем мониторинга компьютерных сетей и серверов нет. К сожалению. Приходится работать с несколькими системами, которые имеют свои достоинства и недостатки, но в итоге перекрывают слабые места друг друга.

Nagios
Раньше я использовал Nagios более активно, сейчас же у меня это вторая система, следящая за важными сервисами и за основной мониторинговой системой (да, это необходимо, так как отсутствие аварий может обозначать и отказ системы, которая сообщает об этих авариях). Устаревшая система с древним интерфейсом. Отчёты близки к нулю. Мониторинг в основном в виде пробников, запускаемых с сервера. Снимать данные с удалённых серверов (например, память/диск) можно, но мне не нравится, слишком много телодвижений. Конфигурировать нудно, всё происходит редактированием конфигов (есть и сторонние утилиты для администрирования через интерфейс, но мне они не пришлись по нраву). Нет графиков. Обычно нужно видеть графики загрузки каналов, использования памяти, количества префиксов BGP, но этого в Nagios нет. Он сообщает о превышении порогов — и всё. Такая себе железобетонная система, которая выполняет свою основную функцию — следит за различными сервисами.

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

Мониторит не только сервера, но и устройства по SNMP, запускает внешние пробы типа пинга, проверки, откликается ли порт. Есть чрезвычайно важная функция для хостинг-провайдера — можно создавать правила слежения за Web-сайтами, причём эти правила могут быть комплексные и эмулировать работу пользователя. Зайти на страницу, положить товар в корзину, сделать заказ. И на каждом шагу проверить код возврата и фрагмент текста, который должен быть на странице. Обычно достаточно и простого запроса-ответа. Очень удобно. Единственное, что нужно иметь в виду — пробы запускаются часто (это настраиваемо, и это плюс для оперативности), но трафика генерируется много.

Пару лет назад я использовал Zabbix для пробы на нескольких своих проектах, и был удивлён, почему на виртуальном сервере закончился трафик. А оказалось, что это Zabbix слишком рьяно следил за сайтами. Стоит заранее продумать этот момент. Нотификации хороши, есть возможность отсылать их не только по email, но и на jabber, и по SMS. По графикам можно судить о различных параметрах, можно строить графики по нескольким переменным.

Минус — агенты периодически умирают (по крайней мере на дистрибутивах FC 10-13×86_64), и нужно либо делать проактивный мониторинг, удалённо запуская скрипты перезапуска, или вручную перезапускать агента.

Большой плюс — можно нарисовать карту сети. Можно настроить приём SMNP-трепов. И т.д. Nagios’у далеко до Zabbix.

Cacti
Графики у Zabbix хороши, но для добирания к ним нужно постараться. Можно сделать страницу с основными показателями, но лично мне реализация не понравилась. И вот тут хороша Cacti — система построения графиков для мониторинга разнообразных параметров. Используется rrdtools, можно сводить множество переменных. Дискретность хорошая — данные видны в течение минут двух. Для уменьшения нагрузки на CPU стоит применять внешний коллектор spine. Можно разбивать графики по деревьям, группировать по устройствам или выводить конкретные графики. Поддерживается SNMP, и, что очень полезно — внешние скрипты. Снял произвольным образом десяток параметров, передал их через скрипт, визуализировал — и всё видно. Есть глюки. В определённых случаях непредсказуемо не воспринимается одна или несколько переменных из набора. Приходится лезть в настройки графика и проверять, воспринимаются ли все параметры.

Плюс — можно указать интересующий диапазон времени и увидеть всю картину. Можно мышкой выделить участок и его увеличить. Удобно для разбора проблем.

Минус — производится округление и поминутная разбивка через сутки уже недоступна, всё приводится к 5-10 минутной разбивке.

Минус — Cacti служит для визуализации. Контроль параметров в пределах заданных границ не производится. Это задача Zabbix.

Минус — чтобы использовать Cacti, нужно тоже сломать голову, и понять, процесс создания графиков.

Повторюсь — Cacti нужно использовать.

Munin
Указанные выше системы мониторинга серверов хороши. Но если нужно понять, что творится с десятком-другим серверов, причём с детализацией до конкретных приложений, то Zabbix нужно долго настраивать. Cacti — тем более. Если же хочется быстро добавить несколько серверов к мониторингу, увидеть на графиках детали по использованию памяти (buffers/swap/slab/inactive и т.д.), увидеть прерывания по конкретным устройствам, посмотреть детальную статистику MySQL, Memcached, Nginx, Apache, посмотреть iostat, vmstat и т.д., то тут на помощь приходит Munin. Очень и очень хорошая система. Есть возможность отсылки нотификаций по email в случае выхода параметров за пределы. Можно выдавать алармы в Nagios.

Минус — нагружает сервер мониторинга. Нельзя сделать «drill-down», отметив интервал времени и посмотрев детали.

Monit
Все перечисленные выше системы визуализировали и следили в общем. Есть одна очень полезная утилита — monit, которая наблюдает за сервисами и в случае необходимости их перезапускает. Например, nginx стал генерировать ошибку «502 bad gateway» из-за того, что отвалился php, запущенный через fastcgi. monit это видит и перезапускает fastcgi. Или в сервере swap подошёл к концу (например, апачи заполонили всю планету), и вот-вот oom_killer станет раздавать kill’ы, но это ни к чему не приведёт и сервер умрёт до его ручного перезапуска. И тут поможет monit — он может превентивно перезагрузить сервер. Пять минут — это не часы отсутствия сервиса.

Rancid
Сетевое оборудование содержит конфиги. Объёмные и комплексные конфиги. На которые потрачены даже не часы, а недели работы, пока они не были до конца вылизаны. И вот в том же Cisco умирает флеш. И тут системный администратор понимает, что бекап был сделан год назад. И всё. Клиенты отвалились, звонят, требуют восстановления сервиса, а специалисты носятся и ищут договора, в которых описаны адреса, vpi/vci и подобные параметры. Бывает? Бывает. Именно поэтому нужны бекапы конфигураций. Можно написать сборщик конфигов, можно использовать монстра вида CiscoWorks Resource Manager, а можно поставить rancid. Программа раз в час собирает конфиги со всех сетевых элементов и помещает их в систему контроля версий CVS. да, CVS — это стандарт, наверное, времён Modern Talking, и лучше git/mercurial или хотя бы SVN, но это работает.

Плюс — генерируются diff’ы конфигов и всегда видно кто что сделал.

Плюс — можно подключить не только Cisco, но и HP, Juniper и т.п., в общем всё, к чему можно получить доступ по telnet/etc, а не только через GUI.

Тоже рекомендую.

etckeeper
И напоследок — система хранения конфигов. /etc помещается в репозиторий системы контроля версий (поддерживаются практически все популярные, я же использую git). Всегда можно увидеть, что именно изменялось в конфигурациях. И это чрезвычайно полезно. Если сервис перестал работать, бекапа нет, менялось много параметров (всё это неправильно), то в обычной ситуации придётся в стрессе вспоминать, что именно менялось. А так — git log/git show покажут всё и позволят вытащить последнюю рабочую версию конфига. Ещё хотелось бы упомянуть мощные системы управления конфигурациями типа cfengine/puppet/chef, но это совсем отдельная тема и больше относится к серверам, чем к провайдингу.

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

Кстати, очень удобно мониторить свои серверы из облачного VPS сервера UNU Cloud. В таком случае, система мониторинга не привязана к серверам и вашей сети. Вы всегда узнаете об аварийной ситуации даже в случае серьезных проблем.

При размещении IT-оборудования в Дата-центре United DC на колокейшн, можно легко соединить виртуальные сервера в одну сеть с физическими серверами и независимо мониторить все свое оборудование. Если через какое-то время система мониторинга не будет справляться с нагрузкой, то в несколько кликов из панели управления облаком возможно добавить недостающие ресурсы.

Oleg Serdyukov, The Apple Geek