In the first part of this series, we introduced the confusion and complexity that tends to occur when looking at the long list of monitoring tools available for Azure.
We then provided a list of currently available tools that we will explore further.
- Part 2: Activity Logs
- Part 3: Application Insights
- Part 4: Azure Advisor
- Part 5: Azure Alerts
- Part 6: Azure Diagnostics
- Part 7: Azure Metrics
- Part 8: Azure Monitor
- Part 9: Azure Security Center (ASC)
- Part 10: Network Watcher
- Part 11: Operations Management Suite (OMS)
- Note: Also known as Log Analytics
- Part 12: Service Health
- Part 13: System Center Operation Manager (SCOM)
We’ve already discussed Azure Activity Logs, Application Insights, Azure Advisor, Azure Alerts, Azure Diagnostics, and Azure Metrics. The next tool on the list is Azure Monitor.
If you have been following along with this series, you may have come to the (correct) conclusion, that Azure Monitor is the central plane for all monitoring toolsets (or at least is becoming that).
Azure Monitor provides infrastructure-level metrics and logs for most services and the surrounding environment in Azure. It’s good to know that Microsoft has publicly stated, for the Azure services that do not yet expose their data into Azure Monitor, they will in the future. Hence the prevailing notion the Azure Monitor is the center of all monitoring toolsets and components.
You’ll notice in the Azure Monitor overview, as has been (and will be) highlighted throughout this series, you will see individual monitoring tools/services listed within the overall solution.
Even if not all current monitoring tools or services are yet to be listed inside of Azure Monitor, start to get into the habit of using it as the starting point for all things “Azure Monitoring”, as this will become the starting point.
Here is the getting started overview documentation: https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-azure-monitor
Real Word Example
So, since Azure Monitor is the central control plane for all the other monitoring toolsets, it’s a little hard to run through an example, without going through examples of a specific toolset (which we are doing individually as part of this series).
One thing I will call out though is the fact that, aside from all the other monitoring tools being listed, we also have 2 additional options listed under Settings: Action Groups, and Auto Scale.
If you select Action Groups, you may notice something familiar (if you read Part 5: Azure Alerts of this series). You would see the Action Group we created for the Alerts we configured.
So this is where we can centrally manage all the various Action Groups that we create.
Note: Just a side note to help people relate to what an Action Group is. If you’ve used the System Center Operations Manager tool before, and have configured the Notification Subscription feature, it’s similar to that. It’s like a notification channel where you specify the type of communication (i.e. Email, SMS, etc.), and the recipient (i.e. an individual person, or a distribution list for a team of people).
Something else I found interesting is when you create a new Action Group and choose the ITSM Action Type (and click the Edit Details link), you can select the ITSM Connection you would like to use. Aside from my connection being broken in this screenshot, it’s very interesting to note that this ITSM connection is, in fact, the ITSM integration element of the Operations Management Suite (OMS). So if you’re looking to integrate Azure Monitor with your ITSM solution, you’ll have to first perform this integration configuration through OMS for it to appear in the list.
Just another side note, in case you’re curious. As of to-date, OMS integrates with the following ITSM solutions (with more to come in the future):
- System Center Service Manager (SCSM)
Here’s a starting article to help you with this type of integration: https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-itsmc-overview
Now onto the Auto Scale settings.
It’s interesting that this setting is listed here, and a part of Azure Monitor because Auto Scale isn’t really considered a monitoring solution or tool. But, if you think about it, it sort-of is. When you look at Auto Scale, it should list any Azure Web App – App Service Plans you may have in your subscription.
The reason why it could (and is) considered a monitoring solution is because the Auto Scale feature has to monitor your Web App in order to know when a condition is met, and thus trigger the auto scale reaction.
So in the case of this blog (running as an Azure Web App, having its own App Service Plan), I can set conditions (to be monitored), in order to scale up, or scale out, the services supporting this site.
The main takeaway here is: Use Azure Monitor for everything. Get into the habit of starting with Azure Monitor, even if you know you want to look at metrics, or Application Insights, etc.
It is and is further becoming, the centralized starting point, for all Azure monitoring toolsets. Who knows, perhaps in the future, some current toolsets will just be merged/rolled into Azure Monitor as a whole!
The next tool in our series will be the Azure Security Center (ASC).