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

Задачи решаемые при мониторинге компьютерной сети:

• система оповещений
• показатели производительности
• профилирование заданий
• запущены ли определенные службы или приложения

• Используйте открытые решения мониторинга.

Мониторинг Linux- кластеров затрудняется несколькими причинами:

• По мере увеличения размера кластера увеличивается и объём собираемых данных, что может привести к перегрузке машины, получающей данные мониторинга. Скажем, если у нас 2000 машин и каждая посылает контрольные показатели на инфраструктурный узел, то этот узел может быть буквально поставлен на колени, а вам останется только гадать, отвечает ли он вообще
• Сбор данных агентами на вычислительных узлах может "высасывать" память и ресурсы процессора из текущих пользовательских задач. Во многих вычислительных центрах обходятся без агентов узлов, потому что это понижает производительность приложений. Нахождение баланса требует компромисса: стоят ли полученные данные затрачиваемых ресурсов процессора?
• Нам не встречался такой масштабируемый инструмент, который привязывал бы пользовательские задания к производительности машины и который профилировал бы задания удобным и визуально привлекательным способом.
• Не существует таких инструментальных средств, которые делали бы всё точно так, как нам хотелось бы. И больше всего в данной области бросается в глаза то, что используемые инструментальные средства не закончены и не в состоянии выполнять хотя бы одну функцию, которая нужна всем. Большинство администраторов использует комбинацию из одной или двух программ. Мы скептически относимся к программам, которые обещают вести мониторинг вашего кластера так, что превзойдут все другие существующие решения: все кластеры разные, и универсального решения не существует. Настраиваемый мониторинг кажется единственным выходом из этой ситуации.

Учитывая сложность проблемы, вот как её решают некоторые из самых ленивых известных нам администраторов.

Наиболее часто встречающееся решение, замеченное нами в больших кластерных вычислительных центрах (включая ведущие университеты и правительственные лаборатории) — это Nagios для оповещений и Ganglia для мониторинга. Эти два очень хорошо настраиваемых инструмента могут дать администратору отличное понимание множества вещей, происходящих в кластере. Ganglia, как оказалось, масштабируется чрезвычайно хорошо.

Но есть также и другие точки зрения. В Университете Южной Калифорнии (USC) Гаррик Стэплс (Garrick Staples) написал pbstop, расширение к программе TORQUE, которое визуально представляет, что делает каждое задание и где оно запущено. Он говорит, что это — весь мониторинг, который ему нужен, и не использует ничего больше.

Вот наиболее популярные, по нашим наблюдениям, инструментальные средства мониторинга с открытыми исходными кодами, применяемые при работе с масштабируемыми кластерами:

• Nagios (NagiosQL)
• Ganglia
• Мониторинг при помощи Cacti
• Zenoss
• CluMon

Мы можем сказать, что многие из этих инструментальных средств в своей реализации, в свою очередь, активно используют RRDtool. Кратко повторим то, что знает ленивый Linux- администратор:

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

• Comparison of network monitoring systems - таблица возможностей различных систем мониторинга.

• Zabbix - громоздок и сложен в использовании.
• Icinga2 - поделка, может и быстрая сама по себе, но поделка.
• Cacti - хорошая вещь, рекомендую её для небольших сетей.
• Pandora FMS - удобный MIB браузер

• SNMP протокол управления сетью, RMON.
• Мониторинг оборудования Cisco при помощи протокола SNMP.
• Squid и SNMP
• Asterisk SNMP