Мониторинг под Windows, Кто писал программы мониторинга? Опции

[miksher]

Здравствуйте.
Хотелось бы спросить у вас, кто-нибудь занимался разработкой программного обеспечения для мониторинга различных контроллеров? Напишите пожалуйста мне кто писал программы мониторинга.

Я занимаюсь разработкой ПО для мониторинга дизель-электро установок(ДЭУ), то есть программа ведет опрос контроллеров установленных в ДЭУ через COM-порты.
Хотел поинтересоваться различными идеями, алгоритмами таких или подобных проектов, а так же поделится своими мыслями.
Пишите пожалуйста сюда, буду благодарен за отклик.

[Lelikk]

Как-то уж очень в общем у вас сформулирована тема
Мониторинг-мониторингу рознь - одно дело графики выходных данных строить с высокой частотой, другое - опрашивать чего-нить раз в полчаса.
Так что напишите, что у вас в принципе за задача.

Про себя: я недавно писал прогу, которая осуществляла мониторинг контроллера, который висит на шине CAN (к компу подключение шло через USB-CAN). На нижнем уровне архитектура была простая - отдельный поток слушал сообщения, полученные фильтровал и разбрасывал по нескольким очередям.
Главный поток крутился по таймеру и забирал сообщения из очередей (очереди были естественно защищены от доступа из нескольких потоков). Основной задачей было практически построение графиков и обмен небольшими конфигурационными сообщениями.

[AlexandrY]

Сумбурное вы чета написали.
Какой-то поток рассылал по очередям и тут же другой поток собирал из этих очередей
И почему поток собирающий из очередей работал по таймеру, а не сразу по событию из очереди?

У мониторингов всегда интересна масштабируемость.
С этой точки зрения их реализации должны преследовать одну из важных целей - их нагрузочная способность должна определяться пропускной способностью физического канала и процессора, а не какого-то таймера например.

Как-то уж очень в общем у вас сформулирована тема
Мониторинг-мониторингу рознь - одно дело графики выходных данных строить с высокой частотой, другое - опрашивать чего-нить раз в полчаса.
Так что напишите, что у вас в принципе за задача.

Про себя: я недавно писал прогу, которая осуществляла мониторинг контроллера, который висит на шине CAN (к компу подключение шло через USB-CAN). На нижнем уровне архитектура была простая - отдельный поток слушал сообщения, полученные фильтровал и разбрасывал по нескольким очередям.
Главный поток крутился по таймеру и забирал сообщения из очередей (очереди были естественно защищены от доступа из нескольких потоков). Основной задачей было практически построение графиков и обмен небольшими конфигурационными сообщениями.

[Lelikk]

У мониторингов всегда интересна масштабируемость.
С этой точки зрения их реализации должны преследовать одну из важных целей - их нагрузочная способность должна определяться пропускной способностью физического канала и процессора, а не какого-то таймера например.

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

P.S. Про таймер - чисто технической средство для регулярной отрисовки