FSLogix CloudCache Event Log - AVD Test
Cloud Cache is a technology that provides incremental functionality to Profile Container and Office Container.
Cloud Cache uses a Local Profile to service all reads from a redirected Profile or Office Container, after the first read. Cloud Cache also allows the use of multiple remote locations, which are all continually updated during the user session. Using Cloud Cache can insulate users from short-term loss of connectivity to remote profile containers. Cloud Cache can also provide real time, 'active active' redundancy for Profile Container and Office Container.
Problems in Cloud Cache can either render FSLogix Profile and Office Container data unavailable, or slow to access. This in turn can leave organizations with unreliable and unresponsive storage. To avoid this, administrators should rapidly capture and troubleshoot issues with the Cloud Cache technology. The FSLogix CloudCache Event Logs, which are typically captured on each session host in an AVD host pool, are a great source of diagnostics on Cloud Cache. The FSLogix CloudCache Event Log - AVD test continuously monitors these event logs and alerts administrators to current and anticipated problems in Cloud Cache, so they can resolve the issues before any permanent damage occurs.
Target of the test : An Azure Virtual Desktop
Agent deploying the test : An internal agent.
Outputs of the test : One set of results for each POLICY FILTER configured
Parameters | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The host for which the test is to be configured. |
Port |
The default port is NULL. |
Log Type |
Refers to the type of event logs to be monitored. The default value is microsoft-fslogix-cloudcache/operational. |
Policy Filter |
This test can be configured with the event sources, event IDs, and event descriptions to be monitored. In order to enable administrators to easily and accurately provide this specification, this page provides the following options:
For explicit, manual specification of the filter conditions, you first need to select the No option against the Policy filter field. This is the default selection. To choose from the list of pre-configured filter policies, or to create a new filter policy and then associate the same with the test, select the Yes option against the Policy Filter field. |
Filter |
If the Policy Filter flag is set to No, then use the Filter text area to specify the event sources, event IDs, and event descriptions to be monitored. This specification should be of the following format: {Displayname}:{event_sources_to_be_included}:{event_sources_to_be_excluded}:{event_IDs_to_be_included}:{event_IDs_to_be_excluded}:{event_descriptions_to_be_included}:{event_descriptions_to_be_excluded}. For example, assume that the Filter text area takes the value, OS_events:all:Browse,Print:all:none:all:none. Here:
By default, the Filter parameter contains the value: all:all:none:all:none:all:none. Multiple filters are to be separated by semi-colons (;). Note: The event sources and event IDs specified here should be exactly the same as that which appears in the Event Viewer window. On the other hand, if the Policy Filter flag is set to Yes, then a Filter list box will appear, displaying the filter policies that pre-exist in the eG Enterprise system. A filter policy typically comprises of a specific set of event sources, event IDs, and event descriptions to be monitored. This specification is built into the policy in the following format: {Policyname}:{event_sources_to_be_included}:{event_sources_to_be_excluded}:{event_IDs_to_be_included}:{event_IDs_to_be_excluded}:{event_descriptions_to_be_included}:{event_descriptions_to_be_excluded} To monitor a specific combination of event sources, event IDs, and event descriptions, you can choose the corresponding filter policy from the Filter list box. Multiple filter policies can be so selected. Alternatively, you can modify any of the existing policies to suit your needs, or create a new filter policy. To facilitate this, a encircled '+' button appears alongside the Filter list in the test configuration page, once the Yes option is chosen against Policy Filter. Clicking on this button leads you to a page where you can modify the existing policies or create a new one (refer to page FSLogix CloudCache Event Log - AVD Test). The changed policy or the new policy can then be associated with the test by selecting the policy name from the Filter list box in this page. |
DD For Information |
eG Enterprise also provides you with options to restrict the amount of storage required for event log tests. Towards this end, the DD For Information and DD For Warning flags have been made available in this page. By default, both these flags are set to Yes, indicating that by default, the test generates detailed diagnostic measures for information events and warning events. If you do not want the test to generate and store detailed measures for information events, set the DD For Information flag to No. |
DD For Warning |
To ensure that the test does not generate and store detailed measures for warning events, set the DD For Warning flag to No. |
Events During Restart |
By default, the Events During Restart flag is set to Yes. This ensures that whenever the agent is stopped and later started, the events that might have occurred during the period of non-availability of the agent are included in the number of events reported by the agent. Setting the flag to No ensures that the agent, when restarted, ignores the events that occurred during the time it was not available. |
Stateless Alerts |
Typically, the eG manager generates email alerts only when the state of a specific measurement changes. A state change typically occurs only when the threshold of a measure is violated a configured number of times within a specified time window. While this ensured that the eG manager raised alarms only when the problem was severe enough, in some cases, it may cause one/more problems to go unnoticed, just because they did not result in a state change. For example, take the case of the EventLog test. When this test captures an error event for the very first time, the eG manager will send out a Critical email alert with the details of the error event to configured recipients. Now, the next time the test runs, if a different error event is captured, the eG manager will keep the state of the measure as Critical, but will not send out the details of this error event to the user; thus, the second issue will remain hidden from the user. To make sure that administrators do not miss/overlook critical issues, the eG Enterprise monitoring solution provides the stateless alerting capability. To enable this capability for this test, set the stateless alerts flag to Yes. This will ensure that email alerts are generated for this test, regardless of whether or not the state of the measures reported by this test changes. |
DD Frequency |
Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency. |
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
FSLogix CloudCache critical errors |
This refers to the number of critical FSLogix CloudCache error events that were generated. |
Number |
A critical event is one that an application cannot automatically recover from. An increasing trend or high value for this measure indicates the existence of irrepairable/fatal problems. The detailed diagnosis of this measure describes all the critical FSLogix CloudCache events that were generated during the last measurement period. Please check the Event Log Viewer for more details. |
FSLogix CloudCache errors |
Indicates the number of less-critical or non-critical FSLogix CloudCache error events that were |
Number |
Ideally, the value of this measure should be 0 or very low. |
FSLogix CloudCache information count |
This refers to the number of FSLogix CloudCache information events generated when the test was last executed. |
Number |
Track the variations to this measure to understand what type of CloudCache activities occurred recently. Please check the Event Log Viewer for more details. |
FSLogix CloudCache warnings |
This refers to the number of FSLogix CloudCache warnings that were generated when the test was last executed. |
Number |
A high value of this measure indicates problems that may not have an immediate impact, but may cause future problems. Please check the Event Log Viewer for more details. |
FSLogix CloudCache verbose |
Indicates the number of verbose events that were generated when the test was last executed. |
Number |
Verbose logging provides more details in the log entry, which will enable you to troubleshoot issues better. The detailed diagnosis of this measure describes all the FSLogix CloudCache verbose events that were generated during the last measurement period. Please check the Event Log Viewer for more details. |