opentelemetry-lambda VS opentelemetry-examples

I mean, sure, you can improve performance a bit by increasing the RAM/compute capacity on the Lambda. But it always adds a pretty steep overhead right now, no matter how much capacity you throw at it.

https://github.com/open-telemetry/opentelemetry-lambda/issue...

https://github.com/aws-observability/aws-otel-lambda/issues/...

OpenTelemetry AWS Lambda repository

With the sample apps from the opentelemetry-lambda repository the Lambda part itself was easy to implement. What took me some time was to provide the jaeger Fargate service with IaC ouside of an k8s environment. But with ECS and ServiceDiscovery that was easy in the end. This should be even more simple in an EKS environment with the jaegertracing helm-charts.

OpenTelemetry recently released https://github.com/open-telemetry/opentelemetry-lambda, but they also have this in the official docs https://opentelemetry.io/docs/instrumentation/js/serverless/. What do you consider to be the better option?

opentelemetry-lambda

You don’t have to create an opentelemetry configuration file such as this for each of your lambdas. In fact, you shouldn’t. In AWS, you can use Lambda Layers. You can define the OpenTelemetry tracing piece of code as a Lambda layer and use it in any Lambda you want. Furthermore, OpenTelemetry went ahead and implemented this opentelemetry-lambda layer for us. All we need to do is use it with our config.

Sorry you're having trouble working with the ADOT Lambda Layers :(. Have you had a chance to open an issue on the GitHub repo for OTel Lambda or ADOT Lambda? You should add your expected vs your actual output!

You can view the complete code on GitHub here.

You can find all gateway configurations in this gateway.yml file.

In the example code for this blog, I also added an AWS api gateway so we can trigger the Lambda using a public URL. That is out of scope for this blog, but you can visit the source code and check it out.

We will start with creating a simple to-do app that uses Mongo and the Gin framework. Then, we will send tracing data to Jaeger Tracing and to Aspecto for visualization. You can find all the relevant files in this Github repository.

Here is a link for the source code.

You can find the complete project in this GitHub repository. We created three versions for the tracing.js file (for Aspecto, Jaeger, and console) to make it easier to use.