qos_processor_qos_message queue is getting filled and queued up on secondary hub

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

qos_processor_qos_message is getting filled and queued up which is eventually filling the disk space.

data_engine is processing the data and its not getting queued up but our question is does QOS_MESSAGE data first go to qos_processor_qos_message queue then from here it pass on to the data_engine queue to process/insert the data in the database?

[main, qos_processor] Failed to parse connection string as : Received status (1) on response (for sendRcv) for cmd = 'get_connection_string' 
[main, qos_processor] Received status (1) on response (for sendRcv) for cmd = 'get_connection_string' 
[main, qos_processor] (1) error, Received status (1) on response (for sendRcv) for cmd = 'get_connection_string' 
[main, qos_processor] Failed to parse connection string as : Received status (1) on response (for sendRcv) for cmd = 'get_connection_string' 
[main, qos_processor] Received status (1) on response (for sendRcv) for cmd = 'get_connection_string' 
[main, qos_processor] (1) error, Received status (1) on response (for sendRcv) for cmd = 'get_connection_string' 

Environment

• Release: 20.3

Cause

• second instance of a qos_processor probe running on a secondary hub with its own data_engine

Resolution

Since this instance of the qos_processor probe was deployed on a separate secondary hub that has its own data_engine (note that running 2 data engines in the same domain is not officially supported), we deactivated the qos_processor probe and disabled its queue.

As per the customer, all of the QOS is still being copied by the data_engine and received by the qos_processor that is on the Primary hub so there is not need for it to also be deployed and running on a separate Secondary hub that is not an HA hub.