Introduction:
Following my initial three intro articles describing what is collected and how it is displayed, this article will cover the cost of these solutions.
In this section we will cover…
- The Purpose of this Article
- Prior Knowledge Requirement
- The cost of Device Inventory
- The cost of Application Inventory
- The cost of Admin Inventory
- Cost Accuracy, and What about Total Cost?
- Putting these Collectors on Different Schedules
- Conclusion
- The Next Steps
The Purpose of this Article:
In this article, I will specifically be discussing the Log Analytics Ingestion costs of these various collectors and NOT covering Function App costs (execution costs). The cost numbers I will be providing are for the US-East region which currently has a $2.30/GB charge for Analytics Logs Ingestion. The numbers I will providing will be coming from a prediction Workbook further explained in the below two articles. You can also find information on checking your regions $/GB in the below articles.
See “Cost Prediction” in: PowerShell DCR Log Analytics for Windows 365 Monitoring Part 2.1: Overview – Getting the Most Out of Azure (azuretothemax.net)
That all said, I will NOT be doing an Indepth explanation on the terminology & concepts in play here which brings us nicely to…
Prior Knowledge Requirement:
While my intro articles had a relatively low prior knowledge requirements as it doesn’t take much to understand what a graph is showing, this article does not benefit from such a low bar. There will be terminology and concepts in play that I will not be explaining as that information has already been written out in detail here: PowerShell DCR Log Analytics: Part 2.2 – Cost – Getting the Most Out of Azure (azuretothemax.net)
Again, if you haven’t followed the learning series, I highly advise that you do before getting too in-depth on this series.
The cost of Device Inventory:
So – how much does it cost to collect this Device Inventory? I really hope you read the above sections otherwise what I am about to say will sound like black magic – but thanks to my monitoring and prediction workbooks, this is a really easy question to answer. I will do a bit more explaining on this one since it’s up first though.
This collector has been running on a 4-hour schedule, on over 6,000 endpoints, and we will use the full last 30 days of that for our calculations. That’s basically as good as a sample for making predictions will get.
In total, the past 30 days of ingested data from the above (all 6,000+ devices running every 4 hours) is only 987 MB – or $2.20. That’s roughly $0.0003667 per device, per month. Starting to see why my learning series talks about how stupidly cheap this is?
Ingestion costs are extremely linear so – average the amount of MB per device over the past 30 days, then multiply that up to 25,000 devices, and this would cost about $9.01 for 25,000 devices per month. Now at that scale things are more complicated in other aspects, you might need multiple Function Apps, but the point here is that this data is not expensive as far as ingestion.
I only poll this data every four hours but again, it’s very linear here. If you want to poll the data hourly, just multiply by 4 as your now collecting the same volume of data 4x as often. That’s now $8.80 per month on 6,000 devices, and $36.04 for 25,000. That’s now roughly $0.00144 per device, per month. No advanced data license from Microsoft will ever beat this.
And if you want to run it only every 6 hours, multiply my original numbers by .66 (two thirds). You get the idea.
The cost of Application Inventory:
Same deal as far as the environment we are using to get these numbers.
This does pull a LOT more data volume in the form of shear text. 26,947.28 MB for the past 30 days. That’s $60.53. But, that’s still just $0.01009 per device, per month. 25,000 devices brings us to $146.95 per month.
If you want to poll this hourly, again multiply by 4. At 6,000 devices it’s about $242.12 per month total, or $0.04 per device, per month. Again, really not that bad.
The cost of Admin Inventory:
This one is basically free. Same deal as far as the environment we are using to get these numbers.
326.3 MB for the past 30 days. That’s $0.73 per month, just $0.000122 per device, per month. 25,000 devices brings that up to about $2.98 per month.
If you want to poll this hourly, again multiply by 4. At 6,000 devices it’s about $2.92 per month, or $0.0004 cents per device, per month. Again, really not that bad.
Note: Believe it or not, the cost of this collector in this particular environment is running a bit higher than normal due to some recent deployments of several additional accounts/groups to all devices. I would honestly expect this to be on the high side compared to the average environment.
Cost Accuracy, and What about Total Cost?
Are you sure these predictions are accurate? What about the total cost including the Function App?
Update: I finally got the numbers I needed to complete this section. Since it’s been a while since I originally wrote the article, I may end up repeating details somewhat in this section.
Are you sure these predictions are accurate?
Truth be told, this is not a yes or no question. The best answer I have to that question is an explanation.
The workbook I use to monitor and predict costs shows a past 30-day ingestion cost of $105.46 for all my tables, including others beyond what is being covered here. Azure itself shows a cost of $105.06. I can tell you that the slight variance is because the Log Analytics cost is exactly-now through exactly-now-30-days-ago. Meaning, if I look at the cost at 4 PM, it’s showing the cost of 4 PM today through 4 PM 30 days ago. Whereas cost analysis uses now (4 PM in my example) through the start (midnight) of whatever day was 30 days ago. So, Cost Analytics is seeing an extra 16 hours of ingestion in this example that Log Analytics can’t. Hence a little extra cost shows up.
Back to my point though, we can see that the workbook does understand how many MBs are coming in and can then easily do the math to figure out the cost of that in my region. The workbook also can see how many individual devices are reporting into a given table. From that, it can find the average MB a single device is sending in. That average multiplied by how many devices you have is how we make our prediction.
The good news is that predicting the ingestion cost is a linear calculation. If you’re going to ingest twice as much, it will cost twice as much. That said, the calculation is reliant on good sample data giving you a good average MB per device. If for some reason every machine in your environment has 500 pieces of software, something totally unlike the 6,000+ devices used to make the sample data that provided the predictions here, your numbers will be different. At the end of the day, these numbers are the most accurate prediction numbers I can provide, and that’s as good as it’s going to get.
What about the total cost including the Function App?
I have a singular Function App in my environment. It’s hit by roughly 150,000 calls every 24 hours. At the given device count & run intervals described above, I can only account for about 108,000 (6,000 * 6 times a day * 3 calls per single run), or roughly 72% of those calls, belonging to these three collectors. We will have to assume that single day percentage is a relatively accurate number for the whole month percentage too.
In the past 30 days, the App Service Plan has cost $37.54, and the storage account for the Function App is another $12.09, bringing our total to $49.63. Saying that this means the above 3 collectors running on the schedule I described must thus cost $35.73 a month (72% of the total) is not accurate. Unfortunately, that’s likely as close as we will get. This is because, unlike ingestion costs, Function Apps are a pain to predict. You get a certain number of executions for free each month (200,000 I believe), part of the cost is from execution time, part is from memory, part is from bandwidth. At the end of the day though, I think this number will still give you confidence this isn’t likely to break the bank. For more information, you can see this article.
Putting these Collectors on Different Schedules:
Something I want to note now. These collectors actually all run off one singular script. So, typically all three of these get deployed on the same schedule. However, if you need to, you can enable/disable any combination of the three collectors in the script, then deploy multiple versions with different on/off combinations to get different schedules between the three. What I just said will make a lot more sense to someone who has gone through the learning series.
Conclusion:
It’s CHEAP. Do I really need to say anything else?
The Next Steps:
See the index page for all new updates! Hopefully, the next article will be getting into actual setup!
Log Analytics Index – Getting the Most Out of Azure (azuretothemax.net)
I will be putting the Windows Endpoint guides on the Log Analytics Index page under the Win365 series.
Disclaimer:
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 