匯出 (0) 列印
全部展開
本主題尚未接受評分 - 為這個主題評分

On-Premises Diagnostic Models

更新日期: 2011年10月

Author: http://msdn.microsoft.com/zh-tw/library/hh307529

參考影像

Learn more about RBA Consulting.

Summary: This article discusses the diagnostic options that are available in Windows Azure, and provides strategies and best practices that you can adopt when you instrument your applications.

Typically, Windows Azure applications perform many critical diagnostic tasks. Some tasks collect performance metrics that will help you to plan for capacity. Other tasks may help you to troubleshoot your application, or to detect problems. You may also need to collect diagnostic data in order to bill customers, and audit users. Diagnostics in cloud applications differ from those in on-premises applications because of the different environments in which the applications operate. It is important to understand how cloud applications differ from traditional on-site applications when you implement diagnostics for Windows Azure applications. This article explains the available diagnostics options in Windows Azure, and provides strategies and best practices that you can adopt when you instrument your applications.

On-Premises Diagnostic Models

On-premises applications operate in static environments. In particular, single-server environments provide a high level of predictability. The servers' location and behavior is well understood. They are usually racked, and located within a data center. Developers know that the server will always be there, and that the local transactions are traceable. The infrastructure for the servers provides either physical or remote access, where locally available data and installed tools can be used to diagnose the application. In addition, developers can perform configuration changes that take immediate effect. The diagnostic models for on-premises applications are based on the characteristics of this type of environment. To instrument an application, you can rely on existing, well-understood APIs. For example, you may use the classes that are included in the System.Diagnostics namespace. Other applications may add layers of abstraction, and use logging frameworks such as the Logging Application Block in the Microsoft Enterprise Library. Regardless of the logging solution, the logging data is always stored on either the server or the network. The data can be stored as a custom flat file, or in a Windows event log. In some cases, other applications that your application depends on may do the same type of logging, and offer additional diagnostic information. On-premises applications can initially be configured with minimal logging levels. If there are problems, these levels can be increased immediately to provide more detailed diagnostic information.

Challenges with Diagnostics in the Cloud

Windows Azure applications operate in a much different environment than on-premises applications do because the cloud is dynamic and elastic. It is an inherent feature of the cloud that your application, in order to scale, will run on multiple virtual machine instances. Requests do not have instance affinity, so transactions are distributed across these instances. Diagnostic data is distributed to each instance's local storage, where it is buffered. The data is only as durable as the lifetime of the instance. Some exceptions, configuration changes, and hardware failure can cause an instance to recycle, which deletes any data stored in that instance's local storage.

With Windows Azure 1.3 (and later), you can now use Remote Desktop to access Windows Azure instances. However, it may not be feasible or efficient to do this. If an error occurs in an application with multiple instances, you must guess which instance to access in order to view the log. This may mean that you must examine every application instance. Also, you cannot use Remote Desktop to view aggregate diagnostic data, such as performance counters, because you can only connect to one instance at a time. Remotely accessing an application also uses up resources, and can harm the application's performance.

Introduction to the Windows Azure Diagnostics Monitor

The Windows Azure diagnostic monitor solves the challenges of persistence and aggregation. It allows you to use familiar logging classes, and to instrument your application according to a standard model that does not introduce any new patterns into your application. Classes such as those in the System.Diagnostics namespace can be used directly to produce trace messages, or performance metrics. The diagnostic monitor can also be used indirectly, with logging frameworks. In other words, the Windows Azure diagnostic monitor allows you to use the logging patterns that you are familiar with from on-premises applications to produce diagnostic data for your cloud-enabled application.

How the Diagnostics Monitor Works

When a Windows Azure role starts, it launches the diagnostic monitor process MonAgentHost.exe. This process is separate from the process that runs roles. That process can be either WaWebHost.exe if the role runs under Hosted Web Core mode, or WaIISHost.exe and w3wp.exe if the role runs under Full IIS (Internet Information Services) mode. The diagnostic monitor process provides an interface that can be called programmatically from within the role. Use the DiagnosticMonitor class from the Microsoft.WindowsAzure.Diagnostics namespace to access this interface, and configure and start the monitor. Configuration defines which sources of diagnostic data to collect and, optionally, when to transfer them. After the process starts, the data, which exists within each role instance, is buffered in the role's local directory storage. The default overall storage quota is approximately four gigabytes (GB) but it can be configured with larger values, if necessary. Each individual buffer can also be configured with their own storage limits. You can configure the overall limit by modifying the OverallQuotaInMB property in the DiagnosticMonitor class. Each individual buffer also provides a BufferQuotaInMB property. When the limit is reached, data is aged out by replacing the oldest data with the new data. The buffered data is only available while the role is running. If the role is recycled or terminated, the buffered data may be lost. By default, the local storage where diagnostic data is buffered to is wiped clean when the role stops. To persist the buffered data, configure the diagnostic monitor to upload the data, either at scheduled intervals or on-demand, to Windows Azure Storage. The type of storage service depends on the type of data. To learn more about the types of diagnostic data, see the following section "Sources of Diagnostic Data." The following figure illustrates the interactions between the different components within a Windows Azure role.

參考畫面

The DiagnosticMonitor class has two important methods, which are GetDefaultInitialConfiguration, and Start. The diagnostic monitor has a default configuration, which collects Windows Azure, IIS 7.0, and Windows Azure Diagnostic infrastructure logs. If you want to modify the default configuration and collect more logs, call the GetDefaultInitialConfiguration to get an instance of the DiagnosticMonitorConfiguration class.

The following diagram illustrates the set of classes you need in order to configure the diagnostic monitor. The "Changing the Diagnostic Configuration" section provides more details on how to manage configuration.

參考畫面

The Start method in the DiagnosticMonitor class starts or initializes the diagnostic monitor. The overloaded Start method allows you to provide a new configuration instead to replace the default one. If the diagnostic monitor is already started, calling the Start method reconfigures the process with the new configuration. Any data that has already been collected from the previous configuration still exists within the role instance's local storage, and is uploaded to Windows Azure storage when a transfer is initiated.

Sources of Diagnostic Data

Windows Azure diagnostics allows you to collect several sources of diagnostic data. The complete list depends on the role type. For example, IIS 7.0 logs are not available in worker roles because worker roles are not configured with IIS. The following table lists the different data sources, when they are available, and how they are stored.

 

Data source

Web role

Worker role

Collected by default

Storage service

Windows Azure logs

Yes

Yes

Yes

Table

IIS 7.0 logs

Yes

No

Yes

Blob

Windows Azure Diagnostic infrastructure logs

Yes

Yes

Yes

Table

Failed Request logs

Yes

No

No

Blob

Windows Event logs

Yes

Yes

No

Table

Performance counters

Yes

Yes

No

Table

Crash dumps

Yes

Yes

No

Blob

Custom error logs

Yes

Yes

No

Blob

Windows Azure Logs

Windows Azure logs represent application-specific diagnostic data that is generated from trace events by the application. To allow Windows Azure to capture these events, the application must be configured with the appropriate trace listener. The DiagnosticMonitorTraceListener in the Microsoft.WindowsAzure.Diagnostics namespace must be added to the list of listeners in the application's web.config or app.config file. The following code shows a web.config file that is configured with the DiagnosticMonitorTraceListener.

<configuration>
  ...
  <system.diagnostics>
    <trace>
      <listeners>
        <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
          name="AzureDiagnostics">
          <filter type="" />
        </add>
      </listeners>
    </trace>
  </system.diagnostics>
  ...
</configuration>

When the application generates a trace, it is handled by the trace listener and buffered. By default, the diagnostic monitor is configured to collect the Windows Azure Log. However, you still must either invoke or enable the transfer. The code below shows an example of how to schedule a transfer. This is covered in more detail in the "Transferring Diagnostic Data" section.

configuration.Logs.ScheduledTransferPeriod = TimeSpan.FromSeconds(5);
configuration.Logs.ScheduledTransferLogLevelFilter = LogLevel.Undefined;

When data is transferred from the buffer, it is stored in a Windows Azure table named WADLogsTable. The table contains the following properties:

  • PartitionKey

  • RowKey

  • Timestamp

  • EventTickCount

  • DeploymentId

  • Role

  • RoleInstance

  • Level

  • EventId

  • Pid

  • Tid

  • Message

The Trace class in the System.Diagnostics namespace includes several methods that allow you to write different types of information to the trace listener. The value or message you provide to a method is included in the Message property (column) within the table. The group of write methods is comprised of the Write, WriteIf, WriteLine and WriteLineIf methods. These methods allow you to specify a category. This is a good practice because you can use the category as a filter when you query for data. The following code is an example of how to include a category.

Trace.WriteLine("This is a verbose message", "General");

This code specifies the message and a "General" category. In the WADLogsTable, the value is displayed as "General: This is a verbose message", which allows you to use query operators to specify the desired category. Querying data is covered in more detail in the "Filtering Diagnostic Data" section.

The group of trace methods includes TraceInformation, TraceWarning, and TraceError. These methods have several benefits. One is that they provide granularity because you can specify the event type that your application raises. The Information (or info), Warning, Critical, and Error trace event types are commonly used. Note that the Verbose event type is associated only with the group of write methods. The event type you use is mapped to the Level property in the WADLogsTable.

The following table is a complete list of the trace, and write methods, and shows how the event types are mapped to values.

 

Method

.NET TraceEventType Enum value

WADLogsTable.Level Int32 value

Trace.Write, Trace.WriteIf, Trace.WriteLine, Trace.WriteLineIf

TraceEventType.Verbose

5

Trace.TraceInformation

TraceEventType.Info

4

Trace.TraceWarning

TraceEventType.Warning

3

Trace.TraceError

TraceEventType.Error

2

Trace.Fail

TraceEventType.Critical

1

note附註
In the TraceEventType enumeration, the values are bit flags. For example, the TraceEventType.Warning value is actually 4 (0x04), while the mapped value is 3. You must be careful not to rely on the values of the TraceEventType enumeration because the DiagnosticMonitorTraceListener uses an internal enumeration, and a mapping function for the Level property.

IIS 7.0 Logs

IIS 7.0 logs represent the IIS requests that are handled by the IIS process. The log files are located in the %SystemDrive%\inetpub\logs\LogFiles directory in the role instance. By default, IIS logging is enabled for web roles (worker roles do not have this log). However, you must ensure that the diagnostic monitor is configured to collect directories. To do this, set an appropriate interval for the ScheduledTransferPeriod's TimeSpan property. If an interval is not set in your code, you can still transfer the logs on-demand. The following code is an example of how to set the TimeSpan property.

var configuration = DiagnosticMonitor.GetDefaultInitialConfiguration();
configuration.Directories.ScheduledTransferPeriod = TimeSpan.FromSeconds(7);

When Windows Azure transfers IIS logs, the files are uploaded to the wad-iss-logfiles blob storage container. To view the actual files, use one of the tools that is available that displays and downloads blob files. One such tool is the Blob Container Viewer that is part of the Windows Azure Tools for Microsoft Visual Studio. This tool is available at http://www.microsoft.com/windowsazure/sdk/.

The following figure illustrates the wad-iis-logfiles container, and the files within it.

參考畫面

Windows Azure Diagnostic Infrastructure Logs

The Windows Azure diagnostic infrastructure logs provide diagnostic data specific to Windows Azure. The log data is stored in the WADDiagnosticInfrastructureLogsTable and represents the events that are related to your deployment, such as error and information messages. For example, if you attempt to add an event log data source with an incorrect format, an error is entered into this log. This log is very helpful when you must troubleshoot deployment-related issues, or errors that occur at the infrastructure level. This data is collected by default.

Failed Request Logs

The failed request logs are not collected by default, and must be enabled by specifying the appropriate tracing options in the application's web.config file. The failed request log files are stored in the wad-iis-failedreqlogfiles blob container. Failed-request tracing is an IIS 7 feature that buffers trace events for requests. If the request fails, the trace information is persisted to log files. Failure, in this case, is configurable. For example, you can define a range of HTTP Status codes, such as "400-599", as failed requests. Any requests that match these criteria are considered to be failed requests, and are logged. You can also specify a length of time that, if a request still is not met, you consider a failure. The following configuration shows how to enable failed request logging. It is configured to fail for pages that take longer than 10 seconds to load, and for requests that have status codes between 400 and 599.

<configuration>
  . . .
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules runAllManagedModulesForAllRequests="true"/>
    <tracing>
      <traceFailedRequests>
        <add path="*">
          <traceAreas>
            <add provider="ASP" verbosity="Verbose" />
            <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
            <add provider="ISAPI Extension" verbosity="Verbose" />
            <add provider="WWW Server" 
                 areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module" 
                 verbosity="Verbose" />
          </traceAreas>
          <failureDefinitions timeTaken="00:00:10" statusCodes="400-599"/>
        </add>
      </traceFailedRequests>
    </tracing>
  </system.webServer>
  . . .
</configuration>

Windows Event Logs

Windows events can also be captured by Windows Azure. Windows events contain important state information about an application, or the system. This means that you can configure your application to collect data, not only about your application, but also about the instance. You should use Windows events to log important states in your application. If you also need to store control flow, or finer-grained logging information such as detailed information about a method's execution, use Trace events to produce Windows Azure logs. Windows events are not enabled by default. To enable them, you must configure the diagnostic monitor. The following code is an example of how to do this.

var configuration = DiagnosticMonitor.GetDefaultInitialConfiguration();
configuration.WindowsEventLog.DataSources.Add("Application!*[System[Provider[@Name='MvcWebRole']]]");
configuration.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromSeconds(11);
configuration.WindowsEventLog.ScheduledTransferLogLevelFilter = LogLevel.Undefined;

In this code, Windows Azure is configured to collect Windows events from the Application channel for MvcWebRole providers. It is important to think about the format that you supply to the Add method. It must begin with the channel name, such as Application or System, and be followed by an exclamation mark (!). After the channel is specified, an XPath expression is required. The supported XPath expression is a subset of the v1 XPath specification. The Consuming Events page on MSDN (http://msdn.microsoft.com/en-us/library/dd996910(v=VS.85).aspx) provides more information, and discusses XPath 1.0 limitations.

An easier way to generate the formatted string is to use the Create Custom View feature in the Windows Event Viewer. This is accessible from the Computer Management MMC snap-in. In the dialog, you can select the filter parameters in the Filter tab, and then retrieve the path from the XML tab. The following two figures illustrate how the example Windows Event log configuration was created.

參考畫面

參考畫面

note附註
Windows Azure applications do not have the necessary permissions to access the Security channel.

Performance Counter Logs

Windows Azure also supports performance counters. They are not collected by default, and you must specify which counters you want to collect. Performance counters are useful when you need to determine an application's performance. You can configure the diagnostic monitor to collect standard Windows performance counters, or your own custom counters. The following code shows how to collect the Process % Time performance counter data.

configuration.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration
{
   CounterSpecifier = @"\Processor(_Total)\% Processor Time",
   SampleRate = TimeSpan.FromSeconds(1)
});
configuration.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromSeconds(13);

note附註
If you want to use custom performance counters, you must use a proxy application to create them, and use the Startup Tasks feature to provide the application with the necessary privileges. For more information, see the article, Real World: Creating Custom Performance Counters for Windows Azure Applications with PowerShell.

Crash Dumps

To enable the Windows Azure crash dumps, use the CrashDumps.EnableCollection method, which allows you to collect either mini or full-sized crash dump files. The files can be collected either by scheduling a directory collection, or by performing an on-demand collection. The crash dump files can be opened with tools such as WinDbg. You can inspect them for information such as the number of threads, or to view the call stacks. Crash dumps occur when an exception is handled by the diagnostic monitor. It is more difficult to create crash dumps for web roles than for worker roles. This is because the Global.asax file catches any exception that reaches it. The Application_Error event handler in the Global.asax file must throw or re-throw the exception if the web role is to generate a crash dump.

The following code shows how to enable full crash dumps.

CrashDumps.EnableCollection(true);

Custom Error Logs

Custom error logs capture any files from any directory that you designate. The directory that you specify must be configured as local storage for your deployment. By default, deployments are provided with local storage that is named DiagnosticStore. The DiagnosticStore directory buffers log files such as crash dumps, IIS logs, and failed-requests log files. It is a good idea to also add your own local storage. As with other file-based logs that are collected by Windows Azure, custom error logs are uploaded to blob storage. However, for custom error logs, you must provide the name of the blob container. The following figure illustrates the configuration, within Visual Studio, of a local storage directory that is named MyCustomLogs.

參考畫面

The following code shows how to configure files within the MyCustomLogs local storage directory so that they are included in the list of locations from which Windows Azure collects and uploads files.

var resource = RoleEnvironment.GetLocalResource("MyCustomLogs");
var directoryConfiguration = new DirectoryConfiguration
{
    Container = "wad-mycustomlogs-container",
    DirectoryQuotaInMB = resource.MaximumSizeInMegabytes,
    Path = resource.RootPath
};
configuration.Directories.DataSources.Add(directoryConfiguration);

本文對您有任何幫助嗎?
(剩餘 1500 個字元)
感謝您提供意見
顯示:
© 2014 Microsoft. 著作權所有,並保留一切權利。