Alex,
We have alert profiles that we use on many tests. For example
1 Failure / 2 rechecks then email if OK. another might be
2 Failure / 2 rechecks then email if OK.
Upon failure some (many) tests just send an email message, these work fine. But in others tests we need to perform an action in addition to sending an email message. For example restart a service. If we could have Two or more alert profiles for a given test, it would be more organized so for example:
On one test we would have
Alert Profile 1: 1 Failure / 2 rechecks then email if OK
Alert Profile 2: Restart SQLServer Service
On another test we would have
Alert Profile 1: 1 Failure / 2 rechecks then email if OK
Alert Profile 2: Restart IIS Service
In this way we could continue to use Alert Profile 1 on many tests and then have a unique second alert action specific to the current test.
Now we need to make a unique alert profile for any situation where a second action is necessary.
Regards,
Ed Schwartz
[/img]
Multiple Alert Profiles on one test
Hi
In this case, you may use any of %CommentLine% macros (e.g, %CommentLine1%) to pass the service name. Also, you may pass the computer name on which the service restarts using %CommentLine% macros, thus allowing you to restart a service remotely. That makes second alert profile unneccessary.
Regards,
Oguzhan
In this case, you may use any of %CommentLine% macros (e.g, %CommentLine1%) to pass the service name. Also, you may pass the computer name on which the service restarts using %CommentLine% macros, thus allowing you to restart a service remotely. That makes second alert profile unneccessary.
Regards,
Oguzhan
I would also very much appreciate having the ability to associate multiple alert profiles with a single test.
Running a very heterogenious environment with a combination of:
a) about 15-20 of potential "attempt-to-fix-before-alerting" action sequences (scripts) often with embedded dependencies
b) about 10 different alert profiles
would with a single action profile require 100-200 different action profiles with lots of overlaps, making the setup totally unmanageable.
A solution, which almost ideally works for us is creating separate "shadow" tests to those where additional action profiles are desired. The shadow tests are configured with a dependancy on the original test's "dead" status.
The way it works is that the original tests ae in a good status for as long as there is no problem whilst their shadow tests are in the Wait for master status.
When a problem occurs the original test goes into the Warning status for the next 2 recurrences whilst the shadow test kicks in immediately and attempts to fix the problem without doing any alerting. Only in cases when the automatic repair actions performed by the shadow tests are not successful, the original test flips from Warning to Bad and performs any alerting work configured in its profile.
Altohough this work-around does not require multiplying the alert profiles it still involves duplication of tests, which is for us a less evil option but could still be dramatically simplified by having the ability to combine multiple action/alert profiles per test. I'd be really grateful, if KS-Soft could consider this for the future development of this otherwise excellent product.
Running a very heterogenious environment with a combination of:
a) about 15-20 of potential "attempt-to-fix-before-alerting" action sequences (scripts) often with embedded dependencies
b) about 10 different alert profiles
would with a single action profile require 100-200 different action profiles with lots of overlaps, making the setup totally unmanageable.
A solution, which almost ideally works for us is creating separate "shadow" tests to those where additional action profiles are desired. The shadow tests are configured with a dependancy on the original test's "dead" status.
The way it works is that the original tests ae in a good status for as long as there is no problem whilst their shadow tests are in the Wait for master status.
When a problem occurs the original test goes into the Warning status for the next 2 recurrences whilst the shadow test kicks in immediately and attempts to fix the problem without doing any alerting. Only in cases when the automatic repair actions performed by the shadow tests are not successful, the original test flips from Warning to Bad and performs any alerting work configured in its profile.
Altohough this work-around does not require multiplying the alert profiles it still involves duplication of tests, which is for us a less evil option but could still be dramatically simplified by having the ability to combine multiple action/alert profiles per test. I'd be really grateful, if KS-Soft could consider this for the future development of this otherwise excellent product.
We have such "suggestion" item in our "to do" list.
On the other hand there is workaround - use macro variables. E.g. you may use %CommentLine3% variable as parameter for "Send e-mail" action. If some test item has e-mail address in this line, "Send e-mail" action will be executed. This way the same profile can work in different way for different tests. E.g. send SMS when triggered by testA and send e-mail when triggered by testB
Also you may use folder-level variables in the same way.
Regards
Alex
On the other hand there is workaround - use macro variables. E.g. you may use %CommentLine3% variable as parameter for "Send e-mail" action. If some test item has e-mail address in this line, "Send e-mail" action will be executed. This way the same profile can work in different way for different tests. E.g. send SMS when triggered by testA and send e-mail when triggered by testB
Also you may use folder-level variables in the same way.
Regards
Alex
Hi Alex,
Thanks for your quick reply and a suggestion.
If I understood correctly, to apply the workaround of using the conditional alert execution for running particular attempt-to-fix actions before issuing any type of alerts, I would basically need to:
1. Assign one CommentLineXX to each of the attempt-to-fix profiles.
2. Go into each of my 10 alert profiles and include actions using the advanced mode that would be executed conditionally based on a value in the respective CommentLineXX variable value.
The only drawback I can see with this work-around is that any newly introduced fix-type of action would require updating all 10 alert profiles with conditional references to the new fix action. But other than that it looks like a workable option.
Have I understood you correctly?
Thank you very much.
Jan
Thanks for your quick reply and a suggestion.
If I understood correctly, to apply the workaround of using the conditional alert execution for running particular attempt-to-fix actions before issuing any type of alerts, I would basically need to:
1. Assign one CommentLineXX to each of the attempt-to-fix profiles.
2. Go into each of my 10 alert profiles and include actions using the advanced mode that would be executed conditionally based on a value in the respective CommentLineXX variable value.
The only drawback I can see with this work-around is that any newly introduced fix-type of action would require updating all 10 alert profiles with conditional references to the new fix action. But other than that it looks like a workable option.
Have I understood you correctly?
Thank you very much.
Jan
Actually I had different option in mind...
If you want to use the same profile for different tests but you want to use different set of actions for these tests (e.g. send SMS when triggered by testA and send e-mail when triggered by testB) then you may use diferent variables as parameters of that e-mail or SMS. If macro variable used as recepients address is not specified, HostMonitor will not send e-mail.
Regards
Alex
If you want to use the same profile for different tests but you want to use different set of actions for these tests (e.g. send SMS when triggered by testA and send e-mail when triggered by testB) then you may use diferent variables as parameters of that e-mail or SMS. If macro variable used as recepients address is not specified, HostMonitor will not send e-mail.
Regards
Alex
I see. That would be well applicable to the built-in alert actions.
Would it work in the same way also for executing external scripts?
I.e. if I define "Execute external programme" as action with the parameter of %CommentLine3%, whenever a path to a shell script with parameters is specified within the test's %CommentLine3% variable it would get exectured whereas if the variable is empty the action would be ignored.
Thank you, Jan
Would it work in the same way also for executing external scripts?
I.e. if I define "Execute external programme" as action with the parameter of %CommentLine3%, whenever a path to a shell script with parameters is specified within the test's %CommentLine3% variable it would get exectured whereas if the variable is empty the action would be ignored.
Thank you, Jan