Create processes profile via MCS and check for process.
Alarm is coming à ok
When the process is running again the alarm was not cleared.
A new alarm was generated with a new pid but didn't clear the original alarm.
- processes (Enhanced) MCS profile
- Testing performed with vi and cdm (nimbus (cdm) processes
- 'Track process by process Identifier ID' selected in the MCS Profile
- Generate alarm on process restart was also selected
- Process instances option was also enabled
Once the monitored process is deactivated, after approx. 1-2 minutes time, more than 1 alarm is generated due to the process being down. The alarms display different NIMIDs.
Also the 2nd alarm with a different NIMID (when tracking by PID), sometimes shows up approx. 1-2 minutes later.
- working as currently designed in MCS
Applying processes v4.82, the clear alarm was generated and the alarm was cleared.
But, if multiple processes are being monitored in a single processes profile, e.g., an application that has multiple processes or an application running multiple times on a given machine, and the processes are all being monitored under that profile, a Profile-level alarm is generated. This is currently 'working as designed' as per testing while using MCS and Non-MCS (IM).
This causes multiple alarms to be generated (1 for the profile, and 1 for the process) which is NOT ideal/optimal.
Yet, what if you are monitoring MULTIPLE processes?
Testing results: No matter HOW MANY processes are being monitored under 1 profile you only get 2 alarms, 1 for the profile and 1 for a single process. This is somewhat confusing and doesn't make sense.
This was also confirmed after testing an IM profile with the processes probe Track Process by PID option and Monitor each process instance option enabled on processes v4.80/4.82.
Hence, this is not a 'new' behavior introduced in the LATEST GA version 4.82 and it is not necessarily related to MCS templates.
For now, the workaround for this double alarm behavior is to disable Track process by Process Identifier (PID) and simply track process by name or name + command line.
Support and DEV will create a new thread for this separately to keep track and discuss how it should be changed/enhanced or what other options ad results make sense.
L1/ L2/DEV team will decide if some design changes should be made moving forward, e.g., options to send an alarm for each application process when down.