Discussion Locked

Monitor an application's pulse with EventLog

0 helpful
1 reply
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

This week's .NET e-newsletter describes how to monitor an application's pulse with EventLog. If you already use EventLog, what do you think of the class? If you don't use EventLog, do you think you might after reading this article?

If you aren't subscribed to the .NET TechMail, visit our e-newsletter subcenter to subscribe to this free e-newsletter:
http://nl.com.com/MiniFormHandler?brand=bu ilder&subs_channel=bldr_front_door&list_id=e605& ; ;;;tag=fb

* Please delete any extra spaces that appear when you paste this link into your browser.

1 reply

by maryweilage

Note from the editor: We received the following reader comment via e-mail about this week's .NET e-newsletter.

The article is very good. There is however one important caveat to the practical use of the class. The first write to the log must be by a user that is a member of the administrator
group for the machine. Thereafter, any user can write to the log.

For windows apps, this is not a very serious problem. For web apps, this is a significant problem as the ASPNET user (Windows 2000) or Network Service (Win 2003) should
have minimum priviledge. I solved this by creating a minimal Windows app to run by an Admin (me!).

Six other observations from my experiance:
1) After having created a new log, close the event viewer and re-open it as there is no refresh on the list of event queues.
2) Once the event log is visible in the event viewer, set its properties to overwrite events as needed and increase its size to at least 2048 K.
3) In many application areas, the name of the event log needs to be configurable so that you can have different log names for testing and live.
4) You need some means of writing a test message from your application, especially if the log name is configurable.
5) As event entries can be info, warning or error, a configurable verbosity setting is useful. At the tersest, only errors are written to the log.
6) I found it best to wrap the event log writing into subroutines contained within a common class. In doing this, I was able to include code that logs which form and routine within the form made the call. For errors if running in debug mode,
it also extracts the line number from which the error was called.

This gives code along the following lines:

Dim xCommon As New CommonLibrary
Dim sMethod As String = System.Reflection.MethodInfo.GetCurrentMethod.Name
Dim sPage As String = Request.ServerVariables("SCRIPT_NAME")
Try
xCommon.WriteEventLogInfo(sPage, sMethod, "Routine entered!")
If SomeDetectableError Then
xCommon.WriteEventLogWarning(sPage, sMethod,"Detected some error!")
End If
' More code
Catch xError As Exception
xCommon.WriteEventLogError(sPage, sMethod, xError, _
"Optional extra debug info!")
lblError.Text = "An error has occurred. Please contact support"
End Try

This discussion is closed to new replies.