Switching to OpenTelemetry from built-in metrics and tracing?

[icebob]

As I see the trends in tracing and metrics topics, I see the OpenTelemetry is becoming the de-facto industry standard for tracing and metrics. OpenTelemetry has mostly all features that have the Moleculer built-in tracing & metrics modules, additionally, it has prebuilt instrumentation modules for many common libraries and is supported by many cloud APM services.

The biggest disadvantage of the built-in tracing is that it's hard to connect the Moleculer spans to other external lib spans. OpenTelemetry can solve it if you use it everywhere in your project.

Since both have the same functionality, it's not worth developing the built-in tracing & metrics modules while there is an out-of-box solution with a bigger time & budget capacity background.
While it would be a breaking change, we can switch it only in the next major version.

What do you think about it? Give a 👍 if you support the switching and give 👎 if not and we should keep and maintain the Moleculer built-in modules or share your thoughts in a comment.

Thanks!

[shawnmcknight]

@kthompson23 tagging you on this as I think you'd probably have some opinions here.

[intech]

This contribution will provide more benefits in the long term than problems now due to breaking changes.
So I fully support this development. 👍

[icebob]

Thanks.

[ccampanale]

I personally support the decision to switch to and adopt OpenTelemetry. I think the writing is on the wall with this one. The "standard" seems to be increasingly adopted widely in the industry which I believe will continue. Adopting would likely better position the framework and limit the amount of custom metrics and tracing development necessity moving forward.

I implemented the AWS X-ray SDK in a custom tracing exporter for the system my team maintains and while it wasn't too complicated, there is a lot of room for improvement. That said, I've placed continued efforts on the back-burner due to possibilities of incorporating OpenTelemetry. I would imagine that incorporating OpenTelemetry would mean easily switching between different providers which would be ideal for teams like mine.

I think it's the right move. 👍🏻

[icebob]

Thanks.

[adam-mccormick]

I'm all for this. There's ongoing interest in OpenTelemerty at work and it would be great to see this supported by Moleculer.

[intech]

@1xtr Tracing is a graph of spans. The more spans, the greater the performance degradation. Therefore, any part of the code that you want to cover the trace will need to be wrapped. If you want to wrap all methods, you can use the hook localMethod in middleware.

[intech]

@1xtr https://gist.github.com/intech/503facbc5320056d8f327070557fdf31

[Aaron-Ritter]

Definitely an upvote from me on OpenTelemetry. But key input for me is first get the most up to date out of the box instrumentation for NodeJS and related frameworks used, and only then try to customize what ever is missing.

OpenTelemetry has a massive backing from the community as well as all the major APM and Cloud vendors on the market.

[kthompson23]

This may be out of scope for the first pass and is separate from the OpenTelemetry tracing specification but the OpenTelemetry collector supports gRPC out of the box. With smaller payloads and compression options it could be a real performance benefit.

[lucduong]

I'm looking forward OTel features. 👍 💯

[lucduong]

Do we have any update here?

[icebob]

It won't be implemented in 0.15 yet, instead, I will add an OpenTelemetry-based middleware and you can change the built-in tracing middleware to this OTEL-based one.

[lucduong]

It won't be implemented in 0.15 yet, instead, I will add an OpenTelemetry-based middleware and you can change the built-in tracing middleware to this OTEL-based one.

Don't you mind to share that middleware once you completed?

[icebob]

It is in the next branch: https://github.com/moleculerjs/moleculer/tree/next/examples/opentelemetry

[goggi]

Hi @icebob, any example on how to integrate the channels to the opentelemetry middleware?