Hub Monitoring Through SDP

[Anon Anon]

I have twenty-six hubs with numerous robots that we are monitoring through SDP.  I have created robot alarms and they work well, however I need to monitor the hubs at each location.  We are connecting to them through tunnels and I do see alarms when a tunnel is down. 

The problem I'm having is that each alarms is the same except the message.  I've tried using variables to trigger on information in the message in the past with no luck.  Any ideas?

Robert

[Anon Anon]

Robert,

For your tunnels, which side is the server and which is the client?  That will make a big difference in the alarms that you see when one goes down.  Can you also provide a sample alarm message from when the tunnels go down?

In our environment, the central hub is the tunnel client, and each remote hub is a tunnel server.  The alarms are more useful that way, but they are still not perfect.  From what I remember, the message includes the tunnel IP address rather than the name entered in the config, so they were a bit off a hassle for our NOC.

I think we get far more useful alarms about queue failures than we do about tunnel failures.  You should be using queues with your remote hubs, so maybe you can use queue alarms rather than tunnel alarms to determine when a hub is down.

-Keith

[Anon Anon]

I used netconnect to monitor the hub port then you can really customize your message.

[Anon Anon]

Here is a sample alarm message:

Connection error. Could not connect to 10.11.100.100/48003. Please check that the server is running.

The remote Hubs are the clients. Are you referring to the spooler as the queue?

[Anon Anon]

I will also try the netconnect to see if I can make it work.  Thanks for your responses.

[Anon Anon]

The net_connect probe will do a good job of telling you when your hub is down.  The bad news is that there are other reasons tunnels can fail to connect even though the port is up.  The good news is that most of those reasons are configuration issues, so they are fairly easy to spot manually if you check to make sure your tunnel is working after you set it up.

When I asked about the queues, I was talking about the queues in the hubs.  If you run a central NAS and data_engine, you need queues to get the messages back to them from your remote hubs.  If you run a NAS and data_engine on each hub, you might not use queues.

To get data from our remote hubs, we create attach queues on them with a subject of "*" so that they save all messages they receive.  Then our central hub has a get queue for each reomte hub, and it collects the messages.  If we lose a tunnel, the queue should also go down.  The reason we like the queue alarms better than the tunnel alarms is that the queue names we use tell us the name of the hub that is down.  That really helps us understand which customer is affected better than if we had to rely on the IP address in the tunnel alarms.

-Keith