Actuators are nothing but Spring Boot provided production-ready features to our application. Spring Boot includes a number of additional features to help you monitor and manage your application when you push it to production. You can choose to manage and monitor your application by using HTTP endpoints. Monitoring of application, gathering metrics, understanding traffic becomes trivial with this dependency.
The main benefit is actually getting all this feature, the moment you add Spring Actuators in your application dependency, without you actually implementing it. Once this dependency is on the classpath several endpoints are available for us out of the box. As with most Spring modules, we can easily configure or extend it in many ways.
Enabling Production-ready Features
The spring-boot-actuator
module provides all of Spring Boot’s production-ready features. The simplest way to enable the features is to add a dependency to the spring-boot-starter-actuator
‘Starter’.
To add the actuator to a Maven based project, add the following ‘Starter’ dependency:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Endpoints
Actuator endpoints let you monitor and interact with your application. Spring Boot includes a number of built-in endpoints and lets you add your own. For example, the /health
endpoint provides basic application health information.
Here are some of the most common endpoints Boot provides out of the box:
- /health – Shows application health information (a simple ‘status’ when accessed over an unauthenticated connection or full message details when authenticated); it’s not sensitive by default
- /info – Displays arbitrary application info; not sensitive by default
- /metrics – Shows ‘metrics’ information for the current application; it’s also sensitive by default
- /trace – Displays trace information (by default the last few HTTP requests)
The full list can be found below
ID | Description | Enabled by default |
---|---|---|
auditevents | Exposes audit events information for the current application. | Yes |
beans | Displays a complete list of all the Spring beans in your application. | Yes |
caches | Exposes available caches. | Yes |
conditions | Shows the conditions that were evaluated on configuration and auto-configuration classes and the reasons why they did or did not match. | Yes |
configprops | Displays a collated list of all @ConfigurationProperties . | Yes |
env | Exposes properties from Spring’s ConfigurableEnvironment . | Yes |
flyway | Shows any Flyway database migrations that have been applied. | Yes |
health | Shows application health information. | Yes |
httptrace | Displays HTTP trace information (by default, the last 100 HTTP request-response exchanges). | Yes |
info | Displays arbitrary application info. | Yes |
integrationgraph | Shows the Spring Integration graph. | Yes |
loggers | Shows and modifies the configuration of loggers in the application. | Yes |
liquibase | Shows any Liquibase database migrations that have been applied. | Yes |
metrics | Shows ‘metrics’ information for the current application. | Yes |
mappings | Displays a collated list of all @RequestMapping paths. | Yes |
scheduledtasks | Displays the scheduled tasks in your application. | Yes |
sessions | Allows retrieval and deletion of user sessions from a Spring Session-backed session store. Not available when using Spring Session’s support for reactive web applications. | Yes |
shutdown | Lets the application be gracefully shutdown. | No |
threaddump | Performs a thread dump. | Yes |
Enabling Endpoints
By default, all endpoints except for shutdown
are enabled. To configure the enablement of an endpoint, use its management.endpoint.<id>.enabled
property. The following example enables the shutdown
endpoint:
management.endpoint.shutdown.enabled=true
If you want endpoint enablement to be opt-in rather than opt-out, set the management.endpoints.enabled-by-default
property to false
and use individual endpoint enabled
properties to opt back in. The following example enables the info
endpoint and disables all other endpoints:
management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=true
Exposing Endpoints
You do not let the world know about your application beans. That’s why there is constraint over endpoints. i.e. you should not expose /beans endpoint over HTTP(web). Here is the list of built-in endpoints and their default exposure.
ID | JMX | Web |
---|---|---|
auditevents | Yes | No |
beans | Yes | No |
caches | Yes | No |
conditions | Yes | No |
configprops | Yes | No |
env | Yes | No |
flyway | Yes | No |
health | Yes | Yes |
heapdump | N/A | No |
httptrace | Yes | No |
info | Yes | Yes |
integrationgraph | Yes | No |
jolokia | N/A | No |
logfile | N/A | No |
loggers | Yes | No |
liquibase | Yes | No |
metrics | Yes | No |
mappings | Yes | No |
prometheus | N/A | No |
scheduledtasks | Yes | No |
sessions | Yes | No |
shutdown | Yes | No |
threaddump | Yes | No |
To change which endpoints are exposed, use the following technology-specific include
and exclude
properties:
Property | Default |
---|---|
management.endpoints.jmx.exposure.exclude | |
management.endpoints.jmx.exposure.include | * |
management.endpoints.web.exposure.exclude | |
management.endpoints.web.exposure.include | info, health |
The include
property lists the IDs of the endpoints that are exposed. The exclude
property lists the IDs of the endpoints that should not be exposed. The exclude
property takes precedence over the include
property. Both include
and exclude
properties can be configured with a list of endpoint IDs.
For example, to stop exposing all endpoints over JMX and only expose the health
and info
endpoints, use the following property:
management.endpoints.jmx.exposure.include=health,info
*
can be used to select all endpoints. For example, to expose everything over HTTP except the env
and beans
endpoints, use the following properties:
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=env, beans
Securing HTTP Endpoints
You should take care to secure HTTP endpoints in the same way that you would any other sensitive URL. If Spring Security is present, endpoints are secured by default using Spring Security’s content-negotiation strategy. If you wish to configure custom security for HTTP endpoints, for example, only allow users with a certain role to access them, Spring Boot provides some convenient RequestMatcher
objects that can be used in combination with Spring Security. For example:-
@Configuration
public class ActuatorSecurity extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.requestMatcher(EndpointRequest.toAnyEndpoint())
.authorizeRequests() .anyRequest().hasRole("ENDPOINT_ADMIN")
.and() .httpBasic();
}
}
The above code ensure that who have the ENDPOINT_ADMIN
role will be authenticated.
If you deploy applications behind a firewall, you may prefer that all your actuator endpoints can be accessed without requiring authentication. You can do so by changing the management.endpoints.web.exposure.include
property, as follows:
application.properties.
management.endpoints.web.exposure.include=*
Configuring Endpoints
Endpoints automatically cache responses to read operations that do not take any parameters. To configure the amount of time for which an endpoint will cache a response, use its cache.time-to-live
property. The following example sets the time-to-live of the beans
endpoint’s cache to 10 seconds:
application.properties.
management.endpoint.beans.cache.time-to-live=10s
Hope this cleared some of your doubts about Spring Actuator.