Paessler introduced a new monitoring technology that is included in the latest Stable version of PRTG. PRTG lets users monitor networks 24/7 and can be installed on the Paessler website.

The new PassiveApplication Performance Sensor allows you to monitor the performance of a server/service without actually accessing either the client or the server directly.

For most other monitoring scenarios you either need access to the server/device itself (to monitor vital data like CPU, memory, disks, bandwidths, etc.), or you need to access the service (to send simulated requests to the server and look at the timing and the content of the replies).

The new sensor type uses a completely different approach: This sensor applies PRTG's built-in packet sniffer to look at all TCP packets going into a server, and it checks the reply packets from the server as well. The idea is that if anyone measures the time between a TCP packet Roundtrip, we can actually measure the performance of the service/server.

This approach works only with a limited set of network protocols that create a new TCP network connection for every request. These are mostly built on top of http/1.0 and http/1.1 (though for 1.1 keep-alive may skew the results a bit). Services like POP3, IMAP, and SMTP are also viable candidates.

Sample Usage Scenarios

You can use our new sensor type in the following scenarios:

  • If your internal infrastructure uses external (web-) services (for example, cloud services like Google Apps or Amazon EC2), you can monitor their performance by using the Passive Application Performance sensor. You have to set up the network in a way that PRTG will be able to "see" all requests to the respective cloud service using its packet sniffer.
  • You can monitor the "real" response behavior of a web server in contrast to special requests of common HTTP sensors which are in a cache. For example, if users suddenly access other areas (because of news or a new blog article), the behavior after the release can be completely different to the test case.
  • Monitor services that you do not want to extra strain because they already execute very expensive database requests.