How to keep control over your Windows Virtual Desktop Insights logs and costs

In this blog-post, we will be going into more detail on which performance counters are required to fully make use of Windows Virtual Desktop insights and how to keep an eye on our monitoring costs.

Under the hood

WVD Insights (Public Preview) uses a couple of key Azure Services to provide valuable monitoring and insights over your Windows Virtual Desktop environment.

Azure MonitorLog AnalyticsAzure Workbooks

Azure Monitor for Windows Virtual Desktop uses Log Analytics to gather all of our data, and this data is split up between two major parts.

  • WVD resource diagnostics
  • Session host diagnostics

WVD resource diagnostics

To monitor and retrieve data related to the supporting WVD infrastructure, WVD resource diagnostics need to be enabled on the following levels. The following Microsoft article describes what is logged.

The amount of log data stored in log analytics varies depending on the size and amount of users that connect to your environment.

WorkspaceCheckpoint
Error
Management
Feed
HostpoolCheckpoint
Error
Management
Connection
HostRegistration
AgentHealthStatus
Application GroupCheckpoint
Error
Management

The following kusto query can help you determine the amount of data ingested into Log Analytics by the overall WVD infrastructure. Feel free to try it out on your Log Analytics workspace.

Usage
| where TimeGenerated > startofday(ago(31d))
| where IsBillable == true
| where Solution == "LogManagement"
| where DataType == "WVDFeeds" or DataType == "WVDAgentHealthStatus" or DataType == "WVDCheckpoints" or DataType == "WVDConnections" or DataType == "WVDErrors"
| summarize TotalVolumeGB = sum(Quantity) / 1000 by bin(TimeGenerated, 1d), Solution
| render barchart

When looking at the WVD resource logs, we don’t see a large amount of data stored here. As a reference case, the screenshot below provides insights on a host pool containing 2 session hosts and accessed by 10 remote app users.

Session host diagnostics

Your session hosts’ actual performance is monitored by “session host diagnostics”, we distinguish two types of data.

Event LogsPerformance Counters

Event Logs

In this blog-post, we will be focusing on the collection of performance counters. The average data ingestion of Event Logs is only a small percentage compared to the data generated by enabling the performance counters.

Performance Counters

Performance Counters and Event Logs have been around for quite some time now. Many 3rd party monitoring tools hook into the existing performance counters and logs provided by default within a Windows Operating System. Log Analytics uses the exact mechanism. With Log Analytics, you can select which counters and logs are being retrieved and at which interval they are stored in your workspace.

When monitoring your Windows Virtual Desktop environment, it’s not uncommon that you want to enable all performance counters and want to collect all logs. It’s even just a few clicks away when you look at the configuration workbook. But be warned, as you can see in the screenshots below, it’s quite an extensive list of counters and logs that we can gather.

The following table represents the list of Performance Counters enabled per Windows Virtual Desktop Session host. A total of 28 counters is what we are looking at, at a sample rate between 3060 seconds. This means every 30-60 seconds data will be ingested into Log Analytics.

ObjectNameCounterNameInterval
LogicalDiskAvg. Disk sec/Transfer60
LogicalDisk% Free Space60
Network InterfaceBytes Total/sec60
Process% User Time60
Process% Processor Time60
ProcessThread Count60
Processor% Processor Time60
SystemProcessor Queue Length60
Terminal ServicesActive Sessions60
Terminal ServicesInactive Sessions60
Terminal ServicesTotal Sessions60
ProcessIO Read Operations/sec60
ProcessIO Write Operations/sec60
LogicalDiskCurrent Disk Queue Length30
LogicalDiskAvg. Disk Queue Length30
MemoryAvailable Mbytes30
MemoryPage Faults/sec30
MemoryPages/sec30
Memory% Committed Bytes In Use30
PhysicalDiskAvg. Disk sec/Read30
PhysicalDiskAvg. Disk sec/Transfer30
PhysicalDiskAvg. Disk sec/Write30
PhysicalDiskAvg. Disk Queue Length30
Processor Information% Processor Time30
RemoteFX NetworkCurrent UDP Bandwidth30
RemoteFX NetworkCurrent TCP RTT30
User Input Delay per ProcessMax Input Delay30
User Input Delay per SessionMax Input Delay30

Small calculation

15 counters x (86.400 seconds in a day / 30 seconds) = 43200 metrics per day
13 counters x (86.400 seconds in a day / 60seconds) = 18720 metrics per day

This leads us to a total of 61920 metrics per day for 1 session host. Now, this might sound logical. However, this calculation is not correct.

When looking at the sizing estimates provided by Microsoft, the calculation is as follows:

XX MB x (number of counters) x (number of agents) x (number of instances)

So what we are missing in our calculation is the number of instances. For example, we have a counter called “% Processor Time” but this is not a single instance counter, “% Processor Time” has many underlying instances for each process that is running on the host. The following screenshot provides you with some more details on the type of instances per counter.

Since the number of instances is challenging to calculate upfront, depending on the size of your session host and the amount of users/applications/processes, in our further calculations, we will be working with averages that we’ve seen in recent environments.

The below table presents the average instances per counter on a host with 10-12 concurrent full desktop users.

ObjectNameCounterNameIntervalInstances
LogicalDiskAvg. Disk sec/Transfer6040
LogicalDisk% Free Space6030
Network InterfaceBytes Total/sec601
Process% User Time6050
Process% Processor Time6050
ProcessThread Count6050
Processor% Processor Time601
SystemProcessor Queue Length601
Terminal ServicesActive Sessions601
Terminal ServicesInactive Sessions601
Terminal ServicesTotal Sessions601
ProcessIO Read Operations/sec6050
ProcessIO Write Operations/sec6050
LogicalDiskCurrent Disk Queue Length3030
LogicalDiskAvg. Disk Queue Length301
MemoryAvailable Mbytes301
MemoryPage Faults/sec301
MemoryPages/sec301
Memory% Committed Bytes In Use301
PhysicalDiskAvg. Disk sec/Read3012
PhysicalDiskAvg. Disk sec/Transfer3040
PhysicalDiskAvg. Disk sec/Write3012
PhysicalDiskAvg. Disk Queue Length301
Processor Information% Processor Time301
RemoteFX NetworkCurrent UDP Bandwidth3050
RemoteFX NetworkCurrent TCP RTT3050
User Input Delay per ProcessMax Input Delay3030
User Input Delay per SessionMax Input Delay3050

Re-calculation

This leads us to re-calculate our previous method.

15 counters turns into a total of 374 instances (Sum of instances with a 30 sec interval)
13 counters turns into a total of 694 instances (Sum of instances with a 60 sec interval)

374 x (86.400 seconds in a day/ 30 seconds) = 1077120 metrics per day
694 x (86.400 seconds in a day/ 60seconds) = 999360 metrics per day


This gives us a total of 2076480 metrics per host per day.

Data ingestion per metric

Now that we have an average of metrics per day per session host let’s look at how much data a performance metric produces.

Credits go to Christoph Petersen, who wrote this excellent kusto query to analyze the average data ingestion per data type. The original query can be found here. I’ve made some minor changes to the query to retrieve the information we need for this use case.

let daystoSearch = 31d;
let tables = search *
| where TimeGenerated >= ago(daystoSearch)
| summarize  RecordCount=count() by $table
| project leftName=$table, RecordCount, Clause=1 ;
Usage
| where TimeGenerated >= ago(daystoSearch)
| where IsBillable == true
| where DataType !="" 
| summarize TotalSize=sum(Quantity) by DataType
| project rightName=DataType, TotalSize, Clause=1
| join kind=leftouter (tables) on Clause 
| where leftName == rightName
| project TableName=leftName , MBperRecord=round(TotalSize / RecordCount,6), RecordCount, TotalGB = round(TotalSize/1024, 6) 
| sort by MBperRecord desc
| where TableName == "Perf" or TableName == "WVDManagement" or TableName == "WVDCheckpoints" or TableName  == "WVDFeeds" or TableName == "WVDConnections" or TableName == "WVDAgentHealthStatus" or TableName == "Event"

The Log Analytics query above provides us with the following result.

On average we ingest about 0,00023 MB per performance counter metric. This leads us to the following calculation.

Final Calculation

Now that we have our data to work with let’s calculate the cost of enabling the Windows Virtual Desktop Insights performance counters on a monthly basis.

# Metrics/Day/Host = 2076480
# MB/Metric = 0,00023 MB
# Days/Month = 31

2076480 x 0,00023 x 31 = 14805,3 MB/Month

This leads us to conclude that by enabling WVD Insights, we generate an average of 14,5 GB per session host per month. When entering these details in the Azure Calculator, we end up having a cost of $28,41 per session host.

Counter update 25/03/2021

A recent update to the Azure Monitor for Windows Virtual Desktop guidelines reduces the overall costs for monitoring WVD by 80%.

In practice it reduces the costs with about 60%.

The following counters have been removed from the default set of counters deployed by the configuration workbook.   

  • Process(*)\% Processor Time 
  • Process(*)\% User Time 
  • Process(*)\ Thread count 
  • Process(*)\ IO Write Operations/second 
  • Process(*)\ IO Read Operations/second 

If you have deployed the configuration workbook in the past, you will need to manually remove the previously mentioned performance counters.

Final Calculation Update 25/03/2021

With the updated performance counters provided by Microsoft we have a new set of data to work with, let’s calculate the cost of enabling the Windows Virtual Desktop Insights performance counters on a monthly basis.

#Metrics/Day/Host = 1356480
#MB/Metric = 0,00023 MB
#Days/Month = 32

1356480 x 0,00023 x 31 = 9671,7 MB/Month

This leads us to a new calculation, concluding that by enabling WVD Insights, we generate an average of 9,6 GB per session host per month. When entering these details in the Azure Calculator, we have a cost of $13,75 per session host.

Next Steps

To keep your monitor costs under control there are a couple of next steps that you could take.

  1. Change the performance counter interval.
  2. Disable/Enable the performance counters that provide valuable insights for your specific use case.
  3. Try working with Budget Forecasting in Azure Cost Management.

Thank you!

Thank you for reading through this blog post. I hope I have been able to assist in calculating and managing monitoring costs for your Windows Virtual Desktop environment.

If you encounter any new insights, feel free to drop me a comment or contact me via mail or other social media channels

2 Comments on “How to keep control over your Windows Virtual Desktop Insights logs and costs

Leave a Reply

Your email address will not be published. Required fields are marked *

Please reload

Please Wait