Prtg Free Version Limitations

[Agnella Datson]

Whenthis technology is used, PRTG sends small data packets to devices, for example, querying routers, switches, and servers for the traffic counters of each port. These are triggering reply packets from the device. Compared to PRTG's other bandwidth monitoring techologies via flows, packet sniffing, or WMI, the SNMP option creates the least CPU and network load.

SNMP is the most commonly used method mainly because it is easy to set up and requires minimal bandwidth and CPU cycles. If your network devices support SNMP and/or if you want to monitor large networks with several hundred or thousands of sensors, we recommend you start with SNMP. Besides network usage monitoring, another well-known feature of SNMP is the ability to also watch other network parameters such as CPU load, disk usage, temperature, as well monitoring many other readings, depending on the queried device.

In order to use Simple Network Management Protocol (SNMP) for monitoring purposes, it is imperative that UDP packets are allowed to travel from the machine running PRTG to the device you want to monitor and back, which is usually the case in LANs and Intranets. For connections across the internet, to a Demilitarized Zone (DMZ), or for Wide Area Network (WAN) connections, some changes to the traversed firewalls may be necessary. Keep in mind that SNMP V1 and V2c are not secure protocols and should not be used across the internet or insecure data connections. Only SNMP version 3 supports encryption.

To better understand and set up SNMP sensors, you may want to learn more about the principle of Object Identifiers (OID) and Management Information Base (MIB). For more information about this, please refer to the Knowledge Base article in the More section below.

It is important to know that if you select an SNMP version which is not supported by the server or device you want to monitor, you will receive an error message. Unfortunately, in most cases, these error messages do not explicitly mention the possibility that you could be using the incorrect SNMP version. These messages provide minimum information only, such as cannot connect or similar. Similar error occur when community strings, usernames, or passwords don't match.

SNMP V1 and V2 scale directly with the performance of the hardware and the speed of the network. In our labs we were able to monitor 30,000 SNMP V1 sensors at a 60 second interval with one PRTG server (core and local probe) plus two remote probes with 10,000 sensors each.

However, SNMP V3 has software dependent performance limitations due to the SSL encryption. Because of internal limitations you can only monitor a limited number of sensors per second using SNMP V3. The limit is somewhere between 1 and 50 sensors per second, depending on the SNMP latency of your network. This means that using an interval of 60 seconds you are limited to between 60 and 3,000 SNMP V3 sensors for each probe. If you experience an increased Probe Interval Delay SNMP or Probe Open Requests channels of the Core/Probe Health sensor (values above 0 % indicate that the SNMP requests cannot be performed at the desired interval) you need to distribute the load over multiple probes. SNMP V1 and V2 do not have this limitation.

The SNMP Community String is similar to a user ID or password that allows access to a router's or other device's statistics. PRTG Network Monitor sends the community string along with all SNMP requests. If the correct community string is provided, the device responds with the requested information. If the community string is incorrect, the device simply discards the request and does not respond.

By convention, most SNMP V1/V2c equipment ships with a read-only community string set to the value public. It is standard practice for network managers to change all the community strings to customized values during device setup.

I am the only IT guy, so a good monitoring tool helps me to keep one step ahead of the problems. Over the years I have tested different monitoring tools, but the ease of configuration and the possibility to fine-tune every little detail of a sensor made my choices for PRTG every time.

The reason? Paessler PRTG is really easy to setup and use. It comes with a lot of sensors that work just out of the box and the pricing structure is awesome. You can get 100 sensors for free and the first plan starts at only $ 1.600,- for 500 sensors.

Here is a Spiceworks poll that was taken in 2016. PRTG is in the second place, but the Spiceworks Monitoring Tool is only suited for 25 devices, so not a real competitor. You can see that PRTG is by far the most popular network monitoring tool. (and keep in mind, the poll was taken on Spiceworks, so you will find the most Spicework enthusiast there)

When you install PRTG you will get a Core Server with a Local Probe. The Core Server stores the data, runs the web server, does the alerting and a lot more. Where the probe actually collects the data from all the sensors. Now in a small local environment, one machine will do just fine collecting and processing all the data.

Another reason to use the remote probes is when you want to use NetFlow or Packet Sniffing sensors on another server or computer. By installing the remote probe you can read out every little detail of the Ethernet traffic.

The requirements of the PRTG Remote probe are really low. I installed it on one of the application servers that are already running on the remote offices. But if we check the system requirements it only requires on a Win 10 OS with 2GB memory.

A basic rule of thumb for the required hardware is one CPU core and 1 GB RAM per 1,000 sensors with a minimum of 2 GB RAM for the core server. The amount of store can be calculated to, you need about 200 KB per sensor per day.

If you Google for PRTG maps you will find a lot of example with the famous PRTG sunburst view or only lists with sensors. Now the sunburst looks really nice, but if you put that up on a screen, nobody can tell which part of your network is down without walking to the screen. It is good to know that the map designer allows you to do so much more.

The structure of your PRTG sensors really determines the ability to create a stunning map or not. Start with using a probe for every site that you want to monitor, then group your devices in a logical way. If you group your switches, you can just drag the Group onto the map, monitoring all your switches witch just one icon on the map.

For important sensors, I like to use the Status Icon -> Name and status (sizeable, status-related background) icon. This will colour according to the sensor status and display the primary channel on it. They are really useful for monitoring applications and services. In the map above I used it for monitoring the server room temperatures and humidity.

Another reason why I like PRTG, transparent pricing. I really hate when I am looking into a software solution and you need to contact sales to get a quote. PRTG has a really simple pricing model. You can buy a license for a fixed price that is valid forever depend on the number of sensors you need. No monthly subscriptions are needed to keep your PRTG running.

I do recommend buying the additional maintenance though. This way you can always update your PRTG server and receive the latest sensors. Also, maintenance allows you to get support from PRTG. All plans come with 12 months maintenance included and you can extend this up to 3 years (giving you a 15% discount)

To get started with PRTG is really easy, you can get it up and running within 10 minutes. PRTG offers a trial and a free version. If you have a really small network you could start with the PRTG Free plan, that is limited to 100 sensors. No internal budget approval is required and you can start monitoring your network within minutes.

But 100 sensors is really limited even for small IT departments, you will have to be very selective with what you are going to monitor. So to get a good feel of PRTG I recommend you start with the PRTG Trial which you can download from there site. You can test the trial for 30 days without any limitations (that means, unlimited sensors).

So we are now logged in for the first time in PRTG. You should change that password as recommend but when you are done go over to the devices page. PRTG will scan you network an run the auto-discovery function on the devices it finds.

Now, this can get a bit overwhelming so what I like to do is remove the default Network Detection group. This way you are left with only the local probe. Now we can start laying out our structure before we add devices.

Start adding new groups under the local probe, for each group you can set the default credentials that are used for scanning the devices. So we are adding a group for the switches, we can set the SNMP v3 credentials for all the devices at once

After you created the groups can set some more details per group. Just open a group and go to the settings page. Here you can set Geolocation of the group (you can set this also on the probe for all the groups), very useful for creating geo maps. And you can set the notification triggers per group.

Setting those notifications will be some trial and error to see what is working out for you. But setting this on a group level, and thus making more groups, really helps to manage your monitoring system.

When you use a sensor with this technology, PRTG sends small data packets to devices, for example, querying routers, switches, and servers for the traffic counters of each port. These trigger reply packets from the device. Compared to PRTG's other bandwidth monitoring technologies via flows, packet sniffing, or WMI, the SNMP option creates the least CPU and network load.

To use Simple Network Management Protocol (SNMP) for monitoring purposes, it is imperative that UDP packets can travel from the machine running PRTG to the device you want to monitor and back. This is usually the case in LANs and intranets. For connections across the internet, to a Demilitarized Zone (DMZ), or for Wide Area Network (WAN) connections, some changes to the traversed firewalls may be necessary. Keep in mind that SNMP V1 and V2c are not secure protocols so you should not use them across the internet or insecure data connections. Only SNMP version 3 supports encryption.

3a8082e126