Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Limit Notifications for JSA Appliances

 

Aggregated Data Limit was Reached

38750130 - The aggregated data view could not be created due to an aggregated limit.

Explanation

The accumulator is a JSA process that counts and prepares events and flows in data accumulations to assist with searches, displaying charts, and report performance. The accumulator process aggregates data in pre-defined time spans to create aggregate data views. An aggregate data view is a data set that is used to draw a time series graph, and create scheduled reports.

The Console is limited to 130 active aggregate data views.

The following user actions can create a new aggregate data view:

  • New reports.

  • New saved searches that use time series data.

When the aggregate data view limit is reached, the notification is generated. As users attempt to create reports, or saved searches, they are prompted in the user interface that the system is at the limit.

User Response

To resolve this issue, administrators can review the active aggregate data views on the Admin tab in the Aggregated Data Management window. The aggregated data management feature provides information on the reports, searches by each aggregate data view. The administrator can review the list of aggregate data views to determine what data is most import to the users. Aggregate data views can be disabled to allow users to create a new rule, report, or saved search that requires an aggregate data view.

If the administrator decides to delete an aggregate data view, a summary provides an outline of the searches, rules, or reports affected. To re-create a deleted aggregate data view, the administrator needs only to re-enable or re-create the search, or report. The system automatically creates the aggregate data view based on the data required.

Found an Unmanaged Process That is Causing Long Transaction

38750048 - Transaction Sentry: Found an unmanaged process causing unusually long transaction that negatively effects system stability.

Explanation

The transaction sentry determines that an outside process, such as a database replication issue, maintenance script, auto update, or command line process, or a transaction is causing a database lock. Most processes cannot run for more than an hour. Repeated occurrences with the same process need to be investigated.

User Response

Select one of the following options:

  • Review the /var/log/qradar.log file for the word TxSentry to determine the process identifier that is causing your transaction issues.

  • Wait to see whether the process completes the transaction and releases the database lock.

  • Manually release the database lock by restarting the process identifier.

Long Running Reports Stopped

38750054 - Terminating a report which was found executing for longer than the configured maximum threshold.

Explanation

The system cancels the report that exceeded the time limit. Reports that run longer than the following default time limits are canceled.

Table 1: Default Time Limits by Report Frequency

Report frequency

Default time limits (hours)

Hourly

2

Daily

12

Manual

12

Weekly

24

Monthly

24

User Response

Select one of the following options:

  • Reduce the time period for your report, but schedule the report to run more frequently.

  • Edit manual reports to generate on a schedule.

    A manual report might rely on raw data but not have access to accumulated data. Edit your manual report and change the report to use an hourly, daily, monthly, or weekly schedule.

Long Transactions for a Managed Process

38750056 - Transaction Sentry: Found managed process causing unusually long transaction that negatively effects system stability.

Explanation

The transaction sentry determines that a managed process, such as Tomcat or event collection service (ECS) is the cause of a database lock.

A managed process is forced to restart.

User Response

To determine the process that caused the error, review the qradar.log for the word TxSentry.

Maximum Sensor Devices Monitored

38750006 - Traffic analysis is already monitoring the maximum number of log sources.

Explanation

The system contains a limit to the number of log sources that can be queued for automatic discovery by traffic analysis. If the maximum number of log sources in the queue is reached, then new log sources cannot be added.

Events for the log source are categorized as SIM Generic and labeled as Unknown Event Log.

User Response

Select one of the following options:

  • Review SIM Generic log sources on the Log Activity tab to determine the appliance type from the event payload.

  • Ensure that automatic updates can download the latest DSM updates to properly identify and parse log source events.

  • Verify whether the log source is officially supported.

    If your appliance is supported, manually create a log source for the events that were not automatically discovered.

  • If your appliance is not officially supported, create a universal DSM to identify and categorize your events.

  • Wait for the device to provide 1,000 events.

    If the system cannot auto discover the log source after 1,000 events, it is removed from the traffic analysis queue. Space becomes available for another log source to be automatically discovered.

Process Exceeds Allowed Run Time

38750122 - Process takes too long to execute. The maximum default time is 3600 seconds.

Explanation

The default time limit of 1 hour for an individual process to complete a task is exceeded.

User Response

Review the running process to determine whether the task is a process that can continue to run or must be stopped.

SAR Sentinel Operation Restore

38750072 - SAR Sentinel: normal operation restored.

Explanation

The system activity reporter (SAR) utility detected that your system load returned to acceptable levels.

User Response

No action is required.

SAR Sentinel Threshold Crossed

38750073 - SAR Sentinel: threshold crossed.

Explanation

The system activity reporter (SAR) utility detected that your system load is above the threshold. Your system can experience reduced performance.

User Response

Review the following options:

  • In most cases, no resolution is required.

    For example, when the CPU usage over 90%, the system automatically attempts to return to normal operation.

  • For system load notifications, reduce the number of processes that run simultaneously.

    Stagger the start time for reports, vulnerability scans, or data imports for your log sources. Schedule backups and system processes to start at different times to lessen the system load.

Threshold Reached for Response Actions

38750102 - Response Action: Threshold reached.

Explanation

The custom rules engine (CRE) cannot respond to a rule because the response threshold is full.

Generic rules or a system that is tuned can generate a many response actions, especially systems with the IF-MAP option enabled. Response actions are queued. Response actions might be dropped if the queue exceeds 2000 in the event collection system (ECS) or 1000 response actions in Tomcat.

User Response

  • If the IF-MAP option is enabled, verify that the connection to the IF-MAP server exists and that a bandwidth problem is not causing rule response to queue in Tomcat.

  • Tune your system to reduce the number of rules that are triggering.