On this page
47. Endpoints
Actuator endpoints allow you to monitor and interact with your application. Spring Boot includes a number of built-in endpoints and you can also add your own. For example the health
endpoint provides basic application health information.
The way that endpoints are exposed will depend on the type of technology that you choose. Most applications choose HTTP monitoring, where the ID of the endpoint is mapped to a URL. For example, by default, the health
endpoint will be mapped to /health
.
The following technology agnostic endpoints are available:
ID | Description | Sensitive Default |
---|---|---|
|
Provides a hypermedia-based “discovery page” for the other endpoints. Requires Spring HATEOAS to be on the classpath. |
true |
|
Exposes audit events information for the current application. |
true |
|
Displays an auto-configuration report showing all auto-configuration candidates and the reason why they ‘were’ or ‘were not’ applied. |
true |
|
Displays a complete list of all the Spring beans in your application. |
true |
|
Displays a collated list of all |
true |
|
Performs a thread dump. |
true |
|
Exposes properties from Spring’s |
true |
|
Shows any Flyway database migrations that have been applied. |
true |
|
Shows application health information (when the application is secure, a simple ‘status’ when accessed over an unauthenticated connection or full message details when authenticated). |
false |
|
Displays arbitrary application info. |
false |
|
Shows and modifies the configuration of loggers in the application. |
true |
|
Shows any Liquibase database migrations that have been applied. |
true |
|
Shows ‘metrics’ information for the current application. |
true |
|
Displays a collated list of all |
true |
|
Allows the application to be gracefully shutdown (not enabled by default). |
true |
|
Displays trace information (by default the last 100 HTTP requests). |
true |
If you are using Spring MVC, the following additional endpoints can also be used:
ID | Description | Sensitive Default |
---|---|---|
|
Displays documentation, including example requests and responses, for the Actuator’s endpoints. Requires |
false |
|
Returns a GZip compressed |
true |
|
Exposes JMX beans over HTTP (when Jolokia is on the classpath). |
true |
|
Returns the contents of the logfile (if |
true |
Note | |
---|---|
Depending on how an endpoint is exposed, the |
Endpoints can be customized using Spring properties. You can change if an endpoint is enabled
, if it is considered sensitive
and even its id
.
For example, here is an application.properties
that changes the sensitivity and id of the beans
endpoint and also enables shutdown
.
endpoints.beans.id=springbeans
endpoints.beans.sensitive=false
endpoints.shutdown.enabled=true
Note | |
---|---|
The prefix ‟ |
By default, all endpoints except for shutdown
are enabled. If you prefer to specifically “opt-in” endpoint enablement you can use the endpoints.enabled
property. For example, the following will disable all endpoints except for info
:
endpoints.enabled=false
endpoints.info.enabled=true
Likewise, you can also choose to globally set the “sensitive” flag of all endpoints. By default, the sensitive flag depends on the type of endpoint (see the table above). For example, to mark all endpoints as sensitive except info
:
endpoints.sensitive=true
endpoints.info.sensitive=false
If endpoints.hypermedia.enabled
is set to true
and Spring HATEOAS is on the classpath (e.g. through the spring-boot-starter-hateoas
or if you are using Spring Data REST ) then the HTTP endpoints from the Actuator are enhanced with hypermedia links, and a “discovery page” is added with links to all the endpoints. The “discovery page” is available on /actuator
by default. It is implemented as an endpoint, allowing properties to be used to configure its path (endpoints.actuator.path
) and whether or not it is enabled (endpoints.actuator.enabled
).
When a custom management context path is configured, the “discovery page” will automatically move from /actuator
to the root of the management context. For example, if the management context path is /management
then the discovery page will be available from /management
.
If the HAL Browser is on the classpath via its webjar (org.webjars:hal-browser
), or via the spring-data-rest-hal-browser
then an HTML “discovery page”, in the form of the HAL Browser, is also provided.
Cross-origin resource sharing (CORS) is a W3C specification that allows you to specify in a flexible way what kind of cross domain requests are authorized. Actuator’s MVC endpoints can be configured to support such scenarios.
CORS support is disabled by default and is only enabled once the endpoints.cors.allowed-origins
property has been set. The configuration below permits GET
and POST
calls from the example.com
domain:
endpoints.cors.allowed-origins=http://example.com
endpoints.cors.allowed-methods=GET,POST
Tip | |
---|---|
Check EndpointCorsProperties for a complete list of options. |
If you add a @Bean
of type Endpoint
then it will automatically be exposed over JMX and HTTP (if there is an server available). An HTTP endpoints can be customized further by creating a bean of type MvcEndpoint
. Your MvcEndpoint
is not a @Controller
but it can use @RequestMapping
(and @Managed*
) to expose resources.
Tip | |
---|---|
If you are doing this as a library feature consider adding a configuration class annotated with |
Health information can be used to check the status of your running application. It is often used by monitoring software to alert someone if a production system goes down. The default information exposed by the health
endpoint depends on how it is accessed. For an unauthenticated connection in a secure application a simple ‘status’ message is returned, and for an authenticated connection additional details are also displayed (see Section 48.7, “HTTP health endpoint format and access restrictions” for HTTP details).
Health information is collected from all HealthIndicator
beans defined in your ApplicationContext
. Spring Boot includes a number of auto-configured HealthIndicators
and you can also write your own. By default, the final system state is derived by the HealthAggregator
which sorts the statuses from each HealthIndicator
based on an ordered list of statuses. The first status in the sorted list is used as the overall health status. If no HealthIndicator
returns a status that is known to the HealthAggregator
, an UNKNOWN
status is used.
Information returned by HealthIndicators
is often somewhat sensitive in nature. For example, you probably don’t want to publish details of your database server to the world. For this reason, by default, only the health status is exposed over an unauthenticated HTTP connection. If you are happy for complete health information to always be exposed you can set endpoints.health.sensitive
to false
.
Health responses are also cached to prevent “denial of service” attacks. Use the endpoints.health.time-to-live
property if you want to change the default cache period of 1000 milliseconds.
The following HealthIndicators
are auto-configured by Spring Boot when appropriate:
Name | Description |
---|---|
Checks that a Cassandra database is up. |
|
Checks for low disk space. |
|
Checks that a connection to |
|
Checks that an Elasticsearch cluster is up. |
|
Checks that a JMS broker is up. |
|
Checks that a mail server is up. |
|
Checks that a Mongo database is up. |
|
Checks that a Rabbit server is up. |
|
Checks that a Redis server is up. |
|
Checks that a Solr server is up. |
Tip | |
---|---|
It is possible to disable them all using the |
To provide custom health information you can register Spring beans that implement the HealthIndicator
interface. You need to provide an implementation of the health()
method and return a Health
response. The Health
response should include a status and can optionally include additional details to be displayed.
import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;
@Component
public class MyHealthIndicator implements HealthIndicator {
@Override
public Health health() {
int errorCode = check(); // perform some specific health check
if (errorCode != 0) {
return Health.down().withDetail("Error Code", errorCode).build();
}
return Health.up().build();
}
}
Note | |
---|---|
The identifier for a given |
In addition to Spring Boot’s predefined Status
types, it is also possible for Health
to return a custom Status
that represents a new system state. In such cases a custom implementation of the HealthAggregator
interface also needs to be provided, or the default implementation has to be configured using the management.health.status.order
configuration property.
For example, assuming a new Status
with code FATAL
is being used in one of your HealthIndicator
implementations. To configure the severity order add the following to your application properties:
management.health.status.order=FATAL, DOWN, OUT_OF_SERVICE, UNKNOWN, UP
The HTTP status code in the response reflects the overall health status (e.g. UP
maps to 200, OUT_OF_SERVICE
or DOWN
to 503). You might also want to register custom status mappings with the HealthMvcEndpoint
if you access the health endpoint over HTTP. For example, the following maps FATAL
to 503 (service unavailable):
endpoints.health.mapping.FATAL=503
The default status mappings for the built-in statuses are:
Status | Mapping |
---|---|
DOWN |
SERVICE_UNAVAILABLE (503) |
OUT_OF_SERVICE |
SERVICE_UNAVAILABLE (503) |
UP |
No mapping by default, so http status is 200 |
UNKNOWN |
No mapping by default, so http status is 200 |
Application information exposes various information collected from all InfoContributor
beans defined in your ApplicationContext
. Spring Boot includes a number of auto-configured InfoContributors
and you can also write your own.
The following InfoContributors
are auto-configured by Spring Boot when appropriate:
Name | Description |
---|---|
Expose any key from the |
|
Expose git information if a |
|
Expose build information if a |
Tip | |
---|---|
It is possible to disable them all using the |
You can customize the data exposed by the info
endpoint by setting info.*
Spring properties. All Environment
properties under the info key will be automatically exposed. For example, you could add the following to your application.properties
:
info.app.encoding=UTF-8
info.app.java.source=1.8
info.app.java.target=1.8
Tip | |
---|---|
Rather than hardcoding those values you could also expand info properties at build time. Assuming you are using Maven, you could rewrite the example above as follows:
|
Another useful feature of the info
endpoint is its ability to publish information about the state of your git
source code repository when the project was built. If a GitProperties
bean is available, the git.branch
, git.commit.id
and git.commit.time
properties will be exposed.
Tip | |
---|---|
A |
If you want to display the full git information (i.e. the full content of git.properties
), use the management.info.git.mode
property:
management.info.git.mode=full
The info
endpoint can also publish information about your build if a BuildProperties
bean is available. This happens if a META-INF/build-info.properties
file is available in the classpath.
Tip | |
---|---|
The Maven and Gradle plugins can both generate that file, see Generate build information for more details. |
To provide custom application information you can register Spring beans that implement the InfoContributor
interface.
The example below contributes an example
entry with a single value:
import java.util.Collections;
import org.springframework.boot.actuate.info.Info;
import org.springframework.boot.actuate.info.InfoContributor;
import org.springframework.stereotype.Component;
@Component
public class ExampleInfoContributor implements InfoContributor {
@Override
public void contribute(Info.Builder builder) {
builder.withDetail("example",
Collections.singletonMap("key", "value"));
}
}
If you hit the info
endpoint you should see a response that contains the following additional entry:
{
"example": {
"key" : "value"
}
}