Skip to content
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

Configure a custom JmsProcessObservationConvention or JmsPublishObservationConvention #5492

Open
mihca opened this issue Sep 27, 2024 · 8 comments
Labels
enhancement A general enhancement help wanted An issue that a contributor can help us with instrumentation An issue that is related to instrumenting a component module: micrometer-jakarta9
Milestone

Comments

@mihca
Copy link

mihca commented Sep 27, 2024

Please describe the feature request.
It should be possible to configure a custom JmsProcessObservationConvention. Currently a DefaultJmsProcessObservationConvention ist hardcoded in the MessageConsumerInvocationHandler.

Rationale
I want to write custom information from the JMS header to the observation (trace info).

Additional context
Its possible to define your own JmsProcessObservationConvention, but I found no possibilty to activate/configure it instead of the DefaultJmsProcessObservationConvention.

@shakuzen shakuzen added enhancement A general enhancement instrumentation An issue that is related to instrumenting a component module: micrometer-jakarta9 and removed waiting-for-triage labels Sep 30, 2024
@shakuzen shakuzen added this to the 1.x milestone Sep 30, 2024
@shakuzen shakuzen added the help wanted An issue that a contributor can help us with label Sep 30, 2024
@shakuzen
Copy link
Member

Thank you for opening the issue. I agree it would be better to allow passing a custom convention when configuring the instrumentation. In the meantime, perhaps you could use a GlobalObservationConvention to achieve what you want until the instrumentation is updated - see this part of the documentation.

Would you be interested in submitting a pull request for this enhancement?

@mihca
Copy link
Author

mihca commented Oct 2, 2024

With a GlobalObservationConvention I was able to get it to work, thanks!

PR: I have no idea how to make it configurable in context of micrometer. Any hints?

@shakuzen
Copy link
Member

shakuzen commented Oct 4, 2024

PR: I have no idea how to make it configurable in context of micrometer. Any hints?

The way to use the instrumentation now is via JmsInstrumentation. I think adding another static method that takes custom conventions would be one way of making it configurable to users. Maybe @bclozel has other ideas.

@bclozel
Copy link
Contributor

bclozel commented Oct 4, 2024

Initially, I did not provide a way to customize the observation convention directly on JmsInstrumentation as in my experience, this instrumentation can happen quite deep into libraries and frameworks (it is the case in Spring) so it's not easy to provide an obvious hook point for that.

I guess you're instrumenting JMS sessions manually and not through a library or framework? In this case, another static method as suggested by @shakuzen would work well.

@mihca
Copy link
Author

mihca commented Oct 8, 2024

We are using Spring Boot, which uses the Spring Framework, which uses Micrometer. You have to understand all three libs...

@bclozel
Copy link
Contributor

bclozel commented Oct 8, 2024

Thanks for your feedback @mihca - this is the main feature behind global observation conventions: you don't need to know where things are instrumented and how, you just need to know which convention to use and override globally.

Admittedly, the JMS processing observability section of the Spring Framework reference documentation is a bit light as it doesn't mention the relevant convention, unlike other instrumentations.

Back to your use case, I believe a global convention is probably the easiest path. We could allow custom conventions here in Micrometer, but we would also need another API in Spring Framework and even maybe something else in Spring Boot. In the end, you would probably provide your custom convention as a bean, which is exactly the same thing as a global one.

Here's my proposal:

Let me know what you think @mihca !

@shakuzen
Copy link
Member

shakuzen commented Oct 9, 2024

I'm not sure there is a dedicated section for this in the Micrometer docs @shakuzen ?

The closest we have is the section I linked earlier which has sample code and JavaDoc comments in it describing the precedence of conventions and gives an example of a GlobalObservationConvention.

@mihca
Copy link
Author

mihca commented Oct 9, 2024

Back to your use case, I believe a global convention is probably the easiest path. We could allow custom conventions here in Micrometer, but we would also need another API in Spring Framework and even maybe something else in Spring Boot. In the end, you would probably provide your custom convention as a bean, which is exactly the same thing as a global one.

I expected that it works like org.springframework.http.server.observation.DefaultServerRequestObservationConvention, which is documented in Spring Framework Observability Support#Using custom observation conventions. Just provide the bean and its insrtumented automatically. But that class is defined in Spring Framework and not Micrometer.

I can improve this section of the Framework docs and review others to always mention the convention and context classes
I can add another section under "configuring observations" to explain how to use global conventions. Or maybe the Spring Boot docs would be a better fit? I'm not sure there is a dedicated section for this in the Micrometer docs @shakuzen ?

Yes, would be nice that there is a hint in the Spring Framework Documentation#JMS message instrumentation to use a global convention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A general enhancement help wanted An issue that a contributor can help us with instrumentation An issue that is related to instrumenting a component module: micrometer-jakarta9
Projects
None yet
Development

No branches or pull requests

3 participants