Erklärung

 

Beim Anlegen eines Server-Eye Sensors spielen 4 Gedankengänge bzw. Schritte zum Aufbau eines Alarmierungskonzepts eine wichtige Rolle. Der Hauptaspekt von Monitoring ist die Erleichterung für den Techniker. Eine Erleichterung ist aber nur gegeben, wenn Störfaktoren wie z.B. unnötige Mails vermieden werden. Generell als Faustregel bei Server-Eye gilt - "Eine Mail, die man liest und löscht ohne direkt etwas tun zu müssen, ist eine unnötige Mail".

 

Das Alarmierungskonzept von Server-Eye ist darauf ausgelegt Mailflut und unnötige Mails zu vermeiden. Erhält man zu viele Mails, liest man diese nicht mehr. Wichtige Alarmmeldungen gehen unter und das Monitoring ist ineffektiv -> man ist am Thema Monitoring vorbeigeschossen.

 

Mit Server-Eye kann man für jeden Sensor die Alarmierungen so einstellen, dass genau die Personen, die etwas tun müssen, genau zu dem Zeitpunkt eine Alarmierung erhalten, wenn (nach Firmenrichtlinien) der Alarm relevant wird. Ist Server-Eye richtig konfiguriert, nimmt man die Verantwortung vom Techniker, die Mails zu priorisieren, denn jede Email die kommt, stellt zu dem Zeitpunkt des Eintreffens einen relevanten Alarms dar, auf den sofort reagieren muss. Die Vorselektierung wann was relevant wird trifft man in Server-Eye

 

Die 4 Schritte zur idealen Alarmierung werden als Beispiel anhand des Sensors "CPU Auslastung" erklärt. Ich wähle den Sensorhub und lege den neuen Sensor an

 

Schritt 1 - Was soll der Sensor tun?

 

Als ersten Schritt definiere ich die Schwellwerte des Sensors und setze alle Einstellungen. Damit lege ich fest was der Sensor überhaupt prüfen soll.

 

Im Beispiel CPU Auslastung definiere ich den Schwellwert auf 90% und überwache alle Kerne im Verbund.

 

Schritt 2 - Wann soll der Sensor prüfen?

 

Habe ich definiert was der Sensor tun soll, muss ich festlegen wann und wie oft der Sensor prüfen soll. Die Häufigkeit der Prüfung wird durch das Sensorintervall bestimmt. Das Intervall wird von Server-Eye anhand gängiger Best Practises bereits vorbelegt. Es muss also nur im Bedarfsfall angepasst werden.

 

Neben dem Intervall kann ich Pausenzeiten setzen. Pausenzeiten definieren Zeiträume, in denen der Sensor nicht arbeitet, sprich pausiert wird. Pausenzeiten lassen sich halbstündlich genau für die ganze Woche setzen und dienen dazu, den Sensor bei Zeiten mit erhöhter Chance auf Fehlalarme entsprechend auszusetzen.

 

Im Beispiel CPU Auslastung lasse ich das voreingestellte Intervall bei 5 Minuten. Da beim Kunden jeden Abend von 20:00 - 22:00 eine Datensicherung mit Symantec Backup Exec durchgeführt wird, die die Maschine generell auslastet, setze ich für die gesamte Woche von 20:00 - 22:00 Uhr eine Pause in den Sensor. So erhalte ich keine unnötige Alarmierung, wenn die Maschine aufgrund der laufenden und bekannten Datensicherung ausgelastet wird.

 

Schritt 3 - Was soll im Fehlerfall passieren?

 

Habe ich definiert was und wann der Sensor prüfen soll, muss ich festlegen, was im Alarmfall passiert bzw. wer wie im Alarmfall alarmiert wird. Dazu bietet Server-Eye mehrere Alarmierungsarten:

 

- per Mail (Standard)

- per SMS (zusätzlich kostenpflichtig)

- per Push (Android / iOS App)

- per morgendlicher Statusmail (schwächste Alarmierungsart)

- per Tanss Ticket (Tanss ist eine deutsche Service Management Lösung)

- per Anzeige im Dashboard bzw. der Wall oder Karte

 

Alarmierungen anlegen kann ich auf beliebig viele Einzel-Useraccounts, beliebig viele Gruppen oder auch direkt auf Accounts / Gruppen meines Endkunden, dank der Mandantenfähigkeit von Server-Eye

 

Tipp: Durch Email Parsing kann hier auch jedes beliebige Ticketsystem direkt angemailt werden. Der Header der Server-Eye Alarmmails enthält alle wichtigen Informationen zum Parsen. Legen Sie dazu einfach die Parsing-Email-Adresse Ihres Ticketsystems als Account im Server-Eye an und tragen Sie die Adresse als Alarmierung ein.

 

Im Beispiel CPU Auslastung soll hier der Techniker "Tobias Weber" per Mail und SMS, der Geschäftsführer "Michael Krämer" per Mail und die Gruppe "Servertechniker" per Mail alarmiert werden

 

Schritt 4 - Wann wird ein anliegender Fehler für mich relevant?

 

Auf jede in Schritt 3 angelegte Alarmierung kann man Minuten genaue Verzögerungen anlegen. Die verzögerte Alarmierung dient zum Einen als Mittel zur Erstellung von Eskalationsstufen und zum Anderen zur Definition, wann genau ein anliegender Alarm für einen selbst relevant wird.

 

Durch Verzögerungen kann jeder Techniker festlegen wann er eine Alarmierung über den gefundenen Alarm erhalten will bzw. wie lange ein Alarm anliegen muss, bis der Techniker darüber informiert wird. Es gibt Fehlerfälle/Alarmfälle in der IT, die nicht sofort relevant sind, z.B. Toner leer, Ping schlägt fehl usw. Durch Verzögerungen lassen sich so unnötige Alarmierungen vermeiden bzw. erhält der Techniker erst eine Alarmierung, wenn er auch auf diese beim Erhalt reagieren muss. Zur besseren Erklärung und Verständnis bitte unbedingt das Beispiel beachten.

 

Durch Verzögerungen lassen sich auch Schwankungen im Sensor gut abfangen. Der Vorteil daran ist, dass der Techniker nicht sofort bei jedem Überschreiten der Schwellwerte eine Alarmierung erhält, jeder Übertritt aber in den Berichten und im Log dokumentiert ist.

 

Verzögerungen finden Sie im OCC unter den Systemhauseinstellungen. Es können beliebig viele Verzögerungen angelegt werden. Diese lassen sich dann global in jedem Sensor auswählen.

 

Im Beispiel CPU Auslastung legen wir als Erstes Eskalationsstufen fest. Der Techniker Tobias Weber setzt auf die Mail/SMS Alarmierung eine Verzögerung von 15 Minuten. Tobias Weber ist also der Erste, dem der Alarm gemeldet wird. Der Gruppe Servertechniker wird eine Verzögerung von 120 Minuten eingetragen. Reagiert Tobias Weber 120 Minuten lang auf den Alarm nicht, werden hier als nächst höhere Eskalationsstufe alle Techniker der Gruppe Servertechniker alarmiert. Bei Michael Krämer als Geschäftsführer wird eine Verzögerung von 240 Minuten gesetzt. Michael Krämer ist die letzte Instanz der Eskalation. Reagiert keiner der Techniker 240 Minuten lang auf den Alarm, erhält Michael Krämer eine Alarmierung, um z.B. die Einhaltung definierter SLA's oder Reaktionszeiten zu veranlassen.

 

Die 15 Minuten Verzögerung bei Tobias Weber definieren wann der Fehler relevant wird. Bei CPU Auslastung interessiert es den Techniker nicht, wenn die Maschine "mal kurz auf 100% peaked". Das kann mal vorkommen je nach gerade laufenden Prozessen. Relevant wird eigentlich erst, wenn die Auslastung der Maschine über 10-15 Minuten lang über 90% liegt, denn dies bedeutet im Normalfall, dass die Mitarbeiter des Kunden jetzt nicht mehr arbeiten können -> Alarmierung kommt -> Techniker muss sofort reagieren.