„AWS Lambda announces the Durable Execution Telemetry Exporter plugin for Lambda durable functions.“ So beginnt die Ankündigung. Trockener formuliert, als es der Inhalt verlangt. Denn was AWS hier nachliefert, ist kein weiteres Dashboard, sondern ein Flugschreiber für Code, der nicht in Millisekunden vorbeirauscht, sondern Stunden, Tage oder im Extremfall ein Jahr lang läuft. Wer durable functions bisher als bequemen Weg gesehen hat, mehrstufige Workflows ohne eigene State-Machine abzubilden, kann ihnen jetzt beim Arbeiten zusehen: Schritt für Schritt, mit Ein- und Ausgaben, Zeitpunkten und Fehlern.
Am besten lässt sich das mit einem Langstreckenflug vergleichen. Ein normaler Lambda-Aufruf ist ein Kurzstreckenflug: Start, Landung, fertig. Wenn etwas schiefgeht, reicht ein Blick auf die Startbahn. Eine durable function ist ein Flug über viele Zwischenstopps. Bisher wusste man am Ende nur, ob die Maschine angekommen ist. Jetzt führt jemand ein Logbuch, in dem jeder Zwischenstopp mit Zeitstempel, Fracht und Zwischenfall steht. Das ist die Rolle des Telemetry Exporters. Ein genauerer Blick lohnt sich: auf das, was er tut, und auf das, was er nicht tut.
Was der Telemetry Exporter mitschreibt
Der Kern klingt unspektakulär, ist aber der wichtigste Punkt: Das Plugin erfasst die Historie einer durable execution nicht als einzelnen Log-Eintrag am Ende, sondern als Abfolge ihrer Schritte. Ausgegeben werden der Ausführungsstatus, die Zeitpunkte der Operationen, die Ein- und Ausgabewerte einzelner Schritte sowie aufgetretene Fehler. Wer schon einmal versucht hat, aus kryptischen Stacktraces zu rekonstruieren, an welcher Stelle ein mehrstufiger Prozess hängen geblieben ist, kennt den Unterschied zwischen „irgendwas ist kaputt“ und „Schritt vier hat auf Schritt drei gewartet, der nach 40 Minuten in einen Timeout gelaufen ist“.
Wichtig ist die zeitliche Dimension. Durable functions können bis zu einem Jahr laufen, und die standardmäßige Aufbewahrung von Ausführungsdaten endet deutlich früher. Der Exporter löst dieses Auseinanderfallen: Wer die Historie dauerhaft braucht, weil sie betrieblich oder geschäftlich relevant ist, kann sie in eigene Speicher schreiben und dort so lange halten, wie es die eigenen Regeln verlangen. Aus einem flüchtigen Zustand wird ein Archiv, und aus einem Archiv eine Datenquelle, die sich auch Monate später noch befragen lässt.
Dass die Schritt-Ein- und -Ausgaben mit exportiert werden, ist praktisch und heikel zugleich. Praktisch, weil man Fehlerursachen bis auf den konkreten Payload zurückverfolgen kann, ohne den Code zu ändern. Heikel, weil in diesen Payloads alles Mögliche stecken kann: Kunden-IDs, Beträge, Adressen, Tokens. AWS hat dafür eine Redaktionsfunktion eingebaut, mit der sich sensible Felder vor dem Export unkenntlich machen lassen. Wer das ignoriert, baut sich eine Telemetrie-Pipeline, die personenbezogene Daten in ein Analyse-System spült, in dem sie nie landen sollten. Also lieber einmal zu früh über Feldlisten nachdenken als einmal zu spät.
Dreizehn Ziele, ein Plugin: wohin die Ausführungsdaten fließen
Der Exporter bringt 13 eingebaute Ziele mit. Genannt werden unter anderem Amazon CloudWatch Logs, Amazon S3 für die Auswertung mit Amazon Athena, Amazon DynamoDB, Amazon Aurora und Amazon OpenSearch Service. Diese Auswahl deckt die üblichen Arbeitsweisen im Cloud Monitoring ab: schnelles Reinschauen bei Logs, günstige Langzeitablage im Objektspeicher, gezielte Abfragen in einer Datenbank, Volltextsuche im Suchindex. Man muss sich also nicht zwischen Betrieb und Analyse entscheiden, sondern kann dieselben Daten an mehrere Orte schicken – mit unterschiedlicher Aufbewahrung und unterschiedlichem Zugriffsprofil.
Für die Praxis heißt das: Die Frage verschiebt sich von „Wie komme ich an die Daten?“ zu „Wer darf was damit tun?“. Sobald Ausführungsdaten in S3, DynamoDB oder OpenSearch liegen, gelten dort die üblichen Berechtigungs-, Verschlüsselungs- und Lebenszyklusregeln. Das hilft Teams mit verteilten Zuständigkeiten: der Betrieb schaut in die Logs, die Analytiker in Athena, das Security-Team in den Suchindex. Es ist aber auch eine Aufgabe, die man nicht dem Zufall überlassen sollte. Ein Export-Ziel ist eine Datensenke. Datensenken brauchen jemanden, der sie pflegt.
Ergänzt wird das durch eine Sampling-Rate, mit der sich die Menge der exportierten Ereignisse steuern lässt. Der Regler entscheidet, ob die Telemetrie aussagekräftig oder unbezahlbar teuer wird. Bei einem Workflow, der millionenfach am Tag läuft, will man nicht jede erfolgreiche Ausführung vollständig archivieren. Bei einem kritischen Prozess, der zwanzig Mal am Tag startet, will man jede einzelne Spur. Sampling erlaubt diese Differenzierung, ohne dass man zwei verschiedene Instrumentierungen pflegen muss.
Ein MCP-Server als Dolmetscher zwischen Telemetrie und Alltag
Interessanter ist der zweite Teil der Ankündigung, weil er über klassische Observability hinausgeht: AWS liefert einen begleitenden Model-Context-Protocol-Server mit, über den KI-Agenten wie Kiro die exportierten Telemetriedaten in natürlicher Sprache abfragen können. Das verschiebt den Zugang zu Ausführungsinsights von der Abfragesprache zum Gespräch. Statt eine Query zu schreiben, beschreibt man das Problem, und der Agent übersetzt es in einen Zugriff auf die Daten.
AWS nennt zwei konkrete Beispiele. Ein Bereitschaftsingenieur kann einen Agenten bitten, die letzten fehlgeschlagenen Ausführungen aufzulisten und die Ursache eines Fehlers zu finden. Eine Business-Analystin kann alle Transaktionen eines bestimmten Kunden heraussuchen lassen. Das erste Beispiel ist klassischer Betrieb, das zweite eher Business-Intelligence. In dieser Doppelung liegt der Reiz. Dieselbe Telemetrie dient der Fehlersuche und der Geschäftsauswertung, weil sie nicht nur „ist durchgelaufen“ protokolliert, sondern den inhaltlichen Verlauf.
Man sollte den MCP-Server trotzdem nicht als Freifahrtschein verstehen. Ein Agent, der auf produktive Telemetrie zugreift, braucht klare Grenzen: welche Daten er sehen darf, welche Fragen er beantworten soll und was passiert, wenn er sich irrt. Die Redaktion sensibler Felder ist hier keine Frage der Hygiene mehr, sondern der Sicherheit, denn ein Modell im Gespräch gibt Antworten in Prosa aus – und Prosa lässt sich schlechter nachträglich schwärzen als ein Log-Eintrag. Wer den Server einsetzt, sollte die Berechtigungen so zuschneiden, dass auch ein neugieriger Agent nicht mehr sieht als nötig.
Wie du den Exporter in Betrieb nimmst
Der Einstieg ist schmal gehalten und in drei Schritte zerlegt: den Exporter installieren, das Plugin im Handler der Funktion registrieren, den MCP-Server beim eigenen Agenten hinzufügen. Unterstützt werden TypeScript, Python, Java und Go, also die Sprachen, in denen durable functions ohnehin zu Hause sind. Das Plugin sitzt im Handler, nicht irgendwo daneben – es ist Teil der Funktion und kein separater Dienst, den man zusätzlich betreiben müsste. Für bestehende Workflows bedeutet das in der Regel eine überschaubare Änderung statt eines Umbaus.
Bevor du losschaltest, lohnt sich eine kurze Bestandsaufnahme. Welche Ziele brauchst du – reicht für den Anfang CloudWatch Logs, oder soll gleich ein Analysespeicher mitlaufen? Welche Felder müssen vor dem Export unkenntlich gemacht werden? Mit welcher Sampling-Rate startest du, und woran erkennst du, dass sie zu grob oder zu fein ist? Diese vier Fragen beantworten sich nicht von selbst, aber sie sind billiger zu klären, bevor der erste Datenstrom läuft, als danach. Ein Flugschreiber, der alles aufzeichnet, nützt wenig, wenn niemand die Aufzeichnung lesen darf oder kann.
Was das für serverless Computing und Cloud Monitoring bedeutet
Lange galt serverless computing als Ort, an dem Beobachtbarkeit notgedrungen oberflächlich bleibt: Man sieht die Invocation, ihre Dauer, ihren Fehlerstatus, und alles dazwischen ist Vermutung. Durable functions haben diese Annahme bereits widerlegt, weil sie Zustand über lange Zeiträume halten und mehr zu beobachten geben als ein einzelner Aufruf. Der Telemetry Exporter schließt die Lücke zwischen „der Workflow hat funktioniert“ und „der Workflow hat funktioniert, weil Schritt fünf korrekt auf das Ergebnis von Schritt vier gewartet hat“. Das ist mehr als eine kleine Verbesserung.
Für Cloud Monitoring bedeutet das: Ausführungsdaten dienen nicht mehr nur der Fehlersuche. Wenn Schritt-Ein- und -Ausgaben dauerhaft in einem abfragbaren Format vorliegen, werden Workflows selbst zur auswertbaren Quelle für Fragen, die sich vorher nicht beantworten ließen. Wie lange dauert ein bestimmter Geschäftsprozess im Schnitt, und wo verliert er Zeit? Welche Schritte scheitern gehäuft, ohne dass die gesamte Ausführung fehlschlägt? Solche Fragen sind mit aggregierten Metriken kaum zu beantworten, mit einer Schritt-Historie schon.
Die Preisfrage ist schnell beantwortet: Der Exporter ist ohne Zusatzgebühr in allen Regionen verfügbar, in denen durable functions unterstützt werden. Die Kosten entstehen also nicht am Plugin, sondern an den Zielen, an die du exportierst – Speicher, Abfragen, Index. Der Kostenhebel liegt damit dort, wo die Entscheidung fällt, und nicht in einer pauschalen Observability-Pauschale. Es bedeutet aber auch: Die Sampling-Rate ist dein wichtigster Kostenschalter.
Unterm Strich
Unterm Strich bekommt man kein Superlativ-Feature, sondern eine solide Antwort auf eine Frage, die sich früher oder später jeder stellt, der mehrstufige Workflows betreibt: Wie erfahre ich, was zwischen Start und Ende tatsächlich passiert ist? Die Antwort ist ein Plugin, das den Verlauf mitschreibt, wahlweise an 13 Orte schickt, sich filtern und redigieren lässt und über einen MCP-Server auch für sprachbasierte Abfragen öffnet. Solide Arbeit statt Spektakel – und deshalb brauchbar.
Die Arbeit beginnt nach der Installation. Wer die Redaktion sensibler Felder überspringt, die Sampling-Rate nie anfasst und die exportierten Daten in einen Speicher kippt, den niemand abfragt, hat eine teure Rumpelkammer gebaut. Wer dagegen vorher festlegt, welche Fragen die Telemetrie beantworten soll, wer sie lesen darf und wie lange sie bleibt, bekommt etwas, das im Betrieb trägt: eine nachvollziehbare Spur durch Prozesse, die zu lang sind, um sie im Kopf zu behalten. Der Flugschreiber ist eingebaut. Lesen muss ihn noch jemand.
Quelle: aws.amazon.com
