# Nagios-AddOn für ISPConfig-Meldungen gesucht



## cjmatsel (28. Aug. 2009)

Hi,

ich überwache alle meine Server mit Nagios. Mit ISPConfig beschäftige ich mich erst seit Kurzem und finde es echt klasse, weil es ne Mange Konfigurationsarbeit abnehmen kann! Daher möchte ich, sobald irgendwo in den von ISPConfig überwachten Mechanismen Fehler oder Warnungen eintreffen, dass diese über Nagios gesehen werden können. Hat jemand sowas schonmal gemacht oder / und Ideen dazu?

cu,
cjmatsel


----------



## JeGr (18. Sep. 2009)

Frage, da ich dich nicht ganz verstehe: Du möchtest mit Nagios überwachen... genau was? Welche Fehler ISPConfig wirft? Oder welche Fehler ISPConfig via "Überwachung" meldet? Bei letzterem wäre es eine etwas schizophrene Situation, denn wozu mit ISPConfig nochmals überwachen, wenn du Nagios hast, das den Job (wahrscheinlich) besser macht?


----------



## cjmatsel (18. Sep. 2009)

> Welche Fehler ISPConfig wirft? Oder welche Fehler ISPConfig via "Überwachung" meldet?


Ja. ISPConfig hat eine Status-Seite, welche entsprechende Meldungen auswirft. Diese ist für mich interessant...



> Bei letzterem wäre es eine etwas schizophrene Situation, denn wozu mit ISPConfig nochmals überwachen, wenn du Nagios hast, das den Job (wahrscheinlich) besser macht?


Jaein; ich müsste ganz genau wissen, was ISPConfig alles wo überwacht und das in nagios nachbauen. DAS finde ich schizophren. Stattdessen würde es mir reichen, dass ISPConfig eine Warnung o.ä. meldet und diese wird dann an Nagios weitergegeben. Der Vorteil: Statt eine ganze Menge einzelner Prozesse mit nagios anzustossen oder den Überwachungsprozess neu zu programmieren, nehme ich die Überwachung von ISPConfig als Schnittstelle zu nagios. Auf den Server muss ich ja sowieso rauf, um eine ISPConfig-Warnung zu lesen bzw. zu bearbeiten...

Wenn der Prozess in der Status-Seite selbst auch als Script aufgerufen werden kann, kann ich den natürlich als nagios-Befehl anstossen. Aber wie gesagt: Ich bräuchte Informationen darüber, was wo überwacht bzw. angestossen werden muss...


----------



## JeGr (21. Sep. 2009)

Bei zwei Fragen mit "Ja" zu antworten macht den Auswahlprozeß nicht einfacher  Was genau soll denn nun aus deiner Sicht von Nagios überwacht werden?

Zu deinem zweiten Punkt: Warum musst du genau wissen, was ISPConfig wo überwacht und das nachbauen? Ich finde es ja einerseits ganz nett, dass ISPConfig quasi eine mini-Überwachung mitbringt, aber wenn ich überwache, dann mit einem Tool, das den Job beherrscht und bei dem ich mich (keine Kritik an ISPConfig) nicht darauf verlassen muss, dass es vielleicht das richtige macht. 

Nagios ist ein Vollblut was Überwachung angeht und deshalb finde ich es unsinnig, mit Nagios die Überwachungspunkte von ISPConfig zu überwachen, da es das selbst kann und noch dazu mit seinen Checks und Plugins um einiges besser und präziser, als das ISPConfig kann. Zumal ISPConfig bspw. nur ansagt, dass der Port "80" (HTTP) up ist. Das bringt mir jedoch nichts, wenn mich ein Kunde anruft und sagt, dass seine Webseite nicht mehr läuft, einen 403er Forbidden bringt oder seit neuestem eine htaccess Auth verlangt, wo keine hingehört. Nagios sagt mir das schon und zwar genau und präzise wann und wo es passiert. Und mit ein paar tiefern Modifikationen kann ich damit auch Business Prozesse abbilden oder SLAs überwachen. Warum soll ich dann also dem Spezialist beibringen, was ein "Amateur" zu sagen hat, wenn er selbst die gleiche Aussage treffen kann ohne obskure Plugins oder Addons einzubinden?

Ich habe auch den Eindruck, dein Ablauf den du im Kopf hast ist ein wenig schräg (nicht böse sein ), aber warum soll der Amateur (ISPConfig) an den Profi (Nagios) eine Nachricht übergeben, dass ein Dienst evtl nicht mehr läuft? Wofür? ISPConfig "alarmiert" doch (glaube ich) selbst? Was soll dann also Nagios mit der Info? Und warum eine ganze Menge eigener Prozesse anstoßen? Natürlich startet Nagios die verschiedenen Checks und dafür Prozesse aber wo ist dabei das Problem? Man kann die natürlich auch durch sowas wie check_multi oder check_mk zusammenfassen, aber wenn du nicht gerade tausende von Checks hast, wäre das übertrieben. 

Was möglich oder denkbar wäre ist ein Addon für ISPConfig zu bauen, welches den Nagios Output bspw. an irgendeiner Stelle der ISPConfig Oberfläche anzeigt. Dafür gäbe es mit NDO, Datenbank und/oder IFrames genug Möglichkeiten.

Ich denke schon, dass ich Nagios (und ISPConfig 2) inzwischen ganz gut kenne und vielleicht erkenne ich gerade deinen Wunsch oder den Sinn deiner Konstellation nicht so ganz, aber ich diskutiere das gerne durch - vielleicht kannst du mich ja noch erhellen, was genau deine Zielsetzung ist und warum und wie du das erreichen möchtest. Vielleicht gibts ja einen viel einfacheren Weg


----------



## cjmatsel (21. Sep. 2009)

> Bei zwei Fragen mit "Ja" zu antworten macht den Auswahlprozeß nicht einfacher  Was genau soll denn nun aus deiner Sicht von Nagios überwacht werden?


Naja, vielleicht ist mir das selbst noch nicht so klar...



> Zumal ISPConfig bspw. nur ansagt, dass der Port "80" (HTTP) up ist.


Den Eindruck hatte ich nicht. ISPConfig warnt sogar, wenn Updates zur Verfügung stehen und noch einiges anderes mehr.



> ISPConfig "alarmiert" doch (glaube ich) selbst?


Das wusste ich noch nicht . Jedenfalls habe ich noch keine Mail oder SMS bekommen, dass etwas nicht stimmt.

Ich verstehe Deine Antwort, aber das ist nicht das, was ich suche. Ich versuchs mal einfach: Mein Ziel: Wenn ISPConfig aus irgend einem Grund einen Warnstatus hat, dann möchte ich diesen über eine Schnittstelle in Fremd-(Monitoring-)systemen sehen. Mehr nicht. Wie man das realisiert, steht dann natürlich auf einem anderen Blatt.

Wie Du schreibst, kann Nagios die Prozesse und deren Stati wesentlich genauer überwachen als ISPConfig. Da ich aber nicht weiß, WAS ich alles überwachen muss, müsste ich also alles zu überwachende selbst festlegen und in Nagios einbinden. DAS ist ja mein Problem, da ich nicht weiß, was ich alles einbinden müsste! Oder noch besser (und jetzt kommen wir zu meinen anderen Postings): Es wird ein Multiline-Plugin für Nagios gleich in ISPConfig mitgeliefert; sodass ein Nagios-Admin wie ich dieses nur in Nagios zu integrieren braucht und alle Stati gleich im Überblick hat. Da Du Nagios kennst, weißt Du auch, dass Nagios von solchen Integrationen unter Anderem lebt. Ich selbst habe schon das ein oder andere kleine Plugin geschrieben und veröffentlicht und nutze auch von anderen veröffentlichte Plugins. Und genau HIER möchte ich ansetzen: Ich möchte, dass die notwendigen Stati in ISPConfig (und von mir aus auch noch mehr wie die einzelnen Webseiten und deren Erreichbarkeit z.B.) von Nagios ausgewertet werden können, OHNE dass ich erst alles auseinander nehmen muss. Wenigstens eine entsprechende Beschreibung, welchen Stati ISPConfig wann und wie überwacht, hilft solche Plugins zu schreiben oder andere Überwachungsmöglichkeiten zu nutzen.

Ich weiß nicht, ob ich das deutlich rübergebracht habe. Es geht mir hier um die Integration von ISPConfig (und / oder des Systems) in ein Monitoring-Werkzeug über Schnittstellen: Die bisherige Integration in das Betriebsystem ist m.E. super klasse und ich bin wirklich begeistert! (Nur um das mal deutlich zu sagen  )

edit:


> Was möglich oder denkbar wäre ist ein Addon für ISPConfig zu bauen, welches den Nagios Output bspw. an irgendeiner Stelle der ISPConfig Oberfläche anzeigt. Dafür gäbe es mit NDO, Datenbank und/oder IFrames genug Möglichkeiten.


Gute Idee...


----------



## JeGr (21. Sep. 2009)

Zitat von cjmatsel:


> Naja, vielleicht ist mir das selbst noch nicht so klar...
> 
> Den Eindruck hatte ich nicht. ISPConfig warnt sogar, wenn Updates zur Verfügung stehen und noch einiges anderes mehr.
> 
> ...


OK aber das ist dann wirklich ein (großes) Problem, wenn du überhaupt nicht weißt was du willst (sprich: nicht weißt, was du überhaupt einbinden musst). Denn ISPConfig bringt dir (zumindest in v2) eine recht rudimentäre Überwachung der Serverdienste mit. Über v3 kann ich nicht sprechen, da ich das nicht aktiv im Einsatz habe. Aber wenn du nicht weißt was du überhaupt überwachst, dann bringt es auch nichts - finde ich  - dass du einfach irgendwelche Stati von ISPConfig übernimmst  Das macht dich ja auch nicht schlauer 

Wir können es natürlich auch anders machen: Du sagst was du hast und ich sage dir was du überwachst?


----------



## cjmatsel (21. Sep. 2009)

Ich habe ISPConfig 3 auf einer debian


----------



## JeGr (21. Sep. 2009)

Alles auf einer Maschine? Wie genau würdest du überwachen wollen? Kundendomains mit? Oder nur Serverdienste?


----------



## cjmatsel (22. Sep. 2009)

> Alles auf einer Maschine?


? Ja, momentan schon. Noch ist nur ein Kundensystem drauf...



> Wie genau würdest du überwachen wollen? Kundendomains mit? Oder nur Serverdienste?


Ich würde ganz gerne erstmal die Serverdienste überwachen wollen. Danach würde ich mir ein Konzept aufbauen wollen, wie man Kundendomains überwacht. Das stelle ich mir so vor, dass ich pro neuen Kunden ein Set oder ein Script habe, was die entsprechenden Daten für die Überwachung erzeugt. Im kleinsten Fall wäre dass eine check_multi-Konfiguration für Nagios pro Kunde. So kann man recht einfach neue Kunden hinzufügen...

Wie klingt das?


----------



## JeGr (27. Sep. 2009)

Zitat von cjmatsel:


> ? Ja, momentan schon. Noch ist nur ein Kundensystem drauf...
> 
> Ich würde ganz gerne erstmal die Serverdienste überwachen wollen. Danach würde ich mir ein Konzept aufbauen wollen, wie man Kundendomains überwacht. Das stelle ich mir so vor, dass ich pro neuen Kunden ein Set oder ein Script habe, was die entsprechenden Daten für die Überwachung erzeugt. Im kleinsten Fall wäre dass eine check_multi-Konfiguration für Nagios pro Kunde. So kann man recht einfach neue Kunden hinzufügen...
> 
> Wie klingt das?


Ganz plausibel. Ich würde dann Nagios einsetzen:

Host: localhost (oder server)
Services: HTTP (check_http), HTTPS (check_http mit Params), HTTP Port 8080 (für ISPConfig Panel), FTP, IMAP, POP3, IMAPS, POP3S (wenns genutzt wird), SMTP, MySQL

Denke das müsste so ziemlich alle Serverdienste abdecken (sollte ich jetzt keinen vergessen haben).

Ich würde dann pro Web checken:



Webseite (www.xyz.de checken, sonst klappts nicht mit VHosts)
MySQL Logins des Webs (MySQL Daten, nur wenn vom Kunde nicht verändert werden, sonst könnte das sinnfrei werden)
FTP User (sh. MySQL Logins)
So würde ichs aufbauen. Und dann alle Webs eines Kunden in einer Hostgruppe mit Namen des Kunden zusammenfassen. Damit lassen sich dann besser Dinge wie SLAs o.ä. realisieren. Ggf. Host- und Service-Templates nehmen (für die virtuellen Dienste des Kunden), dann lässt sich ein neues Kundenweb sehr einfach per Vererbung realisieren 

Gruß


----------



## cjmatsel (28. Sep. 2009)

Das klingt soweit ganz gut, deckt aber nur die Dienste der Server ab. Was ist mit
- vollen Queues
- fehlende Updates
- Systemperformance (bedingt durch das Erreichen der Kundenpräsenz schon abgedeckt) edit: und -auslastung
- Fehler im Log (bzw. in den Logs)


----------



## JeGr (28. Sep. 2009)

Zitat von cjmatsel:


> Das klingt soweit ganz gut, deckt aber nur die Dienste der Server ab. Was ist mit
> - vollen Queues


Welche Queues? Mail? Kommt drauf an wie man voll definiert. Aber geht mit check_mailq - würde ich dann auch an localhost/server binden



Zitat von cjmatsel:


> - fehlende Updates


Welcher Art? Debian Updates? -> check_apt



Zitat von cjmatsel:


> - Systemperformance (bedingt durch das Erreichen der Kundenpräsenz schon abgedeckt) edit: und -auslastung


Ist meist in einer Standard-Nagios-Installation schon vordefiniert. Nach einer Installation ist ja localhost meist mit folgenden Checks schon eingerichtet: Current Load, Current Users, Ping, Root Partition, Swap Usage, Total Processes, PING, SSH. Deshalb hatte ich die nicht extra aufgeführt. 



Zitat von cjmatsel:


> - Fehler im Log (bzw. in den Logs)


check_log, check_log2 oder check_logfiles stehen zur Verfügung.


----------

