Mon Jan 18 23:43, Alex Tutubalin <lexa@lexa.ru> wrote:
AT> ier> Зачем монитору работать непосредственно с какой-либо б/д, внутренние
AT> ier> данные конечно нужно как-то формализовать и сбрасывать в интерфейс
AT> ier> внешним приложениям.
AT> А затем, что если монитор по какой-то причине перезапустили, то все состояние
AT> должно остаться. При хранении в памяти этого не случится.
Перед завершением весь образ данных сбрасывается в файл и считывается
при старте. Не вижу проблемы.
AT> ier> Что такое агенты, непонимаю. Что значит синхронные/асинхронные агенты?
AT> Ну с SNMP вы можете собирать состояние всей сети из одной точки. Но SNMP-ми
AT> дело не ограничивается. Соответственно, возникает кучка програм-агентов,
AT> которые мониторят все остальное - доступность сервисов, свободное место, LA,
AT> и так далее. Агенты могут быть устроены двояко - либо сообщать состояние
AT> системы по запросу из центра (назовем их синхронными), либо сообщать состояние
AT> мониторимой системы в тот момент, когда агенту хочется - их я называю
AT> асинхронными. Асинхронные агенты в ряде случаев удобнее т.к. не требуют наличия
AT> открытого на них порта для обмена данынми.
Согласен. Очень много можно получить по SNMP, но не все.
Что-то можно реализовать просто, например чтобы определить доступность
TCP сервиса достаточно получить коннект на нужный порт. Эту функцию можно
доверить монитору. Более сложные и специфичные вещи могут исполнять
внешние компоненты. Идея очень старая, давно реализована в InetRover'е.
AT> ier> обьекту. Простой пример, интерфейс UP/DOWN. Положим мы опрашиваем это
AT> ier> значение, но trap лишь ускорит определение состояния. Или мы не
AT> ier> опрашиваем это значение (ну не все же свичи в сети опрашивать), тогда
AT> ier> только trap определит состояние и тут же появиться новый обьект
AT> ier> мониторинга (пассивного?).
AT> Угу. Но не все так просто - допустим упал интерфейс и мы тут же перестали
AT> получать сообщения о доступности sendmail'а за ним. Что совершенно нормально.
AT> Но вводить эту логику в монитор - тоже странно т.к. мониторово дело мониторить
AT> что скажут.
Допустим.
Однако тут надо подумать, насколько сложна эта логика. Нужен хороший
унифицированный алгоритм, если он возможен, его надо реализовать.
AT> ier> Или это уже просто хроно-зависимость, засовывать каждый пук в Oracle?
AT> ier> Чтоб врага запутать что-ли? :)
AT> Можно и врага запутать. Мое глубокое убеждение заключается в том, что удобный
AT> внешний интерфейс к потрохам - это хорошо. SQL такой интерфейс дает, а
AT> какой-нибудь странный IPC с монитором - не дает (интерфейс в этом случае
AT> определяется автором монитора). Что делать, если хочется выбрать top-10 самых
AT> падучих интерфейсов за последний месяц ?
Безусловно монитор обязан что-то протоколировать, через внешние
компоненты/модули (интерфейсы) и файлы.
Вопрос только в том что, когда и зачем.
Например, зачем мне (снаружи) всякий раз получать отчеты о текущей
температуре в корпусе или кол-во свободной памяти или загрузку процессора
и т.п., если меня интересует только факт превышения и его
продолжительность. Наврядли когда-нибудь мне понадобиться график стояния
bgp-сессий, там просто будет сплошная (пунктирная) линия ;)
Согласитесь, есть критерии разумной достаточности?
AT> Holy war по языкам программирования следует, наверное, перенести в личную
AT> почту. Дабы придать накал дискуссии - я утверждаю, что ваше знание Perl
AT> остановилось несколько лет назад, еще до распространения Perl5 :).
Я _никогда_ его не знал и уверен что не придется, мне это _не надо_ в этой
жизни, у меня есть инструмент которым более чем доволен. И покончим с этим.
=============================================================================
"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
