A while back I was reading, with great interest, an article by Muthusamy Anantha Kumar (aka "The MAK") about how to monitor the Event Logs of one or more Windows servers. You can find the article at http://www.databasejournal.com/features/mssql/article.php/3310611.
Ever since my days as an enterprise DBA, I've always been interested in techniques and processes that help a single person manage and monitor many resources. This article is a great discussion of two techniques that can help you get closer to that goal.
The MAK lays out two basic approaches to accomplishing this task. First, he presents a Visual Basic approach that reads all the servers listed in a text file, executes a VB program against them to extract the Event Log details, and the collects them into a CSV file. This approach is OK, but for my purposes it lacks two things. First, you'll have to do all the analysis yourself on the CSV file to determine any information of value. Second, it's all a mystery to those who are clueless about VB-- like many of us dyed-in-the-wool DBAs.
The MAK's second approach, which I'll call Method Two, is much more to my liking. With Method Two, you're provided a Transact-SQL script to create all the tables, alerts, and events you need to configure this solution as a much more SQL Server-centric solution, as well as another big VB script. Since I have a strong bias for doing as much work as possible, if not everything, inside of the SQL Server, I vastly prefer Method Two. Another advantage of Method Two is that you can use good ol' SQL queries to pull back your Event Log results. That means easy customization and even automation using DTS.
The only thing that Method Two lacks, IMO, is an 'SP_ADDTASK' script for both collections and reporting that gets you up and running with a fully automated monitoring system.
What do you think of this article?
