Azure Monitor: features and limitations
Today I would like to share with you a note that appeared as a result of my little research on the key features of Azure Monitor.
Based on Microsoft docs, the key features of the tool can be described as follows:
- route - streaming data between services and notification functionality;
- store and arhive - data warehouse;
- query - providing read access to data;
- visualize - visualization, presentation and analytics;
- automate - automation and process triggers (autoscale, email, webhook);
The image below is typical for computed (executable) resources and differs from non-computed ones only in the presence of Application Logs and metrics.
This monitoring section contains information about operations performed within the framework of specific components (resources):
- Name (type) of operation;
- Who initiated it and when it was completed;
- The status of its implementation;
In addition, the following features are provided:
- Export to Storage Account & Azure Event Hub;
- Access via PowerShell & REST API;
- Addition of notification rules;
- Analysis in PowerBI;
Metrics and events
In addition to the ability to track information about the metrics and events of the Azure components used, the addition of custom custom metrics & events is also available.
If we want to take an action based on the metric value, then the alert and response system will help us with this, in the arsenal of which there is the ability to send email notifications, call a webhook or launch a logic app (using request trigger).
Thanks to log search and a specialized query language, it is possible to perform query / filter / aggregate applicable to logs and metrics, as well as visualize the final results in the required form (table, list, bar).
Horizontal scaling is based on the occurrence of one of two types of conditions:
- Based on the metric value, for example, increase the number of running instances of a resource in case of exceeding the% CPU usage or loading of RAM;
- Based on the schedule - for example, if the load on weekends is reduced, then you can reduce the number of copies to the required minimum;
Azure Service Health
Thanks to a component such as Azure Service Health, you can get timely information about technical work and failures in the Azure infrastructure that may affect the availability of services and resources deployed in the cloud. Alerts can be notifications by mail, phone or webhook.
It also gives you the opportunity to prepare in advance for Azure’s scheduled maintenance.
The delay in sending notifications about the occurrence of events can be called a restriction rather conditionally, however, a notification about the operation of a rule will be received in the interval from one to five minutes.
There is no vertical scaling - at the moment, it is possible to change the number of running instances (both up and down), but not their computing power. This is due to the restrictions imposed on this type of scaling — possible lack of hardware and the need to restart.
Not all Azure services currently place information in Azure Monitor, however, this will be implemented in the future.
Shelf life of metrics and activity log entry is limited - it is 30 and 90 days, respectively (for longer duration, you need to connect Azure storage).
In conclusion, we can say that the tool discussed in this article allows you to:
- Unambiguously answer who, when and what actions were performed applicable to resources or infrastructure;
- Receive, analyze and visualize information about the actions taken;
- Add a set of rules and actions to respond when they occur;