We've created new Metric Alerts via an ARM template (as documented here: https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-create-metric-alerts-with-templates and https://docs.microsoft.com/en-us/rest/api/monitor/metricalerts/createorupdate)

If we pass multiple resources in the scopes array, we see three unexpected behaviours:
1) The alert only fires for the first resource in the array
2) The Monitor ui on the portal shows no alert definitions, unless you enable the new portal experience.
3) The new portal experience only shows a single resource being monitored

Retrieving the alert definitions from the REST API shows that the multiple resources in the scope have indeed been successfully stored.

We would like to request a new feature in the Boot diagnostics option, not just screenshot, would like to have console screen that can do operation directly on the console screen. easy to do online troubleshooting

Azure Diagnostics agent is currently creating a table named WADDefaultTable for ETW events by default. This would be more aptly named WADETWEventTable to comply with other default table names for other log resources (such as the event log).

Frequently while I am trying to monitor CPU usage of a VM it will not update the data for a given minute and this leaves wholes in the data

It seems that Azure Monitor REST API for SQL Databases and Storage changed functionality and broke my code 2 days ago. (west europe)

I had a simple REST call that would fetch all 1 minut metrics for a single resource in a single call. New preview api doesn't allow specifying more than a single metric per call which means that my code is now needing to make a call for each metric on each resource. It's probably 10x more REST calls than before.

This worked great with the old API, but 2 days ago it started to return BadOperation.

When adding an alert rule on a VM, the display for "% Committed Bytes in Use" or "% Free Space" metrics show the units under "Threshold" as "Count", but this should be "%". It also shows in the Condition column when looking at a list of Alerts (for example, "> 80 Count" instead of "> 80 Percent").
This seems to be a bug with Portal display for those two metrics and should be fixed.

Last night during what I assume was an auto-update of the Azure Diagnostics service on a Windows Server 2012 VM in Azure, it stopped our World Wide Web Publishing Service and did not restart it. This resulted in a service disruption.

I've attached the Event Log error.

Why did it need to stop the WWW service?
Is there some way to know in advance if it's going to do this, or control when it happens?

Am unable to change the edit chart metric betweenpast hour/ past week/ custom at times, clicking save does not save all the time

On portal in path: Home > Diagnostics settings there is no option to manage diagnostics settings for related resources, each time after configuring resource and closing blade portal redirects me to dashboard. Same thing in Monitor service. As a user I would like to configure few services by adding these settings, back to the list, configure another one. For now it is impossible.

I posted in the MSDN forum and finally solved it. Please read the forum notes for full details and fixes too. Let me highlight the bug. When you click on Diagnostics and then Overview you get a screen for configuring the counters. There it gives option None-Basic-Custom. So it turns out what ever you see set there is actually not set that display is wrong. So when you start the monitor it will say not data found because not counter has been set. So you have to actually edit and add it.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/2bf448f5-372c-478d-a55d-8c5bab6af99f/diagnostic-monitoring-does-not-work-on-azure-stack-single-node-deployment?forum=AzureStack

On the startboard, you can't label a chart. Clicking the chart opens a metrics blade, but there is no context or way of figuring out WHAT system those metrics are reporting from. Metrics blades should display the server/service they are reporting on since they are not ALWAYS displayed in the context of that server.