- play_arrow What's New for Administrators
- play_arrow Overview of JSA Administration
- play_arrow User Management
- play_arrow System Management
- System Management
- System Health Information
- JSA Component Types
- Data Nodes
- Network Interface Management
- JSA System Time
- NAT-Enabled Networks
- Off-site Hosts Management
- Managed Hosts
- Configuration Changes in your JSA Environment
- Deploying Changes
- Restarting the Event Collection Service
- Shutting Down a System
- Restarting a System
- Collecting Log Files
- Changing the Root Password on Your JSA Console
- Resetting SIM
- play_arrow JSA Set Up Tasks
- JSA Set Up Tasks
- Network Hierarchy
- Automatic Updates
- Manual Updates
- Configuring System settings
- IF-MAP Server Certificates
- SSL Certificates
- IPv6 Addressing in JSA Deployments
- Advanced Iptables Rules Examples
- Data Retention
- System Notifications
- Custom Offense Close Reasons
- Configuring a Custom Asset Property
- Index Management
- Restrictions to Prevent Resource-intensive Searches
- App Hosts
- Checking the Integrity Of Event and Flow Logs
- Adding Custom Actions
- Managing Aggregated Data Views
- Accessing a GLOBALVIEW Database
- play_arrow Event Data Processing in JSA
- Event Data Processing in JSA
- DSM Editor Overview
- Properties in the DSM Editor
- Property Configuration in the DSM Editor
- Opening the DSM Editor
- Configuring a Log Source Type
- Configuring Property Autodetection for Log Source Types
- Configuring Log Source Autodetection for Log Source Types
- Configuring DSM Parameters for Log Source Types
- Custom Log Source Types
- Custom Property Definitions in the DSM Editor
- Event Mapping
- Exporting Contents from the DSM Editor
- play_arrow Using Reference Data in JSA
- play_arrow User Information Source Configuration
- play_arrow Juniper Networks X-Force Integration
- play_arrow Managing Authorized Services
- play_arrow Backup and Recovery
- play_arrow Flow Sources Management
- play_arrow Remote Networks and Services Configuration
- play_arrow Server Discovery
- play_arrow Domain Segmentation
- play_arrow Multitenant Management
- Multitenant Management
- User Roles in a Multitenant Environment
- Domains and Log Sources in Multitenant Environments
- Provisioning a New Tenant
- Monitoring License Usage in Multitenant Deployments
- Rules Management in Multitenant Deployments
- Network Hierarchy Updates in a Multitenant Deployment
- Retention Policies for Tenants
- play_arrow Asset Management
- play_arrow Configuring JSA to Forward Data to Other Systems
- Forward Data to Other Systems
- Adding Forwarding Destinations
- Configuring Forwarding Profiles
- Configuring Routing Rules to Forward Data
- Using Custom Rules and Rule Responses to Forward Data
- Configuring Routing Rules to Use the JSA Data Store
- Viewing Forwarding Destinations
- Viewing and Managing Forwarding Destinations
- Viewing and Managing Routing Rules
- play_arrow Event Store and Forward
- play_arrow Security Content
- play_arrow SNMP Trap Configuration
- play_arrow Protect Sensitive Data
- play_arrow Log Files
- play_arrow Event Categories
- play_arrow Common Ports and Servers Used by JSA
- play_arrow RESTful API
Event and Flow Processing Capacity
The capacity of a deployment is measured by the number of events per second (EPS) and flows per minute (FPM) that JSA can collect, normalize, and correlate in real time. The event and flow capacity is set by the licenses that are uploaded to the system.
Each host in your JSA deployment must have enough event and flow capacity to ensure that JSA can handle incoming data spikes. Most incoming data spikes are temporary, but if you continually receive system notifications that indicate that the system exceeded the license capacity, you can replace an existing license with a license that has more EPS or FPM capacity.
Capacity Sizing
The best way to deal with spikes in data is to ensure that your deployment has enough events per second (EPS) and flows per minute (FPM) to balance peak periods of incoming data. The goal is to allocate EPS and FPM so that the host has enough capacity to process data spikes efficiently, but does not have large amounts of idle EPS and FPM.
When the EPS or FPM that is allocated from the license pool is very close to the average EPS or FPM for the appliance, the system is likely to accumulate data in a temporary queue to be processed later. The more data that accumulates in the temporary queue, also known as the burst-handling queue, the longer it takes JSA to process the backlog. For example, a JSA host with an allocated rate of 10,000 EPS takes longer to empty the burst handling queue when the average EPS rate for the host is 9,500, compared to a system where the average EPS rate is 7,000.
Offenses are not generated until the data is processed by the appliance, so it is important to minimize how frequently JSA adds data to the burst handling queue. By ensuring that each managed host has enough capacity to process short bursts of data, you minimize the time that it takes for JSA to process the queue, ensuring that offenses are created when an event occurs.
When the system continuously exceeds the allocated processing capacity, you cannot resolve the problem by increasing the queue size. The excess data is added to the end of the burst handling queue where it must wait to be processed. The larger the queue, the longer it takes for the queued events to be processed by the appliance.
Internal Events
JSA appliances generate a small number of internal events when they communicate with each other as they process data.
To ensure that the internal events are not counted against the allocated capacity, the system automatically returns all internal events to the license pool immediately after they are generated.
