oi_connector and apm_bridge setup and best practices
search cancel

oi_connector and apm_bridge setup and best practices

book

Article ID: 412443

calendar_today

Updated On:

Products

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

Issue/Introduction

This article provides advanced guidance on setting up the oi_connector and apm_bridge for integrating DX UIM into DXOI/DXO2.

Environment

  • DX UIM 23.4.*
  • DXOI / DX02 / DX Operational Observability

Best practice for latest versions to run as of February 2026:

  • For DX UIM 23.4.4 and earlier 

  • DX UIM 23.4.5 and later
     
    • oi_connector 2.03 latest GA probe (includes previous fixes)

  • apm_bridge latest fix compatible for after Java_jre21: apm-bridge-probe-2.0.3-20251203.101929-12.zip

    • The fix listed above is merged and available in apm_bridge v2.10

Cause

  • Setup and configuration guidance

Resolution

oi_connector deployment and configuration

  1. Deployment

    The oi_connector must be on a robot connected to/under the Primary hub but ideally not on the Primary hub robot itself. It can also be installed to a secondary hub connected directly to the Primary hub.

    The oi_connector and apm_bridge should be co-located on the same robot.

    If both probes are already on the Primary Hub, then establish and use a dedicated robot for both the oi_connector and apm_bridge and deactivate the oi_connector on the Primary.

Steps required to install the oi_connector on a robot under the Primary hub

For an oi_connector instance deployed on a remote robot machine connected to the primary hub, the following keys must be set via Raw configure:

    • data_engine_address
    • primary_hub_address
    • connect_to_primary_hub

The values of the following parameters can be set from Infrastructure Manager -> Setup -> Raw Configure. To do so, deactivate if the running probe is running, set the parameter values, and activate the probe again.

For example:

data_engine_address = /<domain_name>/ <primary_hub_name>/<primary_robotname>/data_engine

primary_hub_address = /<domain_name>/ <primary_hub_name>/<primary_robotname>/hub

connect_to_primary_hub = true

IMPORTANT: Ensure you copy the certificate.pem file from the Primary hub to the dedicated robot and reference its location in the robot.cfg otherwise the oi_connector will turn red and not continue to operate. See section below for more details.

     2. Configuration

         Add/adjust the following recommended keys and value:

skip_second_pass_ci_fetch = true


The keys listed below should already be present and set in the oi_connector but it's best to double-check and adjust their values as well. These parameter values have been used in several large environments running the latest GA versions of oi_connector and apm_bridge v2.03, with great success in alleviating the axagateway.uimQos queue when it backs up and/or stops processing and turns yellow.

get_ci_details_alive_time_days = Change from 10 to 2 for large environments

qos_bulk_size = 5000

qos_payload_bulk_size = 5000

get_ci_details_by_met_id_list = true

task_count = 1000

bulk_size = 2000

db_conn_max_pool_size = 15 (Change from default of 10 to 15)

schedule_time_minutes = 300 (Change from default of 30 to 300)

       
This oi_connector parameter needs to be set to false but under good processing could be set to true.

         enable_alive_time_batches = false
         

       Change loglevel = 2 (after troubleshooting is completed)



  • The Hub Status ->Queued column should remain low when refreshed and not continue to build.
  • The queue should remain green and not turn yellow.
  • The Sent column should be continuously sending QOS messages.

      3. Check the log for OutOfMemory errors

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded 
  • If any Java memory errors exist add 2GB or more to the min and the max and deactivate the probes
  • Java best practice: keep the min and max within 2 GB of each other
  • Wait for the port and PID to drop
  • Activate the probes.

      4. CI cache refresh interval setting

Currently, the CI cache refresh runs every 30 minutes. In environments with large metadata volume (1.2M+ entries and growing), this frequent refresh gradually consumes:

    • Database connections
    • I/O resources
    • CPU cycles

Over time, this can lead to resource exhaustion and increase the likelihood of thread starvation.

As the data volume continues to grow, the refresh interval should be adjusted accordingly.

We recommend updating: ci_cache_update_thread_interval_minutes

    • Change from 30 to 1440 (24 hours)

Refreshing once every 24 hours significantly reduces DB pressure compared to the default of every 30 minutes.

Click 'Ok' to save the updated configuration.

Note that there is a file (oi_connector setup parameters) attached to this article which includes a partial extract to serve as a short example reference for the <setup> section parameter values used in a very large environment which processes millions of messages.

apm bridge deployment and configuration

When the apm_bridge is deployed on the same robot as the oi_connector, it needs the following parameters updated with the relevant information:

primary_hub_address = /<domain_name>/ <primary_hub_name>/<primary_robotname>/hub

connect_to_primary_hub = true



inventory_alive_time_days

In apm_bridge 2.03 or earlier the inventory_alive_time_days parameter is only configurable in the range of 1 to 7.

Note that the inventory related to certain probes (such as url_response and net_connect) are not being published because these probes do not periodically update the alive_time in the cm_computer_system table. Therefore, with these settings the inventory count in DX UIM may not correspond/differs with inventory count in DXO2 as it would be missing those devices.

To avoid this, the patch for apm_bridge included in this KB can be deployed: Not all devices / inventory are published from DX UIM to DXO2 

After following the steps above, if the any issues persist such as message backlog/queuing, attach the oi_connector.log and apm_bridge.log to your support case.

Compatibility of Deployment on Secondary Hubs and Robots Connected to the Primary Hub

Configure the security certificate on the secondary hub (hub->robot) or robot under the hub

  • The certificate (certificate.pem) is normally stored on the Primary Hub in the ../nimsoft/security folder.

Copy the certificate FROM the Primary hub TO the dedicated robot where the probe is deployed and add the path of the certificate pointing to the target robot's controller configuration file e.g., .../opt/nimsoft/robot/robot.cfg

For example, you may take a look at the Primary Hub's controller configuration file.

Linux robot example:

   cryptkey = /opt/nimsoft/security/certificate.pem

Windows robot example:

 

Upgrade oi_connector and apm_bridge

To upgrade oi_connector and amp_bridge follow the Best Practices to upgrade oi_connector and apm_bridge

Additional Information

  • Hardware

    • Processor speed: 2.8Ghz or higher
    • vCPUs: 24 (2 sockets × 12 cores) 

  • Network

    When the oi_connecter and apm_bridge are offloaded/deployed on a separate robot under the Primary hub, best practice is that the robot is on the same subnet.

  • Java memory settings

    Set the apm_bridge java min/max memory settings under the Startup->options section to at least 2g and 4g respectively. In larger environments with millions of QOS messages being processed through the queue, the java min/max may be set as high as 14/16GB RAM respectively but its best to track the memory usage and see how much memory the probe takes versus what it appears to need. Use Windows Task Manager and/or top command (Linux/Unix).

  • Robot system sizing (oi_connector and apm_bridge)

    Processor 3GHz or higher recommended:
    • 12 cores
    • 16-GB RAM (Consider increasing the max heap by 4 GB to use the reconciliation feature)
    • SSD: 200-GB or more

  • oi_connector queues processing

    Also note that the axagateway.uimQos queue processing can benefit from the addition of more virtual processors on the system in cases where the probe may be having difficulty with qos event processing, and/or throwing errors such as:

    [QOS_PROCESSOR_THREAD-337, oi_connector] Error while posting the qos data net.sf.ehcache.CacheException: Faulting from repository failed

  • Known issues and other potential solutions with queue processing: 

    See KB: axagateway.uimQos queue build up | oi_connector queues growing yellow not processing


Related KBs/Documents: 

    Attachments

    oi_connector setup parameters for reference get_app
    Powered by Wolken Software