В плане удобства и дружелюбности пользовательского интерфейса наверное Nagios проигрывает.
Я бы не стал столь категорично называть неудачей тот факт, что сами плагины принимают решение о том, в каком состоянии находится сервис. В чем здесь проблма-то? Как правило у любого плагина есть ключи с помощью которых делается тонкая настройка порога переходв в WARNING и CRITICAL. Я лично с этим вообще проблем не испытываю. Понадобилось что-нить нестандартное - взял написал плагин, сделал, что надо. Все просто и понятно, чего тут огород городить. Это и есть та самая гибкость, которая позволяет реализовывать самые нестандартные проверки и методы уведомления.
А еще у Nagios Event Broker есть, вот так :-)

ИМХО большой косяк zabbix в том, что конфигурится он через кликанье в интерфейсе.
Конфиги все же - это правильней. Можно, например, в домене авторегистрацию замутить. В домен вводится новая рабочая станция -> автоматически применяется групповая политика, которая на этой новой рабочей станции запускает скрипт -> скрипт в нужном месте создает типовой конфиг -> перезапуск демона и вуаля -> машина у нас под наблюдением. Сможете такое в zabbix? В конфигах шаблоны позволяют все упростить. Скажем тот же типовой конфиг для новой машины домена мог бы выглядеть так:
define host{
use host-template

name new-workstation
alias MAC addres 00-08-a3-7d-d6-8f
address 192.168.1.1
}

define service{
use service-template

host_name new-workstation
service_description PING
}

Еще несомненное достоинство в том, что в поле address _НЕ_ОБЯЗАТЕЛЬНО_ должен быть IP адрес. На самом деле то, что вы там напишите в дальнейшем просто подставляется вместо макроса $HOSTADDRESS$ при опрделении команд. То есть получается, что указанное в address в конечном счете передается в качестве аргумента плагину, а уж как плагин будет это интерпретировать... Я вот собираюсь написАть плагин которому будет передаваться список IP адресов. Предполагается, что есть хост, у которого много IP-адресов и плагин будет умно каждый проверять и делать CRITICAL только в том случае, если ни один из адресов не пингуется; OK, если пингуются все и WARNING если не пигуется лишь часть адресов.
Интересно как вы решаете задачу мониторинга подобных хостов в zabbix? А как дела обстоят с зависимостями сервисов друг от друга? А есть ли понятие пассивных проверок?

Вы неправильно поняли сути того, что предлагается.
Предлагается не файловое хранилище (журналы) выносить в RAM-диск, а файлик status.dat, который содержит текущее состояние объектов мониторинга и служит единственной цели - его по запросу пользователей парсят CGI скрипты для того, что бы нарисовать карту или просто вывести список хостов/сервисов с их состояниями. Естесственно, что делать регулярный дамп файла в RAM-диск и читать в процессе парсинга из RAM-диска много быстрей, чем с HDD. Однако это все для тех у кого объектов ну очень много (десятки тысяч).

opensource даёт некоторые возможности...
У меня демон в онлайне распихивает данные из Nagios-овского perflog-а по rrd базам. А для отображалки как раз взял javascript-ы от cacti. Ничего сложного. Всё маштабируется и настраивается как угодно.