{"id":756,"date":"2020-02-10T10:45:31","date_gmt":"2020-02-10T18:45:31","guid":{"rendered":"http:\/\/blog.nillsf.com\/?p=756"},"modified":"2020-02-10T17:23:07","modified_gmt":"2020-02-11T01:23:07","slug":"adding-alerts-to-azure-storage-metrics","status":"publish","type":"post","link":"https:\/\/blog.nillsf.com\/index.php\/2020\/02\/10\/adding-alerts-to-azure-storage-metrics\/","title":{"rendered":"Adding alerts to Azure Storage metrics"},"content":{"rendered":"\n

For every system you use, monitoring and alerting is critical. This holds true for Azure storage as well.<\/p>\n\n\n\n

In this quick post I’ll explain how you can setup alert rules for hitting TPS limits.<\/p>\n\n\n\n

Setting up the alert<\/h2>\n\n\n\n

To set up the alerts, navigate to your storage account, look for Alerts, and hit the “New alert rule” button.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Next, you need to define the rules you want to follow for this alert. The first question you get asked if which resource you want to monitor. This could be a single storage account, multiple accounts in a resource group, or all accounts in a subscription. In my case, I’ll create an alert for this specific storage account.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Next, you’ll need to select a condition to match. You can select diffent Signal types, which in our case will be Metrics. Then you can select transactions.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Next, you will see an overview of the current transactions, and you’ll get the opportunity to specify specific dimensions to split the metric. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Then, you’ll have to define which threshold to hit. Azure supports two thresholds here, either they are static (i.e. a metric you provide, e.g. close to the max of the storage account) or dynamic (showing you anomalies in your usage). In my case, I’ll configure a static alert at 1000 transactions. Note as well that you can define the aggregation granularity (over how much transactions will be counted) and how frequent this will be checked.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

After that, you need to create an action group. Actions can be multiple things, ranging from sending an e-mail, to calling a webhook to triggering an automation runbook to run. In my case, I’ll send an e-mail to myself. If you don’t have action groups precreated, you can create them for here by hitting the Create button in stead of the Add button. You can even configure multiple actions as part of a single action group.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Finally, we’ll give our rule a name and enable it. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

It can take up to 10 minutes for the alert to become active, and then it’ll take about 5 minutes for the aggregation window to catch up. Let’s wait a little and then trigger our alert.<\/p>\n\n\n\n

Triggering the alert<\/h2>\n\n\n\n

To trigger my alert based on total amount of transactions, I’ll start a azcopy bench<\/code> job. Azcopy bench<\/code> is a benchmarking tool to verify bandwidth to azure storage. To do this, I’ll start up a Linux VM, and download azcopy <\/code>on there with the following command:<\/p>\n\n\n\n

wget https:\/\/aka.ms\/downloadazcopy-v10-linux\ntar -xvzf downloadazcopy-v10-linux\ncd azcopy_linux_amd64_10.3.4<\/code><\/pre>\n\n\n\n
While in that folder, we can setup our benchmark tool. First, we’ll need a SAS token to connect to our storage account. Head over to the storage blade and look for SAS. Create a new SAS token that at least can write to blob. In my case, I gave full permissions to blob.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Once the token is generated, copy it somewhere safe. Next, we’ll create a new container for our benchmark.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Once that is done, we can format our bench command:<\/p>\n\n\n\n
azcopy bench \"https:\/\/<account>.blob.core.windows.net\/<container>?<SAS>\" --file-count 100 --size-per-file 2G<\/code><\/pre>\n\n\n\n
With that done, let’s run the benchmark and see if the alert rule is triggered.<\/p>\n\n\n\n
And for sure – after waiting a couple minutes – I got an alert in my inbox, explaining we hit the 1000 transactions limit:<\/p>\n\n\n\n
\"\"

<\/figcaption><\/figure>\n\n\n\n
Automating this setup<\/h2>\n\n\n\n
Doing this setup using the portal is easy for a single storage account, but requires some automation to set this up across all your storage accounts. The following Powershell snipper will create a rule that does the same we just created in the portal. <\/p>\n\n\n\n
$action = Get-AzActionGroup -Name \"email_nills\" -ResourceGroupName \"Default-ActivityLogAlerts\"\n$act = New-AzActionGroup -ActionGroupId $action.Id\n$crit = New-AzMetricAlertRuleV2Criteria -MetricName transactions -TimeAggregation Total -Operator GreaterThan -Threshold 1000\n\n$staccs = Get-AzStorageAccount\nforeach ($stacc in $staccs){\n    $alertrulename = $stacc.StorageAccountName + \" exceeded transactions\" \n    Add-AzMetricAlertRuleV2 -ResourceGroupName $stacc.ResourceGroupName -Name $alertrulename -WindowSize 00:05:00 -ActionGroup $act `\n    -TargetResourceId $stacc.Id -Frequency 00:05:00 -Condition $crit -severity 2\n}<\/code><\/pre>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this post we quickly evaluated how we can setup alerts based on the amount of transactions in a storage account. This will trigger automatically and do the required actions. <\/p>\n","protected":false},"excerpt":{"rendered":"
For every system you use, monitoring and alerting is critical. This holds true for Azure storage as well. In this quick post I’ll explain how you can setup alert rules for hitting TPS limits. Setting up the alert To set up the alerts, navigate to your storage account, look for Alerts, and hit the “New […]<\/p>\n","protected":false},"author":1,"featured_media":761,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[2,4,1],"tags":[81,68,76,67],"class_list":["post-756","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-management","category-uncategorized","tag-alert","tag-blob","tag-monitoring","tag-storage"],"jetpack_featured_media_url":"https:\/\/nillsfblog.blob.core.windows.net\/media\/2020\/02\/image-21.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/756","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/comments?post=756"}],"version-history":[{"count":3,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/756\/revisions"}],"predecessor-version":[{"id":777,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/756\/revisions\/777"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media\/761"}],"wp:attachment":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media?parent=756"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/categories?post=756"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/tags?post=756"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}