Icinga - Check Time & Notification mails

Timi

New Member
Hallo,

da wir langsam einige Server haben die wir dementsprechend auch Überwachen müssen haben wir uns für Icinga entschieden. Nach der Einrichtung die zu überwachenden Server eingetragen und NRPE aktiviert. Es werden aktuell die Prozesse, die Load, HTTP, Ping und der Speicherplatz überwacht. Soweit passt das auch alles, allerdings ist mir der Check alle 5 Minuten zu hoch.

Ich würde das ganze gerne jeweils minütlich prüfen lassen damit ich so schnell wie möglich bescheid bekomme (auch wenn es nur ein Schluckauf ist). Leider habe leider keine Konfigurationsdatei gefunden in welcher dies definiert ist.

Auch ist die Frage wo ich die Anzahl der Notifcation Mails einstellen kann, da eine E-Mail mich nicht weckt.

Vielen Dank im Voraus und noch einen angenehmen Abend.

Grüße,
Tim
 

virtual2

Registered User
Zwecks wecken, einfach anag (Android) benutzen, eine ähnliche App gibts auch für iOS. Ist zwar nicht schön nachts unsanft geweckt zu werden, erfüllt aber seinen Zweck und ist bei richtiger Konfiguration ungefähr so laut wie ne Auto Hupe :D

Bzgl. Check Intervall wirst du in der offiziellen Doku fündig:

http://docs.icinga.org/latest/de/servicechecks.html
 

elias5000

Site Reliability Engineer
auch wenn es nur ein Schluckauf ist
Ein Monitoring, das (zu viele) Alarme auswirft auf die nicht mit einer Aktion reagiert werden kann/muss, funktioniert nicht.

Es erhöht die Gefahr, dass echte Alarme nicht erkannt werden, weil sie sich vom Grundlärm des Systems zu schwer unterscheiden lassen. (Signal to Noise Ratio) Deshalb sollte man eine zuverlässige Alarmierung (wenig oder keine false-Alarms) einer schnellen vorziehen.

Non-Actionable Alarms sind in jedem Fall unbedingt zu vermeiden. Wenn man zu viele hat, wird das Monitoring über kurz oder lang ignoriert.
 

harpi

Blog Benutzer
Hi,

wenn du nichts angepasst hast sollten die Config datei im <installdir>/etc/objects/ zu finden sein.

Dort in der Datei "templates.cfg" gibt es einen Abschnitt:

Code:
define service{
        name                            generic-service
Das ist das Template für alle Service-Checks, dieses kannst du entweder anpassen, oder besser am ende der Datei ein eigenes Service-Template erstellen, z.B.

Code:
define service{
        name                            nrpe-service
        use                             generic-service
        max_check_attempts              2
        normal_check_interval           1
        retry_check_interval            1
        register                        0
        notification_period             none
        }
Dieses benutzt das "generic-service" Template dur den Befehl "use", alle Einstellungen die du dann angibst werden mit deinen Werten Überschrieben. In diesem Beispiel "max_check_attempts" & "normal_check_interval" & "retry_check_interval" & "notification_period". Der Befehl "register 0" muss immer in einem Template angegeben werden.

Jetzt kannst du in deine Config Datei bei den Service-Checks die du Definiert hast, das "use" Template gegen dein neu erstelltes "use" Template austauschen,

Code:
define service{
        use                             nrpe-service
        host_name                       <deinhost>
        service_description             CPU Load
        check_command                   check_nrpe!CheckCPU!-a ShowAll warn=90% crit=95% time=5m time=10m time=15m
        }
Jetzt die Config durch einen reload aktivieren.

Alles weitere solltest du der Icinga Doc entnehmen und oder dem entsprechenden Foren.

Gruß
Harpi
 

PHP-Friends

Blog Benutzer
Zwecks wecken, einfach anag (Android) benutzen, eine ähnliche App gibts auch für iOS.
Das setzt aber eine bestehende Internetverbindung voraus. Meiner Meinung nach geht nichts über SMS-Versand mit Zustellgarantie in < 10 Sekunden.

Ein Monitoring, das (zu viele) Alarme auswirft auf die nicht mit einer Aktion reagiert werden kann/muss, funktioniert nicht.

Es erhöht die Gefahr, dass echte Alarme nicht erkannt werden, weil sie sich vom Grundlärm des Systems zu schwer unterscheiden lassen. (Signal to Noise Ratio) Deshalb sollte man eine zuverlässige Alarmierung (wenig oder keine false-Alarms) einer schnellen vorziehen.

Non-Actionable Alarms sind in jedem Fall unbedingt zu vermeiden. Wenn man zu viele hat, wird das Monitoring über kurz oder lang ignoriert.
Das würde ich so nicht pauschalisieren. Wir verwenden ebenfalls ein sehr (sehr) sensibles Monitoring, was uns auch z.B. bei DDoS auf einen Nachbarserver alarmiert. Hierbei entsteht normalerweise eine Downtime von 1-2 Minuten. Der "Trick" ist, das Monitoring so zu gestalten, dass man auch möglichst sofort erkennt, woran es hakt. Das resultiert natürlich in einer ganzen Reihe von Checks je Host und ggf. weiteren Prüfungen, z.B. Informationen über DDoS-Aktivität im gesamten Rechenzentrum, Monitoring verschiedener Uplinks etc.

Nun könnte man generell hingehen und erst ab drei Minuten Downtime einen Alarm auslösen. Damit verliert man bei "richtigen" Downtimes aber eben auch drei Minuten, und das wiederum möchten wir ehrlich gesagt nicht. Zwar machen wir kein hochverfügbares Hosting, aber 99,9% Verfügbarkeit ist unser Mindestanspruch - und nicht das Ende der Fahnenstange.
Auch beim Fallbeispiel (DDoS auf Nachbarn) ist es immer möglich, dass wegen zu geringer Bandbreite oder ungünstiger Aufteilung auf verschiedene IPs kein automatisches Nullrouting erfolgt und somit manuell eingegriffen werden muss. Auch da möchten wir keine drei Minuten verlieren.

Ein Admin, der nach einem Monitoring-Alarm nicht die Ursache prüft und sich selbst vergewissert, dass alles wieder läuft, sollte vielleicht keinen Bereitschaftsdienst machen. :p

Ich stimme natürlich insofern zu, als dass False-Positives nicht unbedingt täglich vorkommen sollten. Aber lieber ein Alarm zu viel als einer zu wenig.
 

elias5000

Site Reliability Engineer
Wenn man auf 3 Minuten Wert legt, dann sollte man Leute im Schichtwechsel haben, die auf Alarme reagieren können.
Bereitschaftler dafür von einem Trigger-happy Monitoring aus dem Schlaf reißen zu lassen halte ich für eine super Möglichkeit um die Motivation zum Bereitschaftsdienst möglichst schnell auf 0 zu reduzieren.

Ich mache selbst regelmäßig 24/7-Bereitschaft und bin extrem froh, dass ich noch einen Support-Level zwischen meinem Schlaf und dem Monitoring habe, die im Schichtwechsel dafür sorgen, dass die False-Alarm-Rate möglichst gering ist.
Wenn man mal vier Nächte in Folge den Nachtschlaf von Alarmen versemmelt bekommen hat, ist geht man echt auf dem Zahnfleisch. (Vier Alarme in einer Nacht sind auch nicht schöner.)
 
Last edited by a moderator:

PHP-Friends

Blog Benutzer
Ich kann dir da durchaus folgen; aber das muss jeder Hoster für sich wissen. Kommt sicherlich auch auf die jeweilige Person an. Bei uns mache ich im Regelfall die Bereitschaft und ich habe mit dem "Monitoring-Wecker" kein Problem, bei einer False-Positive-Meldung schlafe ich fünf Minuten später wieder. Für den Fall, dass etwas zu tun ist, liegt sowieso mein Notebook im Bett.

Dazu sei aber gesagt - sollte ich mich da ungünstig ausgedrückt haben - dass so ein nächtlicher Alarm eigentlich nur alle paar Wochen mal vorkommt und von daher wirklich kein großer Aufreger ist. Natürlich ist es blöd, wenn man tatsächlich mal mehrfach nachts ernsthaft Arbeit bekommt, aber wenn ich wirklich fertig mit der Welt bin, kann ich die restliche Nacht problemlos an einen Kollegen abgeben. Da schläft man schon besser. ;)
 

Top