Description: 

Experience Portal: Explanation for alarm PSESM00068 and PSESM00070

Related Articles:

https://support.avaya.com/ext/index?page=content&id=FAQ107720

Problem Clarification:

Explanation for alarm PSESM00068 and PSESM00070

Solution:

For PSESM00068 and PSESM00070, they work in a similar fashion. This throttling is done in the MPP Session Manager
PSESM00068 - Fetch error attempting to access application
PSESM00070 - Application errors occurred for an application

For example the PSESM00070, it will always appear in the MPP logs as an ERROR. The error is defined to be related to an application. So this event would be throttled on a per application basis.

• If the application produces an error condition and no previous errors then the PSESM00070 would be logged
• For a subsequent error condition for the same application that occurs within the timeframe (15 minutes) the PSESM00070 would NOT be logged
• If the application does not produce any errors for the timeframe (15 minutes) and runs successfully then the trigger is reset (next error would then log PSESM00070)

For example: from Alarm Log screen capture From Log Report for Event PSESM00070 in lab system screen captures:
Alarm Time Alarm Severity Alarm Code Event Code Event Severity Event Message Application

May 22, 2015 5:07:04 PM JST Critical QSESM00070 PSESM00070 Error Application errors occurred for application 0:myEvents 0:myEvents
May 22, 2015 4:09:08 PM JST Critical QSESM00070 PSESM00070
May 22, 2015 4:08:57 PM JST Critical QSESM00070 PSESM00070 Error Application errors occurred for application 0:testapp123 0:testapp123
May 22, 2015 4:00:39 PM JST Critical QSESM00070 PSESM00070 Error Application errors occurred for application 0:myEvents 0:myEvents
 

• Note that the earliest Alarm for QSESM00070 was at 4:00:39. And that alarm was for the application named 0:myEvents.
• Then the next QSESM00070 was logged at 4:08:57, but it was for a different application (0:testapp123) so following the algorithm described above it gets logged.
• Then another QSESM00070 was logged at 4:09:08, but this email does not contain the associated information so I cannot tell which application generated this alarm.
• Then another QSESM00070 was logged at 5:07:04, and this alarm is generated from application 0:myEvents. This is 1:07 since the previous Alarm for this application.

In a test scenario where an event was generated but not an alarm.  Here is a summary of the highlighted events.

Event Time Event Severity Event Code Event Message Session ID
May 22, 2015 5:10:09 PM JST Error PAVB_03329 TTS resource not available xxxxxxxxxxx-2015142081006-19
May 22, 2015 5:07:04 PM JST Error PSESM00070 Application errors occurred for application 0:myEvents xxxxxxxxx-2015142080658-18
May 22, 2015 5:06:58 PM JST Error PAVB_00187 Failed initializing socket for url….. xxxxxxxxxxx-2015142080658-18

• The first event PAVB_00187 is logged at 5:06:58 for session ID xxxxxxxxxxx-2015142080658-18.
• The next event PSESM00070 is logged at 5:07:04 for the same session. Note that this is several seconds after the previous. Also note that the PSESM00070 is only logged at the conclusion of the session.
• The next event PAVB_03329 is logged at 5:10:09 for session ID xxxxxxxxxxx-2015142081006-19 (different than previous). No alarm is generated because PAVB_xxxxx events do not directly generate alarms. The session is evaluated when it finishes and only logs an alarm based on the algorithm described earlier.

I want to point out that not all Events generate Alarms. And if no Alarm is generated then no SNMP notification (Trap) will be generated either. A list of possible Alarm codes can be seen from the EPM “System Configuration” > “EPM Servers” > “Alarm Codes” web page. From there each specific alarm codes can be viewed or changed from the default setting for whether it is enabled, severity, if generates a trap, trap ID, etc.

NOTE:  PSESM00070 is a general error that can be caused by many things and needs investigation.  In my case it was caused by calls being hung up before being fully established.  When the system tried to respond to the call that was no longer there we saw a media not available message.

PSESM00070 Alarms caused by errors within the Application may require further investigation by team supporting this specific Application solution.

Disclaimer: intlx Solutions Knowledge Base

The information contained in this knowledge base ("Content") is provided for informational purposes only and is intended to be a general resource. intlx Solutions does not guarantee the accuracy, completeness, or timeliness of the Content.

Use at Your Own Risk: By accessing and using the Content, you agree that you do so at your own risk. intlx Solutions assumes no responsibility for any errors or omissions in the Content, nor for any damages or losses you may suffer arising out of or related to the use of the Content.

Current Customers: If you are a current intlx Solutions customer and have questions or require further clarification on any information presented here, please do not hesitate to contact our support team directly. They are available to assist you and ensure you have the most up-to-date information specific to your needs.

Not a Customer? If you are not currently an intlx Solutions customer but are interested in learning more about our solutions and how we can help your business, please click here. We look forward to the opportunity to discuss your needs and explore how a partnership with intlx Solutions can benefit you.

Thank you for your understanding.

This article contains data that is aimed at helping fix an issue with a product. Please use this information at your own risk as intlx Solutions is not responsible for actions taken by the steps or procedures shown in these articles.