3. The other data sources
Up until now, we’ve
discussed how to configure a performance counter data source and how to
enable the trace listener in the web.config file. Now let’s look briefly
at the other data sources that are configured in similar ways.
Crash Dumps
Crash
dumps are the log file of last resort. They aren’t really a log file,
but a dump of the status of the computer when a horrible problem has
arisen. There are two types of crash dumps. The normal dump includes a
copy of all the memory on the machine. The mini dump holds only the most
important information, without a complete copy of everything.
If you’re running a web
application, ASP.NET should handle any errors that aren’t handled by
your application (in code or in the global.asax). A crash dump usually
occurs only during a truly catastrophic error. When your code is running
in a worker role, without the soft embrace of ASP.NET, you’re likely to
see these dumps more often.
Crash dump files are stored
in the local data buffer and transferred with the common logs. You can
choose which size dump you want by passing in true to the Enable-Collection or EnableCollectionToDirectory method for a full dump and passing in false for a mini dump.
IIS Failed Request Logs
The
failed request logs for IIS are a new feature in IIS 7. IIS tracks log
data for requests as they come through, but keeps the data only if
certain configurable conditions are met. A condition for keeping the log
data might be that a response takes too long to complete the request.
If the response is completed fast enough, then the log buffer is
flushed. You can configure how IIS manages this process in the tracing section of the system.webServer
part of your web.config. After you configure failed request tracing for
IIS in this way, the logs are collected with the rest of the data logs.
Windows Event Logs
Windows event logs can
provide important clues to serious problems with your applications. Some
applications create custom event log sources for their own logging. The
diagnostic agent in Azure can collect these logs and transfer them to
storage for you.
You need to subscribe to
the event data that you want to receive using an XPath expression.
Because of the security profile your processes run on, you won’t be able
to read the security windows event log. If you add this log to your
configuration, nothing will be logged, and it won’t work correctly until
you remove it.
To capture Windows event logs, you can use the following expression:
diagConfig.WindowsEventLog.DataSources.Add("System!*");
This code grabs everything from the Windows System Event log, which is where you usually want to start your investigations.
4. Arbitrary diagnostic sources
Windows Azure Diagnostics covers a
lot of the diagnostic sources you might use to troubleshoot an issue
with your system. It covers IIS logs, performance counters, Windows
event logs, and several other things. Over time, you’ll probably devise
your own diagnostic source; maybe a log you’re creating that you need to
track. Perhaps this is custom billing data, or a compressed log of the
images used in production, or it might just be the output of a
third-party logging framework you’ve chosen to use.
The agent can transfer anything
you want. All you need to do is get that data into a file in a
designated folder. When you configure the agent, you tell it which
custom directories you want it to monitor. You need to configure some
local storage and then write your log files to it.
Each data source has a
configuration class that you add to the agent’s configuration, and
custom log locations aren’t any different. We’ll use the DirectoryConfiguration
class to tell the agent to monitor a folder. You can set how large that
directory is allowed to become, as well as scheduled transfer
characteristics, as shown in the following code:
Windows
Azure Diagnostics is a powerful tool you can use to help troubleshoot
and diagnose problems. But it isn’t just for problems, as we’ve
discussed; you can also use it to help monitor the behavior of the
system, or the actions of your users. Although Windows Azure Diagnostics
is wonderful, it’s only a source of data. You still need to analyze the
data to turn it into information, and then take action. Sometimes the
action you need to take is to change the configuration of the service
model you’re running your application in. For example, you might need to
add some instances to respond to a spike in traffic. Regardless of the
result of your analysis, you’ll need to store the data you collect in
Azure storage to be able to use it. To do this, you use transfers.
