Nagios-/Icinga-Portal

Hi,

wenn du die status.dat meinst, ja da stehen die auch noch mal direkt drinnen. Das zusätzliche speichern aller Daten ist nur für die Nutzung des Icinga Webs nötig, nicht für das Classic Webinterface.

pnp4nagios hat seine ganz eigenen Daten. Die zieht er nicht aus der Datenbank.

Zitat

ist das nicht komplett blöd, dass man 3 unterschiedliche Datenquellen hat?

Wieso? Gerade die Möglichkeiten zu haben, die Daten aus verschiedenen Datenquellen holen zu können, macht das Ganze doch erst flexible.

Zitat

Außerdem ist ja dann alles doppelt und dreifach abgespeichert.
Kann man das Classic Webinterface nicht auch auf MySQL umstellen und die status.dat deaktivieren?

Nein, weil es so einem die Möglichkeit bietet, bei einem Ausfall der DB, weiter arbeiten zu können.

Zitat

Ich meine MySQL ist doch ziemlich ineffizient bei einer großen Datenmenge, die jedoch statisch ist?

Verstehe nicht ganz was Du damit meinst? Wieso ist MySQL ineffizient bei einer großen Datenmenge? Du kannst ja auch eine Oracle-DB einsetzen.

Gruß
Michael

Zitat

Naja es sind 3 x die gleichen Daten. Einmal pnp4nagios, einmal die interne Icinga Speicherung und dann nochmal alles in der Datenbank.
Die Gefahr ist einfach das die Daten nicht überall die gleichen sind.
Außerdem wird ja dadurch unnötig Speicherplatz benötigt.

Bist du sicher, daß du die einzelnen Speicherungsformate wirklich kennst?
- die "interne" Speicherung stellt lediglich eine Momentaufnahme dar und enthält den Status der letzten Überprüfung
- PNP legt die Daten in RRD-Dateien ab (siehe u.a. hier)
- die Datenhaltung in der Datenbank sorgt für die Ablage der Daten über einen Zeitraum, den du im Prinzip selbst festlegst.

Zitat

Aber Icinga hat doch auch im Core eine Reporting Funktion, d.h es wird nicht nur der aktuelle Status sondern noch mehr gespeichert?

Schau mal hier.

Zitat

RRD ist auch noch ein Thema. Normalerweise wird nach einer bestimmten Zeit wieder die ältesten Daten überschrieben. Ich möchte aber nicht das irgendwelche Daten (auch wenns sie alt sind) überschrieben werden, da über Jahre hinweg Auswertungen gefahren werden sollen.

Keiner hindert dich, die Standardeinstellungen zu ändern, oder selbst Graphen aus der Datenbank zu erstellen.

Zitat von »nagios9«

Kann man das Classic Webinterface nicht auch auf MySQL umstellen und die status.dat deaktivieren?

Könnte man. Grob gesprochen ist die status.dat die Auswahl der jeweils letzten Daten zu jedem Host und Service.

Ob es wirklich sinnvoll ist, die Daten, die die Classic UI garantiert als allererste benötigen wird und die im laufenden Core notwendigerweise aktuell vorhanden sind, erst noch in ein dickes DB-Backend zu stopfen und bei jedem Seitenaufruf wieder 'rauszuSELECTen, ist allerdings eine andere Frage. Da halte ich so etwas wie livestatus für den aussichtsreicheren Kandidaten - mangels plattformübergreifender Ramdisk-Tools, die man der status.dat per Default ins Kreuz schmeißen könnte.

Zitat von »nagios9«

Ich möchte auch nach 3 Jahren jeden Status vor 3 Jahren noch nachvollziehen können.

Dann könnte diese DB sicherlich auch die Daten bereitstellen, die bei PNP standardgemäß in die RRDs laufen. Allerdings wirst Du Dir die Tools, die sie tatsächlich abrufen und in annehmbarer Zeit einen Graphen über das letzte Jahr (also z.B. 365 Tage x alle 5 Minuten x 4 Werte, obwohl man im fertigen Graphen kaum die Woche exakt ablesen können wird ...) fabrizieren, wahrscheinlich selbst schreiben müssen.

Zitat

Ich meinte aber die standardmäßig vorhandene Verfügbarkeits-Auswertungen die im icinga core schon vorhanden sind.

Die holt sich die Informationen aus den Log-Dateien (siehe u.a. hier und hier).

Zitat

Auf pnp4nagios.org habe ich leider keinen Artikel gesehen wie man die Standardeinstellung abändert das keine Daten überschrieben werden.

Vielleicht sollten wir erstmal klären, wie genau die Auflösung sein muß bzw. was du wirklich darstellen willst.

Zitat von »nagios9«

Auf pnp4nagios.org habe ich leider keinen Artikel gesehen wie man die Standardeinstellung abändert das keine Daten überschrieben werden.

Unter PNP liegt RRD und das verwendet von vornherein Ringbuffer mit vorgegebenen (statt von der tatsächlichen Messung getriggerten) Zeittakten. Fallen in einer Zeitscheibe mehrere Messungen an, sind die Daten bereits in dem Moment (durch Mittelwerte u.ä.) "überschrieben", in dem sie in der RRD ankommen.

Explizites Ziel der Übung ist übrigens, daß die RRD Files von vornherein in ihrer finalen Größe angelegt werden können, statt im Stillen bis in alle Ewigkeit zu wachsen (bis die Platte platzt). Auch ein "auf ewig behalten" der aggregierten Daten ist mithin prinzipiell nicht vorgesehen.

Zitat von »nagios9«

Naja standardmäßig wird bei IDO auch alle Daten reingeschrieben, also sind doch ansich schon alle Daten vorhanden?

Standardmäßig fliegen sie aus der IDO (IIRC defaultmäßig nach 30 Tagen) auch wieder 'raus, denn eine geplatzte Platte wird nicht dadurch schöner, daß noch eine DB zwischen Block Device und Nutzdaten herumwurstelt.

Zitat von »nagios9«

Es geht aber auch um Protokollierung. Ein Ausfall der Internetleitung muss z.B. exakt auswertbar sein, da dies die Geschäftsleitung verlangt.

Schönen Gruß an die Geschäftsleitung, sie möchten 'mal darüber nachdenken, warum wohl selbst bei geldnotunverdächtigen Betrieben wie Banken die Archive irgendwann von der operativen Datenbank auf spezielle (Offline-)Langzeitspeichermedien umverlagert werden.

Zitat von »nagios9«

Kann man das Classic Webinterface nicht auch auf MySQL umstellen und die status.dat deaktivieren?

wenn das so einfach waere, haette ich es schon implementiert als alternative zur status.dat - schau dir den cgi code an und sag mir dann ob du es fuer moeglich haeltst, da noch eine rdbms dependency reinzumurksen. lieber ein anderes natives backend, das mit dem core kommuniziert imho. nur das braucht noch zeit - mit ricardo's log filtern sind wir da aber auf gutem wege denke ich.

Zitat von »nagios9«

Das neue Webinterface ist mir zu unübersichtlich.

genau deshalb gibts den fallback der classic ui, die sukzessive erweitert wird - vgl status header in 1.4

Zitat von »nagios9«

Kann man wenn sich die DB (rrd oder?) von pnp4nagios nicht mehr funktioniert auch aus MySQL die Datenbank wiederherstellen?

rrds werden aus performance daten innerhalb des processes von pnp4nagios erzeugt. von dem her gesehen - wenn du dem ding perfdaten lieferst, kann es diese auch verarbeiten. davon abhaengig ob du deinen event broker options / data processing options auch erlaubt hast, *checks in die db zu schreiben, wirst du in icinga_*_checks eine column 'perfdata' finden, die du fuer diese zwecke heranziehen kannst. es gibt diverse scripts die das so machen. wenn mans allerdings archiviert bearbeiten moechte, empfiehlt sich ein bisschen rdbms tuning, partitionierung und archivierte tables. das obliegt dem sysadmin selbst, wie er/sie das angeht - das steht so ein keinem mir bekannten howto im nagios/icinga umfeld.

Zitat von »nagios9«

Davon abgesehen muss man überhaupt MySQL benutzen wenn man lediglich Daten abrufen möchte und in anderen Programmen auswerten möchte?

du kannst auch die status.dat ausparsern. oder neben mysql in den idoutils auch pgsql oder oracle einsetzen. oder du nimmst dir das livestatus modul, wenn es um gepollte abfragen geht, bevorzugt nicht direkt dem kunden gezeigt.

Zitat von »nagios9«

Ich meine MySQL ist doch ziemlich ineffizient bei einer großen Datenmenge, die jedoch statisch ist?

meinst du das oder weisst du das? das waere ne frage die die dbas hier ..

Zitat von »nagios9«

Ich möchte auch nach 3 Jahren jeden Status vor 3 Jahren noch nachvollziehen können.

abhaengig von diversen faktoren wie anzahl der hosts/services (datenmenge) sowie dem feintuning der db laesst sich das mit sicherheit bewerkstelligen. respektive man sagt den idoutils, was sie speichern sollen (timed events zb machen keinen sinn).

Zitat von »nagios9«

Naja wenn ich alle paar Minuten von hunderte von Services überwache und die Daten über Jahre aufbewahren möchte, dann entsteht ein entsprechender Speicherplatzverbrauch.
Jetzt habe ich das ganze einmal in pnp4nagios + 1 x mysql + 1 x icinga noch intern.
Ist doch total unnötig.

relativier diese aussage doch mal, und vergleiche die datenstrukturen.

* pnp = rrds = normalisierte speicherung, die aufloesung aendert sich, dh der speicherplatz verbrauch bleibt *relativ* gleich nach einer gewissen zeit, unter der bedingung, dass keine neuen hosts/services dazukommen (oder checks die ploetzlich perfdaten liefern)
* mysql = relationale db, erfordert housekeeping, erlaubt rdbms spezifische mechanismen zum tuning sowie zur archivierung von 'statischen daten'. dh kann man auch woanders ablegen, wo man platz hat, und nur zur archivierten verarbeitung hervorholen
* icinga intern = status.dat/retention.dat/logs, wovon sich die logs niederschlagen werden. abhilfe kann man sich hier mit os maechismen schaffen, die die logs bspweise weiterrotieren. fuers reporting wirst du diese dann schon auch noch benoetigen, die die logentries in der db dafuer nicht unbedingt geeignet sind

Zitat von »nagios9«

Naja standardmäßig wird bei IDO auch alle Daten reingeschrieben, also sind doch ansich schon alle Daten vorhanden?

fuer die haarstraeubenden historischen inserts gibts in ido2db.cfg per instance_id maximale vorhalte mechanismen. dh es sit immer davon abhaengig wie DU das ganze organisierst. moeglichkeiten dazu gibt es jedenfalls. du kannst auch das db_trim_interval anpassen, das mit 1.4 nunmehr auf 3600s eingstellt ist (db performance...)

Zitat von »nagios9«

Es geht aber auch um Protokollierung. Ein Ausfall der Internetleitung muss z.B. exakt auswertbar sein, da dies die Geschäftsleitung verlangt.

"exakt" relaitiviert sich auf zb check_interval und andere einfluesse, wann diese checks durchgefuehrt werden. ich wuerde da eher beidseitiges monitoring vornehmen. aktive polls und passive traps - um sich daraus den mittelweg zu bilden. und ggf auch nicht icinga/pnp sondern netflow basierte daten.