- "Nagios 2.0 (http://www.linux-mag.com/content/view/2272/)" - подробный обзор системы мониторинга Nagios 2.0 (http://nagios.sourceforge.net/) (находится в стадии бета-тестирования, текущая версия 2.0b4), приводится сравнение возможностей с Nagios 1.x и даются инструкции по установке.
- "An Overview of ping (http://new.linuxjournal.com/article/8605)" - рассказ про диагностику неисправностей сети при помощи утилиты ping, обзор опций, пример perl скрипта использующего модуль Net::Ping;- "Monitoring network traffic with Ruby and Pcap (http://arstechnica.com/columns/linux/linux-20051002.ars)" - пример написания скрипта для мониторинга проходящего трафика на языке Ruby, используя библиотеку libpcap.
URL: http://www.linux-mag.com/content/view/2272/
Новость: http://www.opennet.me/opennews/art.shtml?num=6258
Нагиос? Это который все данные в файлах хранит и жуткую морду имеет? Ну да, есть такой...
>Нагиос? Это который все данные в файлах хранит и жуткую морду имеет?Я вот наоборот плююсь от программ мониторинга использующих SQL для хранения базы и требующих всякие mod_php на сервере.
Чем проще система и чем она менее зависима от таких больших вещей как СУБД, тем она надежнее.Представьте ситуацию, когда у вас слетел SQL сервер и вам вовремя не отпавилась SMS о критическом сбое в сети.
Nagois молодцы, проще нужно делать, хотя сейчас модно все усложнять и доводить до крайностей.
Нет - я понимаю если бы они SQLite использовали, так нет же! Они юзают текстовухи со своим собственным синтаксисом. Куда дальше? Дальше некуда, надо чё-то делать.
Зачем там SQL можешь внятно ответить?
Не обязательно SQL-базу, можно и XML, главно чтобы люди извне могли спокойно брать-вносить данные, не тра*аясь с парсерами на самописный синтаксис файлов.
Только как я уже упоминал, придут всё-равно к базе.
>Не обязательно SQL-базу, можно и XML, главно чтобы люди извне могли
>спокойно брать-вносить данные,Зачем людем лезть в базу ??? Для этого предусмотрен интерфейс плагинов и API.
> не тра*аясь с парсерами на самописный синтаксис файлов.
Да... База в XML, этож какой оверхед получится на парсинг. Нет уж, увольте, вместо того чтобы пробежаться по строкам и выдрать поля через символ разделителя, вы предлагайте парсер уровня web-браузера на каждый запрос использвоать и ни какое кеширование вам не поможет. Экспорт/импорт в XML - дело полезное, но база в XML - маразм продиктованный модой.
PS. У вас талант все усложнять и идти путем технологии ради технологий ?
>Зачем людем лезть в базу ??? Для этого предусмотрен интерфейс плагинов и API.Плагины - это не то. Про апи - дайте чтоли пример как я например могу заюзать указанный АПИ из допустим жабки.
>База в XML, этож какой оверхед получится на парсинг.
Причём тут база? Я про конфигурационный файл. Если им жуть как не охота нормально юзать данные - пусть хоть инициализируют приложение из нормального источника (например XML).
> У вас талант все усложнять и идти путем технологии ради технологий ?
У меня талант (?) использовать уже наработанные технологии, а не создавать велосипеды с квадратными колёсами.
>Плагины - это не то. Про апи - дайте чтоли пример как
>я например могу заюзать указанный АПИ из допустим жабки.http://www.nagios.org/faqs/viewfaq.php?faq_id=50
API для лога и конфига: http://search.cpan.org/~tobeya/Nagios-Object/
XML представление: http://nxe.sourceforge.net/>>База в XML, этож какой оверхед получится на парсинг.
>
>Причём тут база?При том, что вы говорили именно о базе.
>Я про конфигурационный файл.
Еще хуже. Править руками XML файл еще тот гемморой, более неудобный способ придумать трудно.
Кому нужно, пусть себе в XML лепят конфиг, а потом конвертируют в формат конфигов Nagios или возьмут в руки perl и Nagios::Config.
>Если им жуть как не
>охота нормально юзать данные - пусть хоть инициализируют приложение из нормального
>источника (например XML).XML нормальный источник для обмена информацией (импорт/экспорт), но никак не для хранения конфигов.
>> У вас талант все усложнять и идти путем технологии ради технологий ?
>
>У меня талант (?) использовать уже наработанные технологии, а не создавать велосипеды
>с квадратными колёсами.Вы утрируйте.
>Зачем людем лезть в базу ???Сохранять данные - зачем же ещё? Вы вообще против БД или где? Сохранять данные им надо уже сейчас, а дальше - больше, там уже и индексы начнут придумывать и транзакции (не хочется думать как это будет выглядеть в их реализации).
>>Зачем людем лезть в базу ???
>Сохранять данные - зачем же ещё?Зачем посторонним что-то сохранять в базе Nagios в обход интерфейса плагинов ?
>Вы вообще против БД или где?
Я против использования БД там где она не нужна.
>Зачем посторонним что-то сохранять в базе Nagios в обход интерфейса плагинов ?Я уже упоминал об этом - это наз-ся "остальной мир". Т.е. если я захочу интегрировать нагиос в свою систему слежения за сетью, или например написать нормальную морду для него, то мне придётся испытывать дикий дискомфорт и проделывать ненужную работу.
Если же сразу сделать всё на основе уже сложившихся стандартов - всё пучком и проект развивается с различных сторон. Например человек написавший свой "мега вэб-интерфейс" будет так-же коммитить свои наработки по ядру системы, вместо того, чтобы форкать проект и делать свой.
>Я уже упоминал об этом - это наз-ся "остальной мир". Т.е. если
>я захочу интегрировать нагиос в свою систему слежения за сетью, или
>например написать нормальную морду для него, то мне придётся испытывать дикий
>дискомфорт и проделывать ненужную работу.Прикрутите фильтр, который будет писать алерты в _нужном_вам_формате_ в _любой_ приемник данных, нужно в SQL - будет писать в SQL.
фильтры - это хорошо (серьёзно), но вот как я буду добавлять/изменять хосты? Надо с начала и до конца делать программу прозрачную.
>фильтры - это хорошо (серьёзно), но вот как я буду добавлять/изменять хосты?У меня раз в час запускается скрипт который при наличии изменений в базе строит файлы конфигурации nagios. Написал такой построитель с нуля за пару часов, если использовать готовые модули подобные Nagios::Config то меньше времени бы ушло.
>>Плагины - это не то. Про апи - дайте чтоли пример как
>>я например могу заюзать указанный АПИ из допустим жабки.
>http://www.nagios.org/faqs/viewfaq.php?faq_id=50Вы меня неправильно поняли - для Java. Но не суть - далее скажу.
>API для лога и конфига: http://search.cpan.org/~tobeya/Nagios-Object/
Ну на перле тут понятно разобрать не хитрое дело, надо более общо.>XML представление: http://nxe.sourceforge.net/
Вот за эту линку душевно благодарю, поковыряю, хотя прокладка получается не очень кошерная.>>Я про конфигурационный файл.
>Еще хуже. Править руками XML файл еще тот гемморой, более неудобный способ
>придумать трудно.Что неудобного? Посмотрите у ZOPE например - вполне читаемо, расширяемо, определён DTD и можно свои инструменты юзать.
>Кому нужно, пусть себе в XML лепят конфиг, а потом конвертируют в
>формат конфигов Nagios или возьмут в руки perl и Nagios::Config.Не могу согласится, что xml не поддаётся ручному редактированию. Он прост, элегантен и не требует никаких сверхестественных знаний.
>Вы утрируйте.
Согласен, но таки уверен, что гораздо удобнее было бы применение баз с самого начала, а не опосредовано.>У меня раз в час запускается скрипт который при наличии изменений в
>базе строит файлы конфигурации nagios. Написал такой построитель с нуляНу вот "ох как нелюблю" я такие методы. Ну вот нафига две одинаковых сущности хранить и заниматся их синхронизацией? Лучше уж или одно или другое пропатчить на предмет обнаружения чужого источника информации.
Итого: Вы меня убедили, что можно с нагиосом общатся как с нормальной программой, если дописать (выкачать?) пару модулей. Я в свою очередь не вижу (кроме как психологического момента) почему надо было выбирать такие кхм... неудобные схемы храниния данных по умолчанию.
>Я против использования БД там где она не нужна.Нужна она, нужна. Никто не хочет изучать все внутренности продукта, чтобы дописать/интегрировать его.
А, ты что юзаешь?
Zabbix надо юзать!
Zabbix -- это beta. Неинтуитивная бета. Пока кривая бета. Идеи хорошие, реализация подкачала с точки зрения юзабельности, особенно при >10 хостов
<Nagois молодцы, проще нужно делать, хотя сейчас модно все усложнять и доводить до крайностей.>
Полностью согласен с этим замечанием.
Чем проще - тем надежнее, система мониторинга должна быть по определению надежнее тех серверов за которыми бдит.
ну морда у него не такая уж и жуткая, да и новую можно натянуть...
а вот отсутствие заморочек на пхп/эскуэлях/прочей ботве радует. А при нехитрой доработке напильником вызывает настоящий восторг :)
Приятно.
А насчёт Zabbixa - правда... тяжковат при большом количестве хостов... Слабоинтуитивно как-то. Хотя идея с клиентом - хороша, меньше нагрузка на сервер (теоретически).