-
Notifications
You must be signed in to change notification settings - Fork 993
declarative config: add thread details resource processor #14564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
declarative config: add thread details resource processor #14564
Conversation
@trask please have a look |
|
||
public static Stream<Arguments> listProperties() { | ||
return Stream.of( | ||
Arguments.of("otel.experimental.metrics.view.config", Arrays.asList("a", "b")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this view config being removed? same quesetion for the application.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
poor choice to put the incubator in api
The incubator triggers the view config into the classpath - resulting in a file not found exception
ae673f1
to
72df93d
Compare
@trask maybe this can make it into the current release, because we already discussed it before feel free to remove if it still needs discussion |
* This class is internal and is hence not for public use. Its APIs are unstable and can change at | ||
* any time. | ||
*/ | ||
public class ThreadDetailsComponentProvider implements ComponentProvider<SpanProcessor> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still interested in thread.name
being added before span start, especially in declarative config, so it can be used by the declarative config rule-based sampler
I guess we could always have the rule-based sampler hard-code support for thread.name
since it runs on the same thread, but that feels a little hacky (is thread.name
always available in the rule-based sampler then even if the attribute isn't being stamped onto the span?)
I'm not sure how best to accomplish this though
cc @laurit
Part of #14087
Note: automatically also applies to spring starter