Any plan to auto instrument db-scheduler?

[aoshenInDD]

Hi, all, we are using db-scheduler: https://github.com/kagkarlsson/db-scheduler, and it looks like it has not been instrumented with Opentelemetry yet. Are we having any plan to auto-instrument with Opentelemetry? If we do it, how hard will it be? Thanks

[aoshenInDD]

@trask Could you take a look at this thread? thanks

[trask]

hi @aoshenInDD, I'm not aware of any plans

[aoshenInDD]

@trask if I am about to instrument on my own for db-scheduler, how hard will it be? Because the scenario is like this, we are having an application reading from kafka queue which is having trace_id and span_id, by end of processing, we schedule a task in db-scheduler, but since db-scheduler is not auto instrumented, so we are not able to trace it anymore.

Based on this scenario, what should we do?

1. should we fork the java-opentelemetry-agent and add support for db-scheduler? how hard will it be?
2. Or we are using manual instrumentation to fill the gap?

Which one is more doable? Thanks

[trask]

Using manual instrumentation to fill the gap is typically the easiest. After that, if you have a nice working solution, you could extract it and contribute it as "library" instrumentation. Bytecode / java agent instrumentation is typically the hardest.

[aoshenInDD]

@trask For manual translation, is it guaranteed to succeed for db-scheduler? Because in my company, the observability team recommended a try(they are also not sure) but I am not sure it will succeed for sure if using manual instrumentation. Because for context propagation, it uses http based (https://opentelemetry.io/docs/instrumentation/java/manual/#context-propagation), but in my application, it is kafka and db based, so I am not sure using manual context propagation will succeed for sure. May I have your opinion? Thanks

[frederikb]

Hi @aoshenInDD, did you ever proceed with manual instrumentation of db-scheduler? I don't think the situation has changed since then, has it?