Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Azure

Enterprise Application Development : Azure Monitoring and Diagnostics

6/18/2011 4:33:05 PM
- Windows 10 Product Activation Keys Free 2019
- How to active Windows 8 without product key
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Logging config data in our application

Now that we have the collection of diagnostic data configured, we need to add code to our application to send diagnostic data to the listeners. We can do this simply by making calls to the methods in the System.Diagnostics.Trace class (documented at http://msdn.microsoft.com/en-us/library/36hhw2t6.aspx).

One of the more common methods we'll call is Trace.Writeline, as seen here:

Trace.Writeline("An error has occurred!","Error")

If our filter is set to the value Error or higher, our message would be logged. An alternative, easier syntax is:

Trace.TraceError("An error has occurred!")

Again, if our filter is set to the value Error or higher, our message will be logged. The simplified methods are limited to TraceError, TraceInformation, and TraceWarning, whereas the WriteLine method can be used to log diagnostic data at any level, including custom levels.

Transferring and persisting diagnostic data

As diagnostic data are logged, the data are buffered in memory. In order for us to retain the data for analysis, we need to make sure that the data persists in a proper storage container. This is not set up by default, but it takes only a couple of lines of code to configure the transfer of data into the storage location. We can set this transfer to be either scheduled, or on demand.

To automatically transfer the diagnostic data on a schedule, we just need to add a single line to our role's OnStart method:

diagConfig.PerformanceCounters.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1.0)


The entire OnStart method for our web role now reads like this:
Public Overrides Function OnStart() As Boolean
OnStart methodDim diagConfig As DiagnosticMonitorConfiguration = DiagnosticMonitor.GetDefaultInitialConfiguration()
Dim procTimeConfig As PerformanceCounterConfiguration = New PerformanceCounterConfiguration()
procTimeConfig.CounterSpecifier = "\Processor(*)\% Processor Time"
procTimeConfig.SampleRate = System.TimeSpan.FromSeconds(1.0)
diagConfig.PerformanceCounters.DataSources.Add(procTimeConfig)
diagConfig.PerformanceCounters.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1.0)
DiagnosticMonitor.Start("DiagnosticsConnectionString")
Return MyBase.OnStart()
End Function



We'll need to add similar code to the OnStart methods of the other roles in our application if we want to automatically transfer the diagnostic logs for those roles too.

An on-demand transfer is a little different an on-demand transfer can be initiated either from within the role, from another role in the same application, or even a completely different application. To reduce the amount of diagnostic data we need to sort through when debugging, we might want to log every level of diagnostic data but transfer the diagnostic data only when an error occurs.

Public Sub TransferDiagnosticData()
Dim diagManager As DeploymentDiagnosticManager = New DeploymentDiagnosticManager(<Azure storage account name>, <Azure deployment ID>)
dim roleInstDiagMgr as RoleInstanceDiagnosticManager = diagManager.GetRoleInstanceDiagnosticManager( <Role name>, <Role instance name>)
Dim dataBuffersToTransfer As DataBufferName = DataBufferName.Directories
Dim transferOptions As OnDemandTransferOptions = New OnDemandTransferOptions()
With transferOptions
.From = DateTime.MinValue
.To = DateTime.UtcNow
End With
Dim requestID As Guid = roleInstDiagMgr.BeginOnDemandTransfer(dataBuffersToTransfer, transferOptions)
End Sub


Complete documentation for transferring buffered data to storage can be found at http://msdn.microsoft.com/en-us/library/ee830425.aspx.

It's important to note that diagnostic data is treated the same as any other data associated with our application, and we will be charged for the storage of the diagnostic output.

Accessing stored data

Once we've transferred the diagnostic data to storage, we can access it for analysis. Accessing log data is the same as accessing any other Table or Blob Storage. The most convenient way may be using the REST interface documented earlier in this book.

As Azure becomes more popular, third-party diagnostic tools will be developed. One such tool already available is the Cerebrata Azure Diagnostics Manager, found at http://www.cerebrata.com/Products/AzureDiagnosticsManager/Default.aspx. Hundreds of Azure-related applications have been added to Codeplex as well, but many of these projects have withered.


Other -----------------
- Enterprise Application Development : Azure Diagnostics­ under the hood & Enabling diagnostic logging
- Building a Scalable, Multi-Tenant Application for Windows Azure : Scaling the Surveys Application
- Building a Scalable, Multi-Tenant Application for Windows Azure : Scaling Applications by Using Worker Roles
- Building a Scalable, Multi-Tenant Application for Windows Azure : On-Boarding for Trials and New Customers
- Introduction to SQL Azure : Creating our database
- Introduction to SQL Azure : Migrating schema and data
- Introduction to SQL Azure
- Overview of SQL Azure
- Microsoft Azure : Designing our Sample Application
- Microsoft Azure : Setting Up for Development
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server