Update `Group` properties so that the `showDetails` value does not
inherit `Show.NEVER`. Prior to this commit, the `Group` properties
would not correctly inherit a `showDetails` value from the main
`management.endpoint.health.show-details` property.
See gh-22022
Previously, Spring Boot's modules published Gradle Module Metadata
(GMM) the declared a platform dependency on spring-boot-dependencies.
This provided versions for each module's own dependencies but also had
they unwanted side-effect of pulling in spring-boot-dependencies
constraints which would influence the version of other dependencies
declared in the same configuration. This was undesirable as users
should be able to opt in to this level of dependency management, either
by using the dependency management plugin or by using Gradle's built-in
support via a platform dependency on spring-boot-dependencies.
This commit reworks how Spring Boot's build uses
spring-boot-dependencies and spring-boot-parent to provide its own
dependency management. Configurations that aren't seen by consumers are
configured to extend a dependencyManagement configuration that has an
enforced platform dependency on spring-boot-parent. This enforces
spring-boot-parent's version constraints on Spring Boot's build without
making them visible to consumers. To ensure that the versions that
Spring Boot has been built against are visible to consumers, the
Maven publication that produces pom files and GMM for the published
modules is configured to use the resolved versions from the module's
runtime classpath.
Fixes gh-21911
This commit provides a CassandraDriverHealthIndicator and
CassandraDriverReactiveHealthIndicator that do not require Spring Data.
As a result, a health indicator for Cassandra is provided even if the
application does not use Spring Data.
See gh-20887
This commit updates the logic for handling binding exceptions in the
management context when it is separate from the application context.
The changes allow the exception details to be visible to
DefaultErrorAttributes without causing the servlet container to
detect an error condition.
Fixes gh-21036
Update `EndpointDiscoverer` so that `@Endpoint` and `@EndpointExtension`
beans are created as late as possible.
Prior to this commit, endpoint beans and extension beans would be
created during the discovery phase which could cause early bean
initialization. The problem was especially nasty when using an embedded
servlet container since `ServletEndpointRegistrar` is loaded as the
container is initialized. This would trigger discovery and load all
endpoint beans, including the health endpoint, and all health indicator
beans.
Fixes gh-20714
Prior to this commit, details about an exception would get dropped when
the management context was separate from the application context and
an actuator endpoint threw a binding exception.
This commit adds some logic to capture the exception so the management
context error handlers can add the appropriate attributes to the error
response.
Fixes gh-21036
This commit improves the backward-compatibility of the ErrorAttributes
interfaces by providing a default implementation of a new method. It
also encapsulates several parameters that control the inclusion or
exclusion of error attributes into a new ErrorAttributeOptions type to
make it easier and less intrusive to add additional options in the
future. This encapsulation also makes the handling of the
includeException option more similar to other options.
Fixes gh-21324
Prior to this commit, there was a property server.error.include-details
that allowed configuration of the message and errors attributes in a
server error response.
This commit separates the control of the message and errors attributes
into two separate properties named server.error.include-message and
server.error.include-binding-errors. When the message attribute is
excluded from a servlet response, the value is changed from a
hard-coded text value to an empty value.
Fixes gh-20505
Prior to this commit, there was a cycle between `StatusAggregator` and
`SimpleStatusAggregator`, which caused a static initialization bug -
depending on which class (the implementation or its interface) was
loaded first.
This commit turns the static field of the `StatusAggregator` interface
into a static method to avoid this problem.
Fixes gh-21211
This commit removes the support for Reactor Netty metrics since it
seems that Spring Boot should not use this feature:
* HTTP metrics are already covered by WebFlux
* TCP metrics are only meant to TCP server/clients
* allocator metrics are already provided by Netty and there is
no specific API to enable them here.
Closes gh-19388
This commit enables the production of TCP and buffer allocator metrics
for Reactor Netty, client and server.
When applications use auto-configured server
(`NettyReactiveWebServerFactory`) and client (through
`WebClient.Builder`) instances, metrics will be enabled.
Note that HTTP metrics are not enabled here, since similar metrics are
already produced at the WebFlux level. Also, to avoid cardinality
explosion of metrics (through the URI tag), Reactor Netty offers
configurable infrastructure to deduplicate URI tags by turning expanded
URI instances into templated URIs. This is not targeted for Spring
usage.
Closes gh-19388
Update `ConditionalOnAvailableEndpoint` so that it now uses the same
matching code as the endpoint filter. This allows the condition to
match endpoint IDs that contain a dash.
In order to share logic, the `ExposeExcludePropertyEndpointFilter` class
has been deprecated and its logic moved to a new `expose` package
under `IncludExcludeEndpointFilter`. This filter is used by both the
`OnAvailableEndpointCondition` and the auto-configuration classes.
Fixes gh-21044
Prior to this commit, the ManagementErrorEndpoint used to handle error
responses for the management servlet excluded stacktrace and exception
message details from the response unconditionally.
With this commit, the endpoint honors the
`server.error.include-stacktrace` and `server.error.include-details`
properties to conditionally include error details for consistency
with non-management error handling.
Fixes gh-20989
Prior to this commit, default error responses included the message
from a handled exception. When the exception was a BindException, the
error responses could also include an errors attribute containing the
details of the binding failure. These details could leak information
about the application.
This commit removes the exception message and binding errors detail
from error responses by default, and introduces a
`server.error.include-details` property that can be used to cause
these details to be included in the response.
Fixes gh-20505
Update the `HealthEndpointGroups` customization support to use a
post-processor rather than a mutable registry. Although this approach
is slightly less flexible, it removes a lot of complexity from the
`HealthEndpointGroups` code. Specifically, it allows us to drop the
`HealthEndpointGroupsRegistry` interface entirely.
The probe health groups are now added via the post-processor if they
aren't already defined. Unlike the previous implementation, users are
no longer able to customize status aggregation and http status code
mapping rules _unless_ they also re-define the health indicators that
are members of the group.
See gh-20962
Update `AvailabilityProbesAutoConfiguration` to allow the
`management.health.probes.enabled` property to override the platform
detection logic. Prior to this commit, it was possible to use the
property to enable the probes, but it was not possible to disable
them when deploying to Kubernates.
See gh-20962
Relocate probe auto-configuration from the `kubernetes` package to
`availability` since probes could also be used on other platforms.
The classes have also been renamed to named to `AvailabilityProbes...`
See gh-20962
Rename `LivenessProbeHealthIndicator` to `LivenessStateHealthIndicator`
and `ReadinessProbeHealthIndicator` to `ReadinessStateHealthIndicator`.
Also introduce a general purpose `AvailabilityStateHealthIndicator`
class.
See gh-20962
Create a general purpose `AvailabilityState` interface and refactor
the existing `LivenessState` and `ReadinessState` to use it. A single
`AvailabilityChangeEvent` is now used to carry all availability state
updates.
This commit also renames `ApplicationAvailabilityProvider` to
`ApplicationAvailabilityBean` and extracts an `ApplicationAvailability`
interface that other beans can inject. The helps to hide the event
listener method, which is really internal.
Finally the state enums have been renamed as follows:
- `LivenessState.LIVE` -> `LivenessState.CORRECT`
- `ReadinessState.READY` -> `ReadinessState.ACCEPTING_TRAFFIC`
- `ReadinessState.UNREADY` -> `ReadinessState.REFUSING_TRAFFIC`
See gh-20962
This commit removes the duplication added temporarily in Spring Boot to
initialize a default WavefrontSender builder.
This commit also disables a test is failing at the moment, see
https://github.com/micrometer-metrics/micrometer/issues/1964
See gh-20854
This commit upgrades the Wavefront metrics export auto-configuration to
provide a `WavefrontSender` if necessary and use that to export metrics
rather than the http client Micrometer used previously.
As a result, the "read-timeout" and "connect-timeout" properties are no
longer honoured.
Closes gh-20810
StatsD no longer publishes metrics about itself and StatsDMetrics is
deprecated as a result. This commit removes the auto-configuration of
it.
Closes gh-20836
This commit exposes an additional property for Graphite that allows to
restore the previous default behaviour with regards to tags, i.e.
prefixing the ones defined by the "tagsAsPrefix" property.
Close gh-20834
This property is a left-over and was never used in Micrometer so this
commit deprecates its use so that it can be removed in the next feature
release.
Closes gh-20835
This commit fixes the AtlasProperties hierarchy so that it no longer is
a StepRegistryProperties. The AtlasConfig on the Micrometer side of
things does not share the common config hierarchy either and some
properties have different default and lifecycle.
Closes gh-20843
Prior to this commit, we were relying on the
`"spring.main.cloud-platform"` property for overriding cloud platform
detection and enabling liveness and readiness probes. Changes made in
gh-20553 have now been reverted.
This commit adds the `"management.health.probes.enabled"` configuration
property. The auto-configuration now enables the HTTP Probes and
`HealthIndicator` if this property is enabled, or if the Kubernetes
cloud platform is detected.
This property is `false` by default for now, since enabling this for all
Spring Boot applications would be a breaking change. In this case, the
global `"/actuator/health"` endpoint could report `OUT_OF_SERVICE`
during startup time because the application now reports the readiness as
well.
See gh-19593
This commit moves the core Liveness and Readiness support to its own
`availability` package. We've made this a core concept independent of
Kubernetes.
Spring Boot now produces `LivenessStateChanged` and
`ReadinessStateChanged` events as part of the typical application
lifecycle.
Liveness and Readiness Probes (`HealthIndicator` components and health
groups) are still configured only when deployed on Kubernetes.
This commit also improves the documentation around Probes best practices
and container lifecycle considerations.
See gh-19593
Prior to this commit and as of Spring Boot 2.2.0, we would advise
developers to use the Actuator health groups to define custom "liveness"
and "readiness" groups and configure them with subsets of existing
health indicators.
This commit addresses several limitations with that approach.
First, `LivenessState` and `ReadinessState` are promoted to first class
concepts in Spring Boot applications. These states should not only based
on periodic health checks. Applications should be able to track changes
(and adapt their behavior) or update states (when an error happens).
The `ApplicationStateProvider` can be injected and used by applications
components to get the current application state. Components can also
track specific `ApplicationEvent` to be notified of changes, like
`ReadinessStateChangedEvent` and `LivenessStateChangedEvent`.
Components can also publish such events with an
`ApplicationEventPublisher`. Spring Boot will track startup event and
application context state to update the liveness and readiness state of
the application. This infrastructure is available in the
main spring-boot module.
If Spring Boot Actuator is on the classpath, additional
`HealthIndicator` will be contributed to the application:
`"LivenessProveHealthIndicator"` and `"ReadinessProbeHealthIndicator"`.
Also, "liveness" and "readiness" Health groups will be defined if
they're not configured already.
Closes gh-19593
Prior to this commit, `HealthContributor` would be exposed under the
main `HealthEndpoint` and subgroups, `HealthEndpointGroups`. Groups are
driven by configuration properties and there was no way to contribute
programmatically new groups.
This commit introduces the `HealthEndpointGroupsRegistry` (a mutable
version of `HealthEndpointGroups`) and a
`HealthEndpointGroupsRegistryCustomizer`. This allows configurations to
add/remove groups during Actuator auto-configuration.
Closes gh-20554
This commit relaxes the class condition to ConnectionFactory, checking
if the connection factory is a connection pool and bind its metrics to
the registry accordingly.
Closes gh-20349
This commit adds metrics support for `ConnectionPool` beans.
See gh-19988
Co-authored-by: Mark Paluch <mpaluch@pivotal.io>
Co-authored-by: Tadaya Tsuyukubo <tadaya@ttddyy.net>
This commit adds an health indicator for R2DBC. If a validation query is
provided, it is used to validate the state of the database. If not, a
check of the connection is issued.
See gh-19988
Co-authored-by: Mark Paluch <mpaluch@pivotal.io>
Prior to this commit, Actuator endpoints would use the application
ObjectMapper instance for serializing payloads as JSON. This was
problematic in several cases:
* application-specific configuration would change the actuator endpoint
output.
* choosing a different JSON mapper implementation in the application
would break completely some endpoints.
Spring Boot Actuator already has a hard dependency on Jackson, and this
commit uses that fact to configure a shared `ObjectMapper` instance that
will be used by the Actuator infrastructure consistently, without
polluting the application context.
This `ObjectMapper` is used in Actuator for:
* JMX endpoints
* Spring MVC endpoints with an HTTP message converter
* Spring WebFlux endpoints with an `Encoder`
* Jersey endpoints with a `ContextResolver<ObjectMapper>`
For all web endpoints, this configuration is limited to the
actuator-specific media types such as
`"application/vnd.spring-boot.actuator.v3+json"`.
Fixes gh-12951
This partially re-applies the deprecation removal from commit
df1837a16b,
without removing CompositeHealthIndicator, HealthAggregator, and related
configuration that is required by Spring Cloud.
For consistency with SpringApplication, this commit disables bean
overriding by default in ApplicationContextRunner. Bean overriding can
be enabled again using withAllowBeanDefinitionOverriding.
Closes gh-18019
Update all dependencies declarations to use the form `scope(reference)`
rather than `scope reference`.
Prior to this commit we declared dependencies without parentheses unless
we were forced to add them due to an `exclude`.
Replace Gradle single quote strings with the double quote form
whenever possible. The change helps to being consistency to the
dependencies section where mostly single quotes were used, but
occasionally double quotes were required due to `${}` references.
This commit removes references of cache infra following the move to
Micrometer. We no longer ships an infinispan specific binder so the
dependency has been removed as well.
Closes gh-19838
This paves the way for publishing Gradle module metadata once the
problem caused by snapshot versions and our two-step publication
process has been addressed.
See gh-19609
This reverts commit b34a311d02 as,
having disabled the publishing of Gradle's module metadata (4f75ab5),
the changes are no longer needed.
See gh-19609
Previously, enforcedPlatform dependencies were using to pull in the
constraints defined in spring-boot-dependencies and
spring-boot-parent and applied them strictly so that the constrained
version had to be used. This worked as intended in Spring Boot's own
build but incorrectly enforced those same strict version requirements
on external consumers of Spring Boot's modules.
This commit reworks how Spring Boot defines its internal dependency
management so that platform dependencies are exposed to external
consumers while enforced platform dependencies are using internally.
See gh-19609
The Elasticsearch transport client has been deprecated since Spring Boot
2.2.0 and is about to be removed from Spring Data Elasticsearch and
Elasticsearch itself in their next major releases.
The available REST client support variants are now the preferred way of
using Elasticsearch features.
Closes gh-19668
Update `HealthEndpointConfiguration` to also include adapted reactive
health contributors when project reactor is on the classpath. Prior to
this commit, reactive contributors were only exposed in WebFlux
applications. This was a regression from Spring Boot 2.1 that we didn't
catch because all our own reactive contributors all have non-reactive
equivalents.
Closes gh-18805
This commit restores the highest precedence of reactive
HealthContributor over imperative one. Previously, both would be
registered, leading to duplicate entries in health output.
Closes gh-18748
Lee Dobryden
Phillip Webb
Leo Li
Andy Wilkinson
Stephane Nicoll
Alexandre Dutra
Scott Frederick
Johnny Lim
Madhura Bhave
Phillip Webb
dreis2211
Brian Clozel
Jon Schneider
Vedran Pavic
Andreas Born
Dave Syer
babjo
Christoph Strobl
wonwoo
Johannes Graf
thelproad
wycm