QOS_POWER_STATE metric is reported to Splunk for availability monitoring. During testing, customer discovered that for newly installed robots, the QOS_POWER_STATE metric will not be visible in USM, as a result they will also not appear in Splunk.
The entry in S_QOS_DATA exists (as expected, since this data is being pushed from the hub to data_engine) but the entries in S_QOS_DATA will not have a counterpart in the CM_CONFIGURATION_ITEM_METRIC table (joined on ci_metric_id). We observed this behavior for about 10 robots, all of them installed more than 3 hours ago. Seems like discovery_server is not picking up the niscache from the hub in a timely fashion, resulting in the CM_DEVICE perspective and the corresponding CM_CONFIGURATION_ITEM_METRIC entries not being written.
Release : 9.0.2
Component : UIM - DISCOVERY_SERVER
Development normally recommends reducing the niscache update frequency which allows the discovery_server probe to work more efficiently.
1. Deactivate the discovery_server probe
2. From the discover_server probe's Raw Configure GUI, select the setup folder, then in the right-hand pane create a new section called nimbusscan
3. Select the newly created nimbusscan folder from the left-hand pane, then add the following key value in the right-hand pane:
nis_cache_update_interval_secs = 1800
The niscache polling interval controls how often the discovery_server probe calls the controller probes' _nis_cache callback to check for niscache changes. Niscache changes are not event driven. The controller needs to be polled on a regular interval to detect any niscache changes.
4. Activate the discovery_server probe.