This post has been republished via RSS; it originally appeared at: ITOps Talk Blog articles.
Azure Resource Graph is an extremely powerful extension to Azure Resource Management that provides efficient resource exploration at scale. It supports both Azure Lighthouse as well as cross subscription querying. It also provides the ability to do complex filtering and grouping. It can do this because it uses a subset of the Kusto Query Language.
To use Azure Resource Graph successfully, you'll need read access to any subscription and resource(s) that you wish to query. If you do not have read access to a resource or subscription they will not appear in your resulting data sets.
There are a number of tables you can query in Azure Resource Graph. The most common table is the "resources" table. This is where all resources in your Azure subscriptions will live. With few exceptions everything in Azure is a resource. Notably Azure Sentinel and Azure Security Center are not resources, they are solutions that sit on top of a Log Analytics workspace.
To get a idea of all the different types of resources in your subscriptions you can run the following query.
You can get a count of all resources by using summarize.
To query a specific resource type, like virtual machines, you can use a where clause with type.
One thing to note on resource types, sometimes types do not match their current name in Azure. For instance Log Analytics resource type is "OperationalInsights/workspaces." This is because Azure resources are renamed over time but their type cannot necessarily be renamed in Azure.
You can turn on formatted results to see a proper translation of resource types to their current Azure names.
Dynamic types in Kusto are fields that have multiple values or properties under it. In Azure Resource Graph there are multiple fields, and most commonly the properties field that have multiple values and even nested JSON underneath it. These values have a ton of useful information about your Azure resources in them. But you'll need to know how to access the information. There are several ways to access information depending on how the information is formatted.
One of the fields that has useful information nested inside it is the Sku field, some resources have the sku type and tier of the Azure service in this field, while others have it under properties.
Whenever you see curly braces in Azure Resource Graph that means that there are multiple values in that field.
To access information underneath it we can use dot notation.
You can click on see details on the right hand side to see all the fields and if they have any nested values. In this case we're looking at VM properties and its hardware profile size. We can get this information again with dot notation.
We can use dot notation to extract our VMs hardware profile size.
Advanced Dynamic Types
Dot notation works really well for a number of properties. We can go as many levels deep as we want with dot notation, until we run into brackets inside our nested field. See here on the network interface, the nic's ID is inside brackets. This is because we can have more than one nic to one VM.
While technically dot notation would still work by using  in reference to the object in an array, its not dynamic. Meaning if we don't necessarily know if we have 2 objects or 20 in the array. We'll want to use mv-expand for these types of data.
Notice we now have curly braces around our NicID, we can now use dot notation if we want to make this information its own field.
Now that we know some of the ins and outs, lets apply that knowledge to practical examples you can use in your environment.
Summary count of VMs by Size
Summary count of VMs by their current state
Because almost everything in Azure is an Azure resource, VMs have a VM object, as well as disk and NIC objects, each of which are separate Azure resources. One VM can have multiple disks and NICs. If we want to display VM's with their corresponding NICs and Disks we have to use Joins as well as our dot notation and mv-expand to get pertinent information.
Notes about this query: 1, we want to use tolower() which simultaneously makes the value a string, it makes it all lower case as well. This is useful when doing joins as KQL cannot join dynamic types, and will not see the resource IDs as the same if one if camel case and one is lowercase, as KQL is case sensitive. 2, we use left outer joins because a VM can have a public IP but it can also not have a public IP.
I have included many examples for different resource types on my github repo.
Azure Resource Graph is extremely powerful for exploring your resources, creating your own inventory dashboard, and more. Many new tables have been added since Azure Resource Graph's inception. Including the ability to query Azure Monitor Alerts, security scores from Azure Security Center and more.