Separate 'Views" Using Arbitrary Set of Tests

[timn]

Alex:

Here's something to consider for a future enhancement...

I'm the technical guy and I want to define a great many tests in order to be both proactive and to help diagnose trouble when it occurs. In fact, several thousand tests are eventually likely. So I set up AHM the way I want and I'm a happy camper. I can tell pretty quickly whether a red line (i.e. 'bad result') is something to panic about or whether it's something I can fix later or ignore altogether for the time being.

Our company's security guards monitor (among other things) our network overnight. But these folks are not are not technical. I need to present them with a very simple subset of tests and give them very simple instructions -- after all, how do you quickly tell a non technical person "if a file integrity check fails on one of our web farm servers and it was expected because production had a new release today, then ignore the red line -- unless the service check test for that same machine indicates that the IIS service failed to restart, and oh yeah, server83 has been having issue with restarting IIS so if it fails, ignore it and we'll catch it in the morning"?

So I want to create a subset of my tests that the security guards can view along with some simple instructions -- "if anything in your view turns red, page us if we have not already called to inform you that we are aware of the problem".

So far so good. Now I've been researching what's available already in AHM to accomplish this and believe that currently, I have two basic options:

1. Define a report, "HTML for Security Guards" that extracts the subset of tests I want, or
2. Define NEW tests, that are duplicates of existing tests, in a new folder "Security Guard's Folder"

Each of these techniques has it's downside: With the 1st technique, I must choose between 'classes' of tests (Ping, Service, URL, etc.). But that's not what I want to present to the security guards, just certain specific Ping, service and URL tests, etc.

With the second technique, I can specify precisely what the security guards see because the tests are defined specifically for them to view. The problem here is that I'm duplicating tests, so maintenance becomes much more of an issue. For example, if I decide to raise my test interval time because I'm getting too many 'false bad' statuses, I need to remember to do this in two places if the test is also included in the security guard's view. I'm also running such tests twice as often as I really want to.

It would be nice if I could create a 'view' for the security guards that let me specify an arbitrary subset of existing tests.

Have you considered such a feature? Am I missing anything obvious?

[Marcus]

There are several ways to work around your problem. This is how I should try it:

1. Create tests for the security guards (no duplicates, just put the test for the guards in a different folder).

2. Create your own test in a different folder

3. In the root folder create 1 tests which will ping the hostmonitor server itself and on a good reply will create 2 reports in a row: Report over your test and a report over the guard tests (the second report should not contain headers but only footers and the first no footer and only headers). Add an action to combine the two reports to 1 report for yourself. Schedule this test for office hours only.

4. In the root folder create a second test, which will create a guards report, which is a complete report and schedule it for non-office hours.

Sounds logical and workable You could even let the reports be generated 24x7 and let the guards just look at a different report.

[KS-Soft]

It would be nice if I could create a 'view' for the security guards that let me specify an arbitrary subset of existing tests.

Yes, we have this idea but I don't think it will be implemented in HostMonitor 4. More likely in HostMonitor 5..

Regards
Alex

[timn]

[in my best Homer Simpson voice...]

mmmmmm... Host Monitor 5

I haven't had an opportunity yet to play with the suggestion Marcus gave above... it sound like it might be a good workaround. Probably will give it go next week.

[Flashback]

A solution I had was to assign a different Hex value to each "level" of alarm...Catastrophic alarms for example, had a value of #FF000. I store this value in one of the comment lines, and then used a custom report to call this comment line as the background color. Then all you have to do is tell them to look for the colors they need to see.