Привет,
AT>> Хм. А как насчет того, что каждая компонента сваливает данные в SQL
AT>> базу данных
ier> Зачем монитору работать непосредственно с какой-либо б/д, внутренние
ier> данные конечно нужно как-то формализовать и сбрасывать в интерфейс
ier> внешним приложениям.
А затем, что если монитор по какой-то причине перезапустили, то все состояние
должно остаться. При хранении в памяти этого не случится.
AT>> ? И синхронные агенты (периодический опрос переменных и keepalive)
AT>> и асинхронные. Соответственно, аггегирование будет работать с этой
AT>> базой,
ier> Что такое агенты, непонимаю. Что значит синхронные/асинхронные агенты?
Ну с SNMP вы можете собирать состояние всей сети из одной точки. Но SNMP-ми
дело не ограничивается. Соответственно, возникает кучка програм-агентов,
которые мониторят все остальное - доступность сервисов, свободное место, LA,
и так далее. Агенты могут быть устроены двояко - либо сообщать состояние
системы по запросу из центра (назовем их синхронными), либо сообщать состояние
мониторимой системы в тот момент, когда агенту хочется - их я называю
асинхронными. Асинхронные агенты в ряде случаев удобнее т.к. не требуют наличия
открытого на них порта для обмена данынми.
ier> обьекту. Простой пример, интерфейс UP/DOWN. Положим мы опрашиваем это
ier> значение, но trap лишь ускорит определение состояния. Или мы не
ier> опрашиваем это значение (ну не все же свичи в сети опрашивать), тогда
ier> только trap определит состояние и тут же появиться новый обьект
ier> мониторинга (пассивного?).
Угу. Но не все так просто - допустим упал интерфейс и мы тут же перестали
получать сообщения о доступности sendmail'а за ним. Что совершенно нормально.
Но вводить эту логику в монитор - тоже странно т.к. мониторово дело мониторить
что скажут.
ier> Или это уже просто хроно-зависимость, засовывать каждый пук в Oracle?
ier> Чтоб врага запутать что-ли? :)
Можно и врага запутать. Мое глубокое убеждение заключается в том, что удобный
внешний интерфейс к потрохам - это хорошо. SQL такой интерфейс дает, а
какой-нибудь странный IPC с монитором - не дает (интерфейс в этом случае
определяется автором монитора). Что делать, если хочется выбрать top-10 самых
падучих интерфейсов за последний месяц ?
AT> >>> Все процедурные языки программирования одинаковы.
AT> bns>> Это заблуждение.
AT>> Буду рад если его развеют. За прошлый год я написал полсотни тысяч
AT>> строчек на C/C++/Perl и не увидел _принципиальной_ разницы.
ier> Нужен real-time, работа с памятью, сигналами, прерываниями, сложными
ier> цепочками структур, динамические таблицы функций и пр. дребедень.
Видите-ли, realtime не обеспечивает сам unix, поэтому требовать его от средств
разработки сложно. Работа с памятью в perl'е есть (perldoc -f undef, perldoc -f
delete), хотя нужна она существенно реже, работа с сигналами, сложными
структурами данных, динамические таблицы функций, IPC, линкуемость с любой
C-шной библиотекой - тоже в наличии. Что такое прерывание в Unix, чем оно
отличается от сигнала и зачем это монитору событий - мне неведомо.
ier> На перле это будет карточный домик. Тормозной и разбухший.
ier> Зато Makefile писать не надо, так что-ли? ;-)
Makefile - не надо, надо Makefile.PL :)
Holy war по языкам программирования следует, наверное, перенести в личную
почту.
С уважением,Alex Tutubalin
--- GoldED 2.42.G1114+
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
