New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

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

 

Top Tags


View all Tags


Can disconnected remote probes be classified as "not an alarm"

Votes:

0

Your Vote:

Up

Down

Dear Paessler

We have remote probes running on many systems worldwide. These are deployed on devices that may loose internet connection from time to time. This does however not mean the probe server is in bad shape. Only that the internet connection is.

We have made a map for survaillance and setup an email service to alarm us on errors on the remote probe systems. This works well in general. What we miss, is the opportunity to disregard the "Disconnected" alarms the remote probes generate. It's fine that they show up read with the small "X" on the icon on the map, but they also go into the alarm list and may stay there for many days/months. This can cause technicians to overlook other important alarms on connected systems. Setting them into pause could be an idea, but this means we manually have to discover that they reconnected which doesn't seem like the right solution.

Can we somehow make a setting causing the disconnection of remote probes not to be treated as alarms?

Kind regards Kenneth Vindum FLSmidth

alarm disconnected remote-probe

Created on Apr 26, 2018 12:03:48 PM by  Kenneth Vindum (0) 1



6 Replies

Votes:

0

Your Vote:

Up

Down

Dear Kenneth,

the solution would be:

  • Add a ping sensor for each probe (which requires an additional device object for each probe)
  • Set the ping sensor to "Auto-Acknowledge"
  • Open the probe node's setting tab, go to "Dependencies" and select the according ping sensor as master object

Now if the connection gets lost, the ping sensor goes into the acknowledged alarm and the probe node gets paused by the dependency to the ping sensor.

Created on Apr 26, 2018 6:57:19 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dear Arne

Sorry for not getting back earlier.

I'm unable to make the suggested solution work. The ping sensor can't report back when the remote probe looses the internet connection, and never causes the parent nodes 'Dependency' (Ping-sensor) to Auto-Acknowledge.

Adding additional devices to the PRTG server itself with IP addresses pointing towards the Remote Probes won't work as the Remote Probes may change their IP and doesn't have DNS... if that was what you were thinking.

I'm also a bit hesitant to add an extra device for each remote probe. This seems bloated. An extra sensor would however not be a big issue...

Any other ideas, or did I get it wrong?

Created on May 18, 2018 12:59:31 PM by  Kenneth Vindum (0) 1



Votes:

0

Your Vote:

Up

Down

Dear Kenneth,

if the remote probes can change the IP, the solution outlined by me will not work. There is no good solution in this case. A disconnected probe will cause the probe health sensor being in the alert status.

In principle, you could pause the health sensors. But this would also mean that you don't get useful information about the probe status, which is helpful (or necessary) to isolate the cause if there are any stability issues.

Created on May 21, 2018 10:43:17 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dear Arne

I see... although it's not the reply we hoped for. This means that we will register a lot of useless alarms when using PRTG in distributed systems. That's a shame, as it can cause important alarms to be hidden among the "I am not presently here" alarms.

Could this be made a request for change? I suggest a global yes/no variable indication whether to mark disconnected devices as alarms, and the possibility to overwrite the setting on the remote probes settings. I guess this would be possible with the current logic in PRTG.

Created on May 23, 2018 11:57:19 AM by  Kenneth Vindum (0) 1



Votes:

0

Your Vote:

Up

Down

Dear Kenneth,

this is another reply you didn't hope for. We want to keep the PRTG interface concise and only add options if there is enough demand to justify it. Because of this, PRTG is still relatively easy to learn and to operate.

Created on May 23, 2018 12:26:45 PM by  Arne Seifert [Paessler Support]

Last change on May 23, 2018 12:27:04 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dear Arne

I understand, but it's really a shame as it means we'll have re reconsider if PRTG is the right tool for monitoring distributed systems.

Created on May 25, 2018 8:03:29 AM by  Kenneth Vindum (0) 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.