Was ist AWS-Lambda-Monitoring?
AWS Lambda ist ein serverloser Computing-Service, der von Amazon Web Services bereitgestellt wird. Er ermöglicht die Ausführung von Code, von einfachen Funktionen bis hin zu ganzen Anwendungen, ohne dass man dafür Server bereitstellen und verwalten muss. Das AWS Lambda-Monitoring ist ein Teilbereich des AWS-Cloud-Monitorings, der sicherstellt, dass der AWS Lambda-Code ohne Probleme und Verzögerungen läuft.
AWS Lambda ist ein komplexes Ökosystem, das viele Anwendungsfälle unterstützt. Es wird verwendet, um beliebigen Code auszuführen, der in vielen Sprachen geschrieben wurde, von JavaScript bis Go, von Python bis Ruby, C# und Rust, um nur einige zu nennen. AWS Lambda-Funktionen können für viele Bereiche verwendet werden: zum Ausführen von Websites, mobilen Apps oder Datenanalysen, zur Dateiverarbeitung und für viele andere Nutzungsszenarien.
Da es sich hierbei um kritische Teil der Infrastruktur eines Unternehmens handelt, ist es um so wichtiger sicherzustellen, dass diese Arbeitslasten effizient und gesund sind, indem Sie die bewährten AWS-Lambda-Monitoring-Verfahren befolgen. Das Monitoring von AWS-Lambda-Anwendungen kann Ihnen auch helfen, Leistungsprobleme, Ausfälle und Fehler in den Arbeitslasten zu erkennen.
Welche AWS Lambda-Metriken sollten Sie überwachen?
Standardmäßig zeigt Amazon CloudWatch Ihnen AWS Lambda-Metriken an. CloudWatch ist das zentrale Überwachungstool, das Metriken von allen AWS-Cloud-Services und -Ressourcen integriert. Diese Metriken sind im Gegensatz zu den anderen Funktionalitäten von AWS Lambda kostenlos. Amazon sendet die Lambda-Metriken jedes Mal an CloudWatch, wenn eine Funktion die Verarbeitung eines Ereignisses abschließt.
Für das Monitoring von Lambda können Sie einfach ein Dashboard in CloudWatch einrichten und die Metriken für Ihren gesamten Code auf AWS Lambda überprüfen oder ein AWS-Lambda-Monitoring-Tool eines Drittanbieters verwenden, das die Metriken unterstützt, an denen Sie interessiert sind. Es gibt unterschiedliche Arten von Lambda-Metriken, die in 4 Kategorien gruppiert sind: Aufruf, Leistung, Gleichzeitigkeit und asynchroner Aufruf.
AWS-Lambda-Invocation-Metriken
Invocation-Metriken sind Indikatoren für das Ergebnis Ihrer Lambda-Funktionen. Die wichtigsten Metriken, die Sie überwachen sollten, sind die Gesamtzahl der Funktionsaufrufe (Invocation Count), die Anzahl der zurückgegebenen Fehler (errors returned), die Destination Delivery Failures (die Anzahl der fehlgeschlagenen Versuche von AWS Lambda, ein Ereignis an ein Ziel zu senden), die Anzahl der Drosselungen von Aufrufen (Invocation Throttle Count) und die Anzahl der abgebrochenen rekursiven Aufrufe (Recursive Invocation Dropped), ein Zeichen dafür, dass Ihre Funktion möglicherweise Teil einer rekursiven Endlosschleife ist. Das sind die grundlegenden Lambda-Metriken, mit denen Sie überprüfen können, wie Ihre Funktionen ausgeführt werden und ob sie auf Probleme jeglicher Art stoßen.
AWS-Lambda-Leistungsmetriken
AWS-Lambda-Leistungsmetriken liefern Leistungsdetails zu einem einzelnen Funktionsaufruf. Um ein Gefühl dafür zu bekommen, wie gut Ihre Funktionen funktionieren, überprüfen Sie die Duration-Metrik, die Post Runtime Extension Duration, die Ihnen die Dauer für die Verarbeitung eines Ereignisses angibt. Einige Ereignisse lösen auch die Erstellung der Lambda-Metriken Iterator Age und Offset Lag aus. Erstere ist für Funktionen, die mit Amazon-Datenbanken wie DocumentDB, DynamoDB und Kinesis verbunden sind. Sie berechnet die Zeit zwischen dem Empfang des Datensatzes durch einen Stream und dem Zeitpunkt, zu dem das Event Source Mapping das Ereignis an die Funktion sendet. Die Offset-Lag-Metrik ist stattdessen für selbst verwaltete Apache-Kafka-Event-Sources gedacht und zeichnet den Abstand zwischen dem letzten geschriebenen Datensatz und dem letzten von Ihrer Funktion verarbeiteten Ereignis auf.
AWS- Lambda-Concurrency-Metriken
Monitoring von AWS Lambda impliziert oft viele Concurrency-Funktionen und -Services. Die AWS-Lambda-Metriken in der Kategorie "Concurrency" umfassen Metriken wie nicht reservierte (Unreserved) und gleichzeitige Ausführungen (Concurrent Executions) sowie die Anzahl der Funktionsinstanzen, die Ereignisse verarbeiten (Number of Function Instances that are processing Events). Bereitgestellte gleichzeitige Ausführungen (Provisioned Concurrent Executions) und Auslastung (Utilization) informieren Sie stattdessen über die Anzahl der Funktionsinstanzen, die bereitgestellte Gleichzeitigkeit verwenden, und deren Auslastungsgrad.
Metriken für asynchrone AWS-Lambda-Aufrufe
Bei asynchronen Aufrufen gibt es nur 3 Metriken, die AWS-Lambda-Funktionen exportieren. Dabei handelt es sich um die Anzahl der empfangenen Ereignisse (Number of received Events), d. h. der Ereignisse, die erfolgreich in die Warteschlange gestellt wurden, die Anzahl der verworfenen Ereignisse (Number of dropped Events), d. h. der Ereignisse, die stattdessen verworfen wurden, und das Alter der asynchronen Ereignisse (Async Event Age), d. h. die Zeit zwischen dem Einstellen in die Warteschlange und dem erfolgreichen Aufruf der entsprechenden Funktion.
Damit haben Sie einen Überblick über alle nützlichen Monitoring-Metriken, um die Kette von Aufrufen und die Gesamtleistung Ihrer Lambda-Funktionen zu verstehen.
Bewährte Verfahren für das AWS-Lambda-Monitoring
Es schadet zwar nicht, die oben genannten Metriken zu überwachen, es ist jedoch nicht unbedingt notwendig und sogar nicht für jeden Anwendungsfall von AWS-Lambda erforderlich. Eine der wichtigsten Best Practices für das AWS-Lambda-Monitoring besteht darin, sich auf die Metriken zu konzentrieren, die für Sie bzw. Ihren Anwendungfall von Bedeutung sind. Außerdem sollten Sie vermeiden, von Daten überschwemmt zu werden, da mehr Daten es schwieriger machen, zu erkennen, was wichtig ist und was Sie ignorieren können.
Eine wichtige Praxis ist sicherlich die Überprüfung der AWS-Lambda-Logs. Diese werden an CloudWatch weitergeleitet oder lassen sich über die Lambda-Konsole, die AWS-CLI oder über die CloudWatch-API an Ihr verwendetes AWS-Lambda-Monitoring-Tool weitergeben. Dabei müssen Sie jedoch bedenken, dass AWS Lambda-Logs nicht in Echtzeit erstellt werden, sondern dass es zwischen 5 und 10 Minuten dauern kann, bis sie nach einem Funktionsaufruf angezeigt werden.
Das AWS-Lambda-Monitoring erfordert – wie bei anderen Monitoring-Arten auch – die Einrichtung eines geeigneten Alarm- oder Benachrichtigungssystems. CloudWatch-Alarme oder benutzerdefinierte Benachrichtigungen in dem von Ihnen verwendeten AWS-Lambda-Monitoring-Tool wie Checkmk sind unerlässlich, für die sofortige Information, wenn Metriken einen Schwellwert erreichen, und um zu wissen, wann Sie eingreifen müssen.
Ein nützliches Tool von Amazon zur Eindämmung der AWS-Lambda-Kosten ist Cost-Anomaly-Detection. Es ist eine bewährte Praxis der AWS-Lambda-Überwachung, ein System zur Überprüfung und Identifizierung von Kosten und Einsparmöglichkeiten. Cost-Anomaly-Detection kann helfen, aber noch besser ist Checkmk, das Ihnen einen Überblick über die Kosten pro AWS-Service oder pro Konto geben kann und Sie warnt, wenn Sie sich Ihren vordefinierten Grenzen nähern.
Das AWS-Lambda-Monitoring ist ein komplexes Unterfangen, um die Effizienz Ihrer serverlosen Funktionen zu erhalten. Die Überwachung von Hunderten oder Tausenden von Lambdas ist eine unmögliche Aufgabe, die man nur Cloud-Admins überlassen kann. Ein gutes Lambda-Monitoring-Tool mit fortschrittlichen Funktionen wie Checkmk ist unerlässlich, um maximale Beobachtbarkeit und Automatisierung in einer AWS-Cloud-Umgebung zu erreichen. Checkmk kann Admin-Teams bei der Identifizierung von Problemen, verbesserungswürdigen Bereichen und Fehlern helfen und die AWS-Kosten eindämmen.
FAQ
AWS Lambda weist die CPU-Leistung im Verhältnis zum konfigurierten Speicher zu. Standardmäßig verfügen AWS-Lambda-Funktionen über 128 MB zugewiesenen Speicher. Die maximale Speichergröße für jede Funktion beträgt 10 GB.
AWS-Lambda und Fargate sind beides serverlose Techniken zur Ausführung von Code und Anwendungen in der Amazon-Cloud. Lambda führt Code und Anwendungen aus, während Fargate spezifisch für Container ist und in die Kategorie der CaaS-Angebote (Containers as a Service) fällt. Lambda und Fargate sind also keine direkten Alternativen, aber die eine wird der anderen vorgezogen, je nachdem, ob Sie kleine Codeschnipsel oder große Anwendungen ausführen müssen, und die andere, wenn Sie Container in Ihrer Infrastruktur implementieren.