Whether you have a scalable Azure only or hybrid environment, you want to be sure that you are maximising the utilisation of resources while also ensuring that you are not over committing on those resources resulting in poor performance. There are many tools out there for what would traditionally be called RMM – Remote Monitoring and Management – that you can consider as a service from a provider or to install and manage yourself. In this article I will take a look at how Microsoft Azure Monitor is priced and give you an insight into what you can expect in terms of the types of charges.
Azure Monitor is Microsoft’s integrated monitoring and management tool for all things Azure that can also extend to on-premise environments. It is built into your Azure Portal and provides an integrated location to capture performance data and set alerts for system events. The current version is the result of the amalgamation of the original platform with Log Analytics and Application insights as Microsoft continues to fine-tune its monitoring capabilities. The scope of Azure Monitor is wide, ranging from monitoring live web applications and container workloads to storage and virtual machines.
The system is based on a common monitoring data platform where data is drawn from various sources into one place for analysis and alerting. The core of the system is based on collecting data from Metrics and Logs.
Metrics are a measure of an operation at a point in time that are collected to show performance over time, i.e., processor utilisation. Logs are events that occurred within the system such as critical alerts, or service stop / start events. Metrics are ideal for fast detection of issues while logs are good for root cause analysis. Azure Monitor can also extend to integrate with ITSM solutions such as Service Now.
Aside from the technical merits of the solution, where things start to get tricky is when you look at how you will accumulate costs for the day-to-day operation of Azure Monitor. If you have a large environment and are not careful these costs can creep up to give you a surprise.
Like everything in Azure what you pay is a direct result of your utilisation and Azure Monitor is no different. To ensure you are getting the best value for your configuration you need to ensure your IT team are aware of how costs are incurred. Aspects of the service where you can incur costs include:
- Log Analytics
- Application Insights
- Metrics
- Health Monitoring
- Alert Rules
- Notifications
- Platform Logs
To illustrate this, I have put together a couple of scenarios on the tables below.
In the first example I am assuming a moderate sized IT operation with log collections and metrics coming from various sources and stored for a period of 12 months.
In my model I assumed I would like to keep log data for 12 months, so when forecasting my cost I must remember that the cost for storing the logs is accumulating as the months go on. Something to watch also for with Application insights. (Note: I have used North Europe pricing and included on my detailed sheet for free items such as the first 30 days retention for logs etc on the tables. I have not included the detailed tables here for brevity. Notes on the table indicate where these apply)
The first thing that struck me was the number of different items to keep track of on the billing. On the example above there are 16 different items where I can accumulate charges over the “life” of monitoring for an event. For example, I will gather data through a metric, trigger an alert for an event, and this may be dynamic, and send the alert by email and to mu mobile while logging a ticket in Service Now. This to me is basic, but in reality how I configure the system will have an real influence on what costs I’m accumulating. For example, looking at the costs for alert rules, Microsoft charge you for metric, log monitoring (incremental based on the interval checks) as well as for each dynamic threshold. This means when configuring an alert you could be adding costs to your bill and not realise it. (i.e., setting dynamic thresholds when you might not need too, or a 5 min interval or a log (€1.265 per log per month) when 15 min interval would do (€0.422 per log per month).
Already I was finding that I need to be well on top of what I am configuring if I would like to be accurate in predicting my costs!
Next, I decided to see what the costs would look like if I had a larger environment with more going on. I changed up my log analytics to the “capacity reservation” option to avail of a 15% discount on the log data ingestion charge, then increased the amount of utility costs on the other line items to reflect a larger deployment.
From the table you can see that these changes had a dramatic impact on the costs for the likes of data ingestion, storage and alert rules (for alert rules I was subjective and made the assumption if I have 100GB of log data per day I am going to have a lot of alert rules and loges to monitor and I also used a 5 min interval as opposed to 10min on the previous table).
So what is all this telling me? In my experience when it comes to monitoring and alerting tools, IT Engineers are used to going in, setting up what they need and working away in the system. The cost of the system was dealt with when signing up and it is predictable, IT Management or Procurement sorted all that out before the engineer was “let loose”. Now you have a scenario where you will not have a real handle on costs up front, and your IT engineers could inadvertently expose you to costs you had not expected. To be fair to the IT engineer, they are typically there to implement and manage the software, not think of the cost. This is a traditional disjoint that would need to be addressed when putting the system in.
In reality, if you are planning to use Azure Monitor in your environment you will need to take a new approach to determining what your costs will be. You would need to deploy, then learn as you incur cost for a lot of the elements on the tables. (e.g. possibly start with a per gb billing model for data ingestion and see what this is costing before considering the capacity reservations option, keep logs for shorter time periods etc.).
To wrap up, I think Microsoft seem to have overly complicated what should be a straightforward IT operation and don’t seem to have grasped the concept of how competing products try to simplify their billing for predictability. Microsoft appear to have missed this concept when putting together their model for Azure Monitor.
I deployed my first cloud based (called hosted back then) application and server monitoring solution in 2004. Even then the provider had a simple “per device” price model. Here we have a system that has so many underlying variable costs it means an IT team configuring the solution would need some fairly well constructed spreadsheets to even understand what costs they might be incurring.
Author: Jason Boyle, Operations Director, Aspira
