XSOAR incident in Qradar

[assubramania]

Hi Team,

We are encountering a connection timeout issue when attempting to create incidents in Cortex XSOAR using a custom QRadar integration. Based on our observations, we suspect this issue is due to low IOPS on XSOAR, as low as 100, despite the IOPS being allocated as unlimited from the VM Console. We believe the low IOPS are causing delays in writing data to storage, which leads to late incident creation.

Environment Details:

Cortex XSOAR Version: [6.12 Build 857430]
Host OS: Red Hat Enterprise Linux 8.8 (Ootpa)
XSOAR Host Specs:
CPU: 16 cores
Memory: 128 GB
Storage: 2.2 TB SSD
Allocated IOPS: Unlimited (as per VM console)

Symptoms:
Connection timeout when creating incidents.
Incident creation delayed significantly.

Host Utilization (from CLI):

CPU Usage (top):

top - 18:40:08 up 8 min, 1 user, load average: 3.35, 1.94, 0.91
Tasks: 390 total, 1 running, 389 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.2 us, 0.9 sy, 0.0 ni, 78.4 id, 15.4 wa, 0.1 hi, 0.1 si, 0.0 st

RAM Usage (free -m):

Mem: 128397 MB total, 112759 MB free, 9416 MB used, 6221 MB buff/cache

Storage Usage (df -h):

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rhel-var 2.0T 499G 1.5T 25% /var

However, XSOAR app reports different numbers:

CPU Usage (XSOAR Console): 96.39%
Memory Usage (XSOAR Console): 8.48%
Storage Usage (XSOAR Console): 405.099 GB

We are not able to correlate these numbers with what is observed from the CLI. We’ve already checked the IOPS and confirmed it is set to unlimited from the VM console, and storage space seems sufficient.

Request: Could you please help us:

1. Confirm whether the low IOPS could be the root cause of the connection timeout and delayed incident creation.
2. Understand why there discrepancy between the host utilization as reported by the XSOAR app and what is seen on the host CLI.

Any suggestions and action plan urgently.

[Ivetto]

Hi,

In this case the correct assistance would be from your internal VM team so they can confirm the IOPS are as required by our documentation and if not they can implement the required changes.

Once that has been cleared, we recommend you create a case to address question 2.