Pages

July 23, 2019

All About Spring Boot Actuator

What is Actuator?
  • We can monitor our app, gather metrics, understand traffic, or the state of our database with the help of Actuator,
  • With Actuator we can get production-grade tools without having to actually implement these features ourselves.
  • It is mainly used to expose operational information about the running application – health, metrics, info, dump, env, etc. 
  • Actuator uses HTTP endpoints or JMX beans to enable us to interact with it.
How can we add Actuator in our project?
To enable Spring Boot Actuator we'll just need to add the 'spring-boot-starter-actuator' dependency in pom.xml.

Spring Boot 2.x Actuator
2.x Actuator is technology-agnostic, whereas in 1.x it was tied to MVC, therefore to the Servlet API. 2.x Actuator defines its model, pluggable and extensible without relying on MVC for this. With this version we can take advantage of MVC as well as WebFlux as an underlying web technology.

Unlike in the previous versions, 2.x Actuator comes with most endpoints disabled. The only two available by default are /health and /info.

To enable all of them, we could set 'management.endpoints.web.exposure.include=*'. Alternatively, we can also list endpoints that should be enabled.

To explicitly enable a specific endpoint, e.g for shutdown:
management.endpoint.shutdown.enabled=true

To expose all enabled endpoints except one, e.g for example /loggers:
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=loggers

In 2.x by default, all Actuator endpoints are now placed under the /actuator path.

Predefined Actuator Endpoints
  • /auditevents :– lists security audit-related events such as user login/logout. Also, we can filter by principal or type among other fields
  • /beans :– returns all available beans in our BeanFactory. Unlike /auditevents, it doesn't support filtering
  • /conditions :– formerly known as /autoconfig, builds a report of conditions around auto-configuration
  • /configprops :– allows us to fetch all @ConfigurationProperties beans
  • /env :– returns the current environment properties. Additionally, we can retrieve single properties
  • /flyway :– provides details about our Flyway database migrations
  • /health :– summarises the health status of our application
  • /heapdump :– builds and returns a heap dump from the JVM used by our application
  • /info :– returns general information. It might be custom data, build information or details about the latest commit
  • /liquibase :– behaves like /flyway but for Liquibase
  • /logfile :– returns ordinary application logs
  • /loggers :– enables us to query and modify the logging level of our application
  • /metrics :– details metrics of our application. This might include generic metrics as well as custom ones
  • /prometheus :– returns metrics like the previous one, but formatted to work with a Prometheus server
  • /scheduledtasks :– provides details about every scheduled task within our application
  • /sessions :– lists HTTP sessions given we are using Spring Session
  • /shutdown :– performs a graceful shutdown of the application
  • /threaddump :– dumps the thread information of the underlying JVM
How can we create a Custom Endpoint?
It's pretty simple. To get the endpoint, we need a bean. In the below example I have used @Component for this. Also, I decorated the bean with @Endpoint.

Spring Boot 2.x Actuator support CURD model, it supports read, writes and delete operation with the endpoints.The @Endpoint annotation can be used in combination with @ReadOperation,@WriteOperation and @DeleteOperation to develop endpoints.



The path of our endpoint is determined by the id parameter of @Endpoint, in our case, it'll route requests to /actuator/cutomehealthfeature.

Once ready, we can start defining operations using:
  • @ReadOperation – it'll map to HTTP GET
  • @WriteOperation – it'll map to HTTP POST
  • @DeleteOperation – it'll map to HTTP DELETE
FYI,
  • There are no dependencies with MVC
  • All the metadata present as methods before (sensitive, enabled) no longer exists. We can, however, enable or disable the endpoint using @Endpoint(id = “features”, enableByDefault = false)
  • Unlike in 1.x, there is no need to extend a given interface anymore. Earlier our MyEndpoint need to implement Endpoint < List < String > >
  • In contrast with the old Read/Write model, now we can define DELETE operations using @DeleteOperation.
-K Himaanshu Shuklaa..

No comments:

Post a Comment