AWS has released the AWS Lambda Telemetry API, a new way for extensions to receive enhanced function telemetry from the Lambda service. The new API simplifies collecting traces, logs, and custom and enhanced metrics from Lambda functions. Along with several example extensions, there are several extensions available from third parties including Datadog, Dynatrace, Serverless, and Sumo Logic.
The new API allows extensions to subscribe to platform telemetry, function logs, and extension logs. Platform telemetry includes logs, metrics, and traces that describe events and errors related to the lambda environment runtime lifecycle, the extension lifecycle, and the function invocation. Function logs are custom logs generated by the Lambda function code and extensions logs are similar but generated by the Lambda extension.
The API schema is semantically compatible with OpenTelemetry (OTel). Events from the Telemetry API can be used to build and report OTel spans. AWS notes that single Event objects should not be mapped to a single OTel span. For example, the Telemetry API events start, runtimeDone, and runtimeReport represent a single function invocation and should be represented as a single OTel span.
With the release of the new API, a number of AWS partners have released extensions. Datadog has released a Lambda extension that simplifies measuring cold start spans and provides additional enhanced metrics into the Datadog console. Serverless released Serverless Console V.2 which makes use of the new Telemetry API to collect initialization, invocation, and post-processing times for Lambda function calls. The new data allows the Serverless Console to present a new user experience metric that illustrates how long it takes for the AWS Lambda function to return a response.
It is also possible to create custom extensions and there are several examples to help guide development. There are examples in Python, Go, Node.js, Java, C#, and Rust. The examples cover a number of use cases including adaptive batching and a crash uploader.
Lambda extensions run as an independent process in the execution environment and will continue to run after the function invocation is complete. As extensions run as a different process than the function code, it is possible to write them in a different language from the function code. Julian Wood, senior developer advocate with AWS, recommends "implementing extensions using a compiled language as a self-contained binary. This makes the extension compatible with all the supported runtimes."
Extensions leveraging the Telemetry API follow this lifecycle:
To start, the extension registers via the Lambda Extension API and subscribes to receive the INVOKE and SHUTDOWN events. The extension starts a telemetry listener either via TCP or HTTP, with HTTP being the recommended choice. Once started, the extension uses the Telemetry API to subscribe to the desired event streams. Finally, the Lambda service will POST telemetry stream data to the listener.
Extensions using the Telemetry API share the same pricing model as Lambda functions meaning that costs are incurred for requests served as well as the compute time used to run the extension. The AWS Lambda Telemetry API supersedes the existing AWS Lambda Logs API. While the Logs API can still be used, it is recommended to switch to using the new Telemetry API. More information about the new API is available from the AWS blog.
