opentelemetry-lambda VS sqs-consumer

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 could utilize a wrapper like sqs-consumer. Check out their implementation.

To receive the messages from the queue, we will use the sqs-consumer library. The service will receive messages describing newly created orders. After some processing, it will change the order status in the table to ‘completed’.

As we built out this new system, we looked at the current module ecosystem to determine if anything would fit our needs to keep this queue cleared. Unfortunately, the best module we could find, sqs-consumer, did not support FIFO queues and the issues indicated they did not have any intention to do so. Therefore, we wrote sqsiphon. Our library heavily borrows from the public interface of sqs-consumer, but is implemented in a much different way. In particular, sqsiphon leverages the Node.js event loop through setImmediate to build the polling mechanism instead of relying on SQS's "long polling" feature. Additionally, sqsiphon utilizes the JavaScript prototype to reduce reliance on expensive closures. As a bonus, OpenTracing support is built-in to sqsiphon so that applications built with it can be monitored effectively. The result is a library that can poll SQS extremely quickly while requiring very little overhead.