Dieser Beitrag wurde ursprünglich auf tfir.io veröffentlicht.
Kubernetes ist ein beliebtes Container-Orchestrierungssystem und steht im Zentrum der Projekte der Cloud Native Computing Foundation. Kubernetes automatisiert Deployment, Lebenszyklus und Betrieb von Containern, Containeranwendungen und Pods, also Gruppen von einem oder mehreren Containern. Die Plattform, zusammen mit den entsprechenden Arbeitslasten, kann Ereignisdaten generieren. Mit diesen Prozessen sind unterschiedliche Arten von Daten verknüpft. Logs reichen von einfachen Debug-Nachrichten im Stil von „Okay, Stelle erreicht“ bis hin zu ausführlichen Webserver-Zugriffslogs mit Transaktionsdaten. Metriken, oder Zeitreihendaten, sind numerische Werte, die in regelmäßigen Abständen gemessen werden, zum Beispiel die Anzahl der sofort ausgeführten Operationen pro Sekunde, Cache-Trefferraten, die Anzahl der Kundenzugriffe auf Ihre Site oder auch einfachere Dinge wie etwa der CPU- oder Arbeitsspeicherverbrauch eines Containers in den letzten fünf Sekunden.
Observability verarbeitet diese Logs und Metriken und macht sie durchsuchbar, normalerweise in einem entsprechenden Datenspeicher, und kombiniert sie oft zusätzlich mit Anwendungs-Trace-Daten. Diese Trace-Daten, oder auch ausführliche Application Performance Monitoring-Informationen (APM), erfassen, an welchen Stellen Anwendungen oder Dienste ihre Zeit aufwenden, wie und womit sie interagieren, und welche Fehler auftreten. Logs und Metriken liefern eine Black-Box-Ansicht einer Anwendung, und mit APM-Daten können Sie herausfinden, was im Inneren der Anwendungen vor sich geht.
Mit einer Kombination aus Logs, Metriken und Anwendungs-Trace-Daten können Sie die mittlere Dauer bis zur Erkennung und Behebung von Fehlern oder Incidents zwar reduzieren, aber in komplexeren Deployment-Modellen (z. B. mit Kubernetes) ist es auch wichtig, zu verstehen, wo bestimmte Aktionen in einer dynamischen Umgebung ausgeführt werden. An dieser Stelle kommen Metadaten ins Spiel.
Was genau sind Metadaten?
Laut Webster-Definition sind Metadaten „Daten, die Informationen über andere Daten liefern“. Klingt ziemlich unkompliziert, oder? Sie finden Metadaten an vielen Orten im Alltag, zum Beispiel auf der Seite mit diesem Blogeintrag. Sie enthält SEO-Tags, Hinweise zur korrekten Formatierung der Seite in unterschiedlichen Browsern und Schlüsselwörter, die die Seite beschreiben. Die Bilder auf Ihrem Mobilgerät enthalten ebenfalls eine ganze Reihe an Metadaten. Hier ist nur ein kleiner Ausschnitt:
ExifTool Version Number : 11.11 File Name : 60398459048__A20828DD-FAA4-4133-BA1F-059DEC9E7332.jpeg Directory : . File Size : 2.8 MB File Modification Date/Time : 2020:02:21 08:30:01-05:00 File Access Date/Time : 2020:02:21 08:30:23-05:00 File Inode Change Date/Time : 2020:02:21 08:30:22-05:00 MIME Type : image/jpeg JFIF Version : 1.01 Acceleration Vector : -0.03239090369 -0.9104139204 -0.3862404525 Exif Byte Order : Big-endian (Motorola, MM) Make : Apple Camera Model Name : iPhone XS Orientation : Rotate 90 CW X Resolution : 72 Y Resolution : 72 Exif Image Width : 4032 Exif Image Height : 3024
Sie fragen sich jetzt vielleicht, wie Ihnen der MIME-Typ eines iPhone-Fotos bei Ihrer Observability-Initiative helfen kann. Natürlich gar nicht, denn dafür sind Bild-Metadaten nicht gedacht. Aber Sie können sich einen Überblick darüber verschaffen, welchen Zweck Metadaten erfüllen. Mit den iPhone-Metadaten können Sie Ihre Bilder nach Größe, Ausrichtung und Verwackelungsgrad sortieren (daran muss ich scheinbar noch arbeiten). Lassen Sie uns einige Dinge betrachten, die Ihnen tatsächlich beim Korrelieren und bei der Navigation in Ihren Observability-Daten helfen können, nämlich die Logs, Metriken und Anwendungs-Trace-Daten aus Ihrer Umgebung.
Trends für Software- und Hardware-Deployments
Die Zeiten monolithischer Anwendungen auf Bare-Metal-Servern in einem Rechenzentrum, die genau einem Zweck dienen, gehören der Vergangenheit an. Es kommt zwar immer noch vor, dass dedizierte Arbeitslasten auf Servern ausgeführt werden, und daran ist nichts Verkehrtes. Viele große Anwendungen und Produkte nehmen sich alle Rechenleistung, die sie bekommen können. Global gesehen bewegen sich die Branchentrends für Software- und Hardware-Deploymentmodelle jedoch in Richtung Microservices und Container.
Diese Umstellung ist kein völliger Neuanfang, und viele Anbieter setzen mehrere parallele Software-Deploymentmodelle zusammen mit mehreren Hardware-Mustern ein. Virtual Machines oder Cloudinstanzen führen Client-/Server- oder SOA-Anwendungen aus, und Container führen Images für ihre Microservices aus und werden mit Kubernetes oder Docker orchestriert. Oft greifen die Anwendungen und Dienste aus einem Deployment-Modell auf Dienste in anderen Modellen zu, und ein schicker neuer Microservice verwendet möglicherweise immer noch eine auf Bare-Metal gehostete Datenbank.
Angesichts der Vielfalt dieser heterogenen Systeme sind Metadaten besonders wichtig. Durch die Umstellung auf Container, Pods und dynamisch geplante Microservices wird es immer schwieriger, in einem Rechenzentrum auf eine Kiste zu zeigen und zu sagen: „Hier befindet sich meine Anwendung“. Möglicherweise befindet sie sich wirklich dort, vielleicht aber auch auf einem der anderen vier Server hinter Ihnen.
An dieser Stelle kommen Standort-Metadaten ins Spiel. Damit meine ich nicht Längen- und Breitengrade (obwohl diese Angaben auch hilfreich sein können), sondern ein Adressschema, mit dem Sie auf logische Weise zumindest erkennen können, woher bestimmte Daten (Logs, Metriken oder Anwendungs-Trace-Daten) stammen.
Infrastruktur-Eigenschaften
Auf die Lage kommt es an
Ihre Anforderungen hängen von der jeweiligen Umgebung ab, aber Sie sollten sich auch Gedanken über die Zukunft machen. Die Menge an verfügbaren Daten hängt davon ab, wo ein bestimmter Auftrag ausgeführt wird: Monolithische Anwendungen auf Bare-Metal liefern beispielsweise keine Kubernetes-Pod-Daten, und das ist auch in Ordnung. Wir interessieren uns für eine Brotkrumenspur, um Abläufe nachverfolgen zu können. Den Grund dafür werden wir gleich herausfinden.
Mit den Standortdaten können wir eine Metadaten-Hierarchie bis hin zur Anwendungsebene erstellen und herausfinden, wo der Auftrag physisch ausgeführt wird.
Rechenzentrum
Die Rechenzentrums-Metadaten sollten einen eindeutigen Bezeichner für jedes Rechenzentrum enthalten, z. B. den Namen der Stadt. Diese Informationen sind im Fall von Cloudanbietern etwas schwammiger, aber dafür gibt es parallele Alternativen. In diesem Fall nutzen wir den Cloudanbieter und die entsprechende Region, zum Beispiel GCP, europe-west1 und die Verfügbarkeitszone b.
Falls Sie dedizierte Ebenen in Ihren Rechenzentren verwenden, wie etwa bestimmte Hosts, die für Produktion oder Test reserviert oder über mehrere Projekte aufgeteilt sind, sollten Sie diese Informationen auch in Ihre Metadaten aufnehmen. Dabei handelt es sich um einen abgetrennten Teil Ihres Rechenzentrums, eine Art von Rechenzentrum im Rechenzentrum.
Host-Informationen
Ein Teil der Host-Informationen ist immer verfügbar, egal ob wir Bare-Metal, virtuelle Lösungen oder eine Cloudinstanz verwenden. Jeder Host hat Attribute für Hostname, IP-Adresse(n), Hardwaremodell oder Instanztyp, konfigurierten Arbeitsspeicher und Speicher sowie Informationen zum Betriebssystem. Wir können sogar noch ausführlichere Informationen einbinden, wie etwa den Standort des Hosts in Form von Etage, Rack, Reihe und Regal im Rechenzentrum. Es wäre nicht das erste Mal, dass ein gesamtes Rack von einer fehlerhaften Stromversorgung oder Verkabelung betroffen ist!
Anwendungsdetails
Wir haben jetzt genügend Informationen, um herauszufinden, wo einzelne Vorgänge ausgeführt werden - jedoch nur bis zur Hostebene, und auf jedem Host können viele verschiedene Dienste oder Anwendungen ausgeführt werden. Sobald wir uns mit Anwendungen und Diensten befassen, müssen wir die Metadaten der entsprechenden Ebene hinzufügen. An dieser Stelle wird das Ganze etwas verzwickt, daher gehen wir nicht zu sehr auf die Details ein und betrachten ein komplexes Szenario, in dem Microservices mit Kubernetes orchestriert werden. Dieses Beispiel lässt sich anschließend relativ einfach auf Bare-Metal-Anwendungen und virtualisiere Umgebungen übertragen.
Container in Kubernetes und Docker stellen automatisch einige Metadaten bereit, die Sie einbinden sollten. Wir benötigen zumindest den Container- und/oder Pod-Namen, das verwendete Image und die Version des Containers sowie die Startzeit. Im Idealfall binden wir auch den Netzwerknamen und IP-Informationen zusammen mit Netzwerk-, Arbeitsspeicher- und Speicherkontingenten ein. Sind Ihnen die Parallelen zu den Host-Informationen aufgefallen? Container und Virtual Machines sind im Grunde genommen Hosts, die auf anderen Hosts ausgeführt werden. Daher macht es Sinn, dieselben Informationen zu extrahieren.
Bei der Arbeit mit virtualisierten Umgebungen können wir dieselben Parallelen ziehen. Virtuelle Hosts haben dieselben Details wie physische Hosts: Name, IP-Adresse sowie Arbeitsspeicher- und Speichereinschränkungen.
An dieser Stelle haben wir ein Dilemma: doppelt vorhandene Feldnamen. Vergessen Sie nicht, dass wir eine Hierarchie pflegen möchten. Die Host-Metadaten stehen höher in der Hierarchie als Container oder Virtual Machines:
├── NYC DC 1
│ ├── Host 1
│ │ ├── vm 1
│ │ ├── vm 2
│ │ └── vm 3
│ └── Host 2
│ ├── vm 1
│ └── vm 2
└── NYC DC 2
└── Host 1
├── vm 1
├── vm 2
├── vm 3
└── vm 4
Wie Sie sehen, müssen wir diese Werte in unterschiedlichen, vorhersehbaren Namespaces ablegen, um Konflikte zu vermeiden. Dazu können wir sie beispielsweise als Schlüssel-/Wert-Paare übergeben. Die Metadaten für VM 2 auf Host 1 in NYC DC 1 könnten etwa Folgendes enthalten:
dc.name: "NYC DC 1" dc.floor: 2 <other dc fields> host.name: "Host 1" host.IP: … host.available_memory_mb: 16384 vm.name: "vm 1" vm.IP: …
Container sind ein Ausnahmefall, was die Hierarchie betrifft, da ein Kubernetes-Cluster mehrere Hosts umspannen kann. In diesem Fall interessieren wir uns nicht nur für die Standortinformationen eines bestimmten Pods oder Containers, sondern auch für die entsprechenden Orchestrierungs-Metadaten, wie bereits oben erwähnt. Im nächsten Teil sehen wir uns an, wie wir die Observability unserer Anwendungen mit Metadaten verbessern können.
Observability für Anwendungen
Wir können die Aktionen in unseren Systemen jetzt vollständig adressieren und können damit beginnen, die eigentlichen Daten zu sammeln (denken Sie daran, dass Metadaten andere Daten beschreiben). Die „drei Grundpfeiler der Observability“ sind Logs, Metriken und Anwendungs-Trace-Daten (oder auch APM-Daten). Uptime-Daten werden manchmal auch als vierter Grundpfeiler genannt. Wie Sie im folgenden Diagramm sehen, erfassen wir Logs und Metriken in allen Ebenen unseres Ökosystems, inklusive Informationen darüber, welche Arten von Observability-Daten für die einzelnen Abstraktionen gesammelt werden sollten:
Wir möchten beispielsweise Logs, Metriken und Verfügbarkeitsdaten von allen Hosts oder Netzwerkelementen in unseren Rechenzentren erfassen und APM für Anwendungen und Dienste hinzufügen.
Wir reichern diese Daten mit den entsprechenden Metadaten für die einzelnen Ebenen an, um die Transparenz unserer Anwendungen, unserer Infrastruktur und des gesamten Ökosystems zu verbessern. Dies lässt sich auf viele Arten erreichen: Wir können die Daten zusammen mit jedem Ereignis oder Trace senden, um sie schnell durchsuchen und filtern zu können, oder wir können die Metadaten aus den statischen Teilen unseres Ökosystem speichern und später referenzieren. Die zweite Methode spart zwar etwas Speicherplatz, aber dafür besteht die Gefahr, dass Daten veralten, insbesondere in dynamischen Ökosystemen.
Das Puzzle fügt sich zusammen
Wir können unsere mit Metadaten angereicherten Observability-Daten nach beliebigen Aspekten unterteilen und analysieren, und müssen uns nicht auf bestimmte APM-Daten oder Logs beschränken. Wir können beispielsweise die aktuelle CPU-Auslastung pro Host und pro Dienst abfragen:
Oder wir können uns denselben Parameter über einen Zeitraum ansehen:
Auf diese Weise können wir uns auf die gewünschten Details konzentrieren und Fragen beantworten, die andernfalls unbeantwortet geblieben wären, wie etwa:
- Ist mein US-Rechenzentrum im Vergleich zum EMEA-Rechenzentrum überbeansprucht?
- Gibt es Racks in meinem Ökosystem, in denen unverhältnismäßig viele Fehler auftreten?
- Könnte ich einen Teil meiner Entwicklungs-Infrastruktur für die Produktionsumgebung nutzen?
- Auf welchen physischen Hosts werden die Container und Pods für meine E-Commerce-App ausgeführt?
- Und, zuletzt, warum sind meine iPhone-Fotos immer verwackelt?
Fazit
Metadaten bieten eine neue Dimension für Ihre Analyse und liefern neue Möglichkeiten, um Ihre Daten zu unterteilen, zu analysieren und um Geschäfts- und betriebliche Fragen zu beantworten. Achten Sie darauf, dass die Lösung für Ihre Observability-Initiativen mit Ihnen wachsen kann und außerdem durchsuchbare und navigierbare Metadaten berücksichtigt, wie etwa das Elastic Common Schema. Auf diese Weise können Sie sicherstellen, dass Ihre Metadaten an der richtigen Stellen landen.