declarative config: add thread details resource processor#14564
declarative config: add thread details resource processor#14564zeitlinger wants to merge 5 commits intoopen-telemetry:mainfrom
Conversation
github-actions
Bot
added
the
test native
zeitlinger
changed the title
|
@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.
why is this view config being removed? same quesetion for the application.yml
There was a problem hiding this comment.
poor choice to put the incubator in api
The incubator triggers the view config into the classpath - resulting in a file not found exception
zeitlinger
force-pushed
the
declarative-config-thread-details-provider
branch
from
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.
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
There was a problem hiding this comment.
The way I see it we have 2 options. Either let rule based sampler compute thread.name itself or add the thread.name in instrumentation api.
|
@trask as discussed I tried adding the logic to add thread attributes directly in
|
I'll try using the IncubatingUtil pattern from the SDK |
turns out we already use incubating, e.g. |
|
Closed in favor of #15209 |
4 participants
Part of #14087
Note: automatically also applies to spring starter