GUI konfiguracji Nagios [zamknięte]

Wdrożyliśmy Nagios dla usług w naszej sieci i działa świetnie. Powiadomienia są ładne, a szeroki zakres opcji konfiguracji jest bardzo przydatny. Do tego momentu całą konfigurację wykonaliśmy ręcznie, bezpośrednio modyfikując pliki.

Gdy zaczniemy to trochę otwierać dla niektórych innych administratorów, chciałbym wdrożyć GUI, który zmniejszy prawdopodobieństwo błędów. Sprawdziłem kilka różnych projektów GUI i do tej pory wydaje się, że NagiosQL i NConf są jak dotąd najlepszymi konkurentami.

Czy są jakieś zalecenia między tymi dwoma, a może inne, które należy rozważyć? Co powiesz na historie instalacji i użytkowania, „gotchas” i wskazówki, które mogą być przydatne w podejmowaniu decyzji?

Jesteśmy przed tą samą decyzją i obecnie nconf jest naszym ulubionym. Ma tę wielką zaletę, że jest zaprojektowany dla dużych rozproszonych środowisk.

Tworzy automatycznie pliki konfiguracyjne dla różnych serwerów nagios, z których jeden jest jakimś kolektorem, a drugi monitorem, który otrzymuje tylko bierne kontrole z colletora.

Z drugiej strony, obecnie nie możesz poradzić sobie z eskalacjami za pomocą nconf!

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

Używamy OpsView w pracy. Jest to internetowy interfejs GUI, który obsługuje skalowanie usługi Nagios za pomocą klastrowania. Możesz dodawać nowych hostów, nowe usługi przez Internet i potwierdzać awarię. Rejestruje także historyczny widok usług, jeśli chcesz wiedzieć, na przykład, ile procesora potrzebuje serwer regularnie.

Jednak nadal nie będzie można dodawać skryptów Nagios przez Internet.

Mamy dobre doświadczenie z Opsview do zarządzania Nagios. Błędem jest jednak uznanie tego za „front-end” dla Nagios; zamiast tego pomyśl o tym jak o systemie monitorowania, który wykorzystuje Nagios jako swój podstawowy silnik.

Konfiguracja Nagios jest przechowywana w DB, a pliki konfiguracyjne Nagios są generowane programowo, więc jeśli jesteś przyzwyczajony, powiedzmy, do przechowywania konfiguracji Nagios w kontroli źródła lub generowania ich za pomocą własnego skryptu, musisz zrezygnuj z tych procedur.

Zamiast tego otrzymasz:

• scentralizowane zarządzanie rozproszonym systemem Nagios
• zintegrowane zarządzanie pułapkami SNMP
• zintegrowany Nagiosgraph
• zintegrowany NMIS
• zautomatyzowane agregowanie statystyk i generowanie raportów
• nigdy więcej błędów składniowych w plikach konfiguracyjnych Nagios :)
• scentralizowane zarządzanie przestojami
• interfejs API XML, który udostępnia podzbiór funkcji zarządzania Opsview
• automatyczna migracja z istniejącej konfiguracji Nagios

-veve

Chodzi mi o to, że frontend konfiguracyjny może czasami tworzyć naprawdę zbędne pliki konfiguracyjne, których edytowanie ręcznie nie jest intuicyjne, jeśli zajdzie taka potrzeba. Jest to rodzaj problemu w każdym systemie, który korzysta z plików konfiguracyjnych generowanych maszynowo i jest dość dobrze zrozumiany, nawet jeśli nie jest intuicyjny.

Moje zwykłe podejście do Nagios polegało na szerokim użyciu funkcji szablonów i dziedziczenia oraz na podzieleniu moich konfiguracji na wiele, wiele, wiele, wiele plików.

Warto tutaj zauważyć, że społeczność Nagios rozwinęła się niedawno, ponieważ główny programista nie posiada umiejętności przywódczych, a Nagios naprawdę nie poprawił się ani nie zmienił wiele od dziesięciu lat. Icinga jest podobno nowy, ale jeszcze tego nie próbowałem.

UbuntuGeek właśnie opublikował dziś artykuł na ten temat. Jest zgodny z odpowiedzią http://www.ducea.com autorstwa Xerxesa, ale jest tylko trochę bardziej aktualny artykuł z dodanymi nowszymi projektami. W każdym razie, jest to dość szybki przegląd obejmujący kilka konfiguracji GUI Nagios, które powinien dać ci dobry punkt wyjścia.

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

edytować

Dzisiaj otworzyła się także nowa oficjalna giełda nagios, tutaj znajduje się link do sekcji Konfiguracja do szybkiego odniesienia:

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

Nconf nie obsługuje eskalacji usług i hostów

ale,

możesz „rozszerzyć” aplikację, aby obsługiwała ją bezpośrednio z interfejsu GUI poprzez menu administracyjne, tworząc dwie nowe klasy „hostescalation” i „serviceescalation” w każdej nowej klasie, musisz zdefiniować atrybut escalationid z ustawionym „Atrybutem nazewnictwa”, a nie zapisany w wypisuje dedykowany plik konfiguracyjny

następnie zdefiniuj dowolny atrybut związany z eskalacją, który musi zostać zapisany w pliku konfiguracyjnym, na przykład: nazwa_hosta połączona z klasą hosta grupy_kontaktu z listą klasy contactgroups i tak dalej

Z tego samego powodu, co Ty, musieliśmy wdrożyć interfejs. Osobiście uważam, że wszystkie są trochę niezdarne i wolałbym zarządzać plikami konfiguracyjnymi ręcznie (mniej wysiłku). Ale wygląda na to, że nie masz dużego wyboru.

Używamy monarchy, ale nie bardzo mi się to podoba.

Nie próbowałem też niczego innego, ale możesz zacząć tutaj ...

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

Zdecydowanie poleciłbym Centreon jako frontend Nagios. Ułatwia to nie tylko proces konfiguracji, ale może także służyć do wyświetlania statusu i gromadzenia danych o wydajności zwracanych przez kontrole Nagios, które następnie są przekształcane w ładnie wyglądające wykresy. W ten sposób, w pewnym sensie, zaciemniając również kaktusy.

Produkt detaliczny NagiosXI ma rozsądną cenę i ukrywa wszystkie podstawowe tekstowe pliki konfiguracyjne. Używamy go od około sześciu miesięcy i jesteśmy zadowoleni z jego kosztów / korzyści.