Today (02/22/2013.) there was a global problem effecting storage access via https. These changes effected a part of our application. It took our team a large amount of time to figure out the problem was not with our current application and changes we made on it recently, but was due to a global service problem. The management portal worked perfectly, all systems seamed to be live, and we where able to access the storage via http from our local environement (because that was the predefined protocol in our settings). But one of our runtime applications had a https connection string setting which did not work for hours at that point. We could have saved a lot of time if the health problem could have been visible via the management portal and not only a separate web site.

I would love to get all kinds of alerts. Here are som examples:

* When a auto scale event triggers
* When a Cloud Service VM is patched
* When a new Azure OS is available
* When a service is added or deleted by a co-administrator
* If a certificate expires or is about to expire
* If a stagning service or VM *IS* running (sometimes we forget to turn them off)
* If a Cloud Service worker role or VM is *NOT* running.

It could also be a custom job that checks a database for "No new orders in one hour", "A fatal alert in the log" etc.

Since each VM / Cloud Service has 3 major metrics: CPU, Memory , Network - diagnostics should collect this metrics by default (logging level minimal).

Because there are allot of instance types absolute values of Network and Memory counters are not informative and % should be used.
It is more informative to know that instance is using 90% of memory than to have a value of 600 MB. Same is for the network channel load. For example my service is network intensive and now it is really hard to understand when network channel load comes to it's limit and service scale is required.

Once this 2 metrics will be implemented they should be put to auto-scale. I strongly believe that combined with service bus queue they will cover all possible case of auto-scale.

I'd like to see the Diagnostics agent be aware of a graceful shutdown scenario (instance count being lowered for example) and if it has been working on a schedule to push data to storage attempt to push any data since the last scheduled transfer over before the system is fully shutdown.

If you have a schedule set up to move data every 5 or 10 minutes (or really any time schedule that isn't in the seconds) you could considerable amount of data if the role is shutdown between scheduled pushes. It would be nice if an attempt is actually made automatically to move anything since the last scheduled push.

You could manually accomplish this in the Role OnStop to do a manual transfer, but then you could get duplicate data, etc.

The trick would be around how long could the system really wait on the transfer before shutting down. OnStop has roughly 30 seconds...how much could the WAD engine get? Interesting issues to think about, but I think having this type of mechanism built in would be a good idea.

Hi,
We are using the new Azure SDK 2.5 Diagnostics for our Cloud Service.
Since our Performance Counters are dynamic and rely on process ID and process Identifier (the thing with the #) we cannot set the configuration in the wadcfg files but have to create the configuration during runtime and upload it via the REST API.

E.g. ChangeDeploymentConfiguration:
https://management.core.windows.net/{0}/services/hostedservices/{1}/deploymentslots/{2}/?comp=config "POST"

Today we received an error that the maximum length for the public configuration cannot exceed 20480 characters.

That is not acceptable.
First of all we have so many performance counters that we can easily reach this limit. And secondly we do not have any alternative to extend the public configuration e.g with a PUT request (as someone would expect from a RESTful API).

Luckily i was able to work around this by removing some counters from our configuration which are not essential, but in the long run this in just plain unacceptable, since we only postponed the inevetible.

Request:
Add a PUT functionality to extend the public configuration of the cloud service or remove the character limit in the POST method. (at least increase it by the factor 10).

As an example i have added a list of performancecounters we are currently using when running a cloud service with 4 web, 4 worker and 4 cache roles..
those are 6300 characters.
Scaling up to 10 roles each and adding a few counters will already reach the limit.