Hi,
we were glad there was an option if a test turning to 'Waiting for Master' or turning from it to good was handeled as if nothing at all had happened. That means
- no overwriting of %StatusChangedTime% and other related macro variales
- no triggering of 'good' actions
- no other stuff that is meant to be set when a test truely returns to good (despite just leaving a 'wait' state) or truely turns to bad (despite entering wait state).
IMHO such a behavior/option was what the master tests initially were meant for (reducing false alerts, making results more reliable and readable, ...)
Thank you
option to ignore 'Waiting for Master' in actions completely
Dear Alex,
unluckily I deleted the "good" messages as they were trash.
They showed a %StatusChangedTime% of the last "'Wait' 2 'Good' change, not the last '"bad' 2 'good'" or '"good' 2 'bad'"change), they were fired when status went from 'wait' to 'good' etc.
Please tell me /how/ to proove these messages to you and I will.
Thank you.
P.S. Look, Alex, I have a live too and I do not deem myself too stupid (though I never wanted to mess with you in matter of success or intelligence).
Messages like yours appear to me like ones of "that bullshit does not work at all" from users to you.
P.P.S.
And, at least that will even you cannot deny:
Log Analyzer says
0.12.2012 08:57:55 Wait for Master
10.12.2012 08:58:16 Host is alive 7.44 ms
10.12.2012 09:33:27 Wait for Master
10.12.2012 09:33:37 Host is alive 7.46 ms
10.12.2012 10:15:25 Wait for Master
10.12.2012 10:17:35 Host is alive 4.20 ms
10.12.2012 10:22:25 Wait for Master
10.12.2012 10:22:39 Host is alive 68.3 ms
10.12.2012 10:40:24 Wait for Master
10.12.2012 10:43:32 Host is alive 13.2 ms
10.12.2012 11:19:16 Wait for Master
10.12.2012 11:19:24 Host is alive 7.31 ms
10.12.2012 11:36:06 Wait for Master
10.12.2012 12:06:24 Host is alive 18.9 ms
unluckily I deleted the "good" messages as they were trash.
They showed a %StatusChangedTime% of the last "'Wait' 2 'Good' change, not the last '"bad' 2 'good'" or '"good' 2 'bad'"change), they were fired when status went from 'wait' to 'good' etc.
Please tell me /how/ to proove these messages to you and I will.
Thank you.
P.S. Look, Alex, I have a live too and I do not deem myself too stupid (though I never wanted to mess with you in matter of success or intelligence).
Messages like yours appear to me like ones of "that bullshit does not work at all" from users to you.
P.P.S.
And, at least that will even you cannot deny:
Log Analyzer says
0.12.2012 08:57:55 Wait for Master
10.12.2012 08:58:16 Host is alive 7.44 ms
10.12.2012 09:33:27 Wait for Master
10.12.2012 09:33:37 Host is alive 7.46 ms
10.12.2012 10:15:25 Wait for Master
10.12.2012 10:17:35 Host is alive 4.20 ms
10.12.2012 10:22:25 Wait for Master
10.12.2012 10:22:39 Host is alive 68.3 ms
10.12.2012 10:40:24 Wait for Master
10.12.2012 10:43:32 Host is alive 13.2 ms
10.12.2012 11:19:16 Wait for Master
10.12.2012 11:19:24 Host is alive 7.31 ms
10.12.2012 11:36:06 Wait for Master
10.12.2012 12:06:24 Host is alive 18.9 ms
What settings do you use for the action?They showed a %StatusChangedTime% of the last "'Wait' 2 'Good' change, not the last '"bad' 2 'good'" or '"good' 2 'bad'"change), they were fired when status went from 'wait' to 'good' etc.
Have you checked Recurrences counter for this test?
Correct. Log records added in this case, other customers requested such behavior.And, at least that will even you cannot deny:
Log Analyzer says
0.12.2012 08:57:55 Wait for Master
10.12.2012 08:58:16 Host is alive 7.44 ms
Regards
Alex
condition: 3 consecutive 'Good', do onceKS-Soft wrote:What settings do you use for the action?They showed a %StatusChangedTime% of the last "'Wait' 2 'Good' change, not the last '"bad' 2 'good'" or '"good' 2 'bad'"change), they were fired when status went from 'wait' to 'good' etc.
Have you checked Recurrences counter for this test?
settings: send email. subject/body contains "%HostID% alive since %StatusChangedTime%".
%StatusChangedTime% in the mails is time of last WaitForMaster-->Good
I was glad that was an option too as it 'trashes' ('DOS'es) the logs for us.KS-Soft wrote:Correct. Log records added in this case, other customers requested such behavior.And, at least that will even you cannot deny:
Log Analyzer says
0.12.2012 08:57:55 Wait for Master
10.12.2012 08:58:16 Host is alive 7.44 ms
It was even better if it was optional to log the nightly 'I'm still alive' so the log finally showed only real up- and down-entries. Especially for stable tests (that fail once every few weeks) it made the log even more valuable for us.
Hope that makes some sense?
If test status changed like Bad->WaitForMaster->Good then this is correct behavior.condition: 3 consecutive 'Good', do once
settings: send email. subject/body contains "%HostID% alive since %StatusChangedTime%".
%StatusChangedTime% in the mails is time of last WaitForMaster-->Good
If test status changed like Good->WaitForMaster->Good and HostMonitor resetted Recurrences and changed StatusChangedTime counter, then something wrong.
What version of HostMonitor do you use now? Could you please export master and dependant test settings into text file and send to us (support@ks-soft.net)?
Regards
Alex
That's a pity. It's like you describe and the mails do give a wrong impression (to the manager) that the device has been 'up' in between because 1st mail says "down since 01:05:22" and the next mail (6 hours later) says "down since 04:17:55"KS-Soft wrote:If test status changed like Bad->WaitForMaster->Good then this is correct behavior.
If this is intended behavior we will have to find a way to work around it. Maybe execute some HMS script that creates/sets a global macro variable or so.
Anyway, thank you for your help!
You are welcome.
Yes, this is correct behavior.
So the problem - you don't know when device restored "good" status because check depends on another test item?
But if you do not perform test because of master check failure then probably "aggregate" status should be considered as "bad"?
In such case you may use "Synchronize counters" option.
Quote
-------------------
Synchronize counters
This option only applies to tests that have one or more master tests. When the option is turned off, and some test is not being launched because its launch condition has not been met, HostMonitors simply marks such a test with the "Wait for Master" status and does not change any counters. If, however, the option is turned on, HostMonitor will update statistics information accordingly to the Master test status. Thus, if a router on which other tests depend has been tested to a "No answer" status, HostMonitor will increment respective counters (like "Dead time", "Failed tests", etc) for router and for all dependent tests with the "Synchronize counters" option on.
-------------------
Regards
Alex
Yes, this is correct behavior.
So the problem - you don't know when device restored "good" status because check depends on another test item?
But if you do not perform test because of master check failure then probably "aggregate" status should be considered as "bad"?
In such case you may use "Synchronize counters" option.
Quote
-------------------
Synchronize counters
This option only applies to tests that have one or more master tests. When the option is turned off, and some test is not being launched because its launch condition has not been met, HostMonitors simply marks such a test with the "Wait for Master" status and does not change any counters. If, however, the option is turned on, HostMonitor will update statistics information accordingly to the Master test status. Thus, if a router on which other tests depend has been tested to a "No answer" status, HostMonitor will increment respective counters (like "Dead time", "Failed tests", etc) for router and for all dependent tests with the "Synchronize counters" option on.
-------------------
Regards
Alex