ICINGA2-Feinabstimmung

Was ist Icinga2?

Icinga2 ist ein großartiges Werkzeug, das auf der Grundlage des bekannten Nagios-Monitorings aufgebaut ist und alle Vorteile von
übernommen hat. Mit vielen Plugins, die in Ihrem Repository verfügbar sind, und Tausenden weiteren auf der von der Community betriebenen Nagios-Exchange-Website ist Icinga2 eine sehr gute Wahl für die Überwachung Ihrer Infrastruktur.
Ich werde einige der optionalen Funktionen behandeln, die nach der Einrichtung der Hauptkonfiguration an Ihre Bedürfnisse angepasst werden können.

Einige der Punkte sind:

• Die in Ihrer Host-Datei definierten Variablen werden voll ausgenutzt.
• Einrichten von benutzerdefinierten geplanten Ausfallzeiten.
• Ändern des Timeouts für bestimmte Prüfungen.
• Verwendung eines anderen Benutzers für Ihre Prüfungen.
• Schreiben Sie Ihr eigenes Plugin.

DIE IN IHRER HOSTDATEI DEFINIERTEN VARIABLEN VOLL AUSNUTZEN

Host-Variablen sind eine großartige Möglichkeit, das volle Potenzial Ihrer Befehle und Dienste auszuschöpfen.
Eine einzelne Befehlsdefinition kann für viele verschiedene Dienste wiederverwendet werden, und alle Variablen
, die sich ändern können, können direkt in Ihre Host-Datei gestellt werden, wo Sie sie leicht bearbeiten können, ohne
zu riskieren, dass der gesamte Dienst kaputt geht.
Irgendwo in Ihrer Host-Datei können Sie eine Variable definieren wie:

  vars.website_port = "33333"
                    vars.console_port = "44444"
                    vars.agent = "ssh"
                    

Hier ein Beispiel dafür, wie eine "by_ssh"-"http"-Prüfung solche Variablen verwendet:

 object CheckCommand "ssh_http" {
                       import "by_ssh"
                        vars.by_ssh_command = PluginDir + "/check_http -H localhost $uri$ -p $port$ $secondary_port$ $extra_port$ $cust_string$"
                          vars.uri = ""
                          vars.port = ""
                          vars.website_port = ""
                          vars.console_port = ""
                          vars.cust_string = ""
                    }
                    

In diesem Fall ist es nicht nötig, leere Variablendefinitionen zu schreiben, aber ich tue es, um es klarer zu machen.
Hier definiere ich die Befehlsvorlage, wobei ich das "-u" vor der Variable $uri$
absichtlich leer lasse, weil ich sie nicht jedes Mal verwenden möchte, wenn ich diesen Befehl aufrufe. Die "cust_string"-Variable kann
für jeden Parameter verwendet werden, den Sie der http-Prüfung hinzufügen möchten: Zum Beispiel wird " -R something" nach "something"
in der Ausgabe von curl -s -i http://127.0.0.1:PORT/ suchen und kritisch zurückgeben, wenn es nicht gefunden wird. Es gibt drei
Definitionen für port, aber ich verwende immer nur eine. Der Grund dafür ist, dass ich die Ports
in der Host-Datei definieren und den Befehl auf vielen Rechnern wiederverwenden kann.
Zum Beispiel können die Ports von Docker-Containern auf jedem Server anders sein:

    apply Service "website_http" {
                        import "generic-service"
                        check_command = "ssh_http"
                            vars.uri = "-u /some/address"
                            vars.port = ""
                            #vars.website_port = "" Defined in Host file
                            vars.console_port = ""
                            vars.cust_string = ""
                        assign where host.vars.agent == "ssh"
                    }

Die Gewichtung der Variablendefinition ist wie folgt:
Befehl > Hostdatei > Dienst
Der Befehl kann durch eine in der Hostdatei definierte Variable überschrieben werden
Und die Variable in der Hostdatei kann durch eine im Dienst definierte Variable überschrieben werden.
Deshalb wird im Dienst die Variable, die aus der Hostdatei übernommen werden soll, auskommentiert,
während die anderen drei Optionen als leere Variablen definiert sind, um alles andere zu überschreiben, was
versehentlich aus derselben Hostdatei übernommen werden könnte. Auf diese Weise können Sie denselben Befehl mehrmals
aufrufen und dabei unterschiedliche Variablen verwenden, die in jeder Hostdatei definiert sind. Die andere häufigere Verwendung für host.vars ist die Gruppierung von Servern nach Variablen. Wie Sie im obigen Dienst sehen können,
wird der Dienst auf allen Servern mit der Host-Variable agent mit dem Wert "ssh" ausgeführt... (assign where host.vars.agent == "ssh")

EINRICHTUNG VON BENUTZERDEFINIERTEN GEPLANTEN AUSFALLZEITEN

Geplante Ausfallzeiten können in der Datei downtimes.conf im Verzeichnis /etc/icinga2/conf.d/ festgelegt werden.
Die vordefinierte Methode "ScheduledDowntime" wird verwendet, um einen Dienst für einen bestimmten Server oder
eine Reihe von Maschinen zu erstellen. Zum Beispiel:

 apply ScheduledDowntime "YourServiceName" to Service {
                      author = "icingaadmin"
                      comment = "Insert Your Comment Here"<br> <br>  ranges = {
                          monday = "00:00-01:45,14:00-15:00",
                          tuesday = "13:40-14:00,15:34-15:45",

                                       - - -  

                          sunday = "17:00-17:30,18:50-19:00,23:00-00:00"
                        }
                        assign where host.name == "yourHostName"
                    }
                    

Die Ausfallzeiten können auch einer Servicegruppe anstelle eines Hosts zugewiesen werden. Es können beliebig viele pro Tag sein, getrennt durch Kommas in Anführungszeichen. Sie können auch so viele Dienste mit Ausfallzeiten haben, wie Sie benötigen, solange jeder einen eindeutigen Namen hat.
Richtig eingerichtete Ausfallzeiten sind eine sehr gute Sache, denn andernfalls würden geplante Neustarts von Diensten Ihre Überwachungsbenachrichtigungen mit unnötigen E-Mails überfluten.

ÄNDERUNG DES TIMEOUTS FÜR BESTIMMTE PRÜFUNGEN

VERWENDUNG EINES ANDEREN BENUTZERS FÜR IHRE PRÜFUNGEN

IHR EIGENES PLUGIN SCHREIBEN