What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Why are dependencies taking so long to get paused and unpaused

Votes:

0

Your Vote:

Up

Down

I have a device representing a host ESX server, and a set of devices representing the Virtual machines on this host ESX server. I've currently made all the VM devices dependent on the ping sensor of each VM respectively, and I've made each of these ping sensors dependent on the ping sensor of the host ESX server. The idea being, if the ESX server loses connectivity, goes down or is paused for maintenance, I get just a single alert, and the sensors for the VMs on the host ESX will get paused automatically. My problem is that the dependent sensors take a long time to reflect the state of the sensor it's dependent on, and sometimes they dont reflect it at all. For example, even an hour after pausing the ESX ping sensor for maintenance, many of the VM ping sensors (and also sensors for the ESX device) dont get paused. And the few that did eventually get paused do not resume, even though the sensor it depends on has been resumed, and is OK, for almost 3 hours now.

dependencies dependency prtg prtg-network-monitor-13-1-2-1463

Created on Apr 23, 2013 12:43:35 AM by  ashwinn (0) 1



5 Replies

Votes:

0

Your Vote:

Up

Down

If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop in that sensor which is likely why you are seeing this issue of device's not being paused or not coming out of a paused state.

The best way to set this up would be to make the VM devices dependent on the ping sensor of the host and not of their own ping sensor.

The other way that you could do this would be to setup a separate host with the VMware Virtual Machine (SOAP) sensor and set up a ping on that device that would then be the master object and would put the VM's into a pause state if it went down.

Created on Apr 23, 2013 3:09:38 PM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

"If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop in that sensor which is likely why you are seeing this issue of device's not being paused or not coming out of a paused state." - Will this be the case even if I have explicitly set the dependency of the ping sensor to the ping sensor of the host machine? Is it that the device's dependency takes precedence over the sensor's dependency.

Also, when you say "If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop..", till now, I've always set a device's dependency as it's own ping sensor, and have seen that if the ping sensor goes into alarm state, all other sensors on that device get paused, BUT the ping sensor itself remains in alarm state, and does NOT GET PAUSED. It would get paused if a loop was being formed right?

"The best way to set this up would be to make the VM devices dependent on the ping sensor of the host and not of their own ping sensor." - I considered this, but if the VM (not the host) loses connectivity, it's ping sensor will go down, and the other sensors on that VM, being dependent on the ping of the host device, will not get paused, and I'll be getting alerts for all sensors on that device.

"The other way that you could do this would be to setup a separate host with the VMware Virtual Machine (SOAP) sensor and set up a ping on that device that would then be the master object and would put the VM's into a pause state if it went down." - This seems like a good idea, but my experience with VM sensors is that they take a lot of resources in terms of CPU/memory usage, and I would like to use this option only as a last resort, since we're already using almost 2400 sensors.

Created on Apr 24, 2013 1:33:20 AM by  ashwinn (0) 1



Votes:

0

Your Vote:

Up

Down

"If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop in that sensor which is likely why you are seeing this issue of device's not being paused or not coming out of a paused state."

- Will this be the case even if I have explicitly set the dependency of the ping sensor to the ping sensor of the host machine? Is it that the device's dependency takes precedence over the sensor's dependency.

When you set a device to be reliant on it's own ping sensor by making it the master object for the device, when ping goes down, the other sensors that are NOT the ping sensor will be paused. If you set it so that the entire device, including the ping sensor, is reliant on the ping sensor then when it goes down and the sensors get paused the Ping will be paused as well. To bring it out of being paused, the ping sensor would need to come back up but it will remain paused since the device is paused. Therein lies the loop. Making the Ping then reliant on another ping will still yield this problem because when the other ping is brought out of the pause or down state, the device cannot come out of pause because it itself is paused which still includes the ping sensor. It's not so much that the device takes precendence but the timing for it to get out of a pause state would have to be quite unique, which can happen but will cause the inconsistencies that you had mentioned

Also, when you say "If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop..",

till now, I've always set a device's dependency as it's own ping sensor, and have seen that if the ping sensor goes into alarm state, all other sensors on that device get paused, BUT the ping sensor itself remains in alarm state, and does NOT GET PAUSED. It would get paused if a loop was being formed right?

When you set the device's master object as the ping, then it will show the down state and not be paused since it is the master object. The problem arises when you set the ping sensor to be dependent on another device and it can no longer be the Master Object, I think this is the difference in what you are seeing between other devices that are reliant on Ping

"The best way to set this up would be to make the VM devices dependent on the ping sensor of the host and not of their own ping sensor."

- I considered this, but if the VM (not the host) loses connectivity, it's ping sensor will go down, and the other sensors on that VM, being dependent on the ping of the host device, will not get paused, and I'll be getting alerts for all sensors on that device.

Yes this would be the case. If the VM's are dependent on another device's ping and the VM goes down, the other sensors on the VM would all report a failure. What you could do is to INDIVIDUALLY set the other sensors on the VM to be reliant on the ping for the VM then set the ping to be dependent on the Host's Ping, you just CAN'T SET THIS AT THE DEVICE LEVEL.

"The other way that you could do this would be to setup a separate host with the VMware Virtual Machine (SOAP) sensor and set up a ping on that device that would then be the master object and would put the VM's into a pause state if it went down."

- This seems like a good idea, but my experience with VM sensors is that they take a lot of resources in terms of CPU/memory usage, and I would like to use this option only as a last resort, since we're already using almost 2400 sensors.

If you create the host as a device then monitor the VM's through the host using a VMware Virtual Machine (SOAP) sensor, you would only have 1 sensor per VM but these sensors would not provide the same information as you would see from monitoring the VM's seperately.

Created on Apr 24, 2013 10:49:36 AM by  Greg Campion [Paessler Support]

Last change on Apr 24, 2013 11:01:23 AM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thanks Greg. I was hoping to avoid setting the dependency for each sensor of the device individually, but it seems this is the only way.

Is PRTG planning to rectify this in further versions (i'm currently using PRTG Network Monitor 13.2.3.2135), unless there's a specific reason to prevent this cascading dependency check. I'd think it would be a powerful feature that would save a lot of time, not to mention not having to remember to set this every time a new sensor was added to that device.

Created on Jun 7, 2013 3:00:09 AM by  ashwinn (0) 1



Votes:

0

Your Vote:

Up

Down

Since more often than not devices that are set up in PRTG are not reliant on other devices as in your case with the VM's this is not a change that we plan to make. With most devices, they are self reliant and when the ping goes down, the device is down.

As virtualization becomes more prevalent, it's possible that we will change this behavior but right now this setup is not common enough for us to change the way the dependencies are structured.

Created on Jun 7, 2013 1:03:08 PM by  Greg Campion [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.