Nagios Daten (Clients etc.) aus Datenbank holen

EMSPascal

Anfänger

Beiträge: 16

Geburtstag: 28.12.1992 (18)

Geschlecht: Männlich

Wohnort: 49661

Beruf: Fachinformatiker / Systemintegration

Anzahl Nagios-Server: 1 - Einarbeitungsphase

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 65

Anzahl Services: 600

Betriebssystem(e): Ubuntu 10.10

Plugin-Version(en): 1.4.15

1

27.04.2011, 16:42

Hey,

ich denke mir, dass in größeren Unternehmen, Nagios sich die Daten aus Datenbanken holt.

Also nicht nur die Historie darin speichert, sondern auch, Clients, Checks, etc. aus Datenbanken holt.

Liege ich da richtig? Oder bin ich ganz falsch?

Seit mir nicht böse, falls die Frage total sinnlos ist, aber die Frage stelle ich mir schon länger.

Danke schonmal im Vorraus

Zum Seitenanfang

WolfgangF

Fortgeschrittener

Beiträge: 177

Geburtstag: 26.03.1969 (42)

Geschlecht: Männlich

Wohnort: Österreich

Anzahl Nagios-Server: 3

Hobbys: Jazz

Nagios-Version(en): 3.0.1

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: 380

Anzahl Services: 4100

Betriebssystem(e): Linux, Windows

Plugin-Version(en): 1.4.11

NDO-Version: 1.4b9

Sonstige Addon's: PNP-0.4.14

2

27.04.2011, 20:10

aber sicher doch
ich zum Bespiel hol mir Daten raus und überspiele sie in die CMDB von OTRS

Zum Seitenanfang

EMSPascal

Anfänger

Beiträge: 16

Geburtstag: 28.12.1992 (18)

Geschlecht: Männlich

Wohnort: 49661

Beruf: Fachinformatiker / Systemintegration

Anzahl Nagios-Server: 1 - Einarbeitungsphase

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 65

Anzahl Services: 600

Betriebssystem(e): Ubuntu 10.10

Plugin-Version(en): 1.4.15

3

28.04.2011, 09:50

Hey,

danke für die Antwort.

Aber wie sagst du Nagios, dass es/er (? xD) sich die Daten aus einer DB ziehen soll?

Danke

Zum Seitenanfang

WolfgangF

Fortgeschrittener

Beiträge: 177

Geburtstag: 26.03.1969 (42)

Geschlecht: Männlich

Wohnort: Österreich

Anzahl Nagios-Server: 3

Hobbys: Jazz

Nagios-Version(en): 3.0.1

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: 380

Anzahl Services: 4100

Betriebssystem(e): Linux, Windows

Plugin-Version(en): 1.4.11

NDO-Version: 1.4b9

Sonstige Addon's: PNP-0.4.14

4

28.04.2011, 11:07

ad 1) ich habe die Itcockpit Lösung von ITNovum und fülle neue Host dort ein, die NDO ist dann "nur" mehr das Endprodukt
ad 2) aus dem ITCockpit / NDO hole ich mir dann wieder Daten die ich in die CMBD einfülle
beides mache ich mit selbstgebastelten Script die die MySQL Datenbanken der System beackern
LG

Zum Seitenanfang

EMSPascal

Anfänger

Beiträge: 16

Geburtstag: 28.12.1992 (18)

Geschlecht: Männlich

Wohnort: 49661

Beruf: Fachinformatiker / Systemintegration

Anzahl Nagios-Server: 1 - Einarbeitungsphase

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 65

Anzahl Services: 600

Betriebssystem(e): Ubuntu 10.10

Plugin-Version(en): 1.4.15

5

28.04.2011, 12:29

Zitat

Itcockpit Lösung von ITNovum

Das hört sich kostenpflichtig an. Liege ich da richtig?

Ich möchte natürlich lieber auf dem guten Open Source Weg von Nagios bleiben.

Danke aber trotzdem für die Information

Zum Seitenanfang

WolfgangF

Fortgeschrittener

Beiträge: 177

Geburtstag: 26.03.1969 (42)

Geschlecht: Männlich

Wohnort: Österreich

Anzahl Nagios-Server: 3

Hobbys: Jazz

Nagios-Version(en): 3.0.1

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: 380

Anzahl Services: 4100

Betriebssystem(e): Linux, Windows

Plugin-Version(en): 1.4.11

NDO-Version: 1.4b9

Sonstige Addon's: PNP-0.4.14

6

28.04.2011, 15:05

eigentlich nicht- es gibt das opensource Projekt www.open-itcockpit.com

Zum Seitenanfang

dnsmichi

Meister

Beiträge: 2 039

Geburtstag: 30.05.1983 (27)

Geschlecht: Männlich

Wohnort: Wien

Beruf: DNS & Monitoring Developer

Anzahl Nagios-Server: 3

Nagios-Version(en): s/nagios/icinga/

Icinga-Version(en): 1.3.1 / GIT

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: 200+

Anzahl Services: 4000+

Betriebssystem(e): RHEL 5.6 x64

Plugin-Version(en): 1.4.15

IDO-Version: 1.3.1 / GIT MySQL/Postgresql/Oracle

Sonstige Addon's: PNP 0.6.11, check_mk GIT

7

28.04.2011, 15:42

RE: Nagios Daten (Clients etc.) aus Datenbank holen

Zitat von »EMSPascal«

ich denke mir, dass in größeren Unternehmen, Nagios sich die Daten aus Datenbanken holt.

es gibt verschiedene wege, die datenbank zu befuellen und daraus daten auszulesen. by default kennt nagios keinen davon.

wenn du die ndo (nagios data out) utils verwendest, kannst du mit bestimmten filtern daten von nagios via ndomod an ndo2db schicken, womit es dann in die db geschrieben wird (config, status und historische daten/tabellen).

wie du die daten verarbeitest - bspweise durch eine alternative gui oder mittels checkscript - das bleibt dir ueberlassen. du kannst auf monitoringexchange.org mal suchen, obs da was gibt. prinzipiell gibts eigene loesungen, wo man sich aus der db das rauspickt was man braucht.

Zitat von »EMSPascal«

Also nicht nur die Historie darin speichert, sondern auch, Clients, Checks, etc. aus Datenbanken holt.

die nagios cgis als gui koennen das nicht. aber wenn du dir die struktur der ndoutils ansiehst, wirst du alles moegliche finden, womit du arbeiten kannst.
ich verweise da mal frech in die icinga idoutils dokumentation, da das dort aehnlich ist (und es von den ndoutils keine online doku gibt)
http://docs.icinga.org/latest/de/ch12.html

ob du dafuer jetzt eine komplette suite installierst, oder lediglich ndoutils, bleibt dir ueberlassen. spass macht ndoutils keinen, egal wo(mit) es installiert ist.

Icinga 1.3 MySQL,PGSQL,Oracle and IPv6

Demos
Docs: http://docs.icinga.org

Report bugs/Feature requests

* egrep -v "^#|^$" configfile
* check https://dev.icinga.org

Join us online!
irc.freenode.net #icinga-devel

Using Icinga? Tell us!

Zum Seitenanfang

EMSPascal

Anfänger

Beiträge: 16

Geburtstag: 28.12.1992 (18)

Geschlecht: Männlich

Wohnort: 49661

Beruf: Fachinformatiker / Systemintegration

Anzahl Nagios-Server: 1 - Einarbeitungsphase

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 65

Anzahl Services: 600

Betriebssystem(e): Ubuntu 10.10

Plugin-Version(en): 1.4.15

8

28.04.2011, 18:13

@ dnsmichi

Sehr gute und hilfreiche Antwort. Danke dafür.

Aber ich frage mich gerade, ob das überhaupt Leute machen, also Clients, Checks, etc aus Datenbanken zu holen.

Macht das jemand von euch? Oder ist das überhaupt sinnvoll?

Zum Seitenanfang

dnsmichi

Meister

Beiträge: 2 039

Geburtstag: 30.05.1983 (27)

Geschlecht: Männlich

Wohnort: Wien

Beruf: DNS & Monitoring Developer

Anzahl Nagios-Server: 3

Nagios-Version(en): s/nagios/icinga/

Icinga-Version(en): 1.3.1 / GIT

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: 200+

Anzahl Services: 4000+

Betriebssystem(e): RHEL 5.6 x64

Plugin-Version(en): 1.4.15

IDO-Version: 1.3.1 / GIT MySQL/Postgresql/Oracle

Sonstige Addon's: PNP 0.6.11, check_mk GIT

9

28.04.2011, 23:15

es stellt sich die frage, wofuer du das anwenden willst.

wenns drum geht, langzeit daten, wie etwa host/servicechecks zu archivieren, kann man auf die db zurueckgreifen (tipp an dieser stelle - max_*checks_age in ndo2db.cfg auskommentieren und die tables selbst nach alter verschieben/partitionieren). das ist bspweise eine gaengige methodik, um anstelle der rrds (deren aufloesung mit dem alter abnimmt) einen langen zeitraum checkdaten vorzuhalten und daraus graphen zu generieren. da gibts irgendwo ein addon, das genau diese daten aus der ndo db holt.

man kann auch in einer zentralen db dependencies abbilden, wenn man in einem speziellen setup lebt, wo die verschiedenen instanzen nichts voneinander wissen (duerfen) und man so bestimmte beziehungen abbilden kann. ist aber mehr eine kruecke, weil man dabei die abhaengigkeit von einer db (in dem fall mysql) hat. dem kann man dagegenhalten, dass cacti sowieso eine mysql db verwendet, um alles zu configurieren bzw werte vom snmp poller zu speichern.

weiters kann man natuerlich alles in eine db schreiben lassen, die irgendwo steht, wovon wiederum von irgendwo via gui oder aehnlichem die daten jemandem (kunde) gezeigt werden. der weg geht dabei vom core richtung db und nicht retour (mancher mag jetzt auf livestatus verweisen, ich bin aber kein freund von livestatus-abfragen, getriggert durch $kunde, der refresh klickt).

man kann die daten aber auch sonstig verwurschten - das bleibt dir ueberlassen, und bevor du das tatsaechlich angehst, solltest du dir ueberlegen ob du das wirklich brauchst bzw wie dus anwenden willst. das nagios development rund um die ndoutils ist mehr oder weniger tot, zumindest das was man gratis als oss bekommt. (darum gibts u.a. icinga)

Icinga 1.3 MySQL,PGSQL,Oracle and IPv6

Demos
Docs: http://docs.icinga.org

Report bugs/Feature requests

* egrep -v "^#|^$" configfile
* check https://dev.icinga.org

Join us online!
irc.freenode.net #icinga-devel

Using Icinga? Tell us!

Zum Seitenanfang

EMSPascal

Anfänger

Beiträge: 16

Geburtstag: 28.12.1992 (18)

Geschlecht: Männlich

Wohnort: 49661

Beruf: Fachinformatiker / Systemintegration

Anzahl Nagios-Server: 1 - Einarbeitungsphase

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 65

Anzahl Services: 600

Betriebssystem(e): Ubuntu 10.10

Plugin-Version(en): 1.4.15

10

29.04.2011, 09:00

Also ICH brauche es nicht. Denke ich. Nur kam mein Chef zu mir an, und fragte, ob man die ganzen Clients etc. nicht aus einer DB holen kann.

Ich würde gerne auch nochmal wissen, wie Ihr da vorgeht.

Habt Ihr die Host´s, die Ihr monitored, in dem Objects Ordner in Nagios in einer bspw. Hosts.cfg liegen?

Oder macht Ihr es ganz anders?

Gruß

Zum Seitenanfang

pitchfork

Super Moderator

Beiträge: 14 496

Geburtstag: 13.06.1971 (39)

Geschlecht: Männlich

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

11

29.04.2011, 09:23

Zitat von »EMSPascal«

Habt Ihr die Host´s, die Ihr monitored, in dem Objects Ordner in Nagios in einer bspw. Hosts.cfg liegen?

Da Nagios seine config NIE aus einer Datenbank liest, gibt es auch keinen anderen Weg.

Man kann aber die *.cfg Files für Nagios ja aus einer Datenbank erzeugen.

PNP Developer.
PNP 0.6.12 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

Zum Seitenanfang

dnsmichi

Meister

Beiträge: 2 039

Geburtstag: 30.05.1983 (27)

Geschlecht: Männlich

Wohnort: Wien

Beruf: DNS & Monitoring Developer

Anzahl Nagios-Server: 3

Nagios-Version(en): s/nagios/icinga/

Icinga-Version(en): 1.3.1 / GIT

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: 200+

Anzahl Services: 4000+

Betriebssystem(e): RHEL 5.6 x64

Plugin-Version(en): 1.4.15

IDO-Version: 1.3.1 / GIT MySQL/Postgresql/Oracle

Sonstige Addon's: PNP 0.6.11, check_mk GIT

12

29.04.2011, 12:36

Zitat von »EMSPascal«

ob man die ganzen Clients etc. nicht aus einer DB holen kann.

ach da gehts eh nur um object config, keinerlei 'after-check-results'. fuer solche zwecke gibts tools wie nconf, nagiosql, etc die die config db basiert abspeichern, und aus denen dann die cfgs generiert werden. geb ich aber keine empfehlung ab, da ich es selbst noch nie verwendet habe - prinzipiell kann man sich object cfgs auch selbst erzeugen, so wie checkmk das bspweise macht.

Icinga 1.3 MySQL,PGSQL,Oracle and IPv6

Demos
Docs: http://docs.icinga.org

Report bugs/Feature requests

* egrep -v "^#|^$" configfile
* check https://dev.icinga.org

Join us online!
irc.freenode.net #icinga-devel

Using Icinga? Tell us!

Zum Seitenanfang

Tommi

Schüler

Beiträge: 101

Geschlecht: Männlich

Beruf: Oracle DBA

Anzahl Nagios-Server: 2

Nagios-Version(en): 1.3

Icinga-Version(en): 1.3.0

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 14

Anzahl Services: 33

Betriebssystem(e): CentOS5.5,Windows,Solaris10 Sparc

Plugin-Version(en): 1.4.15

IDO-Version: 1.3.0

Sonstige Addon's: pnp4nagios0.6.11,icinga-web,ido2db auf Oracle

13

29.04.2011, 13:05

Vielleicht ist es eine gute Idee, nicht nur die Config über NDO/IDO in die DB zu pumpen, sondern sie in einem zukünftigen Release auch direkt von dort zu laden. Incl. der Möglichkeit, über eine GUI die Daten dort zu manipulieren und dann zu aktivieren.

Zum Seitenanfang

dnsmichi

Meister

Beiträge: 2 039

Geburtstag: 30.05.1983 (27)

Geschlecht: Männlich

Wohnort: Wien

Beruf: DNS & Monitoring Developer

Anzahl Nagios-Server: 3

Nagios-Version(en): s/nagios/icinga/

Icinga-Version(en): 1.3.1 / GIT

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: 200+

Anzahl Services: 4000+

Betriebssystem(e): RHEL 5.6 x64

Plugin-Version(en): 1.4.15

IDO-Version: 1.3.1 / GIT MySQL/Postgresql/Oracle

Sonstige Addon's: PNP 0.6.11, check_mk GIT

14

29.04.2011, 16:17

eine derartige db dependency am core halte ich fuer aeusserst gefaehrlich, gerade so wie der aktuelle core gebaut ist (was passiert wenn die config db haengt?). besser waere eine core api, die config input erlaubt (anstelle der plain text files) und es den db basierten gui tools es selbst ueberlassen bleibt, ob und wie sie die configs dem core zufuehren. bei den config tools mit db muss man das rad zudem nicht neu erfinden, denke ich - sieht nach viel arbeit aus, das ansprechend zu gestalten.

Icinga 1.3 MySQL,PGSQL,Oracle and IPv6

Demos
Docs: http://docs.icinga.org

Report bugs/Feature requests

* egrep -v "^#|^$" configfile
* check https://dev.icinga.org

Join us online!
irc.freenode.net #icinga-devel

Using Icinga? Tell us!

Zum Seitenanfang

bern

Profi

Beiträge: 1 355

Anzahl Nagios-Server: 2-5

Nagios-Version(en): 1-3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 80-200

Anzahl Services: 1400-2000

Betriebssystem(e): Linux

Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)

Sonstige Addon's: n2rrd, PNP, livestatus

15

29.04.2011, 17:44

Zitat von »Tommi«

Vielleicht ist es eine gute Idee, nicht nur die Config über NDO/IDO in die DB zu pumpen, sondern sie in einem zukünftigen Release auch direkt von dort zu laden. Incl. der Möglichkeit, über eine GUI die Daten dort zu manipulieren und dann zu aktivieren.

Nagios-Portal gestern: "Schau' 'mal in die objects.cache und zeig' uns die einschlägigen Definitionen."

Nagios-Portal heute: "Paste doch bitte die Ausgabe eines 'SELECT * FROM NAGCONF_SERVICES WHERE ...'" - "Oh, guter Tipp, ich seh' da grad' 'was ... 'UPDATE VERSTEH_ICH_NICHT=NULL WHERE ...'" - *ZZZAPP*

Nagios-Portal morgen: "Ich hab' 'mal zusätzlichen Webspace gemietet für die ganzen Screenshots, könnte da bitte 'mal einer drübergucken ..."

...

Etwas ernsthafter: Ich kann mir vorstellen, die Nagios-Config an eine DB anzubinden - was nicht notwendigerweise dasselbe ist wie die Configs 1:1 in die DB zu schmeißen. Dann muß sich die gesteigerte Komplexität aber auch lohnen, z.B. dadurch, daß man ein Versionierungssystem dazubekommt (wir hatten doch vor 'nem halben Jahr 'mal 'ne Testmaschine für XY, welche IP war das nochmal ...) oder Erweiterbarkeit (Nagios, DNS, das Inventarisierungssystem und weiß der Himmel was sonst noch kennen eine gemeinsame Rechnerpopulation und bauen von dort mit ihren individuellen Tables weiter) oder ... .

(Erwähnte ich schon, daß ich heute einem gerade erst aufgesetzten James die komplette DB abräumen und neu aufbauen durfte, weil die irgendwie enen User / eine Mailbox plötzlich doppelt hatte, keine Tools zum Fixen, POP3 Login durch Verletzung der Unique Constraint blockiert, etc. ... ? :thumbdown:

)

Zum Seitenanfang

dnsmichi

Meister

Beiträge: 2 039

Geburtstag: 30.05.1983 (27)

Geschlecht: Männlich

Wohnort: Wien

Beruf: DNS & Monitoring Developer

Anzahl Nagios-Server: 3

Nagios-Version(en): s/nagios/icinga/

Icinga-Version(en): 1.3.1 / GIT

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: 200+

Anzahl Services: 4000+

Betriebssystem(e): RHEL 5.6 x64

Plugin-Version(en): 1.4.15

IDO-Version: 1.3.1 / GIT MySQL/Postgresql/Oracle

Sonstige Addon's: PNP 0.6.11, check_mk GIT

16

29.04.2011, 19:15

Zitat von »bern«

Nagios-Portal gestern: "Schau' 'mal in die objects.cache und zeig' uns die einschlägigen Definitionen."

Nagios-Portal heute: "Paste doch bitte die Ausgabe eines 'SELECT * FROM NAGCONF_SERVICES WHERE ...'" - "Oh, guter Tipp, ich seh' da grad' 'was ... 'UPDATE VERSTEH_ICH_NICHT=NULL WHERE ...'" - *ZZZAPP*

Nagios-Portal morgen: "Ich hab' 'mal zusätzlichen Webspace gemietet für die ganzen Screenshots, könnte da bitte 'mal einer drübergucken ..."

das klingt vielleicht bloed, aber du triffst den nagel auf den kopf.

ich persoenlich fuerchte mich vor dem support overload, den eine db dependency verursachen wird. (wir sind eine open source community, wir helfen uns gegenseitig, aber irgendwann wirds problematisch)

es ist jetzt schon absolut kein spass, leuten (die jetzt mal verallgemeinert keine ahnung von sql und aehnlichem haben) zu erklaeren, warum im icinga-web keine daten vorhanden sind und wie man das in der db verifiziert. ich beobachte das nun schon eine weile, und so wie es sich entwickelt, sollten wir mit bedacht daran arbeiten, die datenbank dinge moeglichst einfach zu gestalten - mit denen wir leben muessen - uns aber nicht noch neue eintreten.
ich bin froh, dass es projekte wie nagiosql oder nconf gibt, die sich mit der text config schnittstelle weiterentwickeln koennen (und deren db schema deren sache bleibt). natuerlich sind auch projekte wie mklivestatus ein schritt in die richtige richtung, weg von einer db abhaengigkeit (das vereinfacht den support - mit der implementierung bin ich aus anderen gruenden nicht gluecklich).

meiner meinung nach sollte man sich zusammensetzen, und eine core api designen, die sowohl input als auch output anbietet, verschiedene kanaele (datenoutput, perfdata, commands, configs, etc) und anhand dieser schnittstellen entsprechende mechanismen implementieren, die mit diesen daten umgehen - sei es ein livestatus socket, sei es eine relationale datenbank die liest/schreibt, sei es ein configtool, das irgendwo in einer mongodb schlummert.

dann kann man auch das db schema der NDO/IDO redesignen, gewisse vorzuege von merlin implementieren und auch passende views fuer guis bereitstellen - was addon entwicklern mehr moeglichkeiten bieten wird.

(ich weiss dass es sich leicht redet. ich hab auch selbst grade keine zeit dafuer. icinga+checkmk+pnp muss deployed werden)

Icinga 1.3 MySQL,PGSQL,Oracle and IPv6

Demos
Docs: http://docs.icinga.org

Report bugs/Feature requests

* egrep -v "^#|^$" configfile
* check https://dev.icinga.org

Join us online!
irc.freenode.net #icinga-devel

Using Icinga? Tell us!

Zum Seitenanfang

EMSPascal

Anfänger

Beiträge: 16

Geburtstag: 28.12.1992 (18)

Geschlecht: Männlich

Wohnort: 49661

Beruf: Fachinformatiker / Systemintegration

Anzahl Nagios-Server: 1 - Einarbeitungsphase

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 65

Anzahl Services: 600

Betriebssystem(e): Ubuntu 10.10

Plugin-Version(en): 1.4.15

17

02.05.2011, 20:46

Wow, da haben sich sehr viele interessante Beiträge über das Wochenende angesammelt.

Ich habe das Wochenende an der Nordsee verbracht und kann leider erst jetzt wieder zu Wort kommen

Leider ist wohl eine Zwischenfrage von mir in der Zeit untergegangen, aber ich würde gerne nochmal wissen, ob Ihr eure Hosts, auch ganz nochmal in die bspw. Hosts.cfg schreibt?!

Ich denke da einfach nur dran, das es bei z. B. 300 Hosts sehr unübersichtlich werden kann, oder?

Zum Seitenanfang

Wolfgang

Erleuchteter

Beiträge: 5 284

Geschlecht: Männlich

Anzahl Nagios-Server: 2

Nagios-Version(en): 3.2.1

Icinga-Version(en): Icinga 1.0.1

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: >70

Anzahl Services: >200

Betriebssystem(e): SLES10

Plugin-Version(en): 1.4.11

Sonstige Addon's: NRPE 2.6, NSCA 2.7, PNP 0.4.14 / 0.6

18

02.05.2011, 22:26

Zitat

aber ich würde gerne nochmal wissen, ob Ihr eure Hosts, auch ganz nochmal in die bspw. Hosts.cfg schreibt?!

Ich denke da einfach nur dran, das es bei z. B. 300 Hosts sehr unübersichtlich werden kann, oder?

Es gibt keine allgemeingültige Antwort, weil es u.a. von den organisatorischen Anforderungen abhängig. Wenn man 300 Drucker in einem Unternehmen hat, dann kann man 300 Definitionen in eine Datei packen und wenn 300 Hosts auf fünf Niederlassungen verteilt sind, dann kann man fünf Dateien anlegen (oder auf 50 oder pro Host eine Datei).

Nagios-Doc: Wiki-Format (3.x) oder als (3.0.6)

Icinga-Doc: (de) (en)

PNP-Troubleshooting (de) (en)

Zum Seitenanfang

pitchfork

Super Moderator

Beiträge: 14 496

Geburtstag: 13.06.1971 (39)

Geschlecht: Männlich

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

19

03.05.2011, 10:19

Zitat von »EMSPascal«

Leider ist wohl eine Zwischenfrage von mir in der Zeit untergegangen, aber ich würde gerne nochmal wissen, ob Ihr eure Hosts, auch ganz nochmal in die bspw. Hosts.cfg schreibt?!

Es ist vollkommen egal wie die config Datei heist. Von mir aus nenn sie mein-tolle-config.cfg
Hauptsache die sagst Nagios in der nagios.cfg über cfg_file oder cfg_dir das es sich um eine Object Config Datei handelt.

Weiterhin ist es auch egal ob die die config von Hand schreibst, oder per Script erstellst.
Wenn du die config automatisch erstellst, ist es auch möglich das die Daten aus einer DB stammen.

Die Grenze ist schlicht deine Phantasie.
Nagios wird nur die die Config selbst aus einer DB lesen und das ist auch gut so.

PNP Developer.
PNP 0.6.12 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

Zum Seitenanfang

Tommi

Schüler

Beiträge: 101

Geschlecht: Männlich

Beruf: Oracle DBA

Anzahl Nagios-Server: 2

Nagios-Version(en): 1.3

Icinga-Version(en): 1.3.0

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 14

Anzahl Services: 33

Betriebssystem(e): CentOS5.5,Windows,Solaris10 Sparc

Plugin-Version(en): 1.4.15

IDO-Version: 1.3.0

Sonstige Addon's: pnp4nagios0.6.11,icinga-web,ido2db auf Oracle

20

03.05.2011, 13:24

Zitat

meiner meinung nach sollte man sich zusammensetzen, und eine core api designen, die sowohl input als auch output anbietet,

Weiterhin ist es auch egal ob die die config von Hand schreibst, oder per Script erstellst.
Wenn du die config automatisch erstellst, ist es auch möglich das die Daten aus einer DB stammen.

So sehe ich das auch. Wo die Config intern verarbeitet wird, ist unabhängig. Wenn es für Nagios Core einfacher ist, die Config von Files zu laden, könnte es für Icinga im Idealfall auch mal die Möglichkeit/Option geben, komplett ohne Files zu arbeiten . Aber ich finde, die Möglichkeit Syntax Fehler in manuell editierte Textfiles reinzubauen ist in größeren Installationen mehrfach höher als die entweder direkt aus einer DB zu laden oder automatisch beim Start aus einer DB zu generieren.

Zitat

eine derartige db dependency am core halte ich fuer aeusserst gefaehrlich, gerade so wie der aktuelle core gebaut ist (was passiert wenn die config db haengt?).

Das hängt sicherlich vom Umfeld ab. Oft braucht man in kleineren Umgebungen keine DB,weil es noch übersichtlich ist, In vielen größeren Applikationen ist es jedoch normal, das eine funktionierende DB vorausgestzt wird und genau für diese Anwender mit sehr vielen Hosts und Services wäre eine integrierte DB-basierte Lösung mit offizieller GUI ein Segen.

Zitat

Nagios-Portal gestern: "Schau' 'mal in die objects.cache und zeig' uns die einschlägigen Definitionen."

Nagios-Portal heute: "Paste doch bitte die Ausgabe eines 'SELECT * FROM NAGCONF_SERVICES WHERE ...'" - "Oh, guter Tipp, ich seh' da grad' 'was ... 'UPDATE VERSTEH_ICH_NICHT=NULL WHERE ...'" - *ZZZAPP*

Dieses Supportverfahren finde ich ohnehin heute schon problematisch.Warum nicht zukünftig mal so:

"Klicke auf 'Make support bundle' bzw run 'make_support_bundle.sh" und schicke das generierte File anstatt jede einzelne Komponente extra anzufordern. "Update xyz" muss der Anwender uU. gar nicht zu Gesicht bekommen, wenn es eine Gui oder eine "Apply Patch"-Methode gibt.

Nur mal als Anstoss zum Überlegen

Thomas

Zum Seitenanfang

Nagios-/Icinga-Portal