Kennt ihr das noch, C&C: Red Alert? Ich musste das Erscheinungsjahr googlen – 1996.
22 Jahre her, darf man gar nicht drüber nachdenken!
Reden wir über aktuelle Alerts
Alarme sind bei der Orion Plattform ein sogenanntes „platform feature“, also unabhängig von den tatsächlich verfügbaren Modulen. Zu finden ganz oben unter Alerts.
Dort dann bitte einmal ganz rechts auf „Manage Alerts“:
Auf einem frisch installierten System wird es ungefähr so aussehen:
Und damit fängt das DRAMA dann auch schon an
Jedes Solarwinds Modul bringt etliche Standardalarme, wie z.B. sende mir eine Email wenn ein Knoten nicht mehr antwortet, aber auch wenn irgendwo ein Schwellwert überschritten wurde.
Oder aber ein Switchport plötzlich nicht mehr verbunden ist, was vermutlich vollkommen normal gegen 17:02 am Abend ist wenn ich Accessports im System überwache. Glaubt mir, das hat es alles schon gegeben!
Das System sendet also einen ganzen Haufen Emails die im Grunde genommen nicht notwendig sind. Was machen wir also naturgemäss? Wir werden entnervt und beginnen Emails zu ignorieren.
Dann geht plötzlich ein Uplink down. Und wir merken es nicht, weil unser Monitoringsystem mich zugespamt hat.
Daher mein erster Vorschlag, und das ist vermutlich die Beste Idee die ihr heute liest:
Schaltet erst einmal alle Alarme aus.
Dazu sortieren wir oben nach „Enabled“ und klicken, dass ON oben steht. Alle markieren und „disable“ – erledigt. Ruhe im Haus. Enjoy the Silence ist übrigens von 1990 und damit noch älter als Red Alert.
Im Prinzip kann ich jetzt einen beliebigen Alarm anpassen. Passt jedoch bitte auf – bei einem out-of-the-box Alarm würde ich nur an einer Kopie arbeiten und nicht am Original. Dazu gibt es oben den Schalter „Duplicate & edit“.
Aber ich führe einmal durch den Prozess, einen Alarm komplett selbst zu erstellen, also oben auf „add new alert“.
Zuerst brauchen wir einen Namen, und vielleicht auch eine Beschreibung, wenn der Alarm komplexer ist.
Unten sind ein paar Einstellungen:
Die Zeit ist unter Umständen ganz interessant.
Hier wird nichts anderes getan, als alle 60 Sekunden zu überprüfen ob die Bedingung die gleich kommt eingetreten ist.
Zuerst denkt man sicherlich „Oh das möchte ich alle 10 Sekunden haben“ – aber das bringt nicht wirklich viel.
Bedenkt bitte, dass jede Überprüfung der Bedingungen CPU Zyklen kostet und ich grundsätzlich defensiv mit Ressourcen umgehen würde.
Dann: Die Daten, auf denen die Bedingung aufgebaut ist werden ja abgerufen. Dieser Vorgang geschieht alle x-Minuten je nachdem, was ihr eingestellt habt. Basis wäre alle 10 Minuten.
Macht es jetzt Sinn, alle paar Sekunden nach einer Situationsänderung zu schauen, wenn die zugrunde liegenden Daten eh nur alle 10 Minuten aktualisiert werden?
Bedingt.
Letzten Endes ist das ein dynamisches Konstrukt. Ich würde vermutlich Alarme gruppieren und wirklich kritische Dinge zeitnaher laufen lassen, was ein Kompromiss wäre.
Schaut dazu auch bitte in mein Posting zur Echtzeit.
Dazu empfiehlt sich dann auch die Einstellung „severity“
Die untere Position dient dem Erstellen von Limitierungen, welche dann in der Kontenverwaltung weiter definiert werden können. Dazu schreibe ich auch irgendwann einmal etwas, aber gerade lasst mich das einfach erklären mit „Mitarbeiter aus Berlin sieht nur Alarme aus Berlin.“.
Okay weiter geht’s mit dem nächsten Fenster – der Bedingung.
Was muss passieren, um meinen Alarm zu aktivieren.
Zuerst teilen wir dem System mit, auf was wir alarmieren möchten
Man kann hier ziemlich kreativ werden. Vielleicht möchte ich auf ein bestimmtes Exchange-Konto alarmieren – mein CEO ist gefährlich Nahe an der Obergrenze für Dateianhänge und ich möchte es ihm persönlich mitteilen, bevor die Automatik zuschlägt? Oder ich habe plötzlich eine unbekannte MAC Adresse in meinem Netzwerk?
Aber – ich bleibe bei der Node.
Die nächste Position ist der Umfang des Alarmes.
Gilt das Ding für alle Nodes in meinem Netz? Oder nur bestimmte?
Dann die eigentliche Bedingung. Normalerweise nehme ich ein simples Beispiel wie CPU Load:
Aber schaut einmal hier:
Ich bekomme nun Zugriff auf alles, was wir vom Element „node“ sammeln.
Unter Umständen ist das eine ziemlich lange Liste
Wir sehen rechts in der Vorschau was für ein Wert zurück geliefert wurde. Der Inhalt dieser Spalte gibt nicht immer Sinn – vielleicht haben wir gerade keine Infos zu den Werten – aber es hilft einzuschätzen, ob die Info hilfreich ist oder nicht.
Weil mir gerade die Kreativität abhanden geht nehme ich einmal den administrativen Kontakt:
Aber das reicht mir nicht. Ich klicke auf das Plus und kann mir andere Bedingungen danebenlegen:
Ich nehme eine weitere simple Bedingung – dieses Mal meine freundliche CPU:
Achtet auf die Zeile in Gelb – da versteckt sich ein logischer Operator!
Dann noch ein nettes Spielzeug – die Zeit:
Ganz unten dann noch die „advanced options“. Im Grunde genommen erlaubt das weitere, in sich abgeschlossene Bedingungen, die dann gegeneinander laufen:
Ein Szenario wäre hier vielleicht:
SQL A (on prem) down, Backup B (on prem) down, Notfall DB bei AWS antwortet auch nicht, in der Vertriebsabteilung klingeln Telefone, es ist noch nicht 17:00, ich habe keinen Urlaub.
Auweia!
Aber das wollen wir hier ja nicht. CPU Load und verantwortlich ist dieser Admin-Typ, das reicht mir. Also klicke ich auf weiter zum nächsten Fenster.
Soll sich der Alarm selbst ausschalten? Falls ja, unter welchen Bedingungen?
In den meisten Fällen ist die automatische Einstellung ratsam welche nichts Anderes besagt als „wenn die Bedingung die ich vorhin erstellt habe nicht länger wahr ist“.
Es mag aber auch eine Situation geben, in der ich die manuelle Bestätigung eines Mitarbeiters erwarte, dass alles in Ordnung ist.
Ich klicke auf weiter. Das nächste Fenster ist ganz einfach.
Gilt der Alarm rund um die Uhr? Unwahrscheinlich.
Ich möchte vielleicht andere Aktionen den Tag über auslösen als Nachts, oder auch meine Schwellwerte sind in der Nacht etwas entspannter als am Tag – oder umgekehrt!
Aber – Faulheit siegt heute und ich bleibe bei „always enabled“ und klicke auf weiter.
Jetzt sehen wir die verfügbaren Aktionen und davon gibt es eine ganze Menge:
Üblicherweise nehme ich das hier
Wenn ich auf meinen blauen Knopf drücke erscheint ein Fenster für weitere Details – hauptsächlich natürlich Empfänger und Inhalt der Email:
Vielleicht möchte ich eine Grafik in die Email legen? Bedenkt einfach, dass man sämtliche Charts in Orion in andere Webseiten oder eben Emails exportieren kann.
Oder, für den Fall das eine bestimmte Situation öfter auftritt ist es sinnvoll, Lösungsansätze gleich mit der Email zu senden damit die ausführende Person direkt weiss, was zu tun ist.
Oben im Screenshot sind schon einige Variablen aufgelistet, bei „insert variable“ sieht man eine List der verfügbaren Optionen.
Jetzt reicht mir das aber nicht – ich kann neben der Email direkt noch eine weitere Aktion starten
Ich entscheide mich für einen Ton:
Und jetzt könnte ich sogar noch eine Eskalationsstufe abbilden:
Vielleicht eine SMS?
Das macht ihr, wenn z.B. zuerst eine Email gesendet wurde, kein Mensch reagiert, und ihr dann vielleicht eine andere Email zu einem anderen Empfänger senden möchtet.
Was auch immer! Ich klicke auf weiter.
Wir können eine Aktion definieren die beim Zurücksetzen der Bedingung eingeleitet wird.
Noch eine Email? Mehr Spam? Nein Danke. Aber es gibt Situationen wo dies sehr nützlich sein kann.
Vielleicht habe ich ja ein Ticketing System informiert mit einer Email oder einem Syslog. Das System hat ein Ticket eröffnet, eventuell weitere Schritte eingeleitet. Jetzt könnte ich eine weitere Email, Syslog, Trap oder ähnliches Senden um dem System mitzuteilen, dass die Sache erledigt ist.
Zum Schluss, in Punkt 7, gibt es eine Zusammenfassung und danach kann ich meinen Alarm aktivieren.
So in etwa spielt sich das in den meisten Situation ab – es gibt natürlich noch Themen darüber hinaus wie z.B. dem Erstellen eines Alarms anhand einer ankommenden asynchronen Mitteilung.
Aber ich möchte es heute nicht unnötig verkomplizieren!
Deswegen gibt es jetzt Donuts zur Belohnung:
Normale Nutzer stöpseln das alles zusammen und nutzen die App um Szenen zu erstellen. Wir gehen hier einen Schritt weiter.
Die ist wie geschaffen für mein Alarmszenario.
Ich mag die einzelnen vorbereitenden Schritte nicht wiederholen – guckt einfach hier:
https://www.developers.meethue.com/documentation/getting-started
Mein Resultat ist zuerst eine red.ps1 – die Details ergeben Sinn wenn ihr die Anleitung oben gelesen habt - ich definiere meine Bridge mit 10.0.0.21 und die Hue Go mit dem Namen "Mobile" sowie mein Konto:
Aber viel besser:
Du stellst es einem Kollegen auf den Schreibtisch während du den Kaffee trinkst und sagst einfach "Du bist dran"!
Ich glaube genau dafür wurde das Ding erfunden.
Jetzt möchte ich aber auch eine SMS erhalten. Dazu gibt es verschiedene Optionen, eine kommt hier!
Auf einer Messe in Paris habe ich Mitarbeiter von SMSEagle kennengelernt die mir mitgeteilt haben, dass deren System schon mit der Orion Plattform verbunden und getestet wurde.
Das hat mich neugierig gemacht und man hat mir freundlicherweise ein Testkonto zur Verfügung gestellt.
SMSEagle ist im Prinzip ein Stück Hardware welches über ein Webinterface bedient wird. Strom drauf, LAN Kabel links, SIM Karte rechts rein und fertig.
Bei der Integration in unser Alarmsystem ist dann natürlich http-get die bequemste Lösung und ich muss mich nicht gross mit irgendwelchen API beschäftigen, tatsächlich muss ich nur die Syntax kennen.
Also!
Mein Alarm – Position 5 – Action!
Die SMSEagle Syntax ist echt einfach, URL, Name, Password, Telefonnummer und Inhalt:
url-of-smseagle/.../send_sms
Bei mir also:
Ich teste:
Ein paar Sekunden später habe ich die SMS auf meinem Telefon, auch international.
Stressfrei und einfach!
Habt ihr auch ein paar Ideen zu Alarmen?