Wie Sie serverlose Apps durch Observability optimieren

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.