Skip to main content

Azure Portal CPU Graph Bug or Feature?

I support an Azure PaaS application.

We had a brief outage recently.

Given that the code had not been changed in a month, we suspected some maintenance in an Azure data center stepped on our application.

Ping tests and self-tests failed for approximately 10 minutes.

The outage resolved on its own without intervention.

I submitted a ticket to Azure Support to determine the cause of the outage but the reason I'm writing this post is because of the behavior I observed with the CPU graphs for Cloud Services while investigating the outage.

The CPU graphs show different results depending on the time range selected.

I would expect to see the CPU spike with the same value no matter what time range I selected. But, to see the spike that fired the alert, I had to to "Edit" the chart and select different time ranges to see the differences. It wasn't until I selected a narrow custom time range that the CPU graph would display the CPU spike that corresponded to the alert firing. The alert fires if the CPU percentage exceeds 80% over 15 minutes. So, if you "know" something happened, try different time ranges but especially the custom range to find what you are looking for.

This behavior has been documented and forwarded to the Azure portal team for review. It appears in both the Classic and current Azure portal.

The response from Azure Support when I raised this concern.
"I have had discussion with our Azure UI team and Azure Monitoring team regarding the portal graph.

As they mentioned, When we look at the 24 hours of data in the portal, the data is aggregated at 1 hour granularity and the average is shown. Similar is the case for 1 week of data shown on the portal. Since the spike exist for 5 to 10 minutes, we need to see the custom data option instead of using the 24 hour and 1 week. These 24 hours/ 1 week graph will be helpful when you have spike for more than an hour."

The CPU spikes are lower in the graphs that have a longer time range because of the aggregation and averaging. This is not a bug with the Azure graphs, it's a feature. ;-)








Comments

Popular posts from this blog

Modifying Endpoint URLs on Availability Group Replicas

I recently had to modify the Endpoint URLs on our SQL Server Availability Group replicas.  The reason for this blog post is that I could not answer the following questions: Do I need to suspend data movement prior to making this change?  Would this change require a restart of the database instance? I spent enough time searching on my own to no avail that I tossed the question to the #sqlhelp hashtag on Twitter and Slack but didn't get an answer prior to executing the change request. After reading the relevant documentation, I think it's probably a good idea to suspend data movement for this change. The T-SQL is straightforward.  USE MASTER GO ALTER AVAILABILITY GROUP [AG1]  MODIFY REPLICA ON 'SQL2012-1' WITH (ENDPOINT_URL = 'TCP://10.10.10.1:5022'); ALTER AVAILABILITY GROUP [AG1]  MODIFY REPLICA ON 'SQL2012-2' WITH (ENDPOINT_URL = 'TCP://10.10.10.2:5022'); ALTER AVAILABILITY GROUP [AG2]  MODIFY REPLICA ON 'SQL2012-1

PASS Summit 2012 - Gone to the mountain and returned wiser

http://t.co/pmhsJ3rr I began my conference schedule by attending Allen White's pre-con "Automating SQL Server with PowerShell". Allen starts by telling everyone in attendance “We all can learn something from each other.  We all know something that someone else doesn't.” I thought this was a great intro and inspiration to the attendees to participate in the PASS Community. Later in the day while answering a question, Allen tells us he is not a PowerShell expert.  Which kind of surprises me.  He says he’s just figured out how to use PowerShell with SQL Server. I think he is being a bit too humble.   Afterwards, I talk to Allen about a script I’m working on and he points me in a direction that hopefully will help me finish it. All in all, it was e xcellent day of training on using PowerShell with SQL Server. As the main conference began, I tweeted about how tight the seating was in some of the rooms on the first day of the main conference.   After the Sum

PowerShell: Quick SQL Server Version Check

I have to keep track of our SQL Server version inventory.  The goal is to reduce the SQL Server 2000 population as fast as possible. The following PowerShell script will produce a csv file containing the database server name and the version of SQL Server it's running. 1: ## Get SQL Version installed on multiple servers ## 2: ## ./sqlver.ps1 3: $start = get-date 4: write-host "Start: " $start 5:   6: [reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null 7:   8: $FilePath = "C:\Output" 9: $OutFile = Join-Path -path $FilePath -childPath ("SQLVersions_" + (get-date).toString('yyyyMMdd_hhmmtt') + ".log") 10:   11: # Version inventory 12: @(foreach ($svr in get-content "C:\Input\AllLOBServers.txt") 13: { 14: $s = New-Object "Microsoft.SqlServer.Management.Smo.Server" $svr 15: $s | select Name, Version 16:   17: }) | export-csv -noType $OutFile 18:   1