Alerts, alert analysis tools and usage guidelines
During application processing, a sequence of text entries that are called alert messages is written to the performance alert log (usually named PegaRULES-ALERT-YYYY-MM-DD log.ru). Alert messages identify performance-related issues or errors.
Each performance alert message is named PEGAnnnn, where nnnn is the message ID that represents the system event that generated the alert. The message describes the event and contains additional information such as the value that exceeded the threshold, the type of requestor (for example, browser), and the activity or stream that triggered the alert.
Security alerts are generated when there is a potential security risk to the Pega Platform™ web node. The security alert log is usually named PegaRULES-ALERTSECURITY-YYYY-MMM-DD log. These alerts are named SECUnnnn.
The alert logs contain the following alert types. The category descriptions are displayed on the My Alerts display and in the PegaRULES Log Analyzer tool.
For a list of performance and security alerts, see List of performance and security alerts in Pega Platform.
Pega Autonomic Event Services (AES)
AES monitors, gathers, and analyzes performance and health indicators from multiple SmartBPM systems across the enterprise. AES aggregates the most serious alerts and exceptions into work items for use in a work flow that can be assigned for diagnosis and resolution. These work items include information about their severity, the likely reason for their occurrence, and suggestions on how to fix them.
An Enterprise Health console provides the current status of key system functions that indicate normal, warning, and critical conditions.
AES consolidates and summarizes the Pega log and the JVM GC log, which provide key information about each monitored node.
For more information about AES, see Introduction to Pega Autonomic Event Services.
PegaRULES Log Analyzer (PLA)
This tool consolidates and summarizes the performance alert log, the Pega log, and the JVM GC log, which provide key information about operational and system health. Developers and system administrators can use this information to quickly identify, diagnose, and remediate system and operational issues that might degrade or compromise performance, stability, and scalability.
For more information, see Understanding the PegaRULES Log Analyzer.
Recommended usage thresholds
The following table identifies the recommended thresholds to monitor when managing the performance and health of your configured application. While the Pega Platform does not prevent you from exceeding these thresholds, it is recommended that your Pega Platform applications stay within these usage guidelines for optimal performance and scaling.
| Metrics per session/hour | Maximum value | PAL value |
|---|---|---|
| Maximum bytes of data committed from browser to server | 4 MB | Number of input bytes received by the server |
| Maximum bytes of data sent from browser to server | 15 MB | Number of output bytes sent from the server |
| Interactions between server and browser | 7,500 | Number of server interactions |
| Maximum rules executed | 450,000 | Rules executed |
| Maximum declaratives executed (all types) | 45,000 | Declarative rules executed |
| Maximum context-free expressions executed | 3,500 | Context-free declarative expressions executed |
| Maximum properties tracked by declarative expressions | 60,000 | Tracked property changes |
| Maximum CPU time | 180 seconds | CPU activity time |
| Maximum number of requests to the database | 8,000 | Execution of RDB database operations |
| Maximum number of rows committed to the database | 4,500 | Database rows committed |
| Maximum number of rows read from the database | 85 MB | Bytes read from database storage stream (uncompressed) |
| Maximum data sets written to the database | 60 MB | Bytes written to database storage stream (uncompressed) |
| Maximum alerts generated | 60 | Alerts |
Additional usage guidelines
At any specific time:
- No single database query should exceed 5 seconds of CPU.
- The clipboard should not be larger than 6 MB on average.
- No single clipboard page or repeating pages should exceed 5 MB.
For any single next-best-action decision:
- Pages processed should not exceed 50,000.
- Interaction history records loaded should not exceed 500.
- Interaction history records written cannot exceed 30.
- Strategy results returned should not exceed 70.
- CPU time should not exceed 5 seconds.
- Uncached customer data loaded should not exceed 1 MB.
Previous topic Support Play: Tuning the Sun JVM 1.4.2 and 5.0 for performance Next topic Alerts for asynchronous data page processing