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

[miksher]

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

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

[Lelikk]

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

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

[AlexandrY]

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

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

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

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

[Lelikk]

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

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

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

[AlexandrY]

Хе, к CAN-у я мониторинг тож писал.
Тож графики, управление в realtime и все такое.
http://aly.ogmis.lt/products/closed_polygon/Polygon.htm

Но задач или потоков не использовал, делал проще - все сидело на обработчиках ивентов.
Фишка в том, что многие компоненты Delphi и так используют потоки и нет необходимости еще вводить свои.
Плюс компоненты из палитры в подавляющем числе RAD тулсов под винду не поддерживают многопоточность, и во избежание гемора стараюсь избегать в GUI приложениях интенсивного использования потоков.
Но есть оборотная сторона.
Она в том, что надежность таких приложений собранных из кучи сторонних компонентов и компонентов из палитры с разрастанием функций стремится к нулю.
Поэтому выбор технологии на мой взгляд определяется не "простотой" реализации, а чисто наличием специфических потребностей заказчика, как типа финансовые возможности, имеющаяся IT структура и т.д, потому что простота убивается потом трудной поддержкой.

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

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

[Lelikk]

VCL Delphi - это вопрос отдельный, прямо целая тема для холивара
1) Потоки GUI не мешают - достаточно из них к нему не лезть.
2) Вот именно по приведенным вами соображениям надежности и не использую кучу сторонних компонентов и либ, а обхожусь более менее стандартными API на Win32 или типовые либы на .NET.
3) Под "простотой" понимается отсутствие лишних уровней абстракции и дополнительной функциональности, которые необходимы для обеспечения масштабируемости и универсальности, которые часто нафиг не нужны.
4) Легкость поддержки в первую очередь зависит от качества кода и того, насколько эволюционируют требования к приложению. Чем архитектура проще, тем в общем случае лучше, если только требования в будущем не превысят ее возможностей.

Хе, к CAN-у я мониторинг тож писал.
Тож графики, управление в realtime и все такое.
http://aly.ogmis.lt/products/closed_polygon/Polygon.htm

Но задач или потоков не использовал, делал проще - все сидело на обработчиках ивентов.
Фишка в том, что многие компоненты Delphi и так используют потоки и нет необходимости еще вводить свои.
Плюс компоненты из палитры в подавляющем числе RAD тулсов под винду не поддерживают многопоточность, и во избежание гемора стараюсь избегать в GUI приложениях интенсивного использования потоков.
Но есть оборотная сторона.
Она в том, что надежность таких приложений собранных из кучи сторонних компонентов и компонентов из палитры с разрастанием функций стремится к нулю.
Поэтому выбор технологии на мой взгляд определяется не "простотой" реализации, а чисто наличием специфических потребностей заказчика, как типа финансовые возможности, имеющаяся IT структура и т.д, потому что простота убивается потом трудной поддержкой.

[AlexandrY]

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

А пока вот свежак пришел по новостям:

http://www.zenoss.com/product/what-we-monitor

Это открытая система работающая на базе WEB броузеров может мониторить туже температуру и UPS-ы
по SNMP.

VCL Delphi - это вопрос отдельный, прямо целая тема для холивара
1) Потоки GUI не мешают - достаточно из них к нему не лезть.
2) Вот именно по приведенным вами соображениям надежности и не использую кучу сторонних компонентов и либ, а обхожусь более менее стандартными API на Win32 или типовые либы на .NET.
3) Под "простотой" понимается отсутствие лишних уровней абстракции и дополнительной функциональности, которые необходимы для обеспечения масштабируемости и универсальности, которые часто нафиг не нужны.
4) Легкость поддержки в первую очередь зависит от качества кода и того, насколько эволюционируют требования к приложению. Чем архитектура проще, тем в общем случае лучше, если только требования в будущем не превысят ее возможностей.

[miksher]

Здравствуйте, Всех с прошедшем Новым Годом!!!

А конкретно по мониторингу ДГУ у вас есть какие-нибудь проекты, информация, описание программ или алгоритмы работы программ.
Мне надо просто в дипломе написать сравнительный анализ моей программе с другими программами мониторинга ДЭУ.
Просто у меня препод пративный, я ему когда проект показывал (темудипломного проекта защищал), он мне сказал что таких еменно программ как моя уже навалом. Вот мне и надо на комиссии расказать что это за программы и как они работают.