SignalFx accepts spans from instrumented code via HTTP, so it's possible to use properly configured
Jaeger tracers and the OpenTracing APIs for Go, JavaScript, Python, and Java to trace AWS Lambda Functions.
This directory provides demonstration implementations of a simple, instrumented Roulette app that operates
under the RequestResponse invocation type for the following runtimes:
Each example in this section assumes the deployed Lambda function will be for synchronous handling of client requests to an API Gateway endpoint.
[Client Application]
| ↑
REST API
↓ |
[API Gateway Resource]
| ↑
Trigger Respond
↓ |
[Your Lambda Function] — Spans via HTTP POST → [SignalFx Gateway]
If you are using asynchronous or non-RequestResponse invocation types, the examples can still serve
as a template for tracer instantiation and usage for reporting your traces to SignalFx within the
Lambda execution context. However, the trigger event
will need to be updated to reflect your application's functionality.
Each example provides a description of generating and configuring a Deployment Package for its respective
runtime. All of these examples presume the setting of the SIGNALFX_INGEST_URL environment variable to
forward your traces to your deployed SignalFx Gateway or SIGNALFX_ACCESS_TOKEN for direct association
with your organization. Please note that bypassing the SignalFx Gateway is for demonstration purposes
only, and is not a supported deployment pattern. The Gateway enables many powerful analytical features for
μAPM. If neither the variables are set for your Lambda function via the AWS Console or CLI, all invocations
will generate an internal server error that will be logged to CloudWatch.
$ update-function-configuration \
--function-name <MyTracedFunction> \
--environment Variables={SIGNALFX_INGEST_URL=<MyGateway>}