Hostmonitor list based on SQL or oracle database.

[zendesigner]

Due to our contstant problems with importing through import files to the test list


Please make hostmonitor Enterprise capable by creating the possiblity to run tests from a database backend instead of a HML test list.

A database backend can easily be linked to or use tables from another database containing asset names, ip's, status, etc.

For example tests need to be removed from the test list depending on their "live" status, when a server is brought down for maintanance we need to manually remove the tests, or use difficult import export processes.

If based on SQL database status would be synchronized immediatly and tests would be removed without need of intervention or imports...

GFI has it

[KS-Soft]

Due to our contstant problems with importing through import files to the test list

What exactly the problems?

For example tests need to be removed from the test list depending on their "live" status, when a server is brought down for maintanance we need to manually remove the tests, or use difficult import export processes.

1) Why remove the test if you can disable it?
2) If HostMonitor will work with database, then you will have to manually change the record in database. The same work?
3) We are thinking about such version but it looks like we will need to develop and support 2 different packages because such solution is not good for small companies that need to monitor 5-50 servers and want small and fast application.

Regards
Alex

[zendesigner]

Hi alex,

We mostly have problems with our importing routine.

We have an oracle database that contains a view of our servers with their country, status, and some more fields for our Monitoring department to use in their alerts, like urgency and vitality. This is only a small subset of all the information contained in the assets database about the hardware/software.

A query on this database is done every 5 minutes, compared to the previous query and then test are imported / deleted from the hostmonitor. Mostly we have problems in the processing of the imports going wrong or taking to much time upsetting the routine. If a server is not removed and hostmonitor alerts to something that is on the wrong status , controlroom get annoyed about it.

For example, the helpdesk puts a server on reinstall status (maintanance) after which HM deletes the tests through the automated routine. Unfortunatly the routine failed, leaving the server tested in HM. During staging the server rebooted 13 times , giving control room 52 helpdesk tickets to check that server (server down, up, down etc...).

Basically what i'm trying to convey is that Large enterprises like here (around 3000 servers will be tested in full production, minimum of 4 tests per server) don't manually manage testing, but everthing needs to be kitted, installed automatically and run automatically.
Also hostmonitor runs in each country for their own servers. So hostmonitor install we created uses the same query but performs differently in each country , because they have their own controlrooms.

2) Having a database backend would go a long way in managing updates. We could link or sync (i'm not an sql expert??) our existing database directly with your db fields for example, making changes to our assets instantly noticable in hostmonitor.

1) The reason i delete them is to give a unified view for the control room , they might get confused otherwise (i know it sounds lame , but that's how it is here )

3) Sure i understand, no problem in having two packages and pricing tiers.

Just a thought for the future maybe

[KS-Soft]

For example, the helpdesk puts a server on reinstall status (maintanance) after which HM deletes the tests through the automated routine. Unfortunatly the routine failed, leaving the server tested in HM. During staging the server rebooted 13 times , giving control room 52 helpdesk tickets to check that server (server down, up, down etc...).

May be its better to provide access to HostMonitor? Then your admins will be able to disable/enable test items, acnowledge problems and so on.

And I think "automated routine failed" is not a good reason to change the method of storing data. SQL server can fail as well, or connection to the server, or bug in ODBC driver can lead to hardly diagnosted problems. Instead of 1 possible problem, you will have several.
BTW Why it failed?

2) Having a database backend would go a long way in managing updates. We could link or sync (i'm not an sql expert??) our existing database directly with your db fields for example, making changes to our assets instantly noticable in hostmonitor.

Sure, it has advantages. But this method has several disadvantage as well

1) Right now you cannot enter some invalid data, HostMonitor checks all parameters. If HostMonitor, some home made scripts and several admins will access open database, I am scary to imagine what data can be there.

2) Sometimes customers have problems related to 3rd party software (antivirus monitors, ODBC drivers, etc). It very hard for us to find the reason of such problem but we can deal with that, e.g. disable antivirus, disable ODBC logging and check if problem gone.
If HostMonitor will 100% depend on some database, ODBC/ADO drivers, SQL client libraries, such problem in 3rd party software will be a real nightmare

That's why we have no rush to implement this version.

Regards
Alex

[zendesigner]

May be its better to provide access to HostMonitor? Then your admins will be able to disable/enable test items, acnowledge problems and so on.


-1) Right now you cannot enter some invalid data, HostMonitor checks all parameters. If HostMonitor, some home made scripts and several admins will access open database, I am scary to imagine what data can be there.

Hi alex,

I don't think you have much experience with large enterpises and especially financial institutions. Basically everyhting is denied except explicitely needed to do your job. Jobs are spread over teams to further secure them, meaning different departments act as checks for each other.

The heartbeat testing system needs to be fully automated so that if a guy from Server helpdesk needs to reboot a machine, tests will be postponed on hostmonitor (removed/disabled). They have no access to hostmonitor only to a buttton in the asset center database. That button not only disables hostmonitor but changes backup status also for example.
Hostmonitor creates events in his event viewer that are picked up and processed by tivoli , a description of the problem is added and sent on to the control room.
Their ONLY job is to create a ticket for second line in office hours or page some technician to solve it. Second line then corrects the problem.

So giving administrators on hostmonitor direct acces is not possible for the same reason that they don't have access to that database then. , Corrupting of data is not possible, even the fields are fixed in the asset database.

That's why we have no rush to implement this version.

Ok no problem , it's your product of course