Die Zukunft des IT Service Managements im Cloud-Zeitalter (Teil 6)


Gastbeitrag von Jochen Ott, IT Service Management Architect bei Microsoft Deutschland

Wie im vorherigen Beitrag angekündigt, werfen wir in dieser Folge einen Blick auf diesen „Service Monitoring Service“: Application Teams kennen ihre Anwendung. Wir kennen unseren „Service Monitoring Service“. Es braucht nur einige wenige Dinge, um unseren Service bei den Application- bzw. den Service Teams bekannt und nutzbar zu machen.

  1. Events
  2. Schnittstelle E-Mail-Eingang

Egal über welches Device in der IT wir heute sprechen, ob es ein System, eine Plattform oder eine Netzwerk-Komponente ist, alle diese Geräte schreiben Events – Tausende von Events. Jedes dieser Systeme für sich stellt ein Stück Kapazität dar, die zusammen den Service ausmachen. Wir sprechen von „Capacity Monitoring“, wenn wir alle diese Komponenten im Blick haben wollen. Wir brauchen Schnittstellen zu jeder „Capacity Class“, die von unseren Application-Teams genutzt werden. Über diese Schnittstellen sammeln wir die Event-Informationen ein (SNMP Network Traps, Win Server Event Logs, Internet of Things device logs usw.). Wenn dies so umgesetzt ist, brauchen unsere Application-Teams nur noch Code schreiben, der die passenden Events schreibt – genau zu den Zuständen der App, die der Entwickler für beachtenswert hält.

Eine zweite wichtige Komponente für einen „Service Monitoring Service“ ist die Möglichkeit, eingehende Events und Alerts, die über E-Mail empfangen werden, zu verarbeiten. Entwickler werden Lösungen entwickeln oder kaufen, die Zustände über E-Mail kommunizieren. Gleiches gilt für die unterschiedlichsten Cloud Services, auch hier ist E-Mail noch immer ein Mittel der Wahl zum Transport von Statusnachrichten. Wir benötigen Zugriff auf alle diese Nachrichten für unseren „Service Monitoring Service“. Sie bilden die Metadaten, aus denen wir alle Informationen beziehen und interpretieren.

So kann die Behandlung von E-Mail-Benachrichtigungen im Detail aussehen:

  • Aufsetzen einer Monitoring Inbox für jede Anwendung – oder auch jedes Service-Team
  • Jedes dieser Teams muss die Monitoring Inbox in den Alert-Mechanismus integrieren. Sprich jeder Alert der via E-Mail geschrieben wird, geht zentral an die Monitoring Inbox.
  • Der „Service Monitoring Service“ schaut nun mit der eingestellten Frequenz in diese Inbox(en), nimmt die Alerts auf, wertet sie automatisch aus und generiert dann Alerts für die Application- bzw. Service- Teams. Ab hier handelt es sich dann wieder um ganz normale Alerts, wie wir sie kennen – wir nutzen die bisher vorhanden Wege und Systeme der Verteilung.
  • Der verwendete Code macht es möglich die Inbox(en) automatisch zu leeren, um ein Überlaufen zu verhindern.

Da wir gerade bei den Details des „Service Monitoring Service“ sind, möchte ich noch einige Worte auf das Performance-Monitoring verwenden. Eines der Probleme eines „Service Monitoring Service“ könnte sein, einen zu großen Bereich abdecken zu wollen. Selbst wenn man dieses Risiko verstanden hat, wird dennoch oft versucht, es allen recht zu machen. Dies geht für gewöhnlich nicht gut. Hintergrund: Die IT-Organisation möchte nicht, dass sich die Application Teams mit einer Monitoring-Lösung selbstständig machen.

Performance-Monitoring ist applikationsabhängig. Jede Applikation hat ihre eigenen Schwellenwerte, reagiert anders, muss anders im Monitoring behandelt werden. Daten werden mit unterschiedlicher Frequenz eingesammelt, die Aufbewahrung der Daten ist deutlich unterschiedlich geregelt. Würden wir mit unserem „Service Monitoring Service“ hier wieder versuchen, es jedem recht zu machen, wird der Service scheitern. Wir arbeiten dann gegen die Vision und das Ziel dieses Service.

Sie sehen, hier kommen wir an eine Engstelle. Es geht sicherlich keiner den Gedanken mit, dass wir in Zukunft kein Performance-Monitoring mehr benötigen. Die Lösung kann nur darin liegen, den „Service Monitoring Service“ und den „Performance Monitoring Service” erst einmal entkoppelt zu betrachten. Die Application-Teams müssen lernen, alles was Performance betrifft zu einfachen Events zu verarbeiten, die der „Service Monitoring Service“ dann wie jedes andere Event aufnehmen und bearbeiten kann.


Dieser Beitrag ist Teil einer mehrteiligen Artikelserie. Autor der Serie ist Jochen Ott, IT Service Management Architect bei Microsoft Deutschland.

Serie: Die Zukunft des IT Service Managements im Cloud-Zeitalter

Comments (0)

Skip to main content