Skip to content

Support extensions for attributesExtractors, contextCustomizers, operationListeners and spanNameExtractor #13917

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

Open
wants to merge 23 commits into
base: main
Choose a base branch
from

Conversation

steverao
Copy link
Contributor

Resolved #12250

@Munken
Copy link

Munken commented May 30, 2025

We have a similar need (#13961).

However, in our case we do not care about the specific server instrumentation. in our case we would like to have a header getter injected.

@steverao steverao marked this pull request as ready for review June 4, 2025 14:32
@steverao steverao requested a review from a team as a code owner June 4, 2025 14:32
@steverao steverao changed the title Support extensions for attributesExtractors, contextCustomizers and operationListeners Support extensions for attributesExtractors, contextCustomizers, operationListeners and spanNameExtractor Jun 5, 2025
@steverao steverao marked this pull request as draft June 5, 2025 15:12
@steverao steverao marked this pull request as ready for review June 17, 2025 12:58
@steverao steverao force-pushed the support-custom-extention branch from 0708c7d to f11181d Compare July 8, 2025 12:44
@laurit laurit added this to the v2.19.0 milestone Jul 25, 2025
@laurit
Copy link
Contributor

laurit commented Jul 25, 2025

Open questions:

  • currently we decide whether to customize based on the instrumentation name. This may not let us distinguish between different instrumenters that are part of the same instrumentation e.g. armeria client and server. We could provide a dynamic check that could expose original span name and kind. Or we could use the span suppression keys (the ones that we get from the extractors) to expose what kind of instrumenter we are dealing with.
  • request and response are Objects that can only be used via reflection (even if you have the class you can't cast because of different class loaders).
  • more customizations, e.g. do we want to allow changing span kind?
    cc @trask

@steverao
Copy link
Contributor Author

  • currently we decide whether to customize based on the instrumentation name. This may not let us distinguish between different instrumenters that are part of the same instrumentation e.g. armeria client and server. We could provide a dynamic check that could expose original span name and kind. Or we could use the span suppression keys (the ones that we get from the extractors) to expose what kind of instrumenter we are dealing with.

I think it's necessary to support distinguishing the type of instrumenter in same instrumentation. I are willing to explore related solution later. How about supporting it in a follow-up PR and providing current abilities for users firstly? I have refactored our inner Distro recently, I might need a bit more time to get started.

  • request and response are Objects that can only be used via reflection (even if you have the class you can't cast because of different class loaders).

Sorry, I am not very clear about this point. Could you elaborate more about its background or purpose?

  • more customizations, e.g. do we want to allow changing span kind?

For this point, In fact, I haven't encouraged related requirement so far. I can file an issue to contain it and point one and set corresponding order. We could support them by order and requirement?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Cutsom OperationMetrics、AttributesExtractor、ContextCustomizer in Instrumenter
4 participants