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>
Stephane Nicoll
Andy Wilkinson
Madhura Bhave
Scott Frederick
Phillip Webb
dreis2211
Brian Clozel
Johnny Lim
Jon Schneider
Vedran Pavic
Andreas Born