Quick Intro to Azure Monitor
Azure Monitor is a comprehensive solution for collecting, analyzing, and acting on telemetry data from both your cloud environments and your on-premises environments.
Azure Monitor can collect data from 6 different sources:
This data includes tenant-wide services, such as Azure AD.
This includes Activity Log data and Service Health data for the resources in your subscription.
This includes Resource Logs and/or Metrics for the individual resources themselves in Azure.
This is available for most Azure services.
The options available will vary by resource type. For example, some resources may allow you to monitor both Resource Logs and Metrics, whereas some resources may only support Resource Logs.
Operating System / Guest-level
This data includes information taken from within the Operating System of a server. Some examples are performance counters, syslog data, event log data, crash dumps, and more.
You must install agents/extensions on your servers in order to collect this data. This can get quite confusing, as the current state of monitoring agents in Azure is quite a mess. For example, you may need to install up to 4 different agents on a Linux server, depending on your specific needs. Each agent would collect a different set of data and send it to a different destination.
Microsoft is attempting to simplify and solve this problem by introducing a new agent named the Azure Monitor Agent that is supposed to replace all of the previously mentioned agents. This way you would only need to install one agent and be done with it. However, Microsoft is actively working on updating this agent, and as of now it does not have all of features found on the previous agents.
Detailed application monitoring in Azure Monitor is done with Application Insights, which collects data from applications running on a variety of platforms.
The application can be running in Azure, another cloud, or on-premises.
You could also send your own custom data to Azure Monitor by way of the Azure Monitor API.
Types of data stored within Azure Monitor:
Logs can store a variety of data types that have their own structures.
On the back end, Log data is stored in one or more Log Analytics Workspaces. This brings up a few things you must decide, as a Log Analytics Workspace defines the geographic location of the data, the permissions for who can access the data, and settings such as the pricing tier and data retention. Maybe a single Log Analytics Workspace is sufficient for all of your log data, maybe you need two or more to meet your particular requirements. Please reference Microsoft's guide on how to Design your Azure Monitor Logs deployment for more information.
Metrics are simple numeric data and are more lightweight than Logs.
Metrics are stored in a fully managed time series database. In other words, you don't have to worry about the back end storage with Metrics as Microsoft manages that for you.
Metrics are capable of supporting near real-time scenarios making them particularly useful for alerting and fast detection of issues.
What can Azure Monitor do with this data?
Use Metrics Explorer to analyze your Metrics data on a chart and compare metrics from different resources.
Use Log Analytics to write log queries and interactively analyze log data by using a powerful analysis engine. This uses the Kusto Query Language (KQL).
Pin your Log Analytics query results or Metrics Explorer charts to an Azure Dashboard.
Create an Azure Monitor Workbook and combine multiple sets of data into an interactive report.
Export query results to Power BI, allowing you to use powerful visualizations and to share with users outside of Azure.
Respond / Automate
You can create a Log Alert Rule or a Metric Alert Rule that can send a notification or take an automated action based on data thresholds that you set. The automated actions can be very powerful and include things like Azure Functions and Azure Logic Apps.
Metrics can be used to automatically autoscale Azure resources. For example, maybe you configure a Virtual Machine Scale Set so that it autoscales when the CPU Metric is higher than 75%.
I think I'll wrap it up there. I feel happy that I've covered most of the high-level points of the Azure Monitor service.
I may do a deep-dive article into the various server Agents and Extensions. But, as I said above, it's quite a mess right now and would probably be a very dense and complicated article.