Published by Thomas Timmermann
Last updated on März 03, 2022
•
9 minute read
PRTG bietet zahlreiche vordefinierte Sensoren, die jeder einen oder auch mehrere Aspekte Ihres Netzwerks bzw. Ihrer IT überwachen. Damit erhalten Sie umfassende Informationen beispielsweise zum Zustand Ihres Webservers, Ihrer Datenbank oder Ihres VMware Hosts. Allerdings liefert Ihnen ein einzelner Sensor nicht die Information, ob ein komplexer Prozess noch funktioniert, obwohl einzelne Komponenten ausgefallen sind. So könnte beispielsweise einer von zwei Webservern ausfallen, woraufhin zwar erhöhte Alarmbereitschaft gegeben sein dürfte, die Webseite aber immer noch für die Kunden erreichbar wäre, der Prozess „Webseite" also noch funktionieren würde.
Für solche Fälle gibt es jetzt in PRTG den Business Process Sensor: Damit fassen Sie mehrere Sensoren zu einem Prozess zusammen und definieren individuelle Stufen für Warnungen und Alarmierungen anhand der Wichtigkeit der einzelnen Sensoren. So sind Sie in der Lage, Prioritäten zu setzen, Risiken besser einzuschätzen und komplexe Infrastrukturen übersichtlich abzubilden. Allerdings erfordert der Business Process Sensor ein wenig Vorarbeit: Zwar ist der Sensor in der Bedienung sehr einfach, jedoch erfordert die Konzeption des abzubildenden Prozesses mit all seinen Aspekten im Vorfeld einiges an Denkarbeit.
Beispielprozess Webseite
Nehmen wir als Beispiel den bereits erwähnten Prozess „Webseite". Wir haben uns dabei auf das Website-Backend beschränkt und den Prozess bewusst einfach gestaltet, um Ihnen den Einstieg in den Business Process Sensor leichter zu machen: Ein Load Balancer verteilt einkommende Nutzeranfragen auf 4 Webserver, die wiederum aus zwei redundanten Datenbanken befüllt werden, und wir setzen nur Ping-Sensoren ein, gehen also nur von „erreichbar" oder „nicht erreichbar" aus.
Der Prozess besteht also aus drei Komponenten (Load Balancer, Webserver, Datenbanken), von denen Webserver und Datenbanken mehrfach vorhanden sind und so Redundanzen bilden – eine Grundvoraussetzung für den sinnvollen Einsatz des Business Process Sensors: Gibt es keine Redundanzen, führt der Ausfall jedes einzelnen Aspektes direkt zum Ausfall des kompletten Prozesses. In unserem Website-Backend-Prozess könnten dagegen drei Webserver und eine Datenbank ausfallen und der Prozess würde immer noch funktionieren, sprich die Webseite wäre nach wie vor für Kunden erreichbar.
Um das im Business Process Sensor abzubilden, setzen wir jeweils einen Ping-Sensor auf den Load Balancer, auf die einzelnen Webserver und die Datenbanken und fassen dann die Sensoren der Prozesskomponenten in Channels des Business Process Sensors zusammen und benennen diese entsprechend: Load Balancer, Web Servers und Database.
Jetzt heißt es, die Werte für Benachrichtigungen und Alarme zu definieren. Das geschieht über Prozentangaben: Für die vier Webserver legen wir 75 % für eine Benachrichtigung (Warning) und 50 % für einen Alarm (Error) fest. D. h. für die Komponente Webserver müssen mindestens 3 Webserver (75 %) verfügbar sein, ansonsten geht der gesamte Prozess in den Warning-Status und eine entsprechende Meldung wird versendet. Fällt ein Webserver aus (= 75 % Verfügbarkeit), bleibt der Prozess grün und keine Benachrichtigungen oder Alarme werden versendet. Sind weniger als 50 % verfügbar, sprich nur noch ein Webserver, so geht der Business Process Sensor in den Error-Status und verschickt entsprechende Alarmierungen. Nachdem nur ein Load Balancer vorhanden ist, würde dessen Ausfall den kompletten Prozess lahmlegen. Für den entsprechenden Channel im Business Process Sensor heißt das, dass wir eine benötigte Verfügbarkeit von 100 % festschreiben, sowohl für Warning als auch für Error. In der PRTG Knowledge-Base finden Sie diesen Prozess detailliert abgebildet und beschrieben.
Grünes Licht für den Chef
Über die Benachrichtigungsoptionen in PRTG können wir Art und Versand der jeweiligen Alarme einrichten. So könnte als Warning-Benachrichtigung eine E-Mail an den Administrator versendet werden, bei Error eine SMS an das ganze IT-Team. Sind sämtliche Channels im „Up-Status", zeigt auch der Business Process Sensor „Up" (=grün). In unserem Beispiel könnte also ein Webserver ausfallen und der komplette Prozess wäre noch grün. Fällt dann allerdings noch ein Server aus, würde der entsprechende Channel und damit der gesamte Sensor in den Warning-Modus (=gelb) gehen.
Wollen Sie mit dem Business Process Sensor auf einer Map für Ihren Chef lediglich zeigen, dass der Prozess funktioniert, also die Webseite erreichbar ist, legen Sie die Werte für Warning und für Error auf 100 % für den Load Balancer, 25 % für die Webserver und 50 % für die Datenbanken fest. Solange also der Load Balancer und noch jeweils ein Web- und ein Datenbankserver arbeiten, wäre der Business Process Sensor grün. Damit Sie als Administrator trotzdem informiert werden, wenn einzelne Server ausfallen, können Sie bei den Sensoren der einzelnen Server individuelle Benachrichtigungs- und Alarmierungsschwellwerte definieren.
Etwas Aufwand für viel Durchblick
Bereits bei diesem sehr einfachen Beispiel sind relativ komplexe Überlegungen und Strategien erforderlich. „Im echten Leben" wird es schnell noch deutlich komplexer: Normalerweise überwachen Sie ja nicht nur die blanke Verfügbarkeit über einen Ping Sensor und selbst bei einem so einfachen Prozess wie dem beschriebenen Website-Backend spielen noch viel mehr Komponenten wie beispielsweise Firewalls, Switches, Content Management Systeme etc. eine Rolle. Was ist der Vorteil, warum sollen Sie das auf sich nehmen?
IT ist komplex. Gutes Monitoring vereinfacht diese Komplexität und gibt Ihnen einen globalen Überblick. Natürlich hilft es schon, wenn Sie auf einer umfassenden Übersicht alle Einzelkomponenten abbilden. Allerdings bleibt es dabei schwierig, auf einen Blick zu erfassen, ob gerade unternehmenskritische Prozesse bedroht sind oder ob zwar einige Komponenten Ausfälle oder Leistungseinbußen zeigen, der Bestellprozess für Ihre Kunden aber immer noch funktioniert oder Ihre Kollegen nach wie vor Ihre internen Systeme nutzen können. Hier kommt der Business Process Sensor ins Spiel: Er führt viele Einzelkomponenten in einem Prozess zusammen. Sie sehen auf einen Blick, ob Ihre Kommunikationswege über E-Mail, Skype oder IP-Telefonie reibungslos arbeiten, ob Ihr Vertrieb mit CRM, Webshop und allen zugehörigen Systemen funktioniert oder ob Ihre DevOps auf eine funktionierende Entwicklungsumgebung zugreifen können. Unabhängig davon, ob vielleicht einzelne Geräte oder Dienste von Störungen oder Ausfällen betroffen sind.
Unsere Empfehlung ist klar: Nutzen Sie den Business Process Sensor! Fangen Sie mit einfacheren Prozessen an, um ein Gefühl für die Möglichkeiten zu entwickeln. Planen Sie im Voraus, definieren Sie Ihre Prozesse und priorisieren Sie entsprechend. Sie werden sehr schnell sehen, dass der PRTG Business Process Sensor ein mächtiges Werkzeug ist, wenn es darum geht, Zusammenhänge zu erkennen und einen schnellen Überblick über Ihre Geschäftsprozesse zu bekommen.
Weiterführende Informationen (Englisch)
PRTG bietet zahlreiche vordefinierte Sensoren, die jeder einen oder auch mehrere Aspekte Ihres Netzwerks bzw. Ihrer IT überwachen. Damit erhalten Sie umfassende Informationen beispielsweise zum Zustand Ihres Webservers, Ihrer Datenbank oder Ihres VMware Hosts. Allerdings liefert Ihnen ein einzelner Sensor nicht die Information, ob ein komplexer Prozess noch funktioniert, obwohl einzelne Komponenten ausgefallen sind. So könnte beispielsweise einer von zwei Webservern ausfallen, woraufhin zwar erhöhte Alarmbereitschaft gegeben sein dürfte, die Webseite aber immer noch für die Kunden erreichbar wäre, der Prozess „Webseite" also noch funktionieren würde.
Für solche Fälle gibt es jetzt in PRTG den Business Process Sensor: Damit fassen Sie mehrere Sensoren zu einem Prozess zusammen und definieren individuelle Stufen für Warnungen und Alarmierungen anhand der Wichtigkeit der einzelnen Sensoren. So sind Sie in der Lage, Prioritäten zu setzen, Risiken besser einzuschätzen und komplexe Infrastrukturen übersichtlich abzubilden. Allerdings erfordert der Business Process Sensor ein wenig Vorarbeit: Zwar ist der Sensor in der Bedienung sehr einfach, jedoch erfordert die Konzeption des abzubildenden Prozesses mit all seinen Aspekten im Vorfeld einiges an Denkarbeit.
Beispielprozess Webseite
Nehmen wir als Beispiel den bereits erwähnten Prozess „Webseite". Wir haben uns dabei auf das Website-Backend beschränkt und den Prozess bewusst einfach gestaltet, um Ihnen den Einstieg in den Business Process Sensor leichter zu machen: Ein Load Balancer verteilt einkommende Nutzeranfragen auf 4 Webserver, die wiederum aus zwei redundanten Datenbanken befüllt werden, und wir setzen nur Ping-Sensoren ein, gehen also nur von „erreichbar" oder „nicht erreichbar" aus.
Der Prozess besteht also aus drei Komponenten (Load Balancer, Webserver, Datenbanken), von denen Webserver und Datenbanken mehrfach vorhanden sind und so Redundanzen bilden – eine Grundvoraussetzung für den sinnvollen Einsatz des Business Process Sensors: Gibt es keine Redundanzen, führt der Ausfall jedes einzelnen Aspektes direkt zum Ausfall des kompletten Prozesses. In unserem Website-Backend-Prozess könnten dagegen drei Webserver und eine Datenbank ausfallen und der Prozess würde immer noch funktionieren, sprich die Webseite wäre nach wie vor für Kunden erreichbar.
Um das im Business Process Sensor abzubilden, setzen wir jeweils einen Ping-Sensor auf den Load Balancer, auf die einzelnen Webserver und die Datenbanken und fassen dann die Sensoren der Prozesskomponenten in Channels des Business Process Sensors zusammen und benennen diese entsprechend: Load Balancer, Web Servers und Database.
Jetzt heißt es, die Werte für Benachrichtigungen und Alarme zu definieren. Das geschieht über Prozentangaben: Für die vier Webserver legen wir 75 % für eine Benachrichtigung (Warning) und 50 % für einen Alarm (Error) fest. D. h. für die Komponente Webserver müssen mindestens 3 Webserver (75 %) verfügbar sein, ansonsten geht der gesamte Prozess in den Warning-Status und eine entsprechende Meldung wird versendet. Fällt ein Webserver aus (= 75 % Verfügbarkeit), bleibt der Prozess grün und keine Benachrichtigungen oder Alarme werden versendet. Sind weniger als 50 % verfügbar, sprich nur noch ein Webserver, so geht der Business Process Sensor in den Error-Status und verschickt entsprechende Alarmierungen. Nachdem nur ein Load Balancer vorhanden ist, würde dessen Ausfall den kompletten Prozess lahmlegen. Für den entsprechenden Channel im Business Process Sensor heißt das, dass wir eine benötigte Verfügbarkeit von 100 % festschreiben, sowohl für Warning als auch für Error. In der PRTG Knowledge-Base finden Sie diesen Prozess detailliert abgebildet und beschrieben.
Grünes Licht für den Chef
Über die Benachrichtigungsoptionen in PRTG können wir Art und Versand der jeweiligen Alarme einrichten. So könnte als Warning-Benachrichtigung eine E-Mail an den Administrator versendet werden, bei Error eine SMS an das ganze IT-Team. Sind sämtliche Channels im „Up-Status", zeigt auch der Business Process Sensor „Up" (=grün). In unserem Beispiel könnte also ein Webserver ausfallen und der komplette Prozess wäre noch grün. Fällt dann allerdings noch ein Server aus, würde der entsprechende Channel und damit der gesamte Sensor in den Warning-Modus (=gelb) gehen.
Wollen Sie mit dem Business Process Sensor auf einer Map für Ihren Chef lediglich zeigen, dass der Prozess funktioniert, also die Webseite erreichbar ist, legen Sie die Werte für Warning und für Error auf 100 % für den Load Balancer, 25 % für die Webserver und 50 % für die Datenbanken fest. Solange also der Load Balancer und noch jeweils ein Web- und ein Datenbankserver arbeiten, wäre der Business Process Sensor grün. Damit Sie als Administrator trotzdem informiert werden, wenn einzelne Server ausfallen, können Sie bei den Sensoren der einzelnen Server individuelle Benachrichtigungs- und Alarmierungsschwellwerte definieren.
Etwas Aufwand für viel Durchblick
Bereits bei diesem sehr einfachen Beispiel sind relativ komplexe Überlegungen und Strategien erforderlich. „Im echten Leben" wird es schnell noch deutlich komplexer: Normalerweise überwachen Sie ja nicht nur die blanke Verfügbarkeit über einen Ping Sensor und selbst bei einem so einfachen Prozess wie dem beschriebenen Website-Backend spielen noch viel mehr Komponenten wie beispielsweise Firewalls, Switches, Content Management Systeme etc. eine Rolle. Was ist der Vorteil, warum sollen Sie das auf sich nehmen?
IT ist komplex. Gutes Monitoring vereinfacht diese Komplexität und gibt Ihnen einen globalen Überblick. Natürlich hilft es schon, wenn Sie auf einer umfassenden Übersicht alle Einzelkomponenten abbilden. Allerdings bleibt es dabei schwierig, auf einen Blick zu erfassen, ob gerade unternehmenskritische Prozesse bedroht sind oder ob zwar einige Komponenten Ausfälle oder Leistungseinbußen zeigen, der Bestellprozess für Ihre Kunden aber immer noch funktioniert oder Ihre Kollegen nach wie vor Ihre internen Systeme nutzen können. Hier kommt der Business Process Sensor ins Spiel: Er führt viele Einzelkomponenten in einem Prozess zusammen. Sie sehen auf einen Blick, ob Ihre Kommunikationswege über E-Mail, Skype oder IP-Telefonie reibungslos arbeiten, ob Ihr Vertrieb mit CRM, Webshop und allen zugehörigen Systemen funktioniert oder ob Ihre DevOps auf eine funktionierende Entwicklungsumgebung zugreifen können. Unabhängig davon, ob vielleicht einzelne Geräte oder Dienste von Störungen oder Ausfällen betroffen sind.
Unsere Empfehlung ist klar: Nutzen Sie den Business Process Sensor! Fangen Sie mit einfacheren Prozessen an, um ein Gefühl für die Möglichkeiten zu entwickeln. Planen Sie im Voraus, definieren Sie Ihre Prozesse und priorisieren Sie entsprechend. Sie werden sehr schnell sehen, dass der PRTG Business Process Sensor ein mächtiges Werkzeug ist, wenn es darum geht, Zusammenhänge zu erkennen und einen schnellen Überblick über Ihre Geschäftsprozesse zu bekommen.
You there!
