Lambda Telemetry API Provides Enhanced Observability

Published on Nov 23, 2022

AWS has announced the AWS Lambda Telemetry API, a new way for extensions to receive enhanced function telemetry from the Lambda service. The new API simplifies the process of collecting traces, logs, and custom and enhanced metrics from Lambda functions. In addition to the examples provided, there are a number of extensions available from third parties, including Datadog, Dynatrace, Serverless, and SumoLogic.

With the new API, extensions can subscribe to platform telemetry, function logs, and extension logs. It includes logs, metrics, and traces that describe events and errors associated with the lambda environment runtime lifecycle, the extension lifecycle, and the function invocation. Lambda function logs are custom logs generated by the Lambda function code, while Lambda extension logs are similar, but are generated by Lambda extensions.

There is semantic compatibility between the API schema and OpenTelemetry (OTel). The Telemetry API can be used to build and report OTel spans based on events. According to AWS, single Event objects should not be mapped to a single OTel span. As an example, the Telemetry API events start, runtimeDone, and runtimeReport represent a single function invocation and should be represented as a single OTel span.

As a result of the release of the new API, a number of AWS partners have released extensions. A new Lambda extension from Datadog simplifies the measurement of cold start spans and provides enhanced metrics within the Datadog console. With Serverless Console V.2, you can collect initialization, invocation, and post-processing times for Lambda function calls by utilizing the new Telemetry API. As a result of the new data, the Serverless Console can now display a new user experience metric that illustrates how long it takes for an AWS Lambda function to respond.

It is also possible to create custom extensions, and there are several examples to assist in the development process. Examples are provided in Python, Go, Node.js, Java, C#, and Rust. There are a number of use cases covered in the examples, including adaptive batching and a crash uploader.

As an independent process within the execution environment, lambda extensions continue to run after the function invocation has been completed. As extensions run as a separate process from function code, they can be written in a different language. AWS Senior Developer Advocate Julian Wood recommends implementing extensions as self-contained binary files, which can be used by a variety of runtimes. This will ensure compatibility between extensions across all runtimes, he explains.

The extension registers via the Lambda Extension API and subscribes to receive INVOKE and SHUTDOWN events. It is recommended that the extension starts a telemetry listener via HTTP rather than TCP. The extension uses the Telemetry API to subscribe to the desired event streams once it has been started. Last but not least, the Lambda service will POST data from the telemetry stream to the listener.

Using the Telemetry API, extensions are charged in the same manner as Lambda functions, which means that both requests and compute time are incurred. The AWS Lambda Telemetry API has replaced the AWS Lambda Logs API. While the Logs API can still be used, it is recommended that you switch to using the Telemetry API instead.