We’ve been in Orlando all week at Microsoft Ignite Orlando, and it has been a busy week. Today, I meet with a sysadmin who wanted to know the best option to query multiple Azure Log Analytics workspace.
Here is the scenario he was looking at.
“Our company deploys a solution to different subscriptions. 1 per customer. So a new customer is on-boarded by creating a new subscription, deploying the solution in it and providing the new URL of the service we provide to the customer.”
They have decided to do this to be able to separate the billing per subscriptions cleanly. Their first idea was to ingest all the data from all the Log Analytics workspace in a “Master” workspace.
From there, they would write all the queries they need for their dashboards and alert without having to run them in each workspace. While this is possible, it’s not the most efficient way of doing it, and it could become costly because they would then be ingesting the data twice, and this would affect the pricing. (remember that the first 5GB of data ingested is free in a Pay-As-You-Go model)
What we came up with was to start using cross-resource log queries. This allows them to query not only across multiple Log Analytics workspaces, but also data from Application Insights in the same resource group, another resource group, or another subscription.
This is acceptable to them, but if you’re considering this solution for yourself, remember that there are some limitations:
For the sysadmin, I was speaking with those limitations were not an issue. But this is a stop-gap measure until they can figure out a permanent solution. (they really hope to have more than 100 customers…)
To query multiple workspaces, you need to reference the workspace in your query, using the workspace identifier, and for an app from Application Insights, use the app identifier.
The identifiers can be multiple types:
Resource name or Component Name
Qualified name. It’s like the fully qualified name in this format “subscriptionName/resourceGroup/componentName”. Considering that component names may not be unique, this is a good option.
The Workspace ID. It’s the unique identifier assigned to each workspace represented as a globally unique identifier (GUID). This is a better option since it is unique, but in my opinion, it can be confusing since very few of us can actually remember a GUID.
The Azure Resource ID. The Azure-defined unique identity of the workspace. This is the best option since it’s unique and easy to recognize.
If they wanted to query Application Insights instead of Log Analytics, the query would start with “app()” instead of “workspace().”
In the end, all their queries will still need to be modified to add the proper cross-query information like the example below.
You can find more info on Azure Data Explorer Reference here. And as for the Query Language, there is a detailed reference which you can find here. Or you can visit this page for a tutorial.
In the end, they might end up ingesting all the data in a master log analytics workspace. But that’s the subject of my next post.