Update metrics auto-configurations so that they are auto-configured
after `CompositeMeterRegistryAutoConfiguration` in order to ensure
the `MeterRegistry` bean has been defined.
Prior to this commit, metrics auto-configurations that depended on a
`MeterRegistry` has `@AutoConfigureAfter(MetricsAutoConfiguration.class)`
which is not sufficient since `MetricsAutoConfiguration` does not export
a `MeterRegistry`.
See gh-21134
Previously, the endpoints' responses could occasionally exceed
WebClient's in-memory buffer limt, for example if the threads endpoint
was reporting a large number of threads or the threads had large
stacks.
This commit disables WebClient's in-memory buffer size limit so that
the tests passing is not dependent on the size of the endpoints'
responses.
Closes gh-22743
Prior to this commit, the livenessState and readinessState health
indicators would not be configured automatically and would be missing
from the "liveness" and "readiness" health groups, leading to 404s when
hitting the `/actuator/health/liveness` or `/actuator/health/readiness`.
This commit ensures that the health indicators beans have the proper
name and revisits the auto-configuration conditions to reflect that as
well.
Fixes gh-22562
This commit replaces the Neo4j-OGM based health checks with one based on
the Neo4j Java driver. A Reactive variant is also added in this commit.
See gh-22302
This commit harmonizes dependency declarations for Jackson in the
actuator. Both Jackson and JSR 310 are back to optional in the core
actuator module and mandatory when using the auto-configuration.
Closes gh-22624
The generated snippets were not declared as an output to the
`spring-boot-actuator-autoconfigure` test goal so when the test was
pulled from the cache, it did not contain the `generated-snippets`
directory. This directory is required as an input to the Asciidoctor
plugin.
See gh-22555
This commit introduces a new property to globally disable metrics
export. In integration tests, this property is automatically set to
disable everything but in-memory metrics.
This commit also introduces a `@AutoConfigureMetrics` annotation that
can be used for integration tests that require metrics export to operate
as they would in an application.
See gh-21658
Prior to this commit, the application availability infrastructure
would mix the `AvailabilityState`, the `HealthIndicator` and the
`HealthGroup` concepts and would not align with the rest.
This commit auto-configures the livenessState and readinessState
health indicators with the relevant configuration properties.
Unlike other indicators, they are not enabled by default but might
be in future versions.
This also moves the `management.health.probes.enabled` property
to `management.endpoint.health.probes.enabled` since "probes" here
is not a health indicator but rather a configuration flag for the
health endpoint.
Finally, the probes auto-configuration is refined to automatically
add liveness and readiness indicators for the probes group if
they're not already present.
Closes gh-22107
Prior to this commit, configuring a reactive Elasticsearch client would
auto-configure an Actuator Health check using a synchronous client, with
the default configuration properties (so tarting localhost:9200).
This would lead to false reports of unhealthy Elasticsearch clusters
when using reactive clients.
This commit reproduces the logic for MongoDB repositories: if a reactive
variant is available, it is selected for the health check
infrastructure.
See gh-21042
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
Update `DataSourceHealthContributorAutoConfiguration` so that any
`AbstractRoutingDataSource` beans are still included in the overall
health. Prior to this commit, a regression in Spring Boot 2.2 meant
that if a single routing bean was found an `IllegalArgumentException`
would be thrown.
In Spring Boot 2.1 all `AbstractRoutingDataSource` would be filtered
from the results, but if no results existed the following was returned:
"details": {
"db": {
"status": "UNKNOWN"
},
In Spring Boot 2.2 we now always include routing datasource beans, even
if other non-routing database beans are found. The health details
includes `"routing" : true` to help users disambiguate any results.
Fixes gh-18661
Update `NewRelicProperties` so that the event type sent with each
metric can be configured. An additional `boolean` property has
also been added if the previous behavior using the "meter-name"
is required.
NewRelic's own agents publish metrics to eventTypes aligned with broader
categories. To align with their recommendation the default behavior is
to publish metrics under a "SpringBootSample" category. When doing so,
additional context is provided by including "metricName" and
"metricType" attributes.
See gh-18472
Previously, Maven's default behaviour was relied up which resulted
in the artifact ID being appended to each URL as it was inherited.
This behaviour can only be disabled in Maven 3.6 and later, a version
that we cannot use due to an incompatibility with the Flatten Plugin.
This commit works around Maven's default behaviour by defining
properties for the SCM URL, connection, and developer connection and
then explicitly defining the settings in each pom using these
properties. The explicit definition of the properties in each pom
prevents them being inherited from the parent, thereby disabling the
unwanted appending of the artifact ID to the URL.
Fixes gh-18328
Update `JerseyManagementContextConfiguration` so that customizer beans
are not longer applied. The endpoint resource endpoints are now added
with a registrar bean `@PostConstruct` method.
Prior to this commit, when running the management server on a different
port a `Resource` added by a customizer could be added two different
`ResourceConfig` instance. This breaks the singleton contract expected
by Jersey.
Fixes gh-17801
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Update `LegacyHealthEndpointCompatibilityConfiguration` to ensure that
the default configuration is only overwritten when the user has
explicitly set new values.
Fixes gh-18354
Add a `show-components` property under `management.endpoint.health` and
`management.endpoint.health.group.<name>` that can be used to change
when components are displayed.
Prior to this commit it was only possible to set `show-details` which
offered an "all or nothing" approach to the resulting JSON. The new
switch allows component information to be displayed whilst still hiding
potentially sensitive details returned from the actual `HealthIndicator`.
Closes gh-15076
Update the health endpoint so the nested components are now exposed
under `components` rather than `details` when v3 of the actuator
REST API is being used.
This distinction helps to clarify the difference between composite
health (health composed of other health components) and health
details (technology specific information gathered by the indicator).
Since this is a breaking change for the REST API, it is only returned
for v3 payloads. Requests made accepting only a v2 response will have
JSON provided in the original form.
Closes gh-17929
Add `ApiVersion` enum that can be injected into actuator endpoints if
they need to support more than one API revision.
Spring MVC, WebFlux and Jersey integrations now detect the API version
based on the HTTP accept header. If the request explicitly accepts a
`application/vnd.spring-boot.actuator.v` media type then the version
is set from the header. If no explicit Spring Boot media type is
accepted then the latest `ApiVersion` is assumed.
A new v3 API revision has also been introduced to allow upcoming health
endpoint format changes. By default all endpoints now consume and
can produce v3, v2 and `application/json` media types.
See gh-17929
Allow legacy actuator endpoint IDs that contain dots to be transparently
migrated to the new format. This update will allow Spring Cloud users
to proactively migrate from endpoints such as `hystrix.stream` to
`hystrixstream`.
Closes gh-18148
Restore `HealthIndicatorRegistry` and `ReactiveHealthIndicatorRegistry`
auto-configured beans with a version that adapts to the new contributor
interfaces.
Closes gh-16903
This commit moves `@ConfigurationProperties` to the `@Bean` factory
method as this is unusual to put it at class level if it's exposed
that way.
As HealthIndicatorProperties has a constructor, this makes sure that
the annotation processor enables JavaBean binding mode.
Fix caching issues in `ApplicationContextRequestMatcher` and allow
subclasses to ignore an application context entirely. Update existing
matcher implementations so that they deal with the management context
correctly.
Prior to this commit, the `ApplicationContextRequestMatcher` would
return a context cached from the first request. It also didn't
provide any way to ignore a context. This meant that if the user was
running the management server on a different port the matching results
could be inconsistent depending on if the first request arrived on
the regular context or the management context. It also meant that we
could not distinguish between the regular context and the management
context when matching.
Closes gh-18012
This commit also changes the request matcher for MVC
endpoints to use an AntPathRequestMatcher instead of an
MvcRequestMatcher. The endpoint is always available
under the mapped endpoint path and this way the same matcher
can be used for both MVC and Jersey.
Fixes gh-17912
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Phillip Webb
Martin Benda
Madhura Bhave
Stephane Nicoll
smlc
AndrewDi
Andy Wilkinson
Emily Tsanova
Brian Clozel
Gerrit Meier
Nelson Osacky
bono007
dreis2211
Julio Gomez Diaz
Aleksander Lech
Eddú Meléndez
Lee Dobryden
Leo Li
Alexandre Dutra
Scott Frederick
Johnny Lim
Phillip Webb
Brian Clozel
Jon Schneider
Vedran Pavic
Andreas Born
Dave Syer
babjo
Christoph Strobl
wonwoo
Johannes Graf
thelproad
wycm
Neil Powell
freekry