Every non-trivial application today has its own logging or tracing functionality. Needless to say that logging is often vital in all development cycles of software development, starting from very early prototyping and development and all the way to the field support and maintenance. Logging gives us a view into the system behavior in various circumstances, it can tell a story of what happened and why. It has faces. And we’ve built a product to show them to you.
Why again?
There are plenty of articles, case studies and myriads of frameworks which deal with the subject on the API level. I am not going to describe here the importance and need for good logging infrastructure in well built application. The purpose of this article is to take you from the scope of single application to the scope of software product, which often is a set of applications running on multiple hosts and processes. The idea is to climb one step above single process or host and look at log from enterprise level.
We all know how to do logging – take log4j from Apache as an example; it’s absolutely fantastic framework with incredible flexibility, vast feature set, impressive performance and large audience of users and projects which only grows day after day.
But
API’s such as log4j are relatively low level frameworks giving a programmer tools for tracing log statements and saving (or sending) them to various targets – disk, console, sockets, databases or even instant messengers and rss feeds. Their scope is on the application level mostly limited to single application. Sure, using log4j one can build a framework which deals with log on an enterprise level; after all the tooling is available – just pick up a keyboard and make your own logging system. I worked on many projects and on every single one of them I had to build some logging system. Yes, these are trivial and boring things – managing log files, backing, rolling them up, allow searching through them, have them available for troubleshooting, hooking to an application at real time to observe its logging stream, etc. Very often logging is not taken seriously because it’s a non-functional requirement in majority of the systems. Having log4j you can just jot the logging statements anywhere you like, fix your issues and move on. But when system grows to larger scales, things are getting more complicated and these jotted log statements become useless. I’ve seen many times when end users simply raise severity levels to ERROR in order to get rid of annoying flood of log.
To the point
Having said all this, I would like to show you a solution which can solve many of these problems, and particularly to free you from building your own logging system while focusing on your functional requirements. Don’t reinvent the wheel. LogFaces is created to be an out-of-the-box log server which can be easily hooked with existing applications using log4j as their logging framework. "Off the shelf" is the major feature – you simply install it next to your system and redirect your appenders to logFaces server; it works with TCP or UDP sockets – both well supported by log4xxx. It’s up to you whichprocesses, hosts or even classes should be working with logFaces server – thanks to log4xxx configuration magic, all this is very simple and not intrusive.
Imagine that…
Imagine that you are dealing with multi-host system which needs to be tested in QA. It could be a lot of data. LogFaces can partition this data for you and set you focused on particular aspect. For example, I want to see only presentation tier related activities in correlation with what is going on in data layer. LogFaces viewer provides such capability; it’s called log perspective. Perspectives allow you to focus on particular application on particular host or even packages and classes. And all this can be done without touching you production code.
Aggregate
LogFaces being an aggregator works with database. Sure you can have each application manage its own rolling file appender, or even create a smart appender which merges several applications into one log file. But this requires effort, may be small, and may be not. And again, in the next development this same activity will have to be done again. In logFaces we aggregate logging events into database automatically. You can specify what should be saved and how long the data should be kept. For instance, you can set it up to ensure 7 days of log data from particular applications while ignoring others. You can keep only severe log – this is good when system is stable; or you can keep debug information as well in order to allow developers to fix the issues. And of course there are plenty of queries which can be done on this data. It’s quick and to the point. For example, just one click will give you list of errors from particular package in the past hour. Having that, you can drill down and see what exactly happened at this time point. Particularly interesting is the feature of creating log files – instead of having each application maintain its own policy for log files, you can create them from logFaces storage and have it formatted as you like. Log files creation can also be scheduled and sent to email recipients – this is very good for receiving daily report of problems.
Route
Not only persisted, same data received from applications is also dispatched to clients. Routing is done in real-time and can be very fine tuned by each client separately. For instance, QA people can observe their system under test while integrators or developers can see what happened in theirs. All are separate, not colliding. Clients can be very remote; you can be in the office while looking how your system is doing on site.
It can be small
LogFaces isn’t necessarily for large systems. It can easily work with smaller applications as well. If you don’t need persistence and only need routing capabilities – no problem, database can be disabled. Some of our users having logFaces only for viewing log in real time. Being very network friendly, you can see the log streams coming from different continents into your viewer.
Not only Java
As you know, log4j has implementations for several platforms, it’s not only Java. There are .Net, C, C++ and even Python libraries. The great thing about log4j architecture is its appenders. It doesn’t really matter for logFaces which platform you application is working on as long as it sticks with log4j events schema. At the end everything is getting aggregated, partitioned and ready for you in uniform views.
What it is not
LogFaces is not log analysis tool; it’s not going to recognize patterns of behavior or detect symptoms of problems. There are mature and competent products doing just this. The output from logFaces can be an input for those clever tools.
Come and try it yourself, it’s free for 30 days and is very easy to set up.
No Comments Found