It's been a while since my last blog post and I think it's time to write a new one. Some days ago we had the situation of too many useless successful live- and readyness check messages in our application logs as well as in Kibana and we didn't want to filter these logs afterwards in Kibana, so we decided to implement a filter in our application to get rid of these logs as early as possible and log errors, only. There isn't much in the web about it, so I decided to write this blogpost. Maybe it's useful for others as well.
What's the problem?
In our OpenShift Logs there are tons of log messages like these:
127.0.0.1 - - 09/Jun/2021:16:07:07 +0200 "GET /q/health HTTP/1.1" 200 46 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0
As much as I like that the application is healthy, messages like these are not useful. They blow up the log files and you always have to filter these messages in Kibana to see the really interesting logs.
That's why we want to filter these messages.
How did we do that?
First you have to add three entries to your application.properties file:
The first entry enables the Quarkus internal access logging, the second one declares the name of the logging category which is the same as the loggers name and the last entry is a standard format which is also used by Apache Tomcat (see).
By doing this, the application starts printing access logs. You can test it by calling the /health endpoint of your application.
After enabling the general access logging we have to add the filter itself. This can be done by adding a filter to the existing
logging category. The name of the logger has to be the same as declared in the applications.properties file.
As you can see here in the initAccessLogFilter() method, we get the Logger with the same name
as the quarkus.http.access-log.category=access_log entry in the applications.properties file.
In the next step we set a filter which filters every log entry with a http status code of 200 and containing the health, health/live, health/ready or metrics endpoint.
Conclusion
By adding this handler you can get rid of these non helpful successful access log entries. Unfortunately you don't find much in the web to do this, so I wanted to write this blog post.
Hope this blog post is useful for someone and you learned something new :-)
Bye,
Bennet
Be Social, Share!