8.3.4.3 Processing for Purging
Upon execution of the run_alert_purge.sh
script, the Alert
Purge Utility generates a listing of actions, matches, and alerts that it needs to purge,
and records them in the <INSTALL_DIR>/
database/db_tools/logs/Alert_Purge.log
file. (The utility presumes that you
have determined the input parameters to specify what matches, alerts, and actions to purge.
The utility does not check against the data to verify what it should purge.)
Note:
To capture the SQL statements naming setlog.diagnostic=true
in the
install.cfg
.
The parameters that define what matches to purge consist of one of two possible sets:
- A Behavior Detection job ID, which the
KDD_JOB
table identifies. - A scenario ID, as defined in the
KDD_SCENARIO
table, and a date range. Behavior Detection does not support multiple scenario IDs so you should run them separately. As part of this input set, you can include an optional comma-separated list of current alert status codes.
The utility then purges actions, then matches, then alerts, according to the contents of
the KDD_AP_ACTION
, KDD_AP_MATCH
, and
KDD_AP_ALERT
tables.
The utility captures purging results and any errors in the
Alert_Purge.log
file.
Note:
The Alert Purge Utility does not purge any data from archive tables for erroneous alerts. Also, the system does not update score and previous match count values associated with generated matches and alerts since creation of the erroneous matches.Automatic Restart Capability
The Alert Purge Utility has an automatic restart capability in that any interruption
in the purge processing resumes at that point, regardless of the input parameters.
The system documents logs information about the interruption in the
<INSTALL_DIR>/database/db_tools/logs/Alert_Purge.log
file.
Otherwise, any restart that has not progressed to the purge component behaves as a
new processing run. The restart capability allows interrupted purges to resume at a
convenient point, but is unable to execute all desired input parameters.