Integrate provided OpenTelemetry instrumentations if possible

[Henning-Schulz]

OpenTelemetry comes with instrumentations of multiple libraries and frameworks, which we could integrate into the Ocelot agent. This would mean we could rely on externally maintained code. However, it needs to be evaluated to which extend it can be integrated with our configuration-based instrumentation approach.

[Alexander-Krause-Glau]

As user of ocelot, I am very interested in the continuation of this project and the (announced) support for OpenTelemetry. However, OpenTelemetry's automatic instrumentation focus lies on

captur[ing] telemetry data at the “edges” of an app (https://opentelemetry.io/docs/instrumentation/java/automatic/)

This issue is now two months old. Can you further elaborate on your decisions regarding the Otel support? Do you want to use Otel's SDK in your instrumentation approach, therefore enable complete application tracing as shown by the current ocelot (OpenCensus) version?

[Henning-Schulz]

Hi @Alexander-Krause-Glau,

We are working on a migration from OpenCensus to OpenTelemetry. The next release will already "talk" OTel to the outside (see #1294). Later, we will completely rely on OTel without any OC dependencies.

Is there any specific reason why you are interested in the OTel support, e.g., is there anything you cannot do with the current, OC-based agent?

[Alexander-Krause-Glau]

Hi @Henning-Schulz,

The next release will already "talk" OTel to the outside (see https://github.com/inspectIT/inspectit-ocelot/issues/1294).

That's great to hear, I hope to update my software stack to Otel.

Is there any specific reason why you are interested in the OTel support, e.g., is there anything you cannot do with the current, OC-based agent?

No. However, I favor the new specification due to its ongoing support and community.

---

I've tried to employ the Otel agent (automatic instrumentation via bytecode injection) for a plain Java application that uses nothing but default JDK functionalitites, i.e., no external dependency. The Otel agent was not able to monitor (or even instrument I guess) any method calls. That fits the description of Otel.

Ocelot on the other hand builds upon OpenCensus and adds the missing functionality to record traces at complete application level, not only on the edge. Is this something we can still expect from the Otel-updated Ocelot version? Will Ocelot keep its current functionality?

[Henning-Schulz]

Hi @Alexander-Krause-Glau,

I favor the new specification due to its ongoing support and community.

So do we. That's why we are putting all that effort into the migration.

Will Ocelot keep its current functionality?

Yes, it will. The functionality will be exactly the same, with the only difference that Ocelot uses OTel under the hood instead of OpenCensus. For instance, you will still be able to configure your custom method instrumentation. As a user, you almost won't notice the difference, except for some exporter configuration.