To test the HA crossover connection, here are some commands to verify that your crossover is working and sending data.

How to deternine what QRadar processes are using the most resources.

Is there a command I can run as a customer to help me understand when a certain process is running out of memory?

Visit some of our other Support 101 Pages created specifically to assist customers in answering questions and reach a faster resolution to QRadar topics. We continually work to add more content to deliver value to our customers. These topics can be accessed from any of the QRadar 101 pages top menu bar.

The content below includes a list of all technical notes published under QRadar by category and sorted by popularity. Users can expand or collapse each section below using the + / - buttons. As new documentation is released, this content will be updated and new articles added. Click Expand All before starting a CTRL-F search.

Many users have had issues with incorrectly auto detected log sources.  In some extreme cases, incorrectly detected devices can have a major performance impact, which would lead to degradation on ecs-ec. The solution for this problem was to move this configuration into the database.

How does QRadar handle events or flows that temporarily exceed my license limit?

The QRadar Support team writes articles for users to assist with technical resolutions or common problems. This page includes a searchable list of all published articles. Users can filter the table by keyword to quickly locate support write-ups.

In this post my intention is just to give some quick points on QRadar High Availability (HA)

1.    HA Overview
    -    Uses Primary and Secondary HA hosts
    -    Uses Virtual IPs
    -    Network connectivity is tested via hearbeat (pings) to all managed hosts
    -    HA Can be configured for either  console or managed host
    -    Both devices must have the same versions of the software
    -    Both devices must support the same DSM, scanner and protocols RPMs
    -    Uses data synchronization or shared external storage 
    -    Consistency is maintained locally by using Distributed Replicated Block Device (DRDB)
    -    If using external storage data consistency is maintained through iSCSI or Fibre Channel
    -    Data is synchronized in real time
    -    Note: Asset profiler can impact DRDB speed
    -    "/store" partition on secondary is automatically replicated to the secondary host
    -    Ensure min 1 Gbps between primary and secondary HA hosts
    -    Initial synchronization can take greater than 24 hours
        This may be an understatement. I've seen initial synchronization take upwards of 72 hours.
    -    Secondary host goes into "standby" after synchronization
    -    Primary HA hosts status becomes "offline" when restored from a failover
    -    Primary needs to be placed "online" before it becomes active
    -    Disk replication is enabled while primary is "offline"
    -    Post disk failover synchronization is faster
    -    Basically uses deltas
    -     When the primary host is restored, only the data collected by the secondary during the period the primary was unavailable is synchronized
    -    Replacing or reformating the disk on the primary can result in longer synchronization time in the event of a failback

    IP Considerations
        -    Uses Virtual IPs
        -    Needs 3 IP address - VIP, Primary and Secondary
        -    The IP address initially configured on the primary host is automatically made the cluster VIP
        -    A new IP will need to be assigned to the primary once HA configuration is started
        -    Primary host can act as a standby for secondary 
        -    VIP is used by a host that has a status of active
        -    All IPs must be in the same subnet
        -    Latency must be less than 2ms for traffic crosing the WAN

    HA Wizard
        -    Used to configure Primary, Secondary and cluster VIP
        -    Verifies the secondary has a valid HA activation key
        -    Verifies the secondary is not part of an existing HA cluster
        -    Verifies software version is the same on both devices
        -    Verifies external storage (if configured) on primary and then secondary
        -    Verifies both support the same DSM, scanner and protocol RPMS

    Failover scenarios
        -    Power supply failure
        -    network failure (detected by connectivity tests)
        -    OS malfunction that delays or stops hearbeat tests
        -    RAID failure
        -    Manual failover
        -     Management interface failure on primary hosts

        -    Primary does not take back its role as primary in the case of a failover. 
        -    Secondary stays as primary while primary acts as standy
        -    Primary must be switched to "active" to take over its role

        -    No failover for software errors or disk capacity issues
        -    If both primary and secondary are unable to ping a managed hosts no failover occurs
        -    If primary cannot but secondary can ping a managed host, failover occurs

    HA Failover event sequence
        -    File systems are mounted
        -    Management interface alias is created eth0 is eth0:0
        -    VIP is assigned to the alias
        -    QRadar services are started
        -    Secondary connects to console and downloads configuration files

    Tips for manual synchronization
        -    Ensure primary and secondary hosts are sync'd
        -    Secondary must be in standby
        -    Secondary to offline and power off the primary
        -    DO NOT MANUALLY FORCE FAILOVER DURING PATCHES OR SOFTWARE UPGRADES

2.    HA Planning
    -    File systems on both devices much match - ext-3, etc
    -    Secondary's "/store" partion must be equal to or greater than the primary
    -    Both devices should have the same number of interfaces
    -    Both must use the same management interface
    -    Only 1 VIP
    -    Port 7789 is needed for Distributed Replicated Block Device (DRDB)
    -    DRBD traffic is bidirectional
    -    Disk replication ensures software updates are applied to the secondary
    -    Ensure the host has a valid activation key

3.    HA Management
    -    Uses System and License management window to:
        -    monitor HA
        -    Force failover
        -    Disconnect cluster
        -    Modify cluster settings
        -    Modify heartbeat interval
        -    Place the device in "offline" mode before maintenance

Administrators looking for the latest firmware downloads can review this page to locate firmware updates for QRadar appliances. The installation instructions include a direct download link to the firmware from IBM Fix Central.

How do I locate known issues or open defects logged against QRadar?

What is the impact of initiating a Deploy Full Configuration on QRadar systems?

After Administrative actions a "Deploy Changes" may be required. This article provides information on when to either perform a "Deploy" or "Deploy Full Configuration" and their impact on your QRadar services.

I provide support for european customers of QRadar and all of the family products (QVM, QRM, QRIF, QNI). Nowadays, I am more IT consultant than Civil engineer (MSc Eng), but I still have great passion for all reinforced concrete construction around the world.

The version  of the DSA utility differs based Operating systems and appliance Model types. QRadar 7.2.x uses a different build than QRadar 7.3.x.  M3 and M4 appliances use a different build of the DSA than M5+ appliances. This technote lists the builds required for your base Operating and Appliance type.

QRadar: HA synchronization progress resets to 0%

What are the sequence of events during an High-Availability (HA) failover and how are these experienced?

Events are being dropped on Console with Pipeline NATIVE_To_MPC messages.