GUI конфігурації Nagios [закрито]

Ми впровадили Nagios для сервісів у нашій мережі, і це чудово працює. Повідомлення хороші, а широкий спектр параметрів конфігурації дуже зручний. До цього моменту все налаштування було зроблено вручну, безпосередньо змінюючи файли.

Поки ми починаємо трохи відкривати це для деяких інших адміністраторів, я хотів би застосувати графічний інтерфейс, який зменшить ймовірність помилок. Я перевірив кілька різних GUI-проектів, і поки що, здається, NagiosQL і NConf - найкращі претенденти.

Чи є якісь рекомендації між цими двома, чи, можливо, іншими, які слід врахувати? Як щодо історій встановлення та використання, "готчей" та порад, які можуть бути корисними при прийнятті рішення?

Ми перед тим самим рішенням, і в даний час nconf - наш улюблений. Він має велику перевагу бджільництва, розробленого для великих розподілених середовищ.

Він створює автоматичні файли конфігурації для різних серверів nagios, один отримує якийсь колектор і один монітор, який отримує тільки пасивні чеки від колектора.

З іншого боку, наразі ви не можете впоратися з ескалаціями з nconf!

http://sourceforge.net/apps/mediawiki/nconf/index.php?title=Main_Page

Ми використовуємо OpsView на роботі. Це веб-інтерфейс GUI, який обробляє такі речі, як масштабування послуги Nagios за допомогою кластеризації. Ви можете додавати нових хостів, нові сервіси через Інтернет та підтверджувати відключення. Він також записує історичний вигляд сервісів, якщо ви хочете знати такі речі, як кількість процесора, якому регулярно потрібен сервер.

Однак ви все одно не зможете додавати сценарії Nagios через Інтернет.

Ми мали хороший досвід роботи з Opsview щодо управління Nagios. Однак помилково вважати це Нагіосом як "передовим"; натомість подумайте про це як про систему моніторингу, яка використовує Nagios як основний двигун.

Конфігурація Nagios зберігається в БД, а конфігураційні файли Nagios генеруються програмно, тому якщо ви звикли, скажімо, зберігати свої конфігурації Nagios у керуванні джерелом або генерувати їх за допомогою власного сценарію, вам потрібно буде відмовтеся від цих процедур.

Що ви отримуєте натомість, включає в себе наступне:

• централізоване управління розподіленою системою Nagios
• інтегроване управління захопленнями SNMP
• інтегрований Нагіограф
• інтегрований NMIS
• автоматизована агрегація статистики та створення звітів
• більше немає синтаксичних помилок у ваших файлах конфігурації Nagios :)
• централізоване управління простоями
• API XML, який відкриває підмножину функціоналу управління Opsview
• автоматизована міграція з наявного конфігурації Nagios

-віст

Наслідком цього я є те, що інтерфейс конфігурації іноді може створювати дійсно смішні конфігураційні файли, які не інтуїтивно редагувати вручну, якщо вам потрібно пізніше. Це певна проблема з будь-якою системою, яка використовує машинні файли конфігурації, і досить добре розуміється, навіть якщо це не інтуїтивно зрозуміло.

Моїм звичайним підходом до Nagios було широко використовувати функції шаблону та успадкування та розділити мої конфігурації на багато, багато, багато, багатьох файлів.

Тут варто зауважити, що нещодавно спільнота Nagios роздвоєна через те, що основний розробник не вистачає лідерських навичок, а Nagios насправді за десять років не покращився чи змінився. Icinga нібито новий класний, але я його ще не пробував.

Сьогодні UbuntuGeek опублікував статтю на цю тему. Це так само, як і http://www.ducea.com відповідь Xerxes, але лише трохи більш актуальну статтю з деякими новими проектами, доданими. У будь-якому разі, її гідний швидкий огляд, що охоплює декілька Nagios config gui, які має дати вам добру вихідну точку.

http://www.ubuntugeek.com/nagios-configuration-tools-web-frontends-or-gui.html

редагувати

Нова офіційна біржа nagios також відкрита сьогодні, ось посилання на розділ Конфігурація для швидкого ознайомлення:

http://exchange.nagios.org/directory/Addons/Configuration

Nconf не підтримує ескалацію служб та хостів

але,

ви можете "розширити" додаток, щоб підтримувати його безпосередньо з веб-гуї через меню адміністрування, створивши два нові класи "хостескаляція" та "обслуговуванняескаляція" у кожному новому класі. Ви повинні визначити атрибут ескалаціоніду з набором "Назви атрибути", а не записувати на вихід спеціального файлу конфігурації

потім визначте будь-який атрибут, пов’язаний з ескалацією, який повинен бути записаний у файл конфігурації, наприклад: ім'я хоста, пов’язане з контактом_груп хост-класу, до списку класів груп контактів тощо

З тієї ж причини, що і ви, нам довелося реалізувати фронт-енд. Особисто я вважаю їх трохи незграбними і вважаю за краще керувати файлами конфігурації вручну (менше зусиль). Але, схоже, у вас немає великого вибору.

Ми використовуємо монарха, але мені це все не подобається.

Я ще нічого не пробував, але ви можете почати тут ...

http://www.ducea.com/2008/01/16/10-nagios-web-frontends/

Я б точно рекомендував Centreon як фронтал Nagios. Це не тільки полегшує процес конфігурації, але також може бути використане для відображення статусу та збору даних про продуктивність, повернених чеками Nagios, що, ніж перетворюється на красиві графіки. Таким чином, певним чином, застаріли і кактуси.

Продукт роздрібної торгівлі NagiosXI за доступними цінами і приховує всі основні текстові файли конфігурації. Ми використовуємо його близько півроку і задоволені його витратами / вигодами.