Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Pega Autonomic Event Services 7.3 architecture overview and deployment best practices

Updated on May 25, 2020

Pega Autonomic Event Services™ 7.3 is an application that monitors the performance status of your Pega Platform™ systems. You install it on a stand-alone Pega Platform server. Planning your deployment requires that you are familiar with the application's architecture, best practices that help ensure an efficient deployment, and hardware requirements.

Before making decisions about the server, database, and monitored systems, review the following information:

Architecture overview

The Pega Platform management daemon runs every two minutes and checks current system health, including memory usage, CPU usage, recent response time, requestor count, agent count, and the time of the last system pulse. When you enable integration between a monitored system and Pega Autonomic Event Services, Pega Platform sends a Health Status (HLTH0001) message to Pega Autonomic Event Services via SOAP over HTTP or HTTPS.

Pega Platform includes a ruleset, PegaAESRemote, which supports Pega Autonomic Event Services integration. When you enable integration between a monitored system and Pega Autonomic Event Services, agents in the ruleset periodically gather and push data to the application. This data includes a summary of the standard Pega Platform log usage records, a guardrail compliance report, and schema metadata, primarily index definitions. Additionally, the PegaAESRemote ruleset includes SOAP service rules that provide facilities for Pega Autonomic Event Services to send inquiry and management commands to a monitored node when the optional pull mode features are enabled and manually started.

The following image is a high-level illustration of a typical Pega Autonomic Event Services deployment, showing the relationship between the application and monitored systems.

Pega Autonomic Event Services deployment overview

Pega Autonomic Event Services deployment overview

Alert processing

When a Pega Platform system generates alerts, it writes them to the alert log and sends them by SOAP to Pega Autonomic Event Services, which parses them and stores the records in the pegaam_alert database table. Pega Autonomic Event Services evaluates alert data and triggers critical event scorecard processing for specific codes, such as PEGA0010 Agent Failure. The application parses alert-specific data to determine how to correlate alerts with the same root cause. Every five minutes, an agent aggregates recent alerts based on correlation, and either creates action items for newly observed issues or updates the action items for existing issues. Action work items are stored in table pegaam_action_work.

Exception processing

Exception processing is similar to alert processing. When a Pega Platform system generates exceptions, they are sent by SOAP to Pega Autonomic Event Services, which parses them and stores the records in the pegaam_exception table in the database. Depending on how often an exception occurs, and on the system events that triggered the exceptions, Pega Autonomic Event Services aggregates these records into work objects called exception items. Pega Autonomic Event Services writes these items to the database in the pegaam_exception_work table.

Deployment best practices

To plan your deployment appropriately and ensure optimal performance, consider the following best practices.

Deploy two instances of Pega Autonomic Event Services:

  • Production (AESPROD) – Use this instance to monitor production Pega Platform systems.
  • Non-production (AESNONPROD) – Use this instance for the following tasks:
    • Governance and monitoring of non-production systems
    • Development and testing of customizations to Pega Autonomic Event Services
    • Testing of upgrades and maintenance of Pega Autonomic Event Services
    • Testing of upgrades and maintenance of Pega Platform
    • Governance and monitoring of AESPROD

Use a load-balanced cluster with at least two nodes for AESPROD. The load balancer primarily load balances SOAP requests. Configure the device to provide sticky sessions for users.

The following image is a high-level illustration of Pega Autonomic Event Services deployment best practices.

Pega Autonomic Event Services deployment best practicesPega Autonomic Event Services deployment best practices

Hardware requirements

To create an efficient Pega Autonomic Event Services environment for monitoring Pega Platform systems, consider the minimum and optimal hardware requirements.

Minimum recommended system

For optimal performance and reliability, ensure that you use production-grade servers with load balancing and failover for monitoring production deployments. However, like any Pega Platform system, a Pega Autonomic Event Services deployment can grow based on need and resource availability, and you can start using the application on a single server to host services, agents, and the database, which is sufficient to monitor development, testing, and some small production systems. Use at least the following hardware:

  • One server to host the database and web application server
    • 4 virtual processors (vCPUs)
    • 12 GB RAM
    • 250 GB disk space
  • 100 GB database
  • Web application server with 4 GB heap space

Optimal high load and high availability system

Use a high load and high availability configuration for monitoring large numbers of systems and to provide optimal availability and reliability. At least the following hardware is required:

  • Dedicated database server host with a 200 GB database
  • Two web application server hosts to process messages from monitored systems
  • Load balancer to distribute message traffic and users across the web application servers
  • One application server to host agent (batch), text indexing, and text search processing
    • Run the web/service servers with the Java command argument -DNodeType=WebUser.
    • Run the batch server with the Java command argument -DNodeType=BackgroundProcessing,Bix,Search.
Ensure that the web and agent/indexing servers use the same resources and capacity.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us