Navigating Spring Boot Monitoring: Solving the “DOWN” vs “UP” Dilemma

Introduction:
In the realm of microservices and Spring Boot applications, monitoring plays a pivotal role in ensuring system health and performance. To this end, we rely on the robust capabilities of the Spring Boot Admin Server — a central piece of our monitoring infrastructure.

However, sometimes even the most sophisticated monitoring tools can encounter unexpected issues. In this blog, we will delve into a specific problem we encountered and the innovative solution we implemented to tackle it.

Spring Boot Admin Server

The Spring Boot Admin Server is a vital tool in our arsenal. It is designed to provide real-time insights into the status and performance of our microservices. With a user-friendly interface, it offers a comprehensive overview of the applications in our ecosystem, their health, and other essential metrics. The Spring Boot Admin Server utilizes the actuator endpoints of our applications to gather this crucial information.

The Problem: “DOWN” or “UP”?
Our journey begins when we observed a puzzling issue with our Spring Boot Admin Server. This tool is instrumental in monitoring the status of our applications. Yet, it displayed applications as “DOWN” when, in fact, their actuator endpoints reported them as “UP.” Naturally, this misalignment raised concerns.

Understanding the Issue
Upon investigation, we uncovered the root cause of this inconsistency. In our application, we use the “context-path” configuration to modify the base path for accessing APIs. This means that our API access URLs differ based on whether the “context-path” is defined.

For instance:
- Without “context-path” the API is accessible at: http://www.exampleurl.com/testApi
- With “context-path” set to “custom” the API is accessible at: http://www.exampleurl.com/custom/testApi

The Spring Boot Admin Server utilizes the actuator endpoint to monitor applications. However, it does not account for the “context-path” when determining the actuator endpoint URL. This inconsistency leads to the Spring Boot Admin Server making calls to incorrect URLs, causing the status mismatch.

The correct actuator endpoint URL should be http://www.exampleurl.com/custom/actuator, but Spring Boot Admin Server uses http://www.exampleurl.com/actuator.

Resolving the Monitoring Mismatch
To address this issue, we explored multiple solutions. Two primary options emerged:

Solution 1: Utilize the SimpleDiscoveryClient to specify the actuator endpoint in Spring Boot Admin Server. While this approach is effective, it requires manual addition of endpoints for each application. Moreover, it may not align seamlessly with the dynamic nature of Kubernetes networking.

spring:
  cloud:
    discovery:
      client:
        simple:
          instances:
            backend-service:
                - uri: http://localhost:9090
                - uri: http://192.168.110.50:8080
            user-service:
                - uri: http://localhost:9999
                - uri: http://192.168.110.40:8888

Solution 2: Employ a separate port for the actuator endpoint. This choice proved to be the most suitable remedy. Unlike Solution 1, it does not necessitate future changes in the Spring Boot Admin Server or the application. It’s a one-time setup that ensures accurate monitoring.

management.server.port=8081

The Path Forward: A Seamless Monitoring Experience
With Solution 2 in place, we have achieved a seamless and accurate monitoring experience. The Spring Boot Admin Server now uses distinct ports for actuator endpoints, eliminating any confusion caused by context paths. This approach aligns perfectly with the dynamic nature of our Kubernetes infrastructure, ensuring that monitoring remains efficient and hassle-free.

As we continue to navigate the ever-evolving world of microservices and Spring Boot applications, we remain committed to finding innovative solutions to challenges that arise along the way. Our journey is a testament to the power of problem-solving and adaptability in the pursuit of operational excellence.

In conclusion, monitoring discrepancies can be resolved with creative solutions, and in our case, simplicity triumphed. By addressing the context path issue, we’ve ensured that our Spring Boot applications are consistently shown as “UP” on the Spring Boot Admin Server, allowing us to focus on what matters most — delivering reliable and high-performing services to our users.