Back in the good, old SCOM days, there was a thing called Global Service Monitor (GSM) which is still available. What was / is GSM?
System Center Global Service Monitor is a cloud service that provides a simplified way to monitor the availability of external-web-based applications from multiple locations around the world.
One of the less known capabilities was to use a multi-step webtest file to run your custom checks from the outside – known as the cloud.
Today things have definitely moved towards Azure and web tests are still available in Azure Monitor. Well, Azure Monitor is the synonym for a collection of monitoring tools in Azure like Application Insights. I haven’t played around a lot with web tests, but I liked the approach / idea from the moment I read about it. So I was wondering how we could run a web test from Application Insights, authenticate to Azure AD and then use an API like Azure Resource Graph to run a sample query against it. There are few things which have to be in place in order to perform such tests:
- Azure subscription (of course)
- Azure AD service principal
- Visual Studio Enterprise edition
Prerequisites
First make sure you have Visual Studio Enterprise edition installed, otherwise you won’t be able to install the templates…
…next go to File/New/Project… and see if the Web Performance and Load Test Project template is available…
…if not, run the Visual Studio Installer from the Windows start menu and select this option…
…the next step is to create a service principal in Azure AD, which we will use to authenticate against Azure AD. There are many ways to create a service principal e.g. the portal, Azure CLI or PowerShell. After we created the service principal we assign reader permission on the subscription level, so we have read (view) access on all resources within the subscription.
Finally we managed to setup all prerequisites for the web test.
Setup VS Solution
Start Visual Studio 2017 and select File/New/Project… and choose the Web Performance and Load Test Project…
First we insert a new request…
…then we need to change the properties, the Url property will be set to the tenant specific login url. The {{AADTenantID}} is just a variable, which will be replaced by the Context Parameter during runtime…
Next we add the Form Post Parameters, those are necessary parameters we need to pass in to the POST request. Additionally we define the variables and assigning the actual values in the Context Parameters section…
…AADTenantID is the ID of your Azure Active Directory tenant, ClientID is the ID of the service principal we created before, ClientSecret is the key we got from the service principal in Azure AD and of course the Subscription. The property settings of the Form Post Parameters look like this. First the resource parameter…
…then the client_id parameter…
…the client_secret parameter…
…and the grant_type parameter…
…the Context Parameters are just created using the context menu…
If we run a web test in Visual Studio we should be able to successfully authenticate to Azure AD. Because we need to login into the Azure Resource Graph API (or many other Azure related APIs), it is required to pass the Azure AD access token. In order to get the access token from our request, we need to create an Extraction Rule…
…this looks in the properties windows like this…
How did we get to this logic? Well, if we run the web test, we can see the response, it looks something like this…
…therefore we are able to extract the token and assign it to the Access_Token context parameter. We should now able to run the solution and get a similar result as in these screenshots, by pressing this button in Visual Studio…
The next step is to login into Azure Resource Graph and run a sample query. In order to do so, we need to create a Web Service Request, because this test lets us submit a JSON body in the request…
…the properties need to be like this…
…Here you will find the description of the API, to successfully POST the webservice request, we need to define the following parameters…
…the api-version gets passed as Query String Parameters and defines which api version to use (of course!) and within the Headers section, we need to pass the Bearer token (remember our previous steps where we used the Extraction Rule!)…
…and of course the Content-type…
…finally we are just missing a way to pass a query to the Azure Resource Graph. One way to do so, is to use the String Body, this content will be passed within the webservice request body. Note here the Context Parameter {{Subscription}} we defined before, it is also usable in the String Body…
Now you are asking yourself, how the heck did I get this query and how can we test it in advance? Well, there is a starter documentation and here you can try it out, just in the browser…
…so what does this query do? Well, it just lists all my action groups in my subscription and outputs name, type and location….
So far we are able to login into Azure AD, query the Azure Resource Graph and returning all my action groups. Lets assume we want to let the second web test fail, if there is no such action group like “AdminMail”. We can achieve this by adding a Validation Rule, that checks the response of the request for a certain text. Add it using the context menu Add Validation Rule…
…like this…
…and just configure the desired name in the properties…
That’s it, if you change the name which does not exist in the response output, the test will fail…
The final and last step is to run this web test from Application Insights. Just create a new application, by clicking +Add…
..then follow this arrow heavy screenshot. Choose the web test file (*.webtest) in your Visual Studio solution in …CheckAzureResourceGraph\CheckAzureResourceGraph\bin\Debug…
…and then we should see, running this test from all over the world…
…and if we delete the action group, the tests start failing…
Notes:
Web tests have been around for a long time, but I think they are not so common to the most IT pros. Having Application Insights in place we are able to build any availability and performance tests from the outside of our enterprise, which can be very useful. Because we are able to customize and build these tests as we want, there is basically no limitation (at least I don’t know) in querying any Azure API or application.
