The cdm probe and configuration is deployed to a server using a package. Metrics are not available in Operator Console.
Checking in DrNimbus, the QOS_DEFINITION messages are seen, but QOS_MESSAGE messages are not seen on the bus.
Checking the spooler.log file, we see messages similar to the following:
DATE [0001] 5 spooler: (Metric Plugin): <METRIC_ID> (cdm) matched (0 configs)
DATE [0001] 4 spooler: (Metric Plugin): <METRIC_ID> filtering
DATE [0001] 5 spooler: (Metric Plugin): Processing pipeline finished, 0 messages output
The spooler.log entry is telling us that there is an MCS profile filtering out the cdm metrics. Checking the Monitoring Configuration in Operator Console for this robot, MCS profiles that are stuck in 'Pending' status are found for cdm. As MCS profiles will override any configuration with AC/IM, this is expected. To revert to the configuration applied via cdm packages, after removing these MCS profiles, the issue remains.
The MCS profiles for cdm were only partially deployed. Removing the pending profiles did not clean up the remnants in the plugin_metric folder. The following was still observed in the plugin_metric.cfg file:
<spooler-metrics>
<cdm>
<18246>
$setup_profile$ = 1
</18246>
<18248>
$setup_profile$ = 1
</18248>
<18244>
$setup_profile$ = 1
</18244>
<18250>
$setup_profile$ = 1
</18250>
</cdm>
</spooler-metrics>
A cdm directory in the plugin_metric folder also contained pending information.
These entries remain and are causing the spooler to filter out cdm metrics.
The issue was resolved by performing the following steps:
After doing this, we're seeing QOS_MESSAGE messages in DrNimbus. We're also seeing data in OC.
The issue with MCS profiles remaining in a pending status is addressed in CU2 (and later CU releases) as described here:
MCS Profiles stuck in pending state on DX UIM 23.4 / 23.4.1 (CU1)
It is advised that the latest CU be deployed to avoid this issue from occurring again.