When Alert Notifications Fail: How Paessler PRTG Hosted Monitor Can Help

The basis of any network monitoring solution is alert notifications. You need them to know when there's a problem with your infrastructure. And, when setting up your monitoring solution, there is a fundamental problem that you will have to consider when it comes to notifications: if your infrastructure crashes and no longer accesses a connection to the Internet, how will you be notified? Because traditionally, your monitoring software is onsite. And onsite is down, with no means to communicate with the outside world. Oops. 

This leads us to the age-old philosophical question: Like a tree falling in the forest, if your network fails and you don't get the notifications, did it really fail?

Well, yes. Yes it did, as you will no doubt realize when you start getting angry messages from colleagues/management/customers. You generally want to avoid this. You want to know that things are down pretty much as soon as they are down. Let's take a look at the problem, and then at a possible solution: Paessler PRTG Hosted Monitor.

A Closer Look at the Problem   

The problem is similar, regardless of which monitoring tool you are using, but we will discuss PRTG because...well, because we kind of know it the best. 

In a typical, on-premises PRTG environment, you set up a "local probe", which is a server with at least the minimum requirements for PRTG to run on it. The local probe then monitors the devices on the local network. For multi-site implementations, remote probes are set up at each remote site to monitor the network at those locations. The information gathered by the remote probes is sent back to the local probe for processing.

The solution might look something like this:  

And now the problem: the local probe also handles the alerts, and to send out the alerts, it has to have a connection to the "outside world". So if there is a failure - let's say, over the weekend - where your local infrastructure no longer communicates with the outside world, the alert notifications cannot get out. You will carry on with your weekend in blissful ignorance. While this is good for your weekend, it's obviously not good for you in the long run when things catch up with you. Hope you enjoyed that weekend!

So how do you get around this notification conundrum? Paessler's hosted monitoring solution might be the answer. 

PRTG in the Cloud

With Paessler PRTG Hosted Monitor, Paessler hosts the PRTG core. How the solution works: the core and local probe are run offsite (in the cloud). All you need to do is install and configure remote probes (which do not require as much computing power as you might think) at each of the locations you want to monitor, like your local network and any remote networks you are responsible for. As a nice bonus, we also handle all the latest software and security updates for you, and you can scale your solution size up or down as you need.

Here's a simplified example of what the solution looks like:

So how does this solve the notification problem? Well, because we host the local probe and monitor the remote probes in your environment, alerts are generated (and sent) when a remote probe becomes unavailable. Regardless of the fact that your entire infrastructure might have failed, you still get notified, because the notifications are being sent from the cloud environment.* 

That's the good news. The bad news is, of course, that your entire infrastructure has failed. But at least you know about it. Still bad though. 

*There are two caveats to this that you should keep in mind when considering this solution:

• If you receive your notifications via E-mail, and your E-mail servers are also hosted on your premises...well then you won't receive the notification E-mails. Options here are to host your mail servers in the cloud (for example, Office 365), or to use the PRTG app to get push notifications.
• If only the internet connection on your network is down, but the rest of the infrastructure is running fine, you will still get a notification that the remote probe is unavailable, since it cannot be reached.

Another Possibility: Local Probe Offsite

There is another possibility you can consider, but it requires more configuration, and comes with some problems of its own. You could implement your monitoring solution in such a way that the local probe is run offsite. Then, use remote probes to monitor your local network. This model could look as follows: 

In the same way as the cloud solution above, the local probe will know (and be able to communicate alerts) when the remote probe is down. 

As mentioned, this solution comes with its own problems such as: if the offsite environment that runs your local probe goes down, you won't get a notification. The question is: what makes your offsite environment more reliable than your local environment? 

Your Environment

Of course, these are only two ways of approaching the issue. There are other possibilities. Or it might be that you just decide to live with the risk. In this case, awareness of the potential problem is a good start. This does make your weekends a little uneasier, though, when your smartphone seems eerily silent...

How do you get around this issue with your monitoring solution? Have you experienced this problem before? Any advice of your own? Let us know in the comments below!