Categories
General

QRadar processes

QRadar processes run on top of a linux (Red Hat 6 for versions up to QRadar 7.2.8 and Red Hat 7 for above), and each of the major functions of QRadar often run within their own java virtual machines (JVMs). This means that most of the processes are running with little to no direct effect from the other processes. QRadar main processes running on console and other components are:

  • Hostcontext
    The hostcontext process is the primary process that runs on the console and each managed host, and controls all the core qradar processes. It does not control tomcat, imq or postgres.

The hostcontext is a java process that runs as an on-going daemon. It keep tracks of other running processes that can be listed in the “COMPONENTS” line of the /opt/qradar/conf/nva.hostcontext.conf file.

# cd /opt/qradar/conf
# grep COMPONENT nva.hostcontext.conf
COMPONENT_PROCESSES=reporting_executor,accumulator.accumulator,ariel_proxy_server.ariel_proxy,passive_vis.passive,qflow.qflow0,vis.vis0,ecs

Hostcontext is also responsible for:

  1. executing deploy requests from the console & reporting status updates on deploys (remember – if you can’t deploy changes to one of components then check hostcontext service first),
  2. downloading configuration sets when changes occur,
  3. execute  database “replication” processes each minute,
  4. report the status of the host it’s running on (such as when the box reaches 95% of disk and event collection is stopped to keep integrity of the platform) , and HA peer if running in HA.
  5. Maintenance of the Ariel storage directories (such as deleting and compressing data).
  • Tomcat
    The tomcat along with httpd service are responsible for presenting content on the screen or Graphical User Interface (GUI).
  • Hostservices
    It’s a shell-script that can be found under /opt/qradar/init/hostservices. It does not run as a daemon per-say, but it’s bound to a lock file that can be found under /var/lock/subsys/hostservices, which avoids starting the service if it exists. it’s responsible for managing start and stop of underlying 3rd party services such as qdocker, imq and postgresql. During its start it makes a sanity check on IMQ and Postgres and in case problems are found with them after 7 attempts to start them, it has functions to rebuild those two.
  • Imq
    another JVM, which manages process to process communications. “internal message queue”,  it runs on all hosts.
  • Postgresql
    The postgresql platform database, contains configuration information about runtime portions of QRadar such as event mapping, QIDs, category lookups, rules, etc. It’s also responsible to store offense information, attackers, targets and assets. Can be accessed with “psql -Uqradar”, and it’s logs are available under /var/log/qradar-sql.log. It runs on all hosts and is copied over from console by replication process .
  • Ecs-ec & Ecs-ep
    In older releases of QRadar prior 7.2.2, there was only one process called ecs started by hostcontext. Now, it is split on two event collection (ec) and event processing (ep).  These are  major components in QRadar, that does all event & flow processing. If you are not seeing data on disk or in the UI, check this process first for errors. You can start the ecs process and watch for “ECS Runtime Thread” lines in qradar.log, for any errors. These are run on all event/flow processors & consoles,  but not on flow collectors.

From version 7.3.1 it is added additional process for events correlation, Ecs-ec-ingress, which is a first step on event collection and the process is managed separately from other QRadar services. To minimize interruptions in collecting event data, the service does not automatically restart when the hostcontext service restarts.

  • Vis
    The scanner component, which connects out to scanning integration points It runs on all hosts.
  • Accumulator
    Accumulator is  responsible for creating the (global view) data we use for time series graphs. It runs on console & all event/flow processors
  • Accumulator_rollup
    It runs  once per hour to create the hourly & daily rollups for accumulations. It runs on console & all event/flow processors.
  • Reporting executor
    It runs the scheduler for reporting. Will spawn “report_runner” jvm’s to run each report. Runs only on console.
  • Report runner
    It runs from the reporting_executor process, and one runs for each report. It runs only on the console.