15.1 Logging in a Web Application

The importance of logging has been evident to experienced developers for many years. Arguably, logging can be as important a part of your framework as exception handling or even security, both of which may rely on logging functionality to help carry out their responsibilities. Without logging, application maintenance can become a nightmare for the developers. We all know that all "real" applications periodically go through maintenance cycles.

Still, you may wonder whether logging in web applications is as necessary and important as logging in other types of applications. Because web applications can sometimes be smaller and less complex than their enterprise counterparts, you might think that logging is less important in these applications. However, with nontrivial web applications, this is not the case logging is just as critical there as it is in an enterprise application.

System Versus Application Logging

Log messages can be arbitrarily broken down into two categories: system messages and application messages. System messages have to do with the internal operation of the application, rather than something specific to a user or data for example, a system message might indicate that the application is unable to send an email because the SMTP host is not responding. On the other hand, an application message might indicate that the user "Jane Doe" tried to submit a purchase order that was above her company's credit limit.

The system message in the first case might be logged with a priority of "error," whereas the application message might only get a priority of "info." We can then set up the logging environment so that "error" messages generate an email or a pager message to the system administrators for immediate attention, while "info" messages go into a file for later auditing.

The different types and categories of log messages are typically used for different purposes across organizations. Although many applications may log messages with the priority of "error," what's an error to one organization may just be a warning to another. There's not a great deal of consistency across organizations, and there may never be organizations have different priorities, and what's critical to one may not necessarily be critical to another.

In this chapter, we generalize the discussion of system versus application messages. Because views of what's considered an error differ, there's no general way to specify what's an error, a warning, or just general information for your particular application. That's a decision that you, your development team, and your product-management group will have to make. We'll keep our discussion at a higher level and not focus on these issues.