Multiple dependencies for more efficient monitoring

I'm afraid there are currently no plans to include multi-tiered dependencies for PRTG, sorry. However, what you could do is inherit the dependency pause, which would result in the lower object levels inheriting the dependencies of the overlying objects. You could also use Sensor Factory sensors to define a state formula that will change a state if, for example, 4 sensors in the formula are down. This way you could define the dependency based on the factory sensor.

I'd like to tag onto this as well. I monitor hundreds of Linux servers via SNMP and occasionally SNMP response will stop, requiring the snmpd process to be restarted. With only one dependency (ping), the SNMP sensors show Down and send out false alarms. In the middle of the day this isn't horrible because I can jump on it and ack them. But at 2AM on a critical database server several people get a call and it makes them very unhappy.

If there was a tiered way to say Ping is the overall dependency, but these SNMP sensors also need to have SNMP Response as a dependency...something like that.

I would like to expand on the second part of my earlier response. Although there are no current plans for tiered dependencies, it is still possible to create a mockup of this. As an example:

Group 1 - Dependant on "working Ping"

Device 1 - Dependant on "working SNMP"

(SNMP sensors)

The "working SNMP" sensor can be part of the device and function as a Master Dependency object. Alternatively, it is also possible to define individual dependencies for the SNMP sensors, in case there are other sensors in Device 1 (i.e. non-SNMP sensors). The "working Ping" sensor would have to be outside of group 1, as such there would need to be a second device belonging to a second group. This scheme can be increased as desired, so that even 3 layers of dependencies are possible.

Can a feature to create groups with in a device be made available in future versions. And each group having its own master dependency object. If such a facility could be made available then it will make it convenient to define dependencies.

Dear ruflxs

The PRTG object hierarchy does not allow groups within a device.

Sometimes we discuss the possibility of adding another layer, either to allow groups for probes, or some organization within a device. However, we decide against those changes because we want to keep the complexity of our monitoring solution as low as possible.

We are aware that this approach also means that PRTG cannot provide everything for everyone. But we rather keep a simple-to-use interface and underlying hierarchy and only add options, hierarchy layers and other elements when really necessary.

For the time being, PRTG will keep a single, one-direction dependency path. For more complex operation, please use teh status formula of the factory sensor to compute a result status from multiple sensor inputs. The status formula allows logical operations like AND, NOT and OR.