If your IT shop does software development, Application Logging is useful for several things:
- Knowing who uses an application and how often. This has two immediate benefits.
- Easily create email lists of users for application-specific communications (changes, outages)
- Identify which applications are not being used.
- Understanding outage situations better.
- Debugging (see the caveat at the end of this article).
WARNING: It is very easy to over-complicate all this. Don’t. You probably will have a hard time implementing this with your other IT priorities, so start small and simple.
Consider these requirements for application logging. It is possible to add more complexity, but I think these are a good balance between simplicity and functionality. You can always add more functionality down the road.
- The end user should see no failure or UI delay in the logging system. Ever.
- Basic usage logging includes
- Unique user id (username, email address, etc.)
- Application name. Version number is helpful if you have it.
- Date/time.
- Put the logging information into a location, preferably a database, that makes it easy to report.
- Think about how much logging data you want to keep and for how long.
The simplest design is a common routine that all your applications can call. Web services are the best in today’s world, but anything that all your development platforms can call is fine. Implement a single call with the needed parameters. The call must (1) always return and (2) never throw an error.
Implement the logging function and start using the data. Instead of guessing who is using an application, you will know. Start removing inactive applications.
A quick caveat to my “keep it simple” advice: if you add a single text field (I recommend calling it Notes), you can then put a second layer of logging into the system. The same app can call the logging routine several times with extra information in the Notes field. Simple Excel filters and pivot tables will let you analyze this information. Use this sparingly for debugging intermittent problems. Remember to remove that debug logging from the calling program when done — you don’t want to add to your technical debt.