In many cases, it's best not only to detect
and catch exceptions but to log them as well. For example, some
problems may occur only when your web server is dealing with a
particularly large load. Other problems might recur intermittently,
with no obvious causes. To diagnose these errors and build a larger
picture of site problems, you need to log exceptions so they can be
reviewed later.
The .NET Framework provides a wide range of logging
tools. When certain errors occur, you can send an e-mail, add a
database record, or write to a file.
|
In many cases, it makes sense to use more than one
logging technique. For example, you may decide to log the majority of
your errors to an ErrorLog table in a database but log database errors
to another place, such as the Windows event log.
|
|
One of the most fail-safe logging tools is the Windows event logging
system, which is built into the Windows operating system and available
to any application. Using the Windows event logs, your website can
write text messages that record errors or unusual events. The Windows
event logs store your messages as well as various other details, such
as the message type (information, error, and so on) and the time the
message was left.
1. Viewing the Windows Event Logs
To view the Windows event logs, you use the Event
Viewer tool that's included with Windows. To launch it, begin by
selecting Start =>
Control Panel. Open the Administrative Tools group, and then choose
Event Viewer. Under the Windows Logs section, you'll see the four logs
that are described in Table 1.
Table 1. Windows Event Logs
| Log Name | Description |
|---|
| Application | Used
to track errors or notifications from any application. Generally,
you'll use this log when you're performing event logging, or you'll
create your own custom log. |
| Security | Used to track security-related problems but generally used exclusively by the operating system. |
| System | Used to track operating system events. |
| Setup | Used to track issues that occur when installing Windows updates or other software. |
Using the Event Viewer, you can perform a variety of
management tasks with the logs. For example, if you right-click one of
the logs in the Event Viewer list you'll see options that allow you to
clear the events in the log, save the log entries to another file, and
import an external log file.
Each event record in an event log identifies the
source (generally, the application or service that created the record),
the type of notification (error, information, warning), and the time
the log entry was inserted. To see this information, you simply need to
select a log entry, and the details will appear in a display area
underneath the list of entries (see Figure 1).
You can also review event logs in Visual Studio,
unless you're running the slightly less powerful Visual Studio Web
Developer Express edition, which doesn't include this feature. First,
display the Server Explorer window (if it's not already visible) by
choosing View =>
Server Explorer. (The Server Explorer window usually appears at the
left side of the Visual Studio window, where it shares space with the
Toolbox.) Using the Server Explorer, expand the Servers => [ComputerName] =>
Event Logs group to see a list of event logs on your computer. This
list is a bit longer than what you saw in the Event Viewer, because it
includes both the Windows event logs you saw and custom event logs for
specific applications .
If you expand an event log in the Server Explorer
window, you'll find all the event log entries, grouped according to the
source that made the log entry. Figure 2
shows some of the event logs left in the Application log on the current
computer by the event source .NET Runtime Optimization Source. Once you
select a log entry, you can view its specific details (such as the
event log message and the time it was left) in the Properties window.
One of the potential problems with event logs is
that old entries are automatically discarded when the event log reaches
a maximum size (by default, 20MB). However, you'll find that logs grow
quickly. That means that unless you're using a custom event log that
has lots of space, your log entries might not last for a long period of
time. Ideally, you should use event logs to record information that is
reviewed and acted on over a relatively short period of time. For
example, event logs are a good choice if you plan to log application
errors and review them to diagnose strange behavior immediately after
it happens. Event logs don't make as much sense if you want to get a
detailed picture of application activity six months later, because
Windows (or someone else) may delete old log entries. In this scenario,
a custom database makes more sense.
If you want to add a little more breathing room to
an existing log, you can change its maximum size. To do so, right-click
the log and choose Properties. You'll see the Application Properties
window shown in Figure 3, where you can change the maximum size.
|
You can increase the log size, but you
really shouldn't disable automatic log deletion altogether, because you
could end up consuming a huge amount of space over time if information
isn't being regularly removed. |
