Spring is an application development framework for Java. But as any developer will tell you, Spring and Spring Boot are more than just frameworks. They have become synonyms for Java because most web-based applications written in Java are based on the Spring framework. This is due to the fact that when it was first introduced in 2003 by Rod Johnson, it brought a much-needed structure to Java projects and made it very easy for anybody to get started with building small and large applications in Java.

Being an open-source project itself, Spring is actively maintained by a dedicated group of developers and Pivotal, the company behind Spring. With so many users, it has grown beyond merely a framework by providing tools for almost everything a developer would need to build, test, and deploy an application. For example, there’s a unit-testing tool built right into the framework, plus libraries offered by Spring for load balancing, service discovery, and more. Companies such as Fitbit, Accenture, Picnic, Intuit, and hundreds of others using Spring and Spring Boot serves as a testament that these are enterprise-grade development frameworks.

However, as Spring was developed when distributed computing was not commonplace, there are some things lacking in the framework that can cause inconveniences when you deploy Spring applications in a distributed setup. Luckily, tools such as Epsagon understand the problem and offer great solutions so that you don’t have to jump ship to another framework or programming language.

Challenges with Spring Boot

As already mentioned, Spring was developed at a time when nobody was thinking about distributed computing. So, when you’re deploying a setup with a bunch of microservices all talking to each other, debugging, and especially checking what’s happening with the help of logs, can become a challenge. 

For example, suppose you have two microservices, one for authentication and authorization, and the other to fetch the profile of a user. Whenever a user lands on the profile page, you want to first check if the user has the authorization to see that page, and if so, then view the profile data. So when you make a call to the profile service, it has to make a call internally to the auth service. This can be easily achieved. But the problem here is, if something goes wrong in either of these two services, it’ll be very difficult to figure out what broke in the chain. This is because each service has its own logs and you can’t make sense of the logs when you’re trying to correlate them across multiple services. 

Tracing the flow of control or the flow of data becomes a challenge with Spring-based applications as the architecture of your projects gets bigger and more complicated. It is not uncommon to see tens of services talking to each other in a production environment, with each service maintaining its own logs, completely unrelated to the logs of other services. So if you want to trace one API call that’s failing, you have to spend a lot of time sifting through the logs of all the services involved for that one particular API call. 

Epsagon provides a solution to overcome this challenge and make debugging such setups easy.

Solution for Troubleshooting Spring Applications by Epsagon

Once Epsagon is integrated into a Spring application, it starts collecting data about each event taking place in the application. This happens with all the applications in your distributed architecture. Because all this data is collected in one place, Epsagon is able to correlate the data and logs collected. So when you’re trying to debug an event or an API call, you can easily see the movement of data between applications.

Epsagon can provide this data via multiple types of visualizations. For example, in the Trace view, you can analyze a graph to find the flow between multiple services. You can even click on a node to view details, including logs. Figure 1 below shows an example of all the nodes in a sample application.

 

Figure 1: Node details in Epsagon

 

Similarly, you can check the timeline view to see when and where data was received and processed. Again, you can also view the corresponding logs and click on a row to see additional info. With the data provided here, you can, for example, easily figure out at a glance where a bottleneck is, which might be causing a performance issue.

Also, in the same row, you can get the details of all the resources at that stage and their values. And because you have the ability to assign custom tags to all resources in your architecture, it becomes very easy to identify and find resources when you’re tracing a call as well.

Because Epsagon is able to collect so much valuable information from your applications, you can easily search for whatever information you need right on Epsagon’s console. Epsagon automatically tags traces with metrics that you may want to filter, for example, calls that resulted in a 400 based on a particular exception type. An example of the filter is shown in Figure 2 below.

 

Figure 2: Trace search feature in Epsagon

 

Along with that, you can even limit these traces based on time. For example, you can say that you want to filter traces in the last three hours only, or in the last week. You can even provide a custom date range. This makes it easy to debug an error even days after it occurred. 

Because Epsagon collects the resources along with the traces, you can additionally visualize all types of parameters you could ever want, giving you an analytics dashboard right within Epsagon. When you go to the Traces page, you’ll see a bunch of charts that give you a lot of information at a glance. The best part is, these are customizable. So you can easily select a resource and visualize it in just a couple of clicks. This is very helpful when analyzing how many calls are erroring out and in finding the error that’s causing most of these failures, etc. Or, if you’re an e-commerce platform, you can easily see how many orders are being placed for a given time period. An example of this is shown in Figure 3 below.

 

Figure 3: Analytics in Traces

 

Integrating Epsagon with a Spring Application

Now that you know how easy it is to search, filter, and trace Spring application logs using Epsagon, it’s time to see how to integrate Epsagon into one. You will need to integrate Epsagon into all applications that you want to trace. There are many ways to do this; for example, you can download the Java library and install it at the system level. But because you’re working with Spring, let’s take the Maven route. You just need to include the Maven dependency in the “pom.xml” file:

<dependency>

     <groupId>com.epsagon</groupId>

     <artifactId>epsagon</artifactId>

     <version>{Epsagon version}</version>

</dependency>

After this, you need to set your tokens as environment parameters:

export EPSAGON_TOKEN=epsagon-token

export EPSAGON_SERVICE_NAME=app-name-stage

And that’s pretty much it. After this setup, you should see the logs being captured in Epsagon from your applications.

Tips and Best Practices

Below is a list of tips and best practices that you can follow to make debugging easier with Spring Boot applications in a distributed setup.

  • Make your logs verbose. For example, make sure you include a proper reason for something that failed. If an external API call failed, log the reason you received from the external service.
  • Make sure you don’t log any personally identifiable information (PII). If you’re dealing with any kind of PII, like email addresses, phone numbers, or any other identification that can identify a person, make sure you don’t log such data, as this could turn into a serious privacy breach. By default, Epsagon gives you the option to upload all or none of the payload data. So, if you do upload payload data, you can skip tags such as passwords or any other PII. All the data you send to Epsagon will be encrypted in transit as well as at rest. Because Epsagon is GDPR-compliant, you can be assured that your data is safe.
  • Include Epsagon in as many microservices as possible. This is important because you want to have all the moving parts up on the dashboard when you’re debugging an issue or trying to find the root cause for a drop in performance. Having Epsagon integrated with all of your services makes it easy to visualize the complete flow.
  • Do not log auth and security tokens. This is in addition to the earlier tip about not logging PII. Tokens are the next best thing to PII data. Even though tokens are encrypted and you can’t easily decrypt them, you do get the authorization to perform some actions if you have access to a person’s tokens. It is never a good idea to have this kind of information logged anywhere.
  • Keep access tokens outside your version control system. This is important to ensure your services are not being used anywhere else or in the public domain. For example, when you’re integrating Epsagon into your application, you get a token from Epsagon that you have to save on your server. It’s always advised to keep this at the specified location on the server rather than in any kind of version control system.

Epsagon with Spring Boot for Easy Tracing

Spring and all of its libraries are almost the best tools for any developer building apps for the web, but adding Epsagon to the mix makes everything you do post-deployment even easier. Seeing all the logs from all of your applications in one place neatly correlated and visualized, with the ability to search through each of them, makes it simple to not only debug an error but also proactively improve the performance of these applications.

Read More

Your Guide for Monitoring AWS Lambda with Epsagon

Troubleshooting Express with Epsagon

DevOps Checklist for Distributed Tracing