How to Set Up Ping URL Tests and Health Checks with Azure Monitor Application Insights.

What is Azure Monitor?

Azure Monitor is Microsoft’s comprehensive monitoring solution designed to help you track, analyse, and optimize the performance and health of your applications and infrastructure. It collects and analyses data from various sources, including Azure resources, on-premises systems, and applications, giving you a unified view of your entire environment.

With features like metrics, logs, Application Insights, and alerts, Azure Monitor enables you to proactively identify issues, optimize resource usage, and ensure reliability.

What is Azure Monitor Application Insights?

Azure Monitor Application Insights is a powerful feature of Azure Monitor designed to help you monitor the performance and usage of your applications. It provides deep insights into how your application is performing and how users are interacting with it, enabling you to identify and resolve issues quickly.

Application Insights works by collecting telemetry data from your application, such as request rates, dependencies, exceptions, and user interactions. This data is then analysed and visualized in intuitive dashboards to help you understand your application’s health and performance in real-time.

Application Insights vs. Azure Log Analytics: Understanding the Difference

Application Insights focuses on monitoring application performance and user behaviour by collecting telemetry like request rates, exceptions, and dependencies, making it ideal for developers optimizing applications. In contrast, Azure Log Analytics allows you to query, consolidate, and analyse logs from Azure resources using KQL, enabling cross-resource diagnostics and infrastructure monitoring. Together, they provide a comprehensive view of both application and system health within Azure Monitor.

Availability Alerts

Application Insights periodically send web requests to your application from global locations to monitor its responsiveness. If your application fails to respond or responds too slowly, you can receive alerts. We’ll configure a URL ping test to check the availability of our Web App and set up an alert based on the test results.

Prerequisites

1. Azure Subscription
   Ensure you have an active Azure account. If you’re new to Azure, you can start with a free account on the Azure portal.

2. Live Web Application URL
   Your application must already be deployed and publicly accessible. This URL will be used for the availability test.

Setting Up Application Insights

1. Log In to the Azure Portal
   Go to the Azure Portal and sign in with your Azure credentials.

2. Locate Azure Monitor
   Use the search bar at the top of the Azure Portal, type Monitor, and select it from the results to open the Azure Monitor dashboard.

3. Navigate to Application Insights
   On the Monitor Overview page, find the Insights section and click on Application Insights to set up monitoring for your application.

4. Create or View Existing Application Insights

• To create a new Application Insights resource, click the Create button at the top of the page.

Once created, click on it and scroll down to availability at the left side of the page.

Adding an Availability Test

1. Navigate to Availability
   In the left-hand menu of your Application Insights resource, select Availability under the Investigate section.

2. Add a Classic Test
   On the Availability page, click on the Add Classic test button at the top.

Configuring the Test

1. Provide Test Details
   After clicking Add Classic test, a form will appear for configuring the test.

2. Enter Test Name
   In the Test name field, give your test a descriptive name (e.g., "classic-monitor").

3. Select SKU and URL

   • For SKU, select the URL ping option.

   • Paste the URL of your web app in the URL field. Ensure the URL is correct and publicly accessible.

4. Set Test Frequency
   You can configure how frequently the test runs. Common intervals are 5, 10, or 15 minutes, depending on your monitoring needs.

When you scroll down, you have the test locations, success criteria and the alerts which is enabled by default.

Selecting Test Locations

1. Open Test Locations Dropdown
   In the test configuration form, click on the Test locations dropdown to view the available regions.

2. Default Test Locations
   By default, 5 locations are pre-selected. These include geographically diverse regions to ensure broad coverage of your application's availability.

3. Customizing Locations
   You can select or deselect specific regions based on your preference. Azure allows up to 16 test locations, providing flexibility for monitoring your app’s performance across the globe.

   

   Finalizing the Test Configuration

   1. Success Criteria
      Leave the Success criteria as the default, which typically checks for an HTTP response of 200 and a test timeout of 120 seconds.

   2. Alerts
      Ensure the Alerts option is set to Enabled (default setting). This will allow Azure to notify you when the test fails based on the configured criteria.

   3. Create the Test
      Once all configurations are complete, click the Create button at the bottom of the page to finalize and activate the test.

Test Successfully Created

Once you click Create, your availability test will be successfully created. You can verify this by checking the Availability Tests section on the Availability page. As shown in the screenshot below, the test (e.g., "classic-monitor") will appear in the list, indicating it’s active and ready to monitor your application.

Monitoring the Test Results

After refreshing the Availability page, you can see that all the selected test locations have started running. Each location displays the availability percentage and average response time for your web app.

Reviewing Overall Availability Results

On the left side of the Availability page, you can find the Overall Availability Results section. This provides a summary of the availability tests conducted, showing the number of successful tests as a green progress bar with the corresponding count.

As seen in the screenshot, the test has recorded 11 successful availability checks, confirming that your web app is running smoothly across all selected regions.

Verifying the Web App

To confirm that your web app is running, you can open its URL in a browser. As shown in the screenshot, the web app is in the running state, indicating it is live and ready to serve content.

If you haven’t deployed content yet, Azure provides a placeholder message, as seen here, stating that the app is live but waiting for content to be deployed. This is a great sign that the setup is complete and your app is functioning properly.

Setting Up Alert Rules

1. Open the Alert Configuration
   After clicking on the ellipsis (...) in the Actions column of your test, select the Open Rules (Alerts) page option from the dropdown menu.

   

2. Access Alert Rules Page
   This action will redirect you to the Alerts Rules page, where you can define rules for notifications when your availability test fails or encounters issues.

   

   Reviewing the Default Alert Rule

   After accessing the Alert Rules page, you will see that an alert rule has been created by default for your availability test.

   1. Identify the Alert Rule
      Locate the alert rule associated with your test (e.g., "classic-monitor"). The rule specifies the condition, such as "Failed locations >= 2," which triggers an alert when two or more locations report a failure.

   2. Click to Review or Edit
      Click on the alert rule to review its details or make changes as needed, such as modifying the notification settings or thresholds.

Creating an Action Group

1. Open Action Groups
   After clicking on the alert rule, navigate to the Action groups section.

2. Create a New Action Group
   At the top of the page, click on Create action group. An action group defines a set of notifications and actions to take when the alert is triggered.

   

   Configuring Action Group Basics

   1. Select Resource Group
      Choose an existing resource group or click Create new to create a new one for the action group.

   2. Name Your Action Group

      • Enter a name for your action group (e.g., "RabiatuAG") in the Action group name field.

      • Provide a short Display name (e.g., "Rabiatu-team") for easy identification in notifications.

   3. Proceed to Notifications
      Click on the Next: Notifications button at the bottom of the page to proceed to the next step.

Configuring Notifications

1. Select Notification Type
   For this demo, choose the Email/SMS/Push/Voice notification type from the dropdown menu.

2. Input Notification Details

   • Under Name, enter the name of the recipient or the group responsible for handling alerts (e.g., "Rabiatu").

   • Tick the Email checkbox and provide the email address to be notified when an alert is triggered.

3. Save Notification
   Once the email address is entered, click the OK button to save your notification settings.

4. Proceed to Actions
   After saving the notification settings, click on the Next: Actions button at the bottom of the page to continue.

Configuring Actions

1. Select Action Type
   On the Actions page, you have the option to choose from various action types, such as:

   • Automation Runbook

   • Azure Function

   • ITSM Integration

   • Logic App

   • Webhook

For this demo, we’ll keep it simple and only configure an email notification, as set in the previous step.

2. Skip Additional Actions
   Since we are not adding any additional actions, click Next to proceed.

Reviewing and Creating the Action Group

1. Review Your Configuration
   On the Review + Create page, verify the details of your action group. This includes:

   • Basics: Subscription, resource group, region, action group name, and display name.

   • Notifications: Ensure your selected notification method (e.g., email) is correct.

2. Create the Action Group
   Once you’ve confirmed that all details are accurate, click the Create button to finalize the action group.

Confirming the Action Group

Once your action group is created, you can see it listed under the Action groups section of your alert rule.

• The action group (e.g., RabiatuAG) now appears along with the configured notification type (e.g., 1 Email), as shown below.

• This confirms that the action group is ready to send notifications when the alert rule is triggered.

Email Confirmation

After creating the action group, a notification email is sent to confirm that the specified email address has been added to the action group.

• The email confirms that you are now part of the action group (e.g., Rabiatu-team) and will receive alerts triggered by the group.

• It also provides account information, including the subscription ID, resource group, and action group name, for easy reference.

Simulating a Failure on Your Web App

To test the functionality of the availability test and alert configuration, we’ll simulate a failure by stopping the web app.

1. Navigate to Your Web App
   Go to the App Services section in the Azure Portal. Locate your web app (e.g., rabiatus-app-service) and click on it.

2. Stop the Web App
   On the web app's overview page, click the Stop button to halt the application. This simulates a failure scenario, allowing you to confirm that your alerts are working as expected.

Confirming the Web App Has Stopped

Once you click the Stop button, Azure will process the action and notify you when the web app has successfully stopped.

• Ensure you see the Successfully stopped web app notification, as shown below.

• This confirms that the web app is no longer running and simulates an application failure for testing your availability alerts.

Testing the Stopped Web App

1. Copy Your Web App URL
   Under the Default domain section of your web app's overview page, copy the URL of your web app.

2. Access the Web App in a Browser
   Paste the URL into your browser and attempt to load the application. Since the app is stopped, you should receive an error or an indication that the web app is not accessible.

Verifying the Stopped Web App

After pasting your web app's URL into a browser, you should encounter a 403 Error page, indicating that the web app has been stopped.

• The message confirms that the web app does not accept any requests and is no longer operational.

• This serves as a simulated failure scenario to test the availability test and alert system configured earlier.

Checking the Availability Test Results

1. Navigate Back to Application Insights
   Go to the Availability section in Application Insights to view the status of your test.

2. Refresh the Page
   Since the availability test runs at intervals (e.g., every 5 minutes), you might need to refresh the page a few times to see the results. Click the Refresh button to update the test data.

3. Verify the Failure
   Once the failure is detected, you will see warning icons under the Availability Test section, indicating that the web app is not available from specific locations.

   

   Receiving the Alert Notification

   Once the availability test detects a failure across locations, Azure Monitor will trigger an alert and send a notification to the configured email address.

   • The email will specify that the availability test (e.g., classic-monitor-rabiatus-app-service) has failed at multiple locations, along with details about the test interval (e.g., last 5 minutes).

   • A link is provided to view the application’s availability directly in the Azure Portal for further investigation.

Conclusion

In this blog, we explored how to configure Azure Monitor Application Insights to monitor the availability of a web app. We walked through setting up availability tests, creating action groups for alerts, and simulating a failure scenario to ensure that everything works as expected.

The availability test successfully detected the simulated failure and triggered an alert, sending a notification to the configured email. This demonstrates the power of Azure Monitor in proactively identifying and addressing application performance issues before they impact end-users.

By leveraging these monitoring tools, you can ensure your applications remain reliable, minimize downtime, and respond quickly to potential disruptions.