Skip to content

Configure OIA Services For Specific Deployment Requirements

Please review the values specified in the /opt/rdaf/deployment-scripts/values.yaml file on the CLI VM under the relevant service section. Adjust the configuration based on the allocated memory limits (mem_limit) and the system's desired throughput requirements.

1. alert_ingester / cfx-rda-alert-ingester

Environment Variable
 Description Default Value
INBOUND_PARTITION_WORKERS_MAX Specifies the maximum number of worker processes used for mapping inbound events received by OIA 1
OUTBOUND_TOPIC_WORKERS_MAX Specifies the maximum number of worker processes for mapping outbound requests to external systems 3

Note

Memory Considerations for Inbound Worker Processes

  • Memory Usage: Each inbound worker consumes approximately 700–800 MB of memory. Each outbound topic worker consumes approximately 150 MB of memory.

  • Sizing the Worker Pool:

    - The size of the worker is based on inbound mapping rules that typically use one or a few datasets, each around 10–20 MB in size.

    - An inbound worker is created for each partition assigned to a service instance.

    - Event sources can be assigned to partitions either: Manually check the reference guide, or Automatically by the system.

    - Based on the number of active sources and the partitions assigned to an instance, one or more worker processes are launched in the service container.

    - Therefore, the number of workers to configure should be calculated based on the available memory allocated to the service container, and the number of partitions assigned to the instance.

    - In real-world scenarios, if an instance goes down, its assigned partitions are redistributed among the remaining active instances. Therefore, it's important to maintain a sufficient memory buffer to accommodate such failover situations.

    - An outbound worker pool is created for every outbound topic. Each outbound topic worker consumes approximately 150 MB of memory. Outbound topics correspond to different ticketing request types, such as: Add, Update, Clear, Miscellaneous

    - The default pool size is 3, which translates to a maximum memory usage calculated as: 4 × OUTBOUND_WORKERS_MAX × 150 MB = 1.8 GB. In practice, memory usage typically remains around 1.2 GB, which is sufficient for most scenarios. However, if higher outbound request mapping throughput is required, adjustments to the pool size may be necessary.

  • Sample Sizing Scenario (15 Event Sources with Unique Partitions 0–14):

    - INBOUND_PARTITION_WORKERS_MAX: 1

    - OUTBOUND_TOPIC_WORKERS_MAX: 3

    - Number of Event Sources: 15

    - Total Processes: 22 (Inbound: 8, Outbound: 9)

    - Memory Utilization: 6.5 GB of 16 GB available

    - Approximate Memory Usage: 800 MB per inbound worker, 150 MB per outbound worker.

2. event_consumer / cfx-rda-event-consumer

Environment Variable
 Description Default Value
OUTBOUND_WORKERS_MAX The maximum number of worker processes to use for handling outbound requests to external ticketing endpoints like ServiceNow, MS Teams, etc 5

Note

An outbound worker pool is created for each external ticketing endpoint referenced by the outbound mapping rules configured in the system.

  • Memory Usage: Each outbound worker consumes approximately 200 MB of memory.

  • Sizing the Worker Pool: The size of the worker pool should be determined based on the number of ticketing systems defined in OIA’s outbound mapping rules. For each outbound system, requests are distributed across available service instances to improve throughput.

    - If only one ticketing system is configured, the number of workers can be set equal to the number of available processors (CPUs).

    - If multiple systems are defined, while ensuring memory usage stays within the available system capacity. calculate the worker pool size using the formula: Number of systems x OUTBOUND_WORKERS_MAX x 200 MB

  • Sample Sizing Scenario (Using 15 Workers for a single configured ticketing endpoint):

    - Number of ticketing endpoints: 1

    - Workers per endpoint: 15

    - Total processes: 17 (including 15 outbound workers)

    - Memory usage: 3.5 GB out of 6 GB available

    - Memory consumption per outbound worker: 200 MB