Getty Images/iStockphoto
Wie Sie serverlose Apps durch Observability optimieren
Serverlose Apps bringen Herausforderungen mit sich und manchmal ist es fast unmöglich, Fehler zu beheben. Wenden Sie sich deshalb neuen Überwachungspraktiken zu.
Observability basiert auf der vollständigen Transparenz von Anwendungs-Workflows, einschließlich serverloser Apps. Eine starke Observability-Strategie kann Probleme ausmerzen, muss aber richtig ausgerichtet und sorgfältig implementiert werden.
Im Gegensatz zum Hosting im Rechenzentrum und zu herkömmlichen Cloud-Diensten wie Infrastructure as a Service (IaaS) werden bei serverlosen Bereitstellungen keine Ressourcen für Anwendungen im Voraus festgelegt. Stattdessen werden kleine Anwendungskomponenten – oft als Funktionen oder Microservices bezeichnet – nach Bedarf bereitgestellt und auf der Grundlage von Nutzungsparametern freigegeben. Ressourcen sind nicht explizit, müssen also nicht verwaltet werden, und Unternehmen zahlen nicht für ungenutzte Ressourcen. Allerdings sind Ressourcen nicht beständig, so dass herkömmliche Überwachungsstrategien wahrscheinlich scheitern, da sie sich auf den Zustand der Ressourcen verlassen, um Probleme zu erkennen.
Die beste Strategie hängt davon ab, wie Cloud-Teams in Unternehmen die drei folgenden Faktoren für serverlose Bereitstellungen abwägen:
- Komplexität der Workflows, die serverlose Komponenten verbinden: Je größer die Komplexität ist, desto mehr geht die Observability-Strategie in Richtung Stack Tracing und Probes.
- Breite der Ressourcenbasis, auf der die Komponenten bereitgestellt werden: Eine Cloud, Hybrid Cloud oder Multi-Cloud; je breiter die Basis, desto schwieriger ist es, sich auf Tools von Cloud-Anbietern zu verlassen.
- Primäre Aufgabe der Observability: Liegt die Hauptaufgabe im Ressourcen- und Kostenmanagement, in der Qualität der Benutzererfahrung (QoE) oder in der Fehlersuche und -behebung? Da sich die Aufgabe von Ressourcen und Kosten wegbewegt, konzentriert sich die Observability zwangsläufig mehr auf Workflows und Logik.
Serverlose Observability-Strategien stützen sich auf eine Vielzahl von Methoden, um effiziente und gesunde Anwendungen zu gewährleisten. Im Folgenden werden Faktoren wie Protokollierung, Tracing, Latenz und Kostenerwägungen untersucht.
Protokollierung
Ein Cloud-Anbieter kann Benutzern die Historie der bereitgestellten serverlosen Komponenten in Form von Protokollen und Stack Traces zur Verfügung stellen. Mit diesen Informationen können Komponentenaktivierungen nachverfolgt werden und Teams können den Workflow analysieren, vorausgesetzt, sie kennen die Transaktionen oder Aktivität, mit der die Anwendung gestartet wurde.
Serverlose Observability in einer einzigen Cloud
Einfache serverlose Workflows – solche mit wenigen logischen Verzweigungen und begrenzter Verwendung von serverlosen Komponenten in mehreren Workflows –, die einen einzigen Cloud-Anbieter nutzen, können sich wahrscheinlich auf die folgenden grundlegenden Cloud-Anbieter-Tools verlassen:
- Amazon CloudWatch
- Azure Monitor
- Google Clouds Operations Suite
Diese Tools funktionieren, weil die Aktivitäten jedes Anwendungsbenutzers einem statischen Satz von serverlosen Komponenten zugeordnet sind. Alles, was zur Überwachung der Ressourcennutzung und der QoE und sogar zur Fehlerbehebung von Anwendungen erforderlich ist, sind die Reihenfolge und der Zeitpunkt der Komponentenaktivierungen. Diese stützen sich auf Protokolle und Stack Traces, um Daten über Aktivierungen zu präsentieren, und sie sind abhängig von den Funktionen der einzelnen Cloud-Dienste.
Serverlose Observability in Multi-Clouds
Komplizierter wird die Situation bei komplexen Workflows, die logische Verzweigungen durch Komponenten enthalten, einige Komponenten in mehreren Anwendungen verwenden oder einfache Workflows haben, die mehrere Clouds umfassen.
Hier sind proprietäre Tools wertvoll, weil sie komponenteninterne Telemetrie zur Verfolgung von Logikflüssen bereitstellen können und sie oft mehrere Cloud-Umgebungen unterstützen. Für die Multi-Cloud-Observability einfacher Abläufe können Produkte wie Lumigo oder Honeycomb Informationen aus Monitoring und Ereignissen, Protokollanalyse, Tracing und Stack Tracing einbeziehen.
Tracing
Die Anwendung selbst kann Trace- oder Probe-Funktionen bieten, die Ereignisse an Schlüsselpunkten der Verarbeitung erzeugen. Diese Ereignisse können dann die Arbeit durch die Anwendung verfolgen.
Stack Tracing ist die Mindestanforderung zur Unterstützung komplexer Arbeitsabläufe. Es ermöglicht Betriebsteams, Aktivierungen von serverlosen Komponenten als eine bestimmte Sequenz zu korrelieren. Wenn diese Sequenzen mit den beteiligten Transaktionen verknüpft sind, können Teams die Ressourcennutzung überprüfen, Latenzzeiten verfolgen, Kosten zuweisen und optimieren sowie Fehler beheben.
Datadog ist hier ein häufig verwendetes Tool, das Workflows für Single-, Multi- und Hybrid Clouds verfolgen kann. Andere Tools wie Elastic Observability und AWS X-Ray verbessern die Beobachtbarkeit durch Hinzufügen von Stack Traces, insbesondere in Kombination mit Überwachungs-Tools von Cloud-Anbietern.
Logic Tracing
Komplexe Workflows erfordern manchmal Logic Tracing, so dass Teams Sonden und Tools für das Anwendungsleistungsmanagement in die Observability-Strategie einbeziehen müssen. Das ist ein notwendiger Schritt, da es schwierig ist, den Pfad zu analysieren, den eine Transaktion genommen hat, im Vergleich zu dem, den sie hätte nehmen sollen, ohne die Logik zu kennen, die zur Entscheidung über den Workflow-Pfad verwendet wurde. Es ist auch schwierig, die Auslastung und Latenz für jede Transaktion zu verfolgen. Daher können Teams Sonden hinzufügen, um Ereignisse zu erzeugen.
OpenTelemetry und OpenTracing definieren Standards für programminterne Sonden. Unternehmen wie Dynatrace unterstützen die Sammlung und Analyse von Daten aus diesen programminternen Instrumentierungssonden. Inzwischen unterstützen Open-Source-Projekte wie Jaeger und Appdash die Instrumentierung. Einige Cloud-Dienste können diese Tools ebenfalls anbieten. Oracle Cloud Instrastructure Application Performance Monitoring unterstützt OpenTracing-Sonden.
In-Code-Sonden oder Instrumentierung sind wahrscheinlich entscheidend für das Debugging von serverlosem Code. Es ist schwierig, interaktives Debugging mit serverlosen Komponenten zu verwenden, da die Einführung von Echtzeit-Debugging das Timing der Komponenten verändert. An Schlüsselpunkten der Logik eingeführte Sonden können unterstützen, Probleme mit der Logik einzugrenzen. Sie können auch Faktoren wie das Wissen über die Pfade, die ein Workflow durch eine Anwendung nimmt, oder die Gründe für die Auswahl eines Pfads verfeinern.
Überlegungen zu Latenzzeiten und Kosten
Es mag aus betrieblicher Sicht sinnvoll erscheinen, die Verwaltung von Servern, virtuellen Maschinen (VM) oder Containern zu vermeiden. Die bedarfsgesteuerte Ausführung von Microservices verursacht jedoch zusätzliche Kosten und Latenzzeiten, wenn jeder Service geladen wird. Wenn die Anzahl der auslösenden Ereignisse zunimmt, können die serverlosen Kosten deutlich steigen. Es kann der Punkt erreicht werden, an dem es günstiger ist, entweder ein serverloses Framework in der Cloud über Kubernetes oder Knative bereitzustellen oder stattdessen Container zu verwenden.
Es ist schwer zu sagen, wo die Kostengrenze bei Serverless liegt. Es ist jedoch sinnvoll, einen Pilottest für einen alternativen Ansatz durchzuführen, wenn der Ressourcenverbrauch und die Kosten unerwartet hoch sind oder wenn die QoE durch angesammelte Verzögerungen im Workflow beeinträchtig wird. Viele Observability Tools sind auch in Container- oder Knative-Umgebungen einsetzbar, sodass Unternehmen die Observability über alle sinnvollen Hosting-Optionen hinweg aufrechterhalten können.
