Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Simple Spring Boot Admin Setup

DZone's Guide to

Simple Spring Boot Admin Setup

Take a look at how to setup Spring Boot Admin, a handy way to monitor your Spring Boot applications! You won't want to miss this if you're a Spring Boot user.

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

Spring Boot Admin is a cool dashboard for monitoring your Spring Boot applications. However, setting it up is not that trivial. The documentation outlines two options:

  • Including a client library in your boot application that connects to the admin application – this requires having the admin application deployed somewhere public, or at least reachable from your application, and also making your application aware that it is being monitored.
  • Using cloud discovery, which means your application is part of a service discovery infrastructure, e.g. using microservices.

Both are not very good options for simpler scenarios like a monolithic application being run on some IaaS and having your admin application deployed either on a local machine or in some local company infrastructure. Cloud discovery is overkill if you don’t already need it, and including a client library introduces the complexity of making the admin server reachable by your application, rather than vice-versa. And besides, this two-way dependency sounds wrong.

Fortunately, there is an undocumented, but implemented SimpleDiscoveryClient that let’s you simply run the Spring Boot Admin with some configuration on whatever machine and connect it to your Spring Boot application.

The first requirement is to have the Spring Boot actuator setup in your boot application. The Actuator exposes all the needed endpoints for the admin application to work. It sounds trivial to setup – you just add a bunch of dependencies and possibly specify some config parameters and that’s it. In fact, in a real application it’s not that easy – in particular regarding the basic authentication for the actuator endpoints. You need a separate Spring-security (in addition to your existing Spring-security configuration) in order to apply basic auth only to the actuator endpoints:

@Configuration
@Order(99) // the default security configuration has order 100
public class ActuatorSecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Value("${security.user.name}")
    private String username;

    @Value("${security.user.password}")
    private String password;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(User.withUsername(username).password(password).roles("ACTUATOR","ADMIN").build());

        http.antMatcher("/manage/**").authorizeRequests().anyRequest().hasRole("ACTUATOR").and().httpBasic()
                .and().userDetailsService(manager);
    }
}

This is a bit counterintuitive, but it works. Not sure if it’s idiomatic – with Spring security and Spring Boot you never know what is idiomatic. Note – allegedly it should be possible to have the security.user.name (and password) automatically included in some manager, but I failed to find such, so I just instantiated an in-memory one. Note the /manage/** path – in order to have all the actuator endpoints under that path, you need to specify the management.context-path=/manage in your application properties file.

Now that the actuator endpoints are setup, we have to attach our Spring admin application. It looks like this:

@Configuration
@EnableAutoConfiguration
@PropertySource("classpath:/application.properties")
@EnableAdminServer
public class BootAdminApplication {
    public static void main(String[] args) {
        SpringApplication.run(BootAdminApplication.class, args);
    }

    @Autowired
    private ApplicationDiscoveryListener listener;

    @PostConstruct
    public void init() {
        // we have to fire this event in order to trigger the service registration
        InstanceRegisteredEvent<?> event = new InstanceRegisteredEvent<>("prod", null);
        // for some reason publising doesn't work, so we invoke directly
        listener.onInstanceRegistered(event);
    }
}

Normally, one should inject ApplicationEventPublisher and push the message there rather than directly invoking the listener as shown above. I didn’t manage to get it working easily, so I worked around that.

The application.properties file mentioned about should be in src/main/resources and looks like this:

spring.cloud.discovery.client.simple.instances.prod[0].uri=https://your-spring-boot-application-url.com
spring.cloud.discovery.client.simple.instances.prod[0].metadata.user.name=<basic-auth-username>
spring.cloud.discovery.client.simple.instances.prod[0].metadata.user.password=<basic-auth-password>
spring.boot.admin.discovery.converter.management-context-path=/manage
spring.boot.admin.discovery.services=*

What is that doing? It’s using the SimpleDiscoveryClient that gets instantiated by the autoconfiguration. Actually, that client didn’t work until the latest version – it threw NullPointerException because the metadata (which handles the username and password) was always null. In 1.2.2 of the cloud-commons they fixed it:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-commons</artifactId>
    <version>1.2.2.RELEASE</version>
</dependency>

The simple discovery client is exactly that – you specify the URL of your boot application and it fetches the data from the actuator endpoints periodically. Why that isn’t documented and why it didn’t actually work until very recently – I have no idea. Also, I don’t know why you have to manually send the event that triggers discovery. Maybe it’s not idiomatic, but it doesn’t happen automatically and that made it work.

As usual with things that “just work” and have “simple setups” – it’s never like that. If you have something slightly more complex than a hello world, you have to dig some obscure classes and go “off-road.” Luckily, in this case, it actually works, rather than needed ugly workarounds.

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:
spring ,java ,tutorial ,spring boot

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}