opentelemetry-ext-js VS opentelemetry-js-contrib

AWS has good tools for tracing, but in this example, I will use another remote and distributed tracing platform – Aspecto.

For this article, I will be using Aspecto to visualize my traces. You can follow along by quickly creating a free account.

If we drill down into one of these traces, we can see in more detail how long each request took and clear visualization of the entire workflow.

For the purposes of this guide, I chose to use Aspecto as my visualization tool. This is because Aspecto provides built-in support for visualizing messaging systems like Kafka (and, of course, any other part of our microservice architectures).

To follow along, you can open a new free-forever Aspecto account or log in to your existing one.

That’s about it for this OpenTelemetry Java guide, folks. If you have any questions or issues with any of these steps, feel free to reach out to us via chat or join our OpenTelemetry Slack channel (part of the CNCF Slack).

At Aspecto, you can sign up for free and use our generous free-forever plan (no limited features).

Aspecto has a free-forever tier and provides everything included in Jaeger and more. Sort of like Jaeger on steroids.

However, you can take your tracing visualization to the next level with Aspecto. Try it yourself with the free-forever plan that has no limited features.

Hi all, we wanted to share some love back to the Kafka community. We hope you'd find this instrumentation helpful, check it out on GitHub 🌟and npm

... //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.