Ничего не могу сказать про то что было, т.к. только начали ею заниматься. Склонность потому, что не все наши и чужие девайсы поддерживают SNMP, в то время как все наши и большинство известных нам чужих имеют Modbus, а с появлением Modbus over IP ваще все гламурно.


Звучит очень оптимистично и обнадеживающе. Пугает только навороченность ваших девайсов. Пределом наших мечтаний является самый простенький ethernet-to-serial сервер, в который зашит кастом SNMP agent cо стандартным RFC1628. Такие делают многие конторы(Moxa, Megatec, etc.) но заморачиваться с самостоятельным написанием ПО под малознакомый процессор реально влом.
Трапы нам ваще по барабану(они по большому счету Айтишникам для OpenView нужны), хватает опроса.
Щас умеем мониторить свой Chloride, MGE, APC, Liebert, GE и все что под 1628. Не умеем свои СОС'и и CROSS'ы. :-( Приходица сухими контактами over IP.
ЗЫ,
по деньгам вопрос не принципиальный на фоне стоимости системы.

Сообщение отредактировал Kabron - Dec 30 2008, 10:31

Про мониторинг APC -- не коммерческая тайна?
Можете информацией поделиться?

Перебрал все доступные мне APC-шные MIB-ы, но, пока не получилось "достать" объективную информацию о состоянии "климата" одновременно с нескольких APC-шных датчиков.
Естественно, все APC-датчики (температура+влажность) и APC-дивайсы (различные Symmetra + железка для "климат-контроля" от APC) настроены идентично.
Сначала через WEB и потом, в качестве "контрольного выстрела", через telnet/ssh.
"Цифирки" одинаковые везде выставлены (с небольшой поправкой на "расстояние до объекта").
"Дельта прогресса схождения/расхождения во времени" тоже везде одинакова.
Все дивайсы синхронизированы по общему NTP.

Задача, в общем-то, с виду, несложная -- пропищать мне на мобилу за 40-60 минут до "сдутия", что в серверной комнате температура гарантированно ушла за пределы допустимой.

Или, к примеру, "кондёры" неуправляемые (к сожалению, что неуправляемые) сдохли или энергетики напругу снизили надолго до 160 В вместо обещанных 220 В и кондиционеры отключились.
После восстановления эл./питания кондиционеры (Hitachi, Gree) включаются, но гонят почему-то тёплый воздух и влагу вместо холода т.п..
Помогает только "ручное отключение под надзором" минут на 15-20 и повторный запуск.
Запитать кондиционеры через "умный трансформатор" или от UPS-а или от дизель-генератора пока нет возможности.

В общем, одну беду победить не удалось -- множество ложных сообщений и "недостаточность параметром" известных мне МИБов.
Упало напряжение с 220-ти до 160, к примеру.
Батареи UPS-а начали работать "на подъём".
Жду минут 15-ть и посылаю SMS-сообщение о пониженном напряжении "на входе" (ну, и иже с ним о текущих температуре и влажности).
Не верю. Жду.
Когда заряда батарей хватает минут на 40 (чтобы успеть добраться до места и вручную "опустить" несколько специфичных серверов), отсылаю ещё одну SMS-ку.
Приходится ехать.
Приезжаю (или ещё в дороге) --> входящее напряжение в норме.
"Чтоб они так жили!" (ЦЕ)
Но, раз уж выехал --> приходится доехать и посмотреть что там и как.

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

Сообщение отредактировал ?ELF - Dec 30 2008, 16:00

APC-шными envinroment девайсами не заморачивались, не было необходимости. Когда надо мониторить темп. и влажность, а также для сухих контактов, берем Netprobe Lite от megatec http://megatec.com.tw/. Это единственное полезное их изделие. Для контактов допаиваю подтягивающие резисторы на входы АЦП - итого 8 контролируемых с.к. В остальном с МИБами от АРС никаких проблем не было. Я давал ссылку на нашу прогу выше, можете потестить. Дема работает 15 мин.

Сообщение отредактировал Kabron - Dec 31 2008, 10:44

Почем покупаете дивайсы у megatec не скажете ?

Собираемся тоже самое почти делать по размерам

Точно только после праздников, надо у манагера спросить. Типа 200$. Заодно предостерегу от Net101 - отстойнейшая не вещь.
И кстати что вы думаете о NetAgent II? Они его типа позиционируют как открытую платформу для мониторного софта, но ничего более подробного я не нашел.
Вообще довльно халтурная контора. Несколько раз обащался к ним за хелпом (сбросить пароль на Нетпробе, оживить его просле апгрейда фирмы) - ноль реакции. И это при том что мы их дистрибуторы.
Валяется у меня один труп Нетпроба могу подарить для анализа.
И еще (чета меня понесло), мне очень нравится атмеловский девайс DB101 http://www.atmel.com/dyn/Products/tools_ca...sp?tool_id=4221
даже купил на свои. К нему Лантрониксовкий Xport и готовое сетевое устройство. На худой конец AVR Butterfly, у меня уже собран такой девайс, тока прогу некому написать.

Сообщение отредактировал Kabron - Dec 31 2008, 14:00

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

Склейкой тех либ и драйверов которые дает Atmel должна являться операционная система реального времени (RTOS). Также должно быть и в NetAgent-е.
Иначе не получится действительно мощного и универсального фреймворка который позволит подключаться к любым датчикам, UPS-ам и другому оборудованию и иметь при этом гибкий HMI, диагностику и апгрейд.
Но такие фреймворки либо монструозны поскольку спускаются с линукса и их не тянет ни одна бюджетная платформа, либо они хорошо упакованы и их уже производителям отдавать жалко.
Начинается тогда возня с либами, какими-то кастрированными API и проч. прослойками призванными изолировать юзера от исходников системы.
Характерный пример Lantronix. Я вообще не понял туда прогу свою залить можно? Или все делается через какие-то настройки?
NetAgent думаю будет снабжен той-же левизной, либо будут предлагать услуги по кастомизации своего софта без привлечения программистов заказчика.

В общем случае дополнения в софте SNMP агента для отражения специальных MIB-ов юзера требуют серьезной интеграции в основной софт операционной системы и статической линковки.
Также спецальной структуры callback процедур и статической линковки потребует отражение новых переменных пользователя в HTML страницах встроенного WEB сервера.
Производитель для предоставления таких возможностей должен сделать практически целую интегрированную среду разработки, написать тонны доки. Цена дивайсов вырастет неимоверно.
Похожую стратегию развивает Wavecom в своих модемах.
Все встречавшиеся мне случаи использования технологий с таким подходом кончались неудачно.
В конце концов все упиралось в недостаточную гибкость.

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

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

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

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

На счет СНМП - каждый стандарт лучше чем отсутствие стандарта. ИМХО сдесь пропблема лежит в следующем. Температура, влажность даже напряжения на акумуляторах УПС изменаються очень медлено. И тут можно производить опрос СНМП агента (делать поолинг). А если система основана на событиях или быстродействующих сигналах то появлеться проблема синхронизации актуалного состояния на верхнем уровне. В принципе как я заметил нет более мение хорошего стандарта на котором основаны системы мониторинга. И каждый делает как угодно. А все фирмы "телекомы" требуют чтобы был реализован СНМП хотя его не используют.

Проблемой синхронизации состояний, анализа корреляций, выявления первоисточников событий и причинно следственных связей в цепочке событий занимаются специальные пакеты вроде HP OpenView, стандарты протоколов за это не отвечают.
Другое дело, что персонал на этих пакетах редко может вообще сообразить как это можно сделать.
Полинг применим в интранетах с хорошими каналами и на неответственном оборудовании.
А когда агенты стоят чтобы сообщить, что разорван магистральный канал?
Или им надо сообщить о выходе оборудования из строя или о саботаже?
Это кстати и есть у нас самые характерные сценарии.
Наши операторы электросетей вообще полингом UPS-ов и других резервных источников не занимаются.
Им подавай только трапы и только высокоприоритетные.
А полинг требует серьезного напряга от персонала на свою организацию и знание особенностей обрудования.
При наличи многих десятков типов оборудования и его постоянным апгрейдом полингом врядли кто серьезно заморачивается в больших сетях.

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

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

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

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

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

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

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

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

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

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

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