Monitoring the Microsoft AVD Broker
eG Enterprise provides a specialized Microsoft AVD Broker monitoring model for measuring the performance of the broker, and to draw administrator attention to problems in connection brokering. Figure 1 depicts this unique monitoring model.
Figure 4 : Layer model of the Microsoft AVD Broker
Each layer of Figure 1 is mapped to tests that report a wide variety of metrics on the availability, health, and overall performance of session hosts and user connections to them. With the help of these metrics, administrators can find quick and accurate answers for the following performance queries:
-
Is the AVD service accessible over HTTP/S? If so, is it responding quickly to web requests?
-
Were any errors captured by the Azure diagnostic logs recently? Were these errors service-related, feed-related, or management-centric? What are these errors, and which users caused them?
-
Did any RDP / icon feeds fail? If so, for which host pool and for which users?
-
Is any host pool unavailable currently?
-
Were any session hosts added to or removed from a host pool, recently? If so, which session hosts were added, and which were removed?
-
Were any configuration changes effected on the AVD service via API/Powershell? What types of changes were these - were they object fetches, creations, updates, or deletions? Are any of these changes suspect? Were all changes effected by authorized users only?
-
Did health checks fail on any session hosts in a host pool? If so, which checks failed, why, and on which session hosts?
-
Are all session hosts across host pools receiving heart beats? Which are the sessions hosts that are not receiving them?
-
Are any session hosts idle? Which ones are they, and which host pool do they belong to?
-
Have any session hosts disconnected from the broker? If so, which ones?
-
Are there any 'unavailable' session hosts in a host pool?
-
Did the virtual desktop agent upgrade fail on any session host?
-
Is any user taking too long to log on to an Azure Virtual Desktop? If so, who is that user, and why is his/her logon experience poor - is it because of slowness in the Microsoft-managed Azure control plane? or is it because of problems in the customer-managed network?
-
Which user's connection failed and where - i.e., on which session host? Did connections to this host fail frequently?
-
Which host pool did the problematic session host belong to? Are connections to this host pool failing repeatedly?
-
What type of connections failed the most - desktop connections? or remote application connections?
-
Were specific client types, client operating systems, and client versions behind many of the connection failures?
-
Did connections initiated by specific users fail often?
