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.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Implausible data with disconencted probe

Votes:

0

Your Vote:

Up

Down

Hello Paessler Support,

we've had trouble with the connection to one of our subsidiaries. The effect is intermittent loss of connectivity which results in a disconnection of the remote probe.

In these cases I have had an effect where the sensors of the probe were reporting implausible data, for example SMB sensors showing 0 GB of free space et cetera. The expected behaviour for me would be that all sensors go into the "unknown" state as soon as the probe is disconnected.

Is this a configuration error on my part, can I fix this? Or a problem with PRTG / the probe?

Installed version is 13.1.2.1463 x64

Thank you!

disconnects implausible-data prtg remote-probes

Created on Apr 3, 2013 6:35:58 AM by  Christian Möller (11) 1



6 Replies

Votes:

0

Your Vote:

Up

Down

If these sensors are part of a dependency tree, then when the remote probe goes down, you can have them inherit a paused state. You can read more about dependencies here.

Dependencies

Once all of the sensors are in a paused state, they will not report any false data or any notifications.

Created on Apr 4, 2013 9:15:04 AM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I have a similar problem, similar circumstances. VPN rebuilds on a schedule and this causes a moments loss of connection from Probe to PRTG. During this time 20-30 sensors all pop red, 0GB, 0 processes running, whatever it may be. Notifications are then intermittently fired off and this is troublesome at 2AM in the morning when someone gets called on it.

13.1.2.1463+

Created on Apr 4, 2013 9:39:34 PM by  Randolfini (270) 2 1



Votes:

0

Your Vote:

Up

Down

Randolfini, you could also set up dependencies like I mentioned before but in your case, I think the best option would be to set up schedules for when your VPN is being rebuilt. This can be done for a group of sensors through their parent device's settings under Schedules, Dependencies, and Maintenance Window.

Group Settings

See the section about Schedules, Dependencies, and Maintenance Window.

Created on Apr 5, 2013 7:33:47 AM by  Greg Campion [Paessler Support]

Last change on Apr 5, 2013 7:34:30 AM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,

thanks for your reply!

I have had a similar case again yesterday and I think the dependencies are not the problem. In my case schedules do not apply, since there are no planned VPN renegotiations.

Just to clarify, I have grouped the sensors like this:

Probe -> Group -> (Group ->) Device -> Sensor

For each device I have a ping sensor which is the "master" for the device. What actually went wrong is that the ping sensors still showed green, thus the remaining sensors did not go into the paused or unknown state. And for whatever reason reported data - false data.

As with Randolfini this is quite undesirable for us, since it leads to confusion.

In this case I would have to change all dependencies of all sensors to the probe itself somehow, not overly desirable.

I would like to make a sort of "feature request" out of this, because I think it would be a desirable behavior (and in my opinion the only "correct" behavior) that when a probe disconnects, all sensors of this probe are put into the "unknown" state at once and not after a delay or a refresh period or so.

Created on Apr 5, 2013 7:47:18 AM by  Christian Möller (11) 1



Votes:

0

Your Vote:

Up

Down

If the remote probe goes down and there is still data being reported, then something is wrong, they should go into an unknown state. If you could submit a ticket to [email protected] and include your logs for the remote probes that are being affected as well as the core probe, we can look into this.

See here for submitting logs:

https://www.paessler.com/knowledgebase/en/topic/7983-how-can-i-upload-log-files-to-paessler-support-team

Created on Apr 5, 2013 11:06:07 AM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Just want to tag that this has been resolved with the latest releases. At least for me.

Created on Jul 20, 2013 8:49:59 PM by  Randolfini (270) 2 1



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.