This is a placeholder issue to group smaller tasks together to provide better Observability support for Spring Boot users.

Info enhancements

  • [x] Add details about the JVM, e.g.: name, vendor, version: https://github.com/spring-projects/spring-boot/pull/28136
  • [x] Add details about the OS, e.g.: arch, name, version: https://github.com/spring-projects/spring-boot/pull/28907
  • [x] https://github.com/spring-projects/spring-boot/pull/39799
  • ~Add the list of used profiles: https://github.com/spring-projects/spring-boot/pull/38356~
  • ~Boot/Framework/Cloud/ Data/etc. versions? (also see "arbitrary records from the manifest file" below): https://github.com/spring-projects/spring-boot/pull/38356~
  • ~https://github.com/spring-projects/spring-boot/issues/22924~
  • [x] Add details about the available resources e.g.: cpu, memory
  • [x] https://github.com/spring-projects/spring-boot/pull/38371
  • [x] https://github.com/spring-projects/spring-boot/pull/41262
  • [x] https://github.com/spring-projects/spring-boot/pull/41205
  • [ ] Add details about the used GC
  • [ ] Add details about certain "user" properties: timezone, country, language, user dir
  • [ ] Add network-related details: host, ip
  • [ ] Miscellaneous items: current time, start time, uptime
  • [ ] Enhance StartupInfoLogger with some of these details

See: - An all-in-one implementation example for some of the features above: RuntimeInfoContributor - An example json output

Health enhancements

  • [ ] Add OOB health support for Feign clients: this should go to Spring Cloud OpenFeign, Spring Boot might provide support to handle the Health response (see: this solution), related: https://github.com/spring-projects/spring-boot/issues/36953
  • [ ] Metrics/tracing for health indicators

Spring Security enhancements

  • [ ] /whoami endpoint: show principal and granted authorities

The list is still in progress and very likely to evolve in the near future.

Comment From: dsyer

The activeProfiles is already exposed in the /env endpoint.

Comment From: jonatan-ivanov

Good point, today I was implementing it and I realized that if I don't set the active profiles property but set spring.profiles.default, then environment.getActiveProfiles() will be empty and the profle I set for default will be used. I think on the info endpoint it would be more useful to return the "effectively used profiles" instead of the value of environment.getActiveProfiles(). Something like this I guess:

String[] getEffectiveProfiles() {
    return ObjectUtils.isEmpty(environment.getActiveProfiles()) ? environment.getDefaultProfiles() : environment.getActiveProfiles();
}

Comment From: dsyer

Uptime is already a metric as well - I guess it really belongs there because you don't expect info to change over time.

Comment From: jonatan-ivanov

I think using data that can change over time should be ok on the info endpoint, e.g.: current time (to detect clock skew issues), uptime (to see if the app was restarted or not), even the cpu count can change over time (because of cgroups).

I think the same about data that we have metrics for, e.g.: jvm version info. I think they can be used in different use-cases and the user should decide if they want one or the other or both.