Notification per Email pro Service zu unterschiedlichen Zeiten / Definition eine Nachricht über apply Regel

  • Ich habe ein Icinga2 System aufgesetzt (manuell, ohne Director für hoffentlich bessere Strukturierung). Installiert wurde Icinga2 Version 2.4.2 unter Ubuntu 16.04 LTS

    Ich habe den Eindruck, dass "apply To" Regeln oft nur beim ersten Objekt funktionieren, bei den restlichen hingegen nicht. Leider ist die letzte Analyse ein paar Tage her, daher kann ich nicht 100% meine Erfahrungswerte nennen, aber ich versuche es so weit wie möglich.

    Ich habe sehr viele SNMP-Abfragen (z.B. 175 Services für jeden einzelnen Port einer Stack Switch, 40 Services für verschiedene Lüfter auf der gleichen Stack Switch) und will alle Services gruppieren. Die Gruppierung will ich über eine apply to Regel in einer Service Group Definition machen. Diese Gruppierung funktioniert auch.


    Wenn Beispielsweise ein ping4 Check keine Antwort gibt, will ich sofort benachrichtigt werden, eine Erinnerungsmail soll dann z.B. alle 2 Stunden kommen.

    Wenn ein Lüfter defekt ist, reicht mir eine Erinnerungsmail alle 7 Tage.


    Als Beispiel nehme ich mal meinen Core Switch, nur die IP und Beschreibung ändere ich ein wenig



    Problem 1 hier (auch, wenn ich später die Mails auf die Services, nicht auf die Hosts stellen will):


    Ich würde gerne die Mailbenachrichtigung in der HostGroup definieren anstatt in jedem Host einzeln.

    Ich denke, das macht die Sache übersichtlicher.

    Wenn ich allerdings die Zeile "vars.notification["mail"] = {groups = [ "icingaadmins" ]}" in die Hostgroup eintrage, wird sich nicht in dem Host übernommen, zumindest erhalte ich keine Emails.

    Im Webinterface werden meine Hosts schön zusammengefasst, die apply-Regel greift also.


    Was ist für die Apply-Regeln erlaubt? habe ich hier einen Denkfehler?



    Problem 2:

    Ich schaffe es nicht, für eigene Dienste das notifications-Intervall zu ändern.


    Kurzfristig erfolgreich konnte ich es testen, eine Warnmeldung des automatisch hinzugefügten Dienstes "apt" am Icinga Server alle 3 Minuten Emails gesendet zu bekommen.


    Code
    1. apply Notification "notify-3m" to Service {
    2. import "mail-service-notification"
    3. user_groups = host.vars.notification.mail.groups
    4. interval = 3m // alle xxx Minuten Stunden Email // bei 3m (3 Minuten) funktioniert die häufigere Benachrichtigung, aber seltener wie alle 2 Stunden nicht
    5. assign where (service.name == "apt")
    6. // assign where (service.name == "svc-check-snmp-fan-6") // wird nicht akzeptiert
    7. // assign where (service.name == "cmd-check-snmp-fan-6")
    8. // assign where (service.name == "apt") || (service.name == "cmd-check-snmp-fan-6")
    9. }

    Dann hatte ich auf 5 Stunden hochgestellt und wieder auf 3 Minuten zurück (mit Dienstneustart) und die Emails kommen nun nicht mehr so oft an.

    Vor einigen Wochen hatte ich auch einmal damit experimentiert. Kürzere Zeiten als 2 Stunden wurden akzeptiert, aber Zeiten über 2 Stunden wurden ignoriert. Es wurde dennoch alle 2 Stunden eine Mail gesendet, zumindest hatte es so auf mich gewirkt.



    Wenn ich nun für diesen SNMP-Service eine Benachrichtigung alle 7 Tage haben will (für Tests werde ich eine kürzere Spanne nehmen), was muss ich konfigureren?
    Denn spätestens hier bekomme ich die Mails dann gar nicht mehr wie gewünscht hin.





    Spätestens bei den Notifications blicke ich mit der Syntax nicht durch und habe hier scheinbar ein grundlegendes Verständnisproblem.

    Auch, dass ich nicht über eine apply-Regel den Hosts (oder Services) Definitionen mitgeben kann, irritiert mich.


    Wer kann mich über meine Logikfehler aufklären? Ein Link zu passenden Anleitungen würde mir auch sehr weiterhelfen.

    Danke im Voraus.

  • Nachtrag: Der Service zu apt schickt nun alle 5 Stunden Emails. Das funktioniert also doch.

    Hat das mit den Tests damals ggf damit zu tun, dass sobald man einmal eine kürzere Mailbenachrichtigung eingestellt hat icinga2 sich diese merkt und erst nach dem Absenden die aktuell eingestellte Zeit nutzt?


    Dazu muss ich aber auch sagen, dass ich im Standard der Regeln in der /etc/icinga2/conf.d/notifications.conf

    apply Notification "mail-icingaadmin" to Host

    und

    apply Notification "mail-icingaadmin" to Service

    den Standard auf

    interval = 12h

    umgestellt habe.


    Wem Designfehler auffallen: Darf auch gerne gemeldet werden.

    Beispielsweise werden die Variablen

    vars.hardware und vars.gebaeude noch nicht genutzt, aber sind für zukünftige Sortierungen angelegt.

    vars.snmp_port_ueberwachung und vars.snmp_fan_ueberwachung will ich zu einer Variablen vars.snmp kürzen und dann Werte über Arrays zuweisen.

    Das ist aber eher Kleinkram und nicht für die Funktionsfähihkeit notwendig.

  • Ein paar Gedanken.

    • Nimm englische Bezeichner für Custom-Attribute. Irgendwer fängt sicher an, da mit Umlauten zu arbeiten, oder deutschen Sonderzeichen, die etwa spezielles Escaping benötigen. Das *willst* du nicht maintainen oder fixen müssen. Englische Namen erlauben es auch, jemandem nicht deutschsprachigen das zu lesen und zu verstehen. Ich empfehle so oder so die Fragen hier auf Englisch zu stellen, um mehr Leute abzuholen.
    • assign where ... benötigt keine explizite Klammerung des Ausdrucks, wenn nur einer gegeben ist.
    • das CheckCommand "cmd-check-snmp-fan-6" hat viele Argumente hardcoded. Die sollten zumindest via lokalem vars.<attribut> am CheckCommand festgemacht werden, um ggf. im Service überschrieben zu werden. Dinge wie SNMP-Communites wirst du an mehreren Stellen pflegen müssen, und das sollte *nicht* in jedem CheckCommand dann hardcoded drinnen sein.
    • imports im Service-Apply befolgen eine Reihenfolge und sollten daher immer am Anfang importiert werden. Ansonsten überschreibst du ggf. etwas.
    • Notification-Regeln sind nicht nur auf eine festgelegt. Du kannst und musst da mehrere pflegen.
    • Es ist keine gute Idee, sich nur an der Beispiel-Konfiguration zu orientieren und diese zu modifizieren. Im besten Fall beginnst du neu, und schreibst die ersten Definition selbst, um zu lernen wie die Sprache tickt. Auch die Organisation sollte separat erfolgen, das ist insbesondere dann interessant, wenn du in verteilte Umgebungen später einsteigen willst (die Doku hat dazu ein eigenes Kapitel in "Configuring Icinga 2").
    • Wie Apply funktioniert, hast du glaube ich noch nicht ganz verstanden. Spätestens die Frage nach "to Host" oder "to Service" sollte dich in die Doku springen lassen, und verstehen, welche Objekte hier generiert werden. Was ist denn deiner Meinung nach das Notification-Objekt was dabei rauskommt? Welche Objekt-Relation wird hier hergestellt? Welchen Effekt hat eine Host-Notification wo nur das "host_name" Attribut gesetzt ist? Was passiert, wenn du eine Service-Notification-Apply-Regeln erstellst, und interval veränderst? Welchen Effekt hat es, wenn du mehrere Service-Notifications mit unterschiedlichen Usern erstellst?