Last week a current client called me with an issue on a custom app I built for them over a year ago. I was lucky to remember what the application did, let alone the details of its inner workings. It took less than five minutes to log into the box, find the issue, determine exactly when it had occurred and fix the problem. Literally, 4 minutes, 37 seconds.
The app was instrumented. In this particular instance, it was the most simple kind of instrumentation: exceptions go to the Windows Event Log. This type of instrumentation or logging is required as a bare minimum for any well implemented piece of software. When errors happen, you need to log them; And since there are great toolkits out there for you to use (log4Net) there is no excuse not to. Find a toolkit you like and master it -- it won't take much time.
The hardest part of doing good instrumentation is getting started. Once the framework is in place, everything after that is easy. The best way to get started is to pick one piece of information that you really need to know and get instrumentation working around that single point of data. Because I always like to know who's on the system, I normally start with user log-ons and log-offs. By logging each time a user logs on and logs off, I can spot traffic patterns and potential application load issues. I can also report back to clients on how many people are using the system; clients love that kind of hard data as it helps them justify the cost of developing the application in the first place.
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment