opentelemetry-lambda VS opentelemetry-js-contrib

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!

... //https://www.honeycomb.io/blog/opentelemetry-browser-instrumentation //https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/opentelemetry-instrumentation-xml-http-request //https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/web/opentelemetry-instrumentation-user-interaction //https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/web/opentelemetry-instrumentation-long-task //https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/web/opentelemetry-instrumentation-long-task export default async () => { const otlpOptions = { omitted }; const attributes = { omitted } provider.addSpanProcessor(new SimpleSpanProcessor(new OTLPTraceExporter(otlpOptions))); provider.register({contextManager: new StackContextManager()}); registerInstrumentations({ instrumentations: [ getWebAutoInstrumentations({ '@opentelemetry/instrumentation-xml-http-request': { clearTimingResources: true, } }), new LongTaskInstrumentation({ observerCallback: (span, longtaskEvent) => { span.setAttribute('location.pathname', window.location.pathname) } }), new FetchInstrumentation({ propagateTraceHeaderCorsUrls: [new RegExp('\\/api\\/*')], ignoreUrls: [new RegExp('\\/tile\\/*')], })], }); ... };

To enable only @opentelemetry/instrumentation-http and @opentelemetry/instrumentation-express you can run this command below.

On the noisy NodeJS auto-instrumentation, it is indeed very noisy out of the box. Myself along with a bunch of other ppl finally got the project to allow you to select the instrumentations via configuration. Saves having to create your own tracer.ts/js file.

Here's the PR that got merged earlier in the year: https://github.com/open-telemetry/opentelemetry-js-contrib/p...

The env var config is `OTEL_NODE_ENABLED_INSTRUMENTATIONS`

Anyways, love Opentelemetry success stories. Been working hard on it at my current company and yielding fruits already :)

[2] https://github.com/open-telemetry/opentelemetry-js-contrib/t...

@opentelemetry/instrumentation-aws-lambda

As suggested in both opentelemetry-js-contrib and aws-otel-lambda issues, the solution is changing ES6 export to CommonJS module.exports.

More information about this can be found here and in the instrumentation docs.