Hi,

Please provide below details

1.Which version of AES are you using ans It is installed on top of which PRPC?

2.What is the version of monitored node?

3.Are you monitoring only one system or different system.If different then id this issue occurs for all system?

4.Have you upgraded your AES?

5.How did you configure AES i.e using pdc landing page or updating config xml files?

You can verify its value at backend as well. 

When a Pega Platform node generates exceptions, they are sent by SOAP to the Pega Autonomic Event Services server. It parses the exceptions and stores the records in the pegaam_exception table in the Pega Autonomic Event Services database. Based upon how often an exception occurs and the system events that triggered those exceptions, Pega Autonomic Event Services aggregates these records into work objects called exception items. These items are written to the Pega Autonomic Event Services database in the pegaam_exception_work table

Please verify pegaam_exception table and pegaam_exception_work table.

Please note that duplicate alerts / exceptions should be avoided by configuring the application to be monitored by AES using only PDC landing page.

HI,

Are these exception happened only once in log file, or having same  exception multiple times?

AES creates one case for each set of uniquely 'correlated' exceptions. Ideally there will be one case created for each root issue. As each exception is processed, AES calculates a 'correlation string', then hashes the string to get the correlation value/.  On the action item, go to the Analysis tab and look for Problem Correlation / Problem String. Look at the value.

I believe the correlation string is formed using the exception class and the stack trace - basically the idea is to create one item based on what went wrong and the unique way one navigated the system to cause the issue. If you are getting a different correlation string for each incident, we have to look at the actual data and determine why either the exception itself is unique (despite having the same displayable message) or what is causing unique stack traces.

Curious - does the application make extensive use of circumstance ? Do users have delegated rulesets and unique rules per user / group? Might there be something that causes many versions of same rule / slightly different classes to be available at once?

No known bugs with correlation logic for exceptions at present but that is certainly possible. Please gather and compare correlation strings to assess whether there is a problem with the analysis. We have actually seen AES go the other way -- correlate the same exception on one item when it has more than one root cause more often than what you describe.

Any progress? Did you chose to open an SR?