Docs » µAPM Instrumentation Guide » Lambda Instrumentation

Lambda Instrumentation


Before you start instrumenting your applications, review the information in Instrumentation Overview.

It is possible to trace your Go, Java, Python, and Node.js AWS Lambda functions with SignalFx. Doing so will provide you with the capability to inspect the performance and functionality of your serverless applications.

Manually instrumenting your Lambda functions is effectively like instrumenting your code in other environments: it consists of instantiating a supported tracer in your Lambda function handler, using it to create spans that measure the duration and state of your application code, and closing the tracer client before returning to ensure that spans are correctly reported. Because the Lambda execution environment is only active while your functions are executing, it’s recommended to not attempt to reuse tracer instances across invocations as background span reporting may be affected. Though this is not necessarily a best practice, it’s an effective technique to ensure all your traces are analyzed as soon as possible, instead of potentially deferring delivery to subsequent invocations. This becomes especially important with lightly exercised event triggers and frequent cold starts.

Your Lambda functions must send their trace spans to your deployed Smart Gateway for analysis and reporting to SignalFx. Depending on your network deployment, this might require that your Lambda functions execute within the same AWS VPC as your Smart Gateway. For examples of traced Lambda functions and their language-specific configuration to report to the Smart Gateway, please see our current demo functions.

Choosing a service name for your Lambda

If your application architecture includes one or more Lambda functions, you might want to visualize those as independent services on the Service Maps provided by SignalFx. To do so, set an appropriate and stable service name when configuring the tracer in your Lambda function handler.