From the very beginning, the central idea behind the Spring Boot Admin project (SBA) was to provide a handy admin interface for the managing and monitoring of Spring Boot applications. Spring Boot Admin stands out in its beautiful and user-friendly UI, which is built on top of Spring Actuator endpoints. This gives access to all required operational information such as application health status, CPU and memory metrics, JVM startup flags, an application classpath, application metrics, HTTP traces, and audit events. It also makes it possible to inspect and delete active sessions (using spring-session), manage log levels, make thread and heap dumps, and so on:
In general, Spring Boot Admin is designed to help operate on microservice applications. Also, Spring Boot Admin consists of two parts:
- The server part. The server acts as a central point of gathering information from all available microservices. Also, the server part exposes the UI through which the gathered information is displayed.
- The client part. This part is included and runs within each service in the system and registers the host service to the Spring Boot Admin server.
Even though the server part of Spring Boot Admin was designed to be a standalone application (recommended configuration), it is possible to assign this role to one of the existing services. To give a service Spring Boot Admin server a role, it is enough to provide the application with the de.codecentric:spring-boot-admin-starter-server dependency and add the @EnableAdminServer annotation to enable the required auto-configuration. In turn, to integrate all neighboring services with the Spring Boot Admin Server, they may include the de.codecentric:spring-boot-admin-starter-client dependency and point to an SBA server, or SBA may leverage a pre-existing Spring Cloud Discovery infrastructure based on Eureka or Consul. Alternatively, it is possible to create a static configuration on the SBA server side.
SBA Server also supports cluster replications, so an SBA Server should not be a single point of failure in the highly-available Microservice application:
In the case, when the Spring Boot Admin's dashboard is correctly configured, it contains a mesh of services with the number of registered instances. In turn, each service in the mesh shows its health status, so we may easily understand the whole state of the system. Moreover, it supports push notifications for browsers such as Slack, Hipchat, Telegram, and others, so it may proactively inform the DevOps team about a substantial change within the application infrastructure or it may even be a part of the Pager Duty infrastructure.
Before Version 2.0, as any Spring-oriented add-on, Spring Boot Admin was based on the Servlet API. This meant that both client and server applications were based on blocking I/O that might be inefficient for a high-load reactive system. With 2.0, an SBA server was rewritten from scratch to benefit from Spring WebFlux and do all communications over async non-blocking I/O.
Of course, Spring Boot Admin gives options for adequately securing the SBA server UI as it may expose some sensitive information. Spring Boot Admin also provides integration with a Pivotal Cloud Foundry. In a case in which a Spring Boot Admin Server or client detects the presence of the Cloud Platform, all necessary configurations are applied. Consequently, the clients and the server discovery are simplified. Likewise, an SBA has an extension point, so it is entirely possible to add the desired behavior to an SBA infrastructure. For example, this may include a management page that features toggles or custom auditing.
To summarize, Spring Boot Admin gives an excellent opportunity for a DevOps team to easily monitor, operate, and evolve a reactive system using a handy and customizable UI, and we're going to do this with all the benefits of async non-blocking I/O.