No data available in DX O2 dashboards for UIM servers and groups
search cancel

No data available in DX O2 dashboards for UIM servers and groups

book

Article ID: 434835

calendar_today

Updated On:

Products

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

Issue/Introduction

There is no data available in DX Dashboards for UIM Servers and Groups for DX Operational Observability (SaaS) 26.1.1

Environment

  • DX Operational Observability (SaaS) 26.1.1
  • UIM 23.4 CU 5
  • oi_connector 2.03
  • apm_bridge 2.03

Cause

  • HA Hub repurposed for dedicated oi_connector and apm_bridge 

Resolution

Since the customers' HA hub was originally 'repurposed' as a dedicated server and we were having some issues getting it to open the config via the AC without throwing a PPM MONS-021 (connectivity) error which mentioned the Primary hub NimBUS address, we decided to use a pure dedicated robot for deployment of the apm_bridge.

No matter what we tried to adjust the configuration of apm_bridge or ppm on the admin console would not open the apm_bridge configuration . It threw a  PPM-020 error on the server.

Unable to read configuration

Server Error: Unsupported adapter request for probe at address /<Domain>/<Primary_hub>/<robot>/apm_bridge
 Please use either the Thick Client or Raw Configure for this probe

 PPM-020

We then had to do the following:

1. Open Raw Configuration in PPM probe of the Primary hub

2. Navigate to:

setup → adapter_list

3. Updated the adapter_list to include the required apm_bridge version 2.03 in this case. Then the config opened in the AC.

We configured the apm_bridge probe, saved the configuration and confirmed that the Inventory and Groups were being populated.

We identified that the problem with no data due to apm_bridge was likely caused by an incorrect or most likely expired tenant token, which was resolved by generating a new token and updating the configuration. 

We discovered that moving apm_bridge to the primary hub instead of keeping it on the HA Hub server worked around the apm_bridge issues successfully. The OI Connector should remain on the dedicated server due to its higher resource requirements.

We also found that PPM configuration was causing issues with admin console access, which was resolved by removing the unnecessary PPM instance on the dedicated server and updating configuration settings. Actually as it turns out, the dedicated server/HA hub, didn't have the required adminconsoleapp packages loaded as per the controller->Status->Installed packages. We noticed that while the PPM was successfully removed from the dedicated server, the system was still attempting to use/reference the ppm instance on the HA hub, leading to ongoing configuration issues.

Throughout the troubleshooting process, we observed that data flow had been interrupted for several days before the token issue was addressed, with only limited historical data (7 days) being available in the system.

Noted that after configuration and stability are confirmed, the loglevel for OI connector should be reduced to 1 or 2 to prevent any adverse effects.

We applied the OI connector best practice settings and validated their effectiveness. After we adjusted the settings according to the best practices KB these settings work great most of the time in large environments:

oi_connector and apm_bridge setup and best practices

We also emptied the queue a few times and it began processing QOS quickly and continued to do so.

Once we reverted the apm_bridge back to the dedicated robot not the repurposed HA hub and confirmed data flow and stability, we also validated that groups and inventory were populating correctly.

Additional Information

Final disposition: we reverted back from the customer's need to run the apm_bridge on the Primary hub due to not seeing the data once again, to deploying apm_bridge on a dedicated robot under the Primary. The persistent issue was actually with the UIMAPI. A mix of HTTP and HTTPS was configured/being used for the OC and AC urls configuration when configured in the Admin Console. They both need to use SSL not have a 'mix of SSL and non-SSL' as this caused issue with the getAllGroups UIMAPI callback. Once reconfigured, and connectivity was tested and verified via the AC, all of the Groups were visible in the AC window and the data was populating in DX02.