Instrumentation extension service

[BFergerson]

I was looking to see what the easiest way to add stack traces to exit spans was and stumbled upon the extension system offered in OpenTelemetry. I'm curious if this is a feature SkyWalking would consider adding. I know my use case is unique, so here is another that may be more universal.

In the manual instrumentation documentation, the following example is given:

@Trace
@Tag(key = "tag1", value = "arg[0]")
@Tag(key = "tag2", value = "arg[1]")
@Tag(key = "username", value = "returnedObj.username")
@Tag(key = "age", value = "returnedObj.age")
public User methodYouWantToTrace(String param1, String param2) {
    // ActiveSpan.setOperationName("Customize your own operation name, if this is an entry span, this would be an endpoint name");
    // ...
}

I like the idea of adding the username and age to methodYouWantToTrace, but what if I wanted to add those tags to any EntrySpan starting with the URI /settings/profile/* so that they are automatically inserted whenever users make changes to their profile?

In my last discussion in which I brought up the possibility of creating a gauge for usernames, that was determined to be business monitoring. Does this also fall under that umbrella? If it does, would SkyWalking consider supporting it? If not, is there an alternative?

[wu-sheng]

This use case seems closely to APM case. I want to hear your suppose first.
What is your suggested way to identify this when profiling?

[wu-sheng]

This seems a very expensive way. I am wondering what could we do in a general interceptor?

I imagine SkyWalking scans the classpath for @InstrumentationExtension

By the way, this may not work. The user's classpath may not be a good place for an interceptor-level calling, due to classpath isolation.
Something like this has to be a thing similar with today's plugin codes, from tech perspective.

[BFergerson]

I think the idea of a general interceptor works if it can be done inside user code as opposed to creating a new plugin and adding it to /plugins. SkyWalking plugin system is powerful but a bit difficult to get started with. If someone wants to add instrumentation for a library that SW doesn't support they have to create a new plugin, use apm-customize-enhance-plugin, or rebuild the library with @Trace and other code to the library.

This is probably my view but I would like to see SW be more programmable (i.e. observability-as-code). I would like to simply create a new class, add some annotations, and deploy my code and it's like I've added a new plugin. Maybe that's too much to ask though. I'm not sure what the limitations are.

As for the classpath issue. If SW can find @Trace, why couldn't it find a @InstrumentationExtension?

If that's not possible, could SW offer something like:

SkyWalkingAgent.addUserPlugin(ProfileAttrInjector.class);

[wu-sheng]

There is no block to finding this class, the challenge is running that class. Class definition is scoped inside the classloader, you can't initial a class inside a classloader(a), but running in another classloader(b), unless classloader(b) is a child of classloader(a).

[BFergerson]

That makes sense. I have a closer look at how OpenTelemetry extensions work and let you know if I come up with a better idea.

[wu-sheng]

This mechanism would be easy to work on Spring boot or other single Classloader env. But would be tricky if you work in Tomcat or similar mechanism.