INHALTSVERZEICHNIS


Erklärung

Beim Anlegen eines servereye 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 servereye gilt - "Eine Mail, die man liest und löscht ohne direkt etwas tun zu müssen, ist eine unnötige Mail".

 

Das Alarmierungskonzept von servereye 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 servereye 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 servereye richtig konfiguriert, nimmt man die Verantwortung vom Techniker, die Mails zu priorisieren, denn jede E-Mail, die kommt, stellt zu dem Zeitpunkt des Eintreffens einen relevanten Alarm dar, auf den sofort reagiert werden muss. Die Vorselektierung wann was relevant wird, trifft man in servereye.

 

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 servereye 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 beizeiten mit erhöhter Chance auf Fehlalarme entsprechend auszusetzen.


Im Beispiel CPU Auslastung lasse ich das voreingestellte Intervall auf 5 Minuten. Da beim Kunden jeden Abend von 20:00 - 22:00 Uhr 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 servereye mehrere Alarmierungsarten:

  • per E-Mail
  • per SMS (zusätzlich kostenpflichtig)
  • per Push (Android / iOS App)
  • per morgendlicher Statusmail (schwächste Alarmierungsart)
  • per Ticket
  • per Wall

 

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

 

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 minutengenaue 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 unten 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 findest Du 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 der 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.