Skip to main content

Azure Service Health Alerts

One of the first things to do once you have a Azure subscription created is to set up a service health alert. These alerts will tell you if Microsoft are doing any maintenance or having trouble with a particular service. These alerts are not designed to tell you specifically if your resources will be impacted but more as a overall health status for services so that you are aware that there are issues on the platform.

Setting up ...

First login to your subscription via https://portal.azure.com. Once you have logged in then use the search bar to locate "Service Health"

You will be taken to the Service Health blade which will show you any current issues within Azure. From here you can drill down to the data centres on the world map or see what issues that have been trigger in the last seven days. To add a service health click on "Add service health alert".

You will be taken to the "create alert rule" page. 

The rule can only target one subscription so under "subscription" select which subscription you would like to create this rule in.
Next select what "Services" you would like to be alerted on. I decided that I only want to get alerts on virtual machines as that's all I have in the subscription.
As my virtual machines are only in North Europe so I have just selected "North Europe".
For service health criteria you have four possible event type and we are interested in two of them which is "Service issue" and "Planned maintenance".
The next section is what would action would you like Azure to take when it triggers this alert rule. I am not going to go in to how to create the action group or what options you have. This article will guide you through it (https://docs.microsoft.com/en-gb/azure/azure-monitor/platform/action-groups?WT.mc_id=Portal-Microsoft_Azure_Monitoring)

Click on "Select Action Group".

Select the action group to associate with this alert rule and click "select".
Give your rule a name, any description that you want to add. Select which resource group you wish to save this rule to. Ensure "Enabled alert rule upon creation" box is checked.

Once you double checked that all the settings are how you want them to be then click on "Create alert rule".

Once the rule is created, on the Service Health blade select "Health alerts" and drill down to your subscription and you should see the alert we have just created. You will see the "details" of the alert, the settings you have defined and if you click on "history" you will see when this alert was last fired out as well.

Below is a sample alert that you may receive which you can see that it is notifying us that there is a problem with Log Analytics and Application Insights in North Europe. A tracking ID has been assigned by Microsoft which you can search for within the portal to get further updates on it.



Examples of how I have used the alerts, my team and BCDR team receives all the service outage alerts so that we can see what the trend could. It could be that we are seeing a particular services failing globally affecting one location/region slowly at a time. We can then antipcate or start to see what we can do to prevent our services from being impacted. ie start to do failovers or contact our users to let them know we could be impacted or go to manual procedures etc. We also set up a separate alert which monitors the outage/maintenance where we have deployed our resources. When we receive alerts from this rule then we would notify support teams where their resources have been deployed in those specific locations to let them know that they could be affected.

As you can see setting this up will be useful for you to receive alerts if there are any outages or maintenance planned by Microsoft which could affect the services you have deployed. Just remember to select on services and regions where you have deployed your resources otherwise you may miss an alert. 

Comments

Popular posts from this blog

Rolling back a version of ESXi

There is an option in VMware where after you have performed an major upgrade of ESXi you can roll back to your previous version. The benefit of this is that you would not need to reinstall your ESXi and its configuration if you had issues with the new software. I had to do this on one occassion in my lab where I upgraded from 6.5 to 6.7 and my VMs would not run because the CPU was not supported in 6.7. Please remember if you are using ISO method to upgrade ESXi please ensure you select "Upgrade ESXi, preserve VMFS datastore". Selecting "Install ESXi, preserve VMFS datastore" does not mean preserving datastore means retaining ESXi as it will still do a clean install of ESXi. This method does not work for vSphere 7.0 as there are changes to the partitions on the boot device. Below are the steps to roll back to a previous version which is quite straight forward. As always perform an backup of your host configuration before you upgrade or rollback ( KB2042141 ). I have

Configuring ESXi 6 host to send logs to Syslog Server

In my previous post I talked about configuring VMware Syslog server for Windows which is installed and enabled by default on installation of vCenter 6 for Windows. I will now describe the basic configuration that is required on an ESXi 6 host to be able to send logs out to a syslog server using my vCenter as the example. 1) Navigate to your ESXi host within vCenter. Go to "Manage" tab and select "Settings" followed by "Advanced System Settings". Look for the settings "Syslog.global.loghost" and highlight this settings. Click the pencil icon to edit the configuration for this setting. 2) You can now add the host name or ip address of your syslog server/s. You can enter just hostname or IP address, use udp://hostname:514 or ssl://hostname:1514 to be more specific on the port and protocol to be used. If you have multiple hosts then you use the comma (,) to separate each server i.e. udp://192.168.0.1:514,udp://192.168.0.2:514 3)We n

Custom ESXi Image - ISO using PowerCLI

There comes a time when you have purchased a new hardware to run your ESXi software and discover that the installable base media provided by VMware does not include the drivers or the drivers are out of date. In the world of Windows (Plug and Play) it would discover the hardware and prompt you to provide the drivers so that Windows would install/update the drivers for the hardware. For ESXi if the drivers are not present during load time then the hardware will possibly not work. VMware uses VIB (vSphere Installation Bundle) as a way for vendors to distribute their drivers. To install these VIBs you can either use Update Manager or command line (esxcli). Now this is all good but it does mean you have to first install the base ESXi then use one of the steps above to install/update the drivers.   Some people might feel that it is OK to update the drivers using the above methods but what if it was the network card that was the new hardware and you needed new drivers. Without the net