Ошибка в первом предложении

-- perl -e 'sub _{{{{{{{{print for fun}}}}}}}}_'

я может не в тему, но с чего снимать данные? Если с разных сервисов(http-server, бак с водой и т.п.) то и серваки нужно писать разные ну или хотябы сервак один, но разные входные модули снятия информации. Ну а если есть это, то задача отсылки сообщений уже решается просто. Достаточно к этому серваку плагином (или через унифицируемый протокол) подсоединить клиентов, которым сервак сбрасывает данные о событиях на которые подписан клиент.

у меня все :-)

Смотри, у тебя есть собственное приложение, со своими бизнес-правилами и особенными параметрами работы. Корректность в твоем случае будет определятся открытым(и рабочим) соединением с СУБД(это что касается параметров работы) и температура окружающей среды < 100 градусов. Второе приложение должно иметь постоянное открытое соединение с удаленной системой по RS-485 плюс показателем проблем будет заполнение жесткого диска на 90%.

А вот теперь сведи все в один терминал, который будет уметь отобразить статусы всех клиентов и сигнализировать о возникновении аварийных ситуаций в зависимости от логики клиента.

Это значит, что при разработке собственного ПО нужно будет использовать потенциальный API.

Имхо гораздо проще будет определиться с желанием участия после публикации мини-ТЗ

Кроме периодических опросов Nagios способен обрабатывать SNMP TRAPы. Конечно, для мониторинга их применять неудобно.

Подробности тут: http://en.wikipedia.org/wiki/Snmp

Идея "мониторинг от обратного" интересна, но бывают очень разные ситуации к которым она слаба применима в текущем виде. Например -- отказ по питанию, отказ клиента (краш + откинутая корка). Вариант с введением heartbeat в систему будет вызывать вполне ощутимую нагрузку. И практически бесполезную :-)

А в каком виде она должна быть, чтобы смогла быть применима?

Да, если система падает на аппаратном уровне - это все:) Однако отсутствие heartbeat - тоже решение. Насчет нагрузки не - вопрос спорный.

В центре архитектуры — spread. Клиенты подключаются к определенной группе, куда и начинают отправлять сообщения. Сообщение должно содержать timestamp отправки, идентификатор(ID или имя, которое дает понять, кто отправляет), сами данные. Данные могут быть произвольного формата - как текст, так и бинарная информация.

Центральное приложение должно позволять регистрировать в базе данных(текстовый файл, СУБД — не принципиально) сервисы, сообщения от которых будут обрабатываться. Регистрация включает в себя указание модуля разбора/отображения поля данных согласно специфическим внутренним форматам.

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

Далi буде:)

Есть потреба в такой системе!
Имеется компрессор (далее их будет несколько)
к нему присоединены датчики давления и температуры.
Которые прицеплены к приборам ОВЕН с выходом
на RS485(посл. порты). Необходимо писать
показания на диск, анализировать ошибки и в
в случае проблем вырубить, а также по требованию
показать текущее (или ранее бывшее) состояние.
Использовать большие СКАДЫ не хочется. Да и проблемы
с нестандартной переферией. Вот такая история.

Вот такой вопрос?

А годится ли Перл для Реал-Тайма?
Зачем лезть в бутылочное горлышко!
Ну ладно оформление отчета, расчет части данных.
Зачем в системе логгирования Перл?!?
Или у нас собралось сообщество крутых перлистов,
которые смогут заставит перл работать для
обработки запросов прерываний железа.
Или давайте построим ось на Перле!
Всему свое место, перлу место в Никс-сетях,
остальное от лукавого.
Давайте отделять уровни взаимодействия между
жалезом, драйверами, системными библиотеками,
службами и прикладными программами, в том числе
и на Перле.
Получается что, никто не сформулировал никаких
временных параметров. Что нужно, как, какими затратами,
как быстро, как читабельно для поддержки.
Вообщем пустой разговор со стенкой.
Стенка стенка скажи как сделать систему логгирования?
Стенка - Исправь для начала свои мозги, тогда и система
не понадобится! Вот такой разговор по душам.
И мы еще чего то ждем!

Не хотелось бы скатываться на личности:) Однако у меня складывается впечатление, что Вы читали мои предыдущие сообщения не сильно внимательно. Я ни разу не сказал, что система логирования будет написана на perl.
Задача состоит в том, чтобы сделать саму систему, а на чем будут реализованы компоненты - не суть важно.
В настоящий момент мы работаем над графической консолью, которая будет принимать сообщения от распределенных источников. В моем случае источники написаны как раз на perl и знать их состояние хотя бы с разрешением в 1 секунду для меня крайне необходимо.

Насчет места perl в Unix - какая разница, где и как работает язык? Язык - это всего-лишь инструмент и от степени владения им зависит область применения. Аналогично можно сказать про любой язык, суть не изменится. Не надо думать, что на одном и том же языке можно решать все задачи - это неверно.

Ваша задача с датчиками может быть решена не через SCADA. Возьмите контроллер, который умеет IEC-61131(например, i-8xxx с ISaGRAF на борту) и пишите. Нет жаления возиться с коммерческой SCADA - возьмите бесплатную или скачайте демо для MasterSCADA, они дают возможность работать бесплатно для 24 точек ввода/вывода(для вас должно хватить).

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

Где можно увидеть Вашу графическую консоль?
Или это большой секрет?
Хотя-бы скриншот можно?

Последний Ваш совет дан поверхностно.
Эти варианты рассматривались, но
нужно нечто более интересное.

В настоящий момент мы работаем над графической консолью:) Как только будут результаты - обязательно дам знать. Просто сейчас там все на уровне анализа и первичного разбития на объекты. Кода написано не так и много.

Насчет вариантов - как мне кажется, нужно не интересное, а работающее:) Советую работающее, проверял сам. 

К Nagios вроде как есть плагин NSCA - для пассивного опроса серверов. Но проблему с реалтаймовостью это не решает. Будет ли система востребована или нет - не знаю, но хочется попробовать свои силы в коллективной работе. На работе правда очередной аврал недели на две, но это временно. :)

Скрин первого варианта консоли уже опубликовал:)