Azure Monitor: Repeating Graph or Row Per Resource Group

Hi all,

I’m a complete beginner to Grafana so bare with me!

I’m looking to create a dashboard that iterates though all resources of a certain type and creates a graph for each one found. From some experimentation as the Graph “metric options” require a Resource Group i think i need to repeat a Row that contains the graph to achieve this.

To start with I’m using storage accounts and the transactions metric.

I’ve used the examples here: Azure Monitor plugin for Grafana | Grafana Labs to create variables with the query’s below:
$ResourceGroups: ResourceGroups() - “Include All Option” = Enabled
$StorageAccountNames: ResourceNames($ResourceGroups,Microsoft.Storage/storageAccounts) - “Include All Option” = Enabled

The row containing the graph is is set as “Repeat for”: ResourceGroups

As it stands, if I select a Resource Group from the drop down boxes at the top of the dashboard graphs are created for that Resource group. But only that Resource group is shown.

The graphs show what they should so i’m happy with that :slight_smile:

Any help is greatly appreciated.


Slight update, the repeating Rows for Resource groups is now working, but it try’s to graph the same set of Storage Accounts for all repeated Resource Groups.

So i guess the question is, if i iterate through Resource Groups ($ResourceGroups) using repeating Rows is there a way to repopulate $StorageAccountNames with the Storage Accounts of the next Resource Group.

Possibly this bug:

I’m using the cloud hosted version reporting the version: * Grafana v5.4.3 (6539180)

Hi @andychown,

Your version of Hosted Grafana had the bug #15133, but I don’t think that’s the only problem.

I restarted your instance with version 5.2.5 and imported the bug’s use-case dashboard (title: “Row and var bug”).

The bug is no longer present but your dashboard rows still won’t get updated as expected.

The actual problem is that $StorageAccountNames is defined on the Dashboard and doesn’t get redefined for each Row. The StorageAccountNames list contains the list of account names in every ResourceGroups selected in $ResourceGroups. Both variables are flat lists with no data structure between them.

You could remove the Rows, and then repeat the graph panel for every $StorageAccountNames. The downside is you won’t see the ResourceGroup in the panel title.

Great, i’m not bothered about using rows unless i have to.

I’ve made the change but using the all option for ResourceGroup and StorageAccountNames still doesn’t list all storage accounts.


Azure Monitor doesn’t support ResourceGroups() in a dashboard variable with “Multi-value” mode selected.

If you look at the query inspector, you can see how the query API has incorrect syntax with the Multi-value variable. In the following example, I replaced ResourceGroups names with “rgA” and “rgB” for confidentiality:

  "xhrStatus": "complete",
  "request": {
    "method": "GET",
    "url": "api/datasources/proxy/2/azuremonitor/subscriptions/<guid>/resourceGroups/{rgA,rgB}/resources?api-version=2018-01-01"
  "response": {
    "error": {
      "code": "InvalidResourceGroup",
      "message": "The provided resource group name '{rgA,rgB}' has these invalid characters: '{,}'. The name can only be a letter, digit, '-', '.', '(', ')' or '_'."

The API expects exactly one resource group name. According to @daniellee this is has been a known issue for over a year. It’s not possible to do this kind of query on the Azure portal either.

I created this GitHub issue to track this on our side:

Thanks for the help, that’s a real shame. The dynamic creation of graphs for everything in a subscription would be so useful for me, we have teams creating resources alot with devops pipelines etc.
I’m not a developer so I might be talking nonsense. But in PowerShell if I know the name of an object or the type of objects but not the Resource Group I can use Get-AzureRMResource and then filter on the resource type or name. Once you you have the correct resource, the Resource Group is and attribute of that object.

Maybe that is an option to get around the problem: