consider adding a bean name tag to async spans

[codefromthecrypt]

When eventually coming up with #1464, we found it very hard to figure out which executor was causing "async" spans. Since the controls are based on bean name, it seems a decent idea to have a bean name tag. Ex spring.bean=fooExecutor

[marcingrzejszczak]

That can be problematic cause the async span comes from a TraceRunnable or TraceCallable. Those are not beans really. I would have to extend the constructors to pass the creating object's name. However passing the bean name is also not easy. What I could do though is pass the class name of the object creating the runnable / callable. WDYT?

[codefromthecrypt]

I tried to look up what the original context was.. I think it was about the name of the executor bean, that being something helpful to pinpoint what's going on when there is no other info. this continued more recently here spring-attic/spring-cloud-gcp#2158

[marcingrzejszczak]

Getting the bean name can be tricky, doing the class name would be trivial

[marcingrzejszczak]

Ok, so one way of solving this is explicitly creating executor services with a provided name. Example below:

	@Bean
	ExecutorService billingExecutor(BeanFactory beanFactory) {
		return new TraceableExecutorService(beanFactory, Executors.newFixedThreadPool(10), "Billing");
	}

	@Bean
	ExecutorService pointsExecutor(BeanFactory beanFactory) {
		return new TraceableExecutorService(beanFactory, Executors.newFixedThreadPool(10), "Points");
	}

	@Bean
	ExecutorService playerExecutor(BeanFactory beanFactory) {
		return new TraceableExecutorService(beanFactory, Executors.newFixedThreadPool(10), "Player");
	}

	@Bean
	ExecutorService inventoryExecutor(BeanFactory beanFactory) {
		return new TraceableExecutorService(beanFactory, Executors.newFixedThreadPool(10), "Inventory");
	}

another option is that e.g. someone uses a AsyncTaskExecutor implementation, e.g. MyAsyncTaskExecutor, I can by default not call the span async but my-async-task-executor.

WDYT @adriancole @saturnism ?

[saturnism]

/cc @meltsufin @elefeint as well

iirc, for spring cloud gcp, the issue was more on hiding some executor pools from being instrumented/traced.

w/ TraceableExecutorService, is the idea that onlyTraceableExecutorService will be instrumented? and a regular executor no longer get instrumented automatically? (i do like this primarily because it's easily/explicit to differentiate which ones will have trace applied automatically).

[marcingrzejszczak]

All of the executor services still would be instrumented unless you set spring.sleuth.scheduled.enabled=false (the property is wrong - we'll fix it). If a service is already a Traceable... one then it won't get instrumented again.

The idea is such that if you explicitly create executor services, then you can provide proper names for the spans.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.