Currently observability has been added, mainly, to the web related parts of the framework. Other portfolio projects implement observability as well (like Spring Integration, Spring Batch etc.). However there are some places in the framework like the JmsTemplate, MessagingTemplate etc. which might/could also benefit from metrics/tracing. Especially when used in combination with the web.

The same might apply/be useful for the DispatcherServlet (or the reactive variant) to include some metrics/tracing as well.

How far should the observability/metrics story go in the framework itself?

Comment From: bclozel

Hey @mdeinum

There's no general rule and we're considering this on a case by case basis.

  1. is there metrics/tracing support in similar libraries or semantic conventions in other instrumentations (like OTel) for this?
  2. Framework primarily relies on the Observation API which drives timers (but not gauges or other types); is this compatible with the data we would like?
  3. Tracing is an important part of the story; is context propagation possible there, especially for remote calls (i.e. is there a way to contribute tracing information to outgoing/from incoming messages?).
  4. We want to keep the instrumentation useful and concise, and avoid overwhelming developers with more data than necessary for observability. Typically we don't want to step into the world of profilers or debuggers.

*Template instrumentation can be all considered in my opinion. We have to tackle them one by one and make sure to get actionable feedback from real world usage as for these features, operational aspects are key. Once infrastructure is out, we must ensure that we don't break APIs, and that we don't break existing dashboards.

I'm not sure about DispatcherServlet instrumentation - what would you like to see there?

I would be in favor of creating dedicated issues for each instrumentation so that each has a place for discussing the KeyValues, observation name, convention, behavior, etc. I think we should close this issue in favor of others once this conversation has reached a good place. What do you think?

Comment From: mdeinum

Not sure if the DispatcherServlet needs any, when looking at Spring Boot there is already metrics etc. available for incoming requests for both the Servlet as well the Reactive support.

For the different messaging templates I was think something analogous to the web observability? Like messages/timing per destination. Looking at the OTel it falls between the HTTP and RPC stuff (as that seems mostly web related). Depending on the messaging in use it might be doable to support tracing through message headers, but that might be dipping into Spring Cloud messaging support as well (or this could serve as a basis for that in the long run)?

Creating dedicated issues for each instrumentation seems like a good fit, that also seems like to be how things are handled currently.

Comment From: vpavic

Are there plans to add observability for JMS in 6.1?

I'm asking because issues like https://github.com/spring-projects/spring-framework/issues/29883 and https://github.com/spring-projects/spring-framework/issues/30089 are in the 6.1.x milestone and this one is not.

Perhaps this is because there are several topics that have been brought up here, and maybe some of them should be tracked in separate issues and have this one track only observability for JMS?

Comment From: bclozel

Indeed @vpavic, we should create dedicated issues for each technology. If you've got knowledge and uses cases in the JMS space, please create a new issue.

I'm closing this issue as it's too general right now. If you're reading this issue and would like to get observability support in Spring Framework for a particular technology and you have concrete use cases to test that support - same process applies: please create a new issue.

Comment From: vpavic

I've opened #30335.