In some of my previous posts I mentioned that Process monitoring is busted in Kaseya and I still stand by it, but I have some new info that may or may not be of use so here it goes.
As most of you guys will know Process monitoring can generate an Alert if a process is running or is not running. In an ideal world if you monitor for a process that is running and then that monitor would re-arm once it has stopped running however in Kaseyaland you will get an alert around every 1 minutes and 4-5 milliseconds for as long as the executable is running or not running depending what you are monitoring for.
From my research last year into this the minimum run time time for an executable file to be detected appeared to match the agent check-in time which is commonly 30 seconds. This however appears to have changed in the last 6 months or possible since my Kserver upgrade to 6.0.1 and today I found the minimum run time for process to be detected is around 60.4 - 60.5 seconds (1 minutes and 4-5 milliseconds). I found that 75 seconds could potentially give you a duplicate alert around 1/10 times, I tested this twice and got the same result.To clarify what I mean with a duplicate alert is; You run the executable and you get an alert and as soon as you see the alert you run the executable again and then you get 2 more alerts because the total time span from when you first run the executable to the second time you ran it is picked up as one executable running for around 3minutes with an alert every 60.4 - 60.5 seconds.
I ran another tests with a process that runs for 60.5 seconds also generates a duplicate alert around 1/10 times which made me come to the conclusion that there must be a cool down period after the process has stopped which i suspect could be related to the 30 second agent check-in or potentially an unknown polling time.
So in short if you decide to use process monitoring, your executable must run for at least 60.4 - 60.5 seconds (1 minutes and 4-5 milliseconds) to get an alert every time it runs. If you plan to use the "dummy" executable method to trigger Alerts via agent Procedure put a Pause in your Agent procedure of say 1-2min so that two process alerts triggered within a 30-60second window of each other does not blend and generate a 3rd False alert.
All my evidence is empirical so if you disagree and/or have proof that would correct any of my observations please feel free to add it in the comments.
Just an update on this, last night I finally upgraded my Kserver from 6.0.1 to 6.1 and after retesting this I found that my 60.5 second executable gives me 12 alerts for 10 tests meaning I got 2 false alerts. Using my 30 second executable I now get 10/10 instead of the 1/10 I got around a month ago. My Test Process monitor set has a 30second re-arm period which in theory should have given me 2 alerts per test run with my 60.5 second executable yet yesterday I got 10/10 and today 12/10 alerts per test.
The one constant out of all of this is using a 30-60 second window between tests, it definitely decreases the number of false alerts.
Great food for thought. Two questions, 1) what is your agent check in interval and 2) have you found that by adjusting the check in interval affects (effects... I can never get those straight) your results?
My other signature was way better!
1) I use the standard 30 Second check-in time.
2) Nope, I have not tried to change it as check in times as it should only affect when you receive the alerts in Kaseya and not the actual time stamp the alert occurs.
So after many months of no traction in getting Kaseya to add Procedure alerting, I have given up and decided to revisit this method of generating alerts. In the process of troubleshooting this method I have discovered or possibly rediscovered something that they don't teach in any of the Kaseya provided training.
When executing a fake process via an agent procedure the actual agent procedure will the majority of the time (or appears to) block the agent from executing the process monitoring. How I discovered this is by changing the method of executing the fake process as my default method of executing any standalone executable is the "Execute Shell Command" option. Note that the "Execute Shell Command" step will always finish after the executable task has finished, which means if you need generate an alert via a fake process your fake process has to run at least +30sec after the procedure has ended.
The easiest method to get around this problem is to use the "Execute File" option and to not tick the "Wait for the program to complete before continuing" check box.
I tested this last night by scheduling 1min fake process to run execute every 30min and applied a monitoring set with a 1min 30sec re-arm period to avoid getting duplicate alerts and it worked perfectly.
Hope that other ppl can make use of this information.
@ HardKnox, are you still using this method for generating Alarms in Group Status Alarm for Events created by Event Log Monitoring? I created a fake process that runs for 60 seconds, created a Monitor Set that looks for that Process to be runing and has a re-arm of 90 seconds. I run the script with Execute File and I see my fake process running, but no Alarm is generated. Any idea what might be causing it not to generate the Alarm?
Weird, it appears to be working today... Is the default check-in time 30 seconds?
Sure do and its working great since I figured out the bugs.
How are you executing the fake process? The key is to execute it using the "Execute File" without using the "Wait for the program to complete before continuing" option as the procedure that executes the process will block the process monitoring sometimes and the "Execute Shell Command" step will wait until the fake process is done before it continues so the process monitoring will get blocked again.
Copyright © 2012 Kaseya International Limited. All rights reserved. Kaseya and the Kaseya k-bug logo are among the trademarks or registered trademarks owned by or licensed to Kaseya International Limited. All other brand and product names are or may be trademarks of, and are used to identify products or services of, their respective owners.