Track Availability in Application Insights

An azd template (Bicep) that implements three different ways to track availability in Application Insights using:

• a standard test (webtest)
• an Azure Function
• a Logic App workflow

Overview

This template deploys the following resources:

The following availability tests are deployed:

• Two standard tests (webtest):
  1. Checks the availability of an API every 5 minutes from 5 locations
  2. Checks the validity of the SSL certificate of the API
• Two Azure Functions:
  1. Checks the availability of an API every minute
  2. Checks the validity of the SSL certificate of the API
• A Logic App workflow:
  1. Checks the availability of an API every minute

For the backend, an API in API Management is used that randomly returns a 200 OK or 503 Service Unavailable response based on a configurable approximate failure percentage.

After deployment, availability test results should appear in Application Insights. See the following image for an example:

When tests fail, alerts will fire in Azure Monitor. See the following image for examples:

See the Demo Guide for a more detailed overview of what's included in this template and how it works.

Some things to take note of:

• This sample uses Azure Functions to perform availability tests from code because they provide an easy way to trigger the tests on a schedule. You can use other services that host .NET code as well.
• The Logic App sample is not entirely low code. A Logic App with custom .NET code is used in order to track the availability in Application Insights. A custom connector is in the works, but it's not available yet due to some challenges with deployment.
• You can use any backend to check for availability, not just an API in API Management.

Important

This template is not production-ready; it uses minimal cost SKUs and omits network isolation, advanced security, governance and resiliency. Harden security, implement enterprise controls and/or replace modules with Azure Verified Modules before any production use.

Getting Started

Prerequisites

Before you can deploy this template, make sure you have the following tools installed and the necessary permissions.

Required Tools:

• Azure Developer CLI (azd)
  • Installing azd also installs the following tools:
    • GitHub CLI
    • Bicep CLI
• .NET Core 9 SDK
• npm CLI (This template uses a workaround to deploy the Logic App workflow, which requires the npm CLI.)
• This template includes several hooks that run at different stages of the deployment process and require the following tools. For more details, see Hooks.
  • PowerShell
  • Azure CLI

Required Permissions:

• You need Owner permissions, or a combination of Contributor and Role Based Access Control Administrator permissions on an Azure Subscription to deploy this template.

Deployment

Once the prerequisites are installed on your machine, you can deploy this template using the following steps:

1. Run the azd init command in an empty directory with the --template parameter to clone this template into the current directory.

   azd init --template ronaldbosma/track-availability-in-app-insights

   When prompted, specify the name of the environment, for example, track-availability. The maximum length is 32 characters.

2. Run the azd auth login command to authenticate to your Azure subscription using the Azure Developer CLI (if you haven't already).

   azd auth login

3. Run the az login command to authenticate to your Azure subscription using the Azure CLI (if you haven't already). This is required for the hooks to function properly. Make sure to log into the same tenant as the Azure Developer CLI.

   az login

4. Run the azd up command to provision the resources in your Azure subscription. This will deploy both the infrastructure and the sample application, and typically takes around 7 minutes to complete. (Use azd provision to only deploy the infrastructure.)

   azd up

   See Troubleshooting if you encounter any issues during deployment.

5. Once the deployment is complete, you can locally modify the application or infrastructure and run azd up again to update the resources in Azure.

Demo

See the Demo Guide for a step-by-step walkthrough on how to check and demonstrate the deployed availability tests.

Clean up

Once you're done and want to clean up, run the azd down command. By including the --purge parameter, you ensure that the API Management service doesn't remain in a soft-deleted state, which could block future deployments of the same environment.

azd down --purge

Configure approximate failure percentage

The backend API will randomly return errors for an approximate percentage based on the approximateFailurePercentage parameter that you can configure in main.parameters.json. In the following example, the approximate failure percentage is set to 10%:

"approximateFailurePercentage": {
  "value": ${APPROXIMATE_FAILURE_PERCENTAGE=10}
}

As you can see, the value can also be set using the APPROXIMATE_FAILURE_PERCENTAGE environment variable.

The value is used to create a named value in API Management called approximate-failure-percentage. The backend API has a policy that uses the named value to implement the logic to return either a 200 OK or 503 Service Unavailable response. See backend-api.get-status.xml for the details.

Contents

The repository consists of the following files and directories:

├── demos                      [ Demo guide(s) ]
├── hooks                      [ AZD hooks ]
├── images                     [ Images used in the README ]
├── infra                      [ Infrastructure As Code files ]
│   |── functions              [ Bicep user-defined functions ]
│   ├── modules                
│   │   ├── application        [ Modules for application infrastructure resources ]
│   │   ├── services           [ Modules for all Azure services ]
│   │   └── shared             [ Reusable modules ]
│   ├── types                  [ Bicep user-defined types ]
│   ├── main.bicep             [ Main infrastructure file ]
│   └── main.parameters.json   [ Parameters file ]
├── src                        [ Application code ]
│   ├── functionApp            [ Azure Functions ]
│   └── logicApp               [ Logic App workflow]
├── azure.yaml                 [ Describes the apps and types of Azure resources ]
└── bicepconfig.json           [ Bicep configuration file ]

Hooks

This template has several hooks that are executed at different stages of the deployment process. The following hooks are included:

• prepackage-logicapp-build-functions-project.ps1: This PowerShell script is executed before the Logic App is packaged. It builds the custom .NET code project for the Logic App using the dotnet build command.

• predown-remove-law.ps1: This PowerShell script is executed before the resources are removed. It permanently deletes the Log Analytics workspace to prevent issues with future deployments. Sometimes the requests and traces don't show up in Application Insights & Log Analytics when removing and deploying the template multiple times.

Troubleshooting

API Management deployment failed because the service already exists in soft-deleted state

If you've previously deployed this template and deleted the resources, you may encounter the following error when redeploying the template. This error occurs because the API Management service is in a soft-deleted state and needs to be purged before you can create a new service with the same name.

{
    "code": "DeploymentFailed",
    "target": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-track-availability-sdc-cliqc/providers/Microsoft.Resources/deployments/apiManagement",
    "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
    "details": [
        {
            "code": "ServiceAlreadyExistsInSoftDeletedState",
            "message": "Api service apim-track-availability-sdc-cliqc was soft-deleted. In order to create the new service with the same name, you have to either undelete the service or purge it. See https://aka.ms/apimsoftdelete."
        }
    ]
}

Use the az apim deletedservice list Azure CLI command to list all deleted API Management services in your subscription. Locate the service that is in a soft-deleted state and purge it using the purge command. See the following example:

az apim deletedservice purge --location "swedencentral" --service-name "apim-track-availability-sdc-cliqc"

Function App deployment failed because of quota limitations

If you already have a Consumption tier (SKU=Y1) Function App deployed in the same region, you may encounter the following error when deploying the template. This error occurs because you have reached the region's quota for your subscription.

{
  "code": "InvalidTemplateDeployment",
  "message": "The template deployment 'functionApp' is not valid according to the validation procedure. The tracking id is '00000000-0000-0000-0000-000000000000'. See inner errors for details.",
  "details": [
    {
      "code": "ValidationForResourceFailed",
      "message": "Validation failed for a resource. Check 'Error.Details[0]' for more information.",
      "details": [
        {
          "code": "SubscriptionIsOverQuotaForSku",
          "message": "This region has quota of 1 instances for your subscription. Try selecting different region or SKU."
        }
      ]
    }
  ]
}

Use the azd down --purge command to delete the resources, then deploy the template in a different region.

Logic App deployment failed because of quota limitations

If you already have a Workflow Standard WS1 tier (SKU=WS1) Logic App deployed in the same region, you may encounter the following error when deploying the template. This error occurs because you have reached the region's quota for your subscription.

{
  "code": "InvalidTemplateDeployment",
  "message": "The template deployment 'logicApp' is not valid according to the validation procedure. The tracking id is '00000000-0000-0000-0000-000000000000'. See inner errors for details.",
  "details": [
    {
      "code": "ValidationForResourceFailed",
      "message": "Validation failed for a resource. Check 'Error.Details[0]' for more information.",
      "details": [
        {
          "code": "SubscriptionIsOverQuotaForSku",
          "message": "This region has quota of 1 instances for your subscription. Try selecting different region or SKU."
        }
      ]
    }
  ]
}

Use the azd down --purge command to delete the resources, then deploy the template in a different region.