Cloud

Monitoring und Beobachtbarkeit in Aktion

Dies ist der zweite Teil eines zweiteiligen Blogs. Im ersten Teil wurde erklärt, wie Monitoring und Beobachtbarkeit Hand in Hand gehen. In diesem Blogbeitrag beschreiben wir, wie wir die Beobachtbarkeit und das Monitoring bei Public Cloud Managed Services (PCMS) für unsere Kunden im Rahmen unseres Leistungsangebots für Managed Services umsetzen.

Wie wir die Beobachtbarkeit und das Monitoring bei PCM umsetzen

Gleich zu Beginn möchte ich sagen, dass sich die Landschaft der Infrastruktur und der Anwendungen unserer Kunden ständig weiterentwickelt. So wie der Kundenbestand und die Diversity wachsen, so wächst auch die Anpassung der Produkte an den Markt. Zu unseren Herausforderungen gehört das Onboarding neuer Kunden, was fast immer bedeutet, dass wir herausfinden müssen, wie wir neue Dienstleistungen und Anwendungen in der Cloud überwachen, manchmal in einer nativen und manchmal in einer hybriden Umgebung.

Ein Bild sagt mehr als tausend Worte. Das obige Diagramm zeigt die Details der Beobachtbarkeit und der Monitoring-Landschaft bei PCMS für Azure (wir haben auch AWS-Kunden, aber das ist ein anderer Blogbeitrag für einen anderen Tag).

Die erste Ebene, die Telemetrie, befindet sich auf der rechten oberen Seite. Dazu gehören Datenquellen unserer Public Cloud-Kunden, wie z.B. verschiedene Arten von Protokollen der PaaS- und SaaS-Cloud-Ressourcen, z.B. Aktivitätsprotokolle oder Anmeldeprotokolle, die mit EventHub erfasst werden, und deren Metriken, die von Azure Monitor gesammelt werden. Darüber hinaus senden die IaaS-Ressourcen ihre Metriken und Protokolle mithilfe von Beats-Agenten direkt an unseren Elastic Stack und erfassen auch die Verwaltungs- und Aktivitätsprotokolle der Cloud-Angebote von O365 und M365, um Lösungen für die Beobachtung und das Monitoring der Cloud-Arbeitsplatz-Domain bereitzustellen. Zu guter Letzt ist der Trend zu hybriden Szenarien zu nennen, bei denen unsere Kunden ihre verschiedenen Clouds und On-Premises-Infrastrukturen miteinander verbinden. Wir erfassen Protokolle und Metriken bestimmter Betriebsmittel, manchmal direkt und manchmal über öffentliche Cloud-Angebote wie Azure Arc und AWS Outpost.

Die zweite Ebene ist die Datenaufbewahrung. Bevor wir darauf eingehen, ist es wichtig, den Datenimport zu verstehen. Es gibt zwei Endpoints für die Dateneingabe. Sie lassen sich einfach in Push- und Pull-Modi unterteilen. Unsere Erfüllungsgehilfen Metricbeat und Filebeat laufen auf der Kubernetes-Infrastruktur und ziehen Metriken, Logs und Traces aus Public Clouds. Dies betrifft in erster Linie PaaS- und SaaS-Betriebsmittel. Die Ausnahme sind die Aktivitätsprotokolle, die für alle Arten von Betriebsmitteln gelten. Der zweite Endpoint für den Ingest ist unser Elastic Ingest Node, der sich direkt in unserem Elastic Stack befindet. Die Erfüllungsgehilfen, die auf IaaS- oder manchmal auch auf computergestützten Cloud-Appliances laufen, senden ihre Metriken, Logs und Traces direkt an unseren Elastic Stack. Sobald die Daten eingelesen sind, werden sie in Lucene-Indizes im Backend gespeichert. Die Retention der Daten hängt von der Datenart und dem Business Case ab. Sie kann jedoch für jeden Datensatz konfiguriert werden, um Kunden mit spezifischen Retention-Anforderungen zu unterstützen.

Die dritte und letzte Ebene sind die tatsächlichen Leistungen; hier passiert die Magie. Der erste Teil ist das Monitoring des Zustands der einzelnen Komponenten, das aus den Monitoring-Profilen abgeleitet wird. Ein typisches Monitoring-Profil enthält mehr als eine der nachstehenden Komponenten:

  • Warnmeldungen auf Basis von Metriken, Protokollen und Traces
  • Machine Learning-Jobs, Detektion von Anomalien auf der Grundlage von Datensätzen
  • SIEM, Sicherheitsereignisse auf Basis des eingehenden Datensatzes
  • Dashboards und Visualisierungen, basierend auf den eingehenden Datensätzen
  • Gespeicherte Suchen, die die eingehenden Datensätze betreffen

Eine weitere Leistung unseres Observability- und Monitoring-Stacks besteht darin, den Betriebsteams zu ermöglichen, Veränderungen zu verstehen. Mit der Möglichkeit, die zugrunde liegenden Datensätze, die aus allen möglichen Protokollen und Metriken bestehen, direkt abzufragen, können die Betriebsteams die Frage "Was hat den Change verursacht?" beantworten. Das lässt sich so zusammenfassen:

  • Bereitstellung der Dienstleistung
  • Konfiguration schieben
  • Veränderung der Arbeitsbelastung
  • Eine gebrochene Cloud-Abhängigkeit

Oder: "Welche Auswirkungen hat dieser Change?" Das lässt sich folgendermaßen zusammenfassen:

  • Kundenerlebnis
  • Gesundheit und Performance der Dienstleistung (auch SLOs genannt)
  • Betriebsmittelverbrauch und Kosten.

Um das letzte Wort aus dem ersten Teil der Normenreihe zu wiederholen: Monitoring und Beobachtbarkeit gehen Hand in Hand, das eine ersetzt das andere nicht, sondern ermöglicht und verbessert gemeinsam definierte Geschäftsergebnisse. Dies ist der zweite Teil eines zweiteiligen Blogs. Der erste Teil, der erklärt, wie Monitoring und Beobachtbarkeit Hand in Hand gehen, ist hier verfügbar.

Chetan Goswami

Chetan Goswami

DevOps Engineer

Mehr getIT-Beiträge

Bereit für Swisscom

Finde deinen Job oder die Karrierewelt, die zu dir passt. In der du mitgestalten und dich weiterentwickeln willst.

Was du draus machst, ist was uns ausmacht.

Zu den Karrierewelten

Zu den offenen Security Stellen