When I was preparing one of my Spring Boot projects to go live, I faced with the problem how to get notified about the errors that might appear in the production environment. Based on my Android development experience I tried to find something like Crashlytics — you just put a simple dependency in the application, put the access key in configuration, all errors are reported to their backend and you get notified by email or by push notification on your mobile phone. I found literally nothing!

How to get notified about the errors that might appear on production environment?

I was asking friends who were Java Developers about the similar solution, but they didn’t hear about anything like this. At the end, it appears that there is no such solution on the market and the error notifications are handled in the other way that I thought. Seems that all the errors are reported in application logs and there are a different set of tools to detect and report them.

I was looking for some solutions to parse logs and first what I found was Logstash from ELK stack (Elasticsearch-Logstash-Kibana). It’s a service that may have many inputs (e.g. log files), filter or transform them in the way you want and then pass them to the specified outputs. Furthermore, it can be configured using a single file with really simple syntax, so getting started with this tool was really quick. I decided to give it a try — I created a configuration file pasted below and it works really well until now.

Little explanation

The configuration takes a Spring Boot app log file as an input. Then we filter those messages to have only those which contains stack traces. Then they’re sent via email, using the email output plugin — of course, you need to provide all data required to connect to mail server.

In order to make this configuration work, you need to install email output plugin, as it’s not bundled in default Logstash installation. The plugin installation is quite easy —guide can be found here.

Extension points

The script I put above can be quite easily extended. For example:

You can add more log files or other inputs with the same message format to aggregate errors from more sources. My production usage analyzes 3 log files (each with different type value in input definition) and then the email subjects use this type variable, so I know which app reported an error. Adding new output could additionally store sent errors somewhere else to build some kind of event log or if you’re afraid that the email might not be delivered.

Questions?

I didn’t want to dive into configuration file details too much here, so if you have any specific question how it works or why some specific line is there, please write your question in the comments — I’ll reply as soon as I can.