Dieses Feld dient lediglich einer einfachen und kurzen Beschreiung eines Service-Checks und wird in der Übersicht aller Services von Hosts angezeigt. Für ausführlichere Informaionen kann das Feld Beschreibung verwendet werden.
Dieses Feld bietet die Möglichkeit zur Angabe einer Beschreibung des Services. Dieses Feld wird auch in Statusmeldungen angezeigt, wenn es einen Text enthält.
Das Feld Kommentar bietet wie das Feld Beschreibung eine Möglichkeit um Zusatzinformationen abzulegen. Dieses Feld wird auch in Statusmeldungen angezeigt, wenn es einen Text enthält.
Jeder Service kann aktiviert und deaktiviert werden. Ist ein Service deaktiviert, so wird der Service nicht weiter überwacht. Der Service wird zusätzlich in den Status INFO versetzt und erhält in der Statusmeldung eine Zusatzinformation.
Mit diesem Parameter lässt sich bestimmen, ob der Service-Check als Host-Alive-Check markiert wird. Weitere Informationsn zum Host-Alive-Check finden Sie im folgenden Dokument: Was ist ein Host-Alive-Check?
Ein passiver Check ist ein Check, der nicht von Bloonix selbst geprüft wird, sondern von einem externen Service. Passive Checks haben keinen Timeout und der Status wird erst aktualisiert, wenn sich der externe Service meldet und einen Status liefert. Es wäre zum Beispiel denkbar, SNMP Traps bei bestimmten Ereignissen an den Bloonix-Agenten zu versenden, dieser wiederrum sendet den Status an den Bloonix-Server. Falls Sie weitere Fragen zur Konfiguration von passive Checks haben, so wenden Sie sich bitte an den Bloonix-Support.
Jeder Service-Check, der in der WebGUI von Bloonix eingerichtet wird, wird mit einer sogenannten Agenten-Lokation versehen. Diese Lokation bestimmt, welcher Bloonix-Agent für die Überwachung des Service verantwortlich ist. Es gibt insgesamt drei mögliche Optionen zur Auswahl des Standorts: localhost, intranet und remote.
Mit der Option localhost soll der Check lokal auf Ihrem Server ausgeführt werden. Installieren Sie hierzu den Bloonix-Agent auf Ihrem Server. Diese Option ist besonders sinnvoll, wenn Sie die Systemvitals, wie zum Beispiel die CPU, den Hauptspeicher oder auch die Festplatten überwachen möchten.
Mit der Option intranet ist ihr lokales Netzwerk gemeint. Installieren Sie hierzu den Bloonix-Agenten in Ihrem lokalen Netzwerk auf einem zentralen Server. Von diesem Server aus sollen die Checks ausgeführt werden. Diese Option ist sinnvoll, wenn Sie Hosts haben, auf denen entweder der Bloonix-Agent nicht installiert werden kann oder die Services über SNMP in Ihrem lokalen Netzwerk überwacht werden sollten. Das können zum Beispiel Router, Switches etc. sein.
Mit der Option remote soll der Check von einem externen Server ausgeführt werden, also ein Server, der nicht in Ihrem lokalen Netzwerk steht. Dies ist besonders für Internetservices sinnvoll. Zum Beispiel können Sie über einen externen Check die Funktionalität Ihres Webservers, Mailservers oder auch DNS-Servers überprüfen.
Für weitere Informationen lesen Sie unbedingt das Dokument Wie überwacht Bloonix Hosts und Services
Mit den Check Einstellungen können Sie die Einstellungen für den Check bestimmen. Dies können beispielsweise eine IP und ein Port Ihres Service sein, oder auch Schwellwerte und Timeouts. Jeder Check hat ein eigenes Set von Optionen. Eine kurze Beschreibung zu den Check Optionen finden Sie direkt im Formular. Klicken Sie hierzu einfach auf das kleine Info-Icon zu jeder Option.
Bitte lesen Sie unbedingt das Dokument: Host Variablen
Mit diesem Paramter wird der globale Timeout eines Checks festgesetzt. Wenn die Ausführungszeit des Checks länger dauert, dann wird der Prozess mit einem Kill-Signal hart beendet und der Status des Service wird auf CRITICAL gesetzt.
Mit diesem Parameter wird der Check-Intervall des Service eingestellt. Wenn kein Wert angegeben ist, dann wird der vererbte Wert des Hosts verwendet.
Mit diesem Parameter wird der Check-Intervall des Service eingestellt, die sich im Status WARNING, CRITICAL oder UNKNOWN befinden. Wenn kein Wert angegeben ist, dann wird der vererbte Wert des Hosts verwendet.
Mit diesem Wert wird bestimmt, nach welcher Zeit der Status eines Service als veraltet markiert wird und sollte um ein vielfaches von "Intervall" gesetzt werden. Das ist zum Beispiel dann wichtig, wenn ein Bloonix-Agent aus irgendeinem Grund den Status eines Service nicht mehr aktualisiert, vielleicht weil er ausgefallen oder zu stark überlastet ist. Wenn kein Wert angegeben ist, dann wird der vererbte Wert des Hosts verwendet.
Die Option Bestätigt bietet die Möglichkeit, den Status eines Services als "bestätigt" zu markieren, wenn der Status des Service nicht OK ist. Das bedeutet, dass jegliche Benachrichtiung solange für den Service eingestellt wird, bis der Status des Service wieder OK ist. Die Markierung "bestätigt" wird auch automatisch wieder aufgehoben, wenn der Service wieder im Status OK ist.
Diese Option ist sehr hilfreich, wenn Sie zum Beispiel genau wissen, dass sich der Status eines Service zunächst nicht ändern wird und wenn Sie erst wieder benachrichtigt werden möchten, wenn der Status wieder OK ist und dann wieder in einen kritischen Status wechselt.
Mit der Option Benachrichtigungen eingeschaltet können Warnmeldungen per E-Mail und SMS auf unbestimmte Zeit deaktiviert werden.
Dieser Parameter gibt an, nach wievielen Prüfungen, die nicht OK waren, Sie über den Status eines Services per E-Mail oder SMS benachrichtig werden. Standardmäßig ist der Wert auf 3 gesetzt. Das bedeutet, dass eine Warnmeldung erst versendet wird, wenn ein Service-Check drei Mal hintereinander ein WARNING, CRITICAL oder UNKNOWN geliefert hat.
Mit dieser Option lassen sich sogenannte "false positives" abfangen. Wenn es zum Beispiel einen kurzen "Netzwerkhänger" oder eine "Lastspitze" gab, so möchte man sicherlich nicht gleich mit E-Mails und SMS bombardiert werden, sondern erst, wenn der Service bei einer zweiten oder dritten Prüfung noch immer einen nicht-__OK__ Status liefert.
Wenn diese Options auf yes gesetzt ist, dann wird ein Service als CRITICAL markiert, sobald der Service Attempt max erreicht hat und sich eigentlich im Status WARNING befindet.
Die Option ist standardmäßig auf no gesetzt.
Die Erkennung von zu häufigen Statuswechseln ist ein sehr wichtiger Teil des Benachrichtigungssystems. Es bewahrt Sie davor, mit E-Mails und SMS geradezu bombardiert zu werden.
Immer dann, wenn ein Service den Status wechselt, wird der Wechsel im Event-Log des Hosts vermerkt. Wenn nun ein Status in einem bestimmten Zeitraum den Status zu häufig wechselt, dann wird das Versenden von Benachrichtigungen eingestellt und der Service erhält in der Statusmeldung den Zusatz: [SERVICE IS FLAPPING BETWEEN STATES]
Zur Konifguration dieses Features gehören folgende Parameter:
Mit den drei Parametern können Sie die Funktion ein- oder ausgeschalten, den Zeitraum in Sekunden angeben, in dem der Wechsel eines Status gezählt wird und die maximale Anzahl bestimmen, wie oft ein Status im dem definierten Zeitraum wechseln darf.
Fallbeispiel:
Nehmen wir an, dass der Zeitbereich zur Erkennung von zu häufigen Statuswechsel auf 1800 Sekunden und in die maximale Anzahl von Statuswechsel auf 8 gesetzt ist. In diesem Fall würde der Statuswechsel des Services aus den letzten 30 Minuten gezählt werden und sollte die Anzahl größer oder gleich 8 sein, dann wurde erkannt, das zu häufig der Status in diesem Zeitraum wechselte und es werden keine weiteren Statusmeldungen mehr versendet, solange bis die Anzahl der Statuswechsel der letzten 30 Minuten wieder kleiner 8 beträgt.
Ein flüchtiger Service ist ein Service, dessen Status nur für einen sehr kurzen Zeitraum kritisch ist. Dies kann zum Beispiel bei der Prüfung von Logdateien der Fall sein. Nehmen wir zum Beispiel an, es wird eine Logdatei nach kritischen Ereignissen untersucht. Sollte ein Ereignis gefunden und der Status CRITICAL zurückgegeben werden, dann ist es sehr gut möglich, dass das Ereignis bei der nächsten Prüfung nicht mehr in der Logdatei vorkommt. Der Status würde also wieder zurück in den Status OK wechseln. Genau für diesen Zweck kann ein Service als flüchtig markiert werden.
Ist also ein Service als flüchtig markiert, dann bleibt der Service solange im Status WARNING, CRITICAL oder UNKNOWN, bis der Status in der WebGUI manuell zurücksetzt wurde oder bis die Vorhaltezeit abgelaufen ist. Somit stellen Sie sicher, dass das Event auf jedem Fall von einem Administrator beachtet wird.
Die Vorhaltezeit ist eine Zeitangabe in Sekunden, wann der Service-Check automatisch wieder zurück auf OK gesetzt werden soll, nachdem dieser als kritisch markiert wurde. Ein Wert von 0 besagt, dass die Zeit nie abläuft. Der Wert 0 ist auch der Standardwert für diese Option.
Für das manuelle Zurücksetzen des volatile Status gibt es einen Link, den Sie in der Navigation von Hosts und Services finden.
Der Benachrichtigungsintervall beeinflußt das erneute Versenden von Warnmeldungen. Wenn ein Service aus dem Status OK in den Status WARNING wechselt, dann wird für den betroffenen Service eine Benachrichtigung per E-Mail und/oder SMS versendet. Wenn der Status des Services sich in der angegeben Zeit des Benachrichtigungsintervalls nicht ändert, dann wird eine erneute Benachrichtigung versendet. Auf diese Weise werden Sie als Administrator in einem regelmäßigen Intervall daran erinnert, in welchem Status sich ein Service befindet.
Zu beachten ist hierbei jedoch, dass wenn der Status des Service zurück auf OK und dann wieder auf WARNING wechselt, der Benachrichtigungsintervall sofort verfällt. So verhält es sich auch, wenn sich der Status von WARNING zu CRITICAL oder von CRITICAL zu UNKNOWN ändert, also zu einem höheren Status wechselt.
Der Grund für dieses Verfahren ist recht einfach zu verstehen. Stellen Sie sich vor, Sie erhalten nachts um 2 Uhr eine Mail über den kritischen Zustand eines wichtigen Service. Nun beheben Sie das Problem und legen sich mit der Gewissheit wieder schlafen, dass das Problem behoben ist. Wenn nun der Service erneut in den kritischen Zustand wechselt, dann möchten Sie natürlich erneut über den Zustand informiert werden.
Die gleiche Situation lässt sich auch mit einem Statuswechsel von WARNING zu CRITICAL beschreiben. Sie erhalten wieder nachts um 2 Uhr eine Meldung, diesmal aber nur eine Warnmeldung. "Ok", denken Sie sich, "WARNING heißt noch lange nicht CRITICAL" und das Sie vielleicht noch ein paar Stunden Zeit haben das Problem zu lösen. Nun passiert es aber, dass der Service innerhalb kurzer Zeit von WARNING auf CRITICAL wechselt. In diesem Fall möchten Sie natürlich sofort erneut informiert werden um den Fehler zu beheben.
Der Standardwert des Benachrichtigungsintervalls ist auf 3600 Sekunden gesetzt.
