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
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
With its initial fix in gh-18444, the `WebClient` instrumentation would
record all CANCEL signals, including:
* when a `timeout` expires and the response has not been received
* when the client partially consumes the response body
Since the second use case is arguable intentional, this commit restricts
the instrumentation and thus avoids recording two events for a single
request in that case.
Closes gh-18444
Prior to this commit, cancelled client requests (for example as a result
of a `timeout()` reactor operator would not be recorded by Micrometer.
This commit instruments the cancelled signal for outgoing client
requests and assigns a status `CLIENT_ERROR`.
The cancellation can be intentional (triggering a timeout and falling
back on a faster alternative) or considered as an error. The intent
cannot be derived from the signal itself so we're considering it as a
client error.
Closes gh-18444
The system keyspace has a replication factor of 1 and is local to each
node; it is therefore recommended to query system.local with a
consistency level of ONE or LOCAL_ONE.
Stronger consistency levels may result in an Unavailable error, but this
does not mean that the node is down.
See gh-20709
Prior to this commit, `LivenessState` and `ReadinessState` were
immutable classes. This was done in order to have additional behavior
and information in those classes.
Because the current implementation doesn't need this, this commit turns
those classes into simple enums.
Additional state and information can be added to the
`*StateChangedEvent` classes.
See gh-19593
This commit upgrades the algorithm when trailing slash are to be
ignored. Previously a root URI (i.e. "/") would result to to empty
string which is an issue for monitoring system that requires tag values
to be non empty. If the URI is a single character, the trailing is not
applied and "/" is left as is.
Closes gh-20536
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 upgrades to the Couchbase SDK v3 which brings the following
breaking changes:
* Bootstrap hosts have been replaced by a connection string and the
authentication is now mandatory.
* A `Bucket` is no longer auto-configured. The
`spring.couchbase.bucket.*` properties have been removed
* `ClusterInfo` no longer exists and has been replaced by a dedicated
API on `Cluster`.
* `CouchbaseEnvironment` no longer exist in favour of
`ClusterEnvironment`, the customizer has been renamed accordingly.
* The bootstrap-related properties have been removed. Users requiring
custom ports should supply the seed nodes and initialize a Cluster
themselves.
* The endpoints-related configuration has been consolidated in a
single IO configuration.
The Spring Data Couchbase provides an integration with the new SDK. This
leads to the following changes:
* A convenient `CouchbaseClientFactory` is auto-configured.
* Repositories are configured against a bucket and a scope. Those can
be set via configuration in `spring.data.couchbase.*`.
* The default consistency property has been removed in favour of a more
flexible annotation on the repository query methods instead. You can now
specify different query consistency on a per method basis.
* The `CacheManager` implementation is provided, as do other stores for
consistency so a dependency on `couchbase-spring-cache` is no longer
required.
See gh-19893
Co-authored-by: Michael Nitschinger <michael@nitschinger.at>
Previously, any HTTP request to an endpoint that included a principal
would bypass the cache. This prevented authenticated requests from
making use of the cache and its configurable time-to-live.
This commit updates the caching operation invoker to include the
principal, if any, in its cache key. As a result, requests that
include a principal will make use of the cache, potentially returning
the result of a previous invocation of the same endpoint by the same
principal.
Closes gh-19538
Unfortunately, while redundant for new applications, removing the
leading slash adversely affected existing application upon upgrades as
it caused Liquibase to re-apply every change log.
Closes gh-20177
When a request to the /actuator/env/{toMatch} endpoint does not match a
property, a response status 404 was being returned along with a body
containing the existing property sources. This commit removes the body
from the response to be more consistent with a typical 404 response.
Fixes gh-20314
Phillip Webb
dreis2211
Brian Clozel
Andy Wilkinson
Andreas Born
Stephane Nicoll
Alexandre Dutra
Scott Frederick
Johnny Lim
Said BOUDJELDA