Azure SDK 2.9 diagnostics exceptions

8
votes

I created a blank solution with a single Azure Worker Role. I enabled performance monitoring and diagnostics using the default settings.

When I run the app (which runs successfully) I try to look in the local development Azure Storage tables for the WADPerformanceCountersTable but cannot find it.

I see the following event in the event log:

Microsoft.Cis.Monitoring.Query.QueryException: ErrorFail
   at Microsoft.Cis.Monitoring.Query.QueryLocalTable..ctor(String TableName, String TablePath)
   at ApplicationInsightsExtension.MATableReader.ReadTableRecords(String tableName, String tablePath, DateTime startTime, DateTime endTime)
   at Microsoft.Azure.Plugins.Diagnostics.dll.MAStatusWriter.UpdateStatusReport(Object sender, ElapsedEventArgs e)

Local machine setup:

  1. Visual Studio 2013 Community Edition
  2. Azure SDK 2.9
  3. Windows 10
  4. Running Visual Studio as Administrator
  5. Worker Role definition has elevated privileges

More links:

2
c#azurediagnostics
Do you mean that the table WADDiagnosticInfrastructureLogsTable is create, but the table WADPerformanceCountersTable is not create in Azure Storage Emulator when you run cloud service on local? - Fei Han
No neither created for me - Alexander Williamson
I have deployed my app, and I am seeing this same error for my deployed app - Nathan Tregillus
Same error here - cdiazal
I have a suspicion that this is caused by \n line endings as opposed to \r\n line endings, in my case, caused by checking out the project with git for cygwin. Don't know which files actually cause the issue, but checking out with git for windows fixed it for me. Fiddling with the git autocrlf settings or making a .gitattributes file would probably do the same. - spender

2 Answers

0
votes

I have removed every nuget related with ApplicationInsights in my WebRole, every table with old data and now I have IIS Logs and Performance Logs.

Give it a try and see if it works for you

-1
votes

I found that simply removing the <system.diagnostics> element entirely from the web role's configuration file, meant that instead of getting the diagnostics initialisation error in the event log you get the actual error that Azure diagnostics was trying to log. Which is what I was looking for.