Customizing Span Names for QuartzTelemetry when running from javaagent

[dvag-gloeckner-daniel]

Hi all,

the default QuartzSpanNameExtractor uses the Quartz job's group and job key to generate the span name. This might be quite OK for cron jobs, however, for jobs started ad-hoc this produces verbose span names which cannot be used for grouping, e.g. in metrics.

I could imagine a few ways to improve this:

• being able to configure a custom span name extractor via the javaagent's configuration so you can implement any naming strategy
• configuring an alternatice custom span name extractor via the javaagent's configuration which uses the job's class name as a span name

Please let me know if there's any interest in either of the 2 options being implemented and I can work on it.

[trask]

hi @dvag-gloeckner-daniel, it's a bit tricky to provide a custom span name extractor to the javaagent

would it work for you to use the quartz library instrumentation where you can provide a custom span name extractor, and suppressing the javaagent quartz instrumentation? (https://opentelemetry.io/docs/zero-code/java/agent/disable/#suppressing-specific-agent-instrumentation)

[dvag-gloeckner-daniel]

@trask I'll check out if this works for our scenario and how much code we'd need to maintain just to fix the span name :) Quartz might not be the most actively used framework these days but I could imagine that a number of people would benefit from improved span naming support for Quartz jobs in Otel so I'm still interested in a more integrated solution.

[trask]

@dvag-gloeckner-daniel another possible option is to use Span.current().updateName(...) from your scheduled job code to update the quartz span name

[dvag-gloeckner-daniel]

@trask I ended up writing my own, small instrumentation based on opentelemetry-instrumentation. It's great that OTel is so extensible.

What we'd need to switch back to the provided Quartz instrumentation:

• pluggable span name extractor
• pluggable error cause extractor
• pluggable attributes extractor

Plus a way to make link the Quartz job to the trace id from the context which created the job. While writing this I noticed how much customization I neded to add so it's probably much better to not depend on the standard instrumentation and have our own little instrumentation.