Hello! I'm new to Host Monitor... I just came across it earlier this week and really like it so far!
I have a scenario that I would like to know if HM can support and/or if there is a possibility for a future enhancement.
We have 6 offices that each have their own file server that I am the admin for, each has an internet connection, and each has a firewall.
In my office, I would like to have HM perform monitoring functions through the internet/firewall at the remote locations without having to open up all of the ports (like 137, 138, 139) to the internet.
Is there a way to have remote machines with HM report their test status' back to one primary HM machine?
If not, a possible feature that would be extremely beneficial (in our case) would be something of this sort:
Host Monitor could have two additional fields on the test screen. One for a Yes or No choice for "Perform Test Remotely", and a second to contain a DNS name or IP address of the remote machine. Possibly a third field could be added for a password or some security identifier that the client piece could validate before performing the test.
The remote machine could then have a client program or service that would accept a Host Monitor test parameter information, perform the test, and return a status back to the Host Monitor machine at the main office.
The flow would work like this:
1. Host Monitor machine starts a free disk space test and it is marked "Remote Test" for machine "ntserver.remotelocation.com".
2. Host Monitor contacts ntserver.remotelocation.com on TCPIP port 12345, allowing it to pass through the remote firewall, and sends the test parameters to it.
3. ntserver.remotelocation.com performs the disk space test using the test parameters that were sent from the main office Host Monitor machine, and generates the appropriate test result.
4. ntserver.remotelocation.com then responds to the main office Host Monitor machine over TCPIP port 12345, passiing back through the firewall, with the test result.
5. The Host Monitor machine at the main office then performs any alert notifications that are required by the response or goes on to the next test.
Anyone have any thoughts on how a Client/Server or Distributed Monitoring could be set up?
Distributed Monitoring or Client Server type setup
>In my office, I would like to have HM perform monitoring functions through the internet/firewall at the remote locations without having to open up all of the ports (like 137, 138, 139) to the internet.
Is there a way to have remote machines with HM report their test status' back to one primary HM machine?
Not yet, it will be implemented in version 4.0
>The flow would work like this:
Thank you for suggestions. We already think about this feature and even have some pieces of code
Regards
Alex
Is there a way to have remote machines with HM report their test status' back to one primary HM machine?
Not yet, it will be implemented in version 4.0
>The flow would work like this:
Thank you for suggestions. We already think about this feature and even have some pieces of code
Regards
Alex
Since logging is very important for me, I'm a bit concerned about this when running a distributed environment. Since we log all actions, a tipical daily text log file would be around 10 megs (don't know exactly now, since I've turned them off). Sending every result to the central HM is not the most ideal solution.
Sending all results to the central HM with a HM specific port, requires you to set open a port for HM exclusively on you firewall(s). This is a thing the firewall administrator(s) in general don't like.
So my ideal situation would be:
- Remote HM will log locally (compressed if possible to reduce size). Status changes or all, depending on the user needs.
- Remote HM wil notify the central HM only on status change. Since HM 'knows' snmp, this would be the prefered method for me and something you can 'sell' to the firewall administrator(s). Being able to send to multiple destinations would be great. This could reduce the central HM to a report generator only for remote tests (at least in my case, since I don't have to send an extra trap to the management server).
- Central HM will collect (daily) logs from the remote HM and log them according to local settings (text, html, database, etc.). Remote logs will be deleted when they are succesfull stored by the central HM. (database storage in our case).
Sending all results to the central HM with a HM specific port, requires you to set open a port for HM exclusively on you firewall(s). This is a thing the firewall administrator(s) in general don't like.
So my ideal situation would be:
- Remote HM will log locally (compressed if possible to reduce size). Status changes or all, depending on the user needs.
- Remote HM wil notify the central HM only on status change. Since HM 'knows' snmp, this would be the prefered method for me and something you can 'sell' to the firewall administrator(s). Being able to send to multiple destinations would be great. This could reduce the central HM to a report generator only for remote tests (at least in my case, since I don't have to send an extra trap to the management server).
- Central HM will collect (daily) logs from the remote HM and log them according to local settings (text, html, database, etc.). Remote logs will be deleted when they are succesfull stored by the central HM. (database storage in our case).
>So my ideal situation would be:
- Remote HM will log locally (compressed if possible to reduce size). Status changes or all, depending on the user needs.
In this case you will have to buy license for each instance of HostMonitor. Its good for us, but not very good for you.
Probably we will charge something for remote agents license, but not much.
>Remote HM wil notify the central HM only on status change. Since HM 'knows' snmp, this would be the prefered method for me and something you can 'sell' to the firewall administrator(s).
In our plans we call it "HostMonitor will be able to send messages to Central Console"
Anyway you have to open port on firewall, right?
Regards
Alex
- Remote HM will log locally (compressed if possible to reduce size). Status changes or all, depending on the user needs.
In this case you will have to buy license for each instance of HostMonitor. Its good for us, but not very good for you.
Probably we will charge something for remote agents license, but not much.
>Remote HM wil notify the central HM only on status change. Since HM 'knows' snmp, this would be the prefered method for me and something you can 'sell' to the firewall administrator(s).
In our plans we call it "HostMonitor will be able to send messages to Central Console"
Anyway you have to open port on firewall, right?
Regards
Alex
>Probably we will charge something for remote agents license, but not much.
Since the program is cheap already, I don't think my boss would mind if I can convince him of the benefits. (less traffic, better performance of central HM).
>In our plans we call it "HostMonitor will be able to send messages to Central Console"
Anyway you have to open port on firewall, right?
Yes, but have you ever tried to confince a firewall administrator to open a port for a program he doesn't know AND runs on windows? SNMP is a protocol they know and will be set to open without problems.
Since the program is cheap already, I don't think my boss would mind if I can convince him of the benefits. (less traffic, better performance of central HM).
>In our plans we call it "HostMonitor will be able to send messages to Central Console"
Anyway you have to open port on firewall, right?
Yes, but have you ever tried to confince a firewall administrator to open a port for a program he doesn't know AND runs on windows? SNMP is a protocol they know and will be set to open without problems.
A downside to having it setup your way (distributed remote host monitors reporting a status change to a central host monitor) would be that a host monitor client machine could not notify the main host monitor console if it were down. In that case, the main host monitor console would never know it since the client agent could not send a status change.
If any piece between your remote client agent and the main host monitor machine was down, the central host monitor could not show a test failure due to a failure of a service, a cable, a hub, a router, an internet connection, etc. Any of those would cause the client piece not to notify the main host monitor machine of a status change to failure.
A benefit of having it set up as a server/agent seupt would be that if the main host monitor machine sends the test criteria to the client agent for execution, it will know if any piece is down along the path and will be able to show an appropriate failure status and alert accordingly. It will also be able to show a test failure if it was unable to contact the remote monitor client.
The client agent could still have an option for logging all tests performed locally by it if having a detailed log at the remote site is important.
Food for thought...
If any piece between your remote client agent and the main host monitor machine was down, the central host monitor could not show a test failure due to a failure of a service, a cable, a hub, a router, an internet connection, etc. Any of those would cause the client piece not to notify the main host monitor machine of a status change to failure.
A benefit of having it set up as a server/agent seupt would be that if the main host monitor machine sends the test criteria to the client agent for execution, it will know if any piece is down along the path and will be able to show an appropriate failure status and alert accordingly. It will also be able to show a test failure if it was unable to contact the remote monitor client.
The client agent could still have an option for logging all tests performed locally by it if having a detailed log at the remote site is important.
Food for thought...
I've worked in server administration and networking for about 15 years. I've never really had any problem explaining to another network engineer why I need a specific port opened since they know me and know that I know what I'm talking about. It would depend on your various situation and how much corporate politics are involved in whether or not you could convince him to open the firewall port...
All of that aside, I just came up with another thought on it...
Another option is that the single port being used could be configurable so that you can use a well known port number if you need to. I.E. if your company network policy allows http traffic, you can use port 80 as long as your client machine doesn't have a web server or anything else answering port 80 on it. That way you could pick a port on the firewall that your network engineer doesn't have a problem with.
More food for thought!!! <grin>
All of that aside, I just came up with another thought on it...
Another option is that the single port being used could be configurable so that you can use a well known port number if you need to. I.E. if your company network policy allows http traffic, you can use port 80 as long as your client machine doesn't have a web server or anything else answering port 80 on it. That way you could pick a port on the firewall that your network engineer doesn't have a problem with.
More food for thought!!! <grin>
The only problem here is that you will send information for every test to and from the remote HM srvice, while a simple single test if the remote HM service is running (for example every 5 minutes) can be done from the central HM service (just as you would do now).On 2003-02-04 23:04, eNet wrote:
A benefit of having it set up as a server/agent seupt would be that if the main host monitor machine sends the test criteria to the client agent for execution, it will know if any piece is down along the path and will be able to show an appropriate failure status and alert accordingly. It will also be able to show a test failure if it was unable to contact the remote monitor client.
One of the advantages of having a remote HM service is not sending all your data over the network. If you have slow connections, this is a real plus!
Besides, not being able to connect ot a server does not mean the server (or all servers in the site) are down. So what will happen to your logging. It could have 'invalid' down entries for the remote tests.
And I love the configurable port idea......
<font size=-1>[ This Message was edited by: Marcus on 2003-02-05 00:56 ]</font>
On 2003-02-05 00:55, Marcus wrote:
Besides, not being able to connect ot a server does not mean the server (or all servers in the site) are down. So what will happen to your logging. It could have 'invalid' down entries for the remote tests.
<font size=-1>[ This Message was edited by: Marcus on 2003-02-05 00:56 ]</font>
The invalid down entries could be controlled by using the depends on criteria in the tests like you would use now. If a server disk space test depends on the server responding to a ping test, which depends on the router responding, which depends on etc... If one of the required tests fails, the ones that depend on it could go to an unknown state until the item it depends on is resolved. I think that functionality could work the same as it is already implemented.
>The invalid down entries could be controlled by using the depends on criteria in the tests like you would use now
Exactly and that's not what's wanted. If you just test the remote HM from the Central HM and if fails, you know you have to take action. But you also know if it is just a network problem between the central and remote HM, your tests will be performed and your logging wil be correct! I rather see an UP instead of an UNKNOWN in my logging.
Besides that, I think the main issue here is small bandwith and how to use it as less as possible. If you have a good connections, there is no reason to use a remote agent (I know, your first post: unless open ports are the problem).
<font size=-1>[ This Message was edited by: Marcus on 2003-02-06 01:07 ]</font>
Exactly and that's not what's wanted. If you just test the remote HM from the Central HM and if fails, you know you have to take action. But you also know if it is just a network problem between the central and remote HM, your tests will be performed and your logging wil be correct! I rather see an UP instead of an UNKNOWN in my logging.
Besides that, I think the main issue here is small bandwith and how to use it as less as possible. If you have a good connections, there is no reason to use a remote agent (I know, your first post: unless open ports are the problem).
<font size=-1>[ This Message was edited by: Marcus on 2003-02-06 01:07 ]</font>
Well...
Since the current version of HostMonitor work by "transparent" networking to get information to/frem monitored servers/services, I dont mind to change even locally server/services to "talk" by a installed "client-software". That client can be installed with local rights, be able to talk to/from any valid HM, be able to crypt monitoring data to/from any valid HM, be able to talk to any specific (of my choice) port, be able to be flexible to any firewall (ie. setup source/destination IP/port) etc. etc.
As long as any valid centralized HM will be able to update remote agent software, then I'll put my "choice" on that one!
On the first place I thought, that one HM force was, "no client/agent software" installed on monitored servers/services... but, on the other hand... I do see many strange problems that could be avoided by a remote agent (ie. stalled answers from services, process and performance counters etc.)
Soo... Alex, we did'nt show You the road.. more likely a good "hint", right? ;-D
Cheers,
Hans Mosegaard
<font size=-1>[ This Message was edited by: hmo on 2003-02-16 15:22 ]</font>
Since the current version of HostMonitor work by "transparent" networking to get information to/frem monitored servers/services, I dont mind to change even locally server/services to "talk" by a installed "client-software". That client can be installed with local rights, be able to talk to/from any valid HM, be able to crypt monitoring data to/from any valid HM, be able to talk to any specific (of my choice) port, be able to be flexible to any firewall (ie. setup source/destination IP/port) etc. etc.
As long as any valid centralized HM will be able to update remote agent software, then I'll put my "choice" on that one!
On the first place I thought, that one HM force was, "no client/agent software" installed on monitored servers/services... but, on the other hand... I do see many strange problems that could be avoided by a remote agent (ie. stalled answers from services, process and performance counters etc.)
Soo... Alex, we did'nt show You the road.. more likely a good "hint", right? ;-D
Cheers,
Hans Mosegaard
<font size=-1>[ This Message was edited by: hmo on 2003-02-16 15:22 ]</font>