To configure the collection of diagnostic data, you edit settings in the CMS or gateway machine policy. Browse to the Diagnostics policy folder and edit these settings:
Defaults to 720, equivalent to 12.00 pm (noon). This setting specifies when, or how often, diagnostic data is collected. This is dependent on the Collection Frequency setting.
If the Collection Frequency (see below) is:
Defaults to 1. This setting indicates how often (in days) diagnostic data is collected.
If the Collection Frequency is zero, data is collected more frequently than one a day; this depends on the Collection Time setting—see above.
If the Collection Frequency and Collection Time are both zero, automatic scheduled collections are disabled
Defaults to zero. This setting determines how long (in minutes) the CMS or gateway spends collecting diagnostic data.
For example, if the Collection Frequency is 1 and the Collection Period is 120, then diagnostics are collected daily over a two-hour period.
If the Collection Period is zero, the server automatically calculates an appropriate collection period.
This setting is only invoked if there has been no communication between the parent and child machine. It specifies the maximum number of additional threads used simultaneously to collect and process diagnostic data from child machines. It defaults to 10.
To minimize network impact, diagnostic data is collected as part of the normal communications between a parent and its child machines. But if there has been no communication between these machines during the collection period, additional threads are created specifically to actively collect this diagnostic data.
You can increase concurrency by raising the number of collection threads. This reduces the time needed to collect the data but also has a greater impact on your network. Alternatively, you may choose to reduce the number of collection threads so that data trickles back to the parent server, lengthening the collection time but reducing network load.
Defaults to seven days. This setting is used to rectify inaccurate session records identified when processing the diagnostic data. That is, a user account is logged out of CA DataMinder but the session record on the parent server indicates the user is still logged in. For example, this may happen if problems occur when uninstalling a client machine.
How does this setting work? If diagnostic data from a child machine indicates the machine has not been running for longer than this expiry period, all open machine and user sessions for this machine are updated to the Logged Out state.
If the Session Record Expiry Period is zero, session records are never cleared by this method.
|
Copyright © 2014 CA.
All rights reserved.
|
|