Azure诊断程序是否在Azure临时插槽中运行？

Question

When collecting Azure diagnostic data, does the staging slot also send diagnostic data to the WadPerformanceCounters Table?

If so, how can I turn this off? Or how can I differentiate between staging/production when reading the diagnostics.

I don't want to display data about our website assuming it's all production when in fact part of it is the staging slot.

Answer 1

Yes - Windows Azure diagnostics runs in the Production and Staging slots. The only real difference between these two slots is the DNS name.

As for enabling diagnostics, there is a good starting point at http://msdn.microsoft.com/en-us/library/gg433048.aspx . This provides links to a lot of info on Windows Azure diagnostics.

I don't believe there is a way in the diagnostics table data (WadPerformanceCountersTable, for example) to distinguish between Production and Staging slots. You might be able to filter based off the RowKey value, which I believe contains the deploymentID and that would be different between Production and Staging.

You could also use a different storage account for Production and Staging slots. It'd be a fairly quick update of the .cscfg that could be done at run time.

Answer 2

When collecting Azure diagnostic data, does the staging slot also send diagnostic data to the WadPerformanceCounters Table?

Yes, they do end up in the same table.

Each deployment gets its unique deployment identifier which can be found on the dashboard for particular instance (production or staging)

Sample WadPerformanceCountersTable table

---

In order to find logs related to specific deployment (staging or production) you can filter the table by deployment identifier eg

DeploymentId eq '1a2c09bea1234bc1b5e6edb99993ab21' 

If you have too many entries for a single deployment identifier, you reduce number of entries by adding, say, time attribute (all entries with DeploymentId '1a2c09bea1234bc1b5e6edb99993ab21' logged after midnight 5 January 2013 ) eg

DeploymentId eq '1a2c09bea1234bc1b5e6edb99993ab21' and Timestamp gt datetime'2013-01-05T00:00:00Z'

Please note that this is not very optimal way of filtering Azure Table Storage (as pointed out by Kiwi and Gaurav.

Any query which will not include PartitionKey will result in full table scan. Since PartitionKey in WAD tables represent a date/time value, I would recommend using that instead of Timestamp . You may find Effective way of fetching diagnostics data post very useful.

That should help you finding out entries per environment (staging vs. production) and particular deployment.