I have been using my implementation of the PRTG monitoring system now for some time and for a large number of clients. The system is inexpensive and works extremely well. What I like most about it is its flexibility and ability to be customised heavily according to your needs. Here is my guide to setting up a PRTG monitoring server to monitor all the typical enterprise systems including: AD, Exchange, DFS, Network equipment and more.
System Requirements
I typically use a VM with the follow specifications:
4 CPUs
8GB RAM
2x 100GB HDDs
GB LAN
You will need to ensure that you have access via the company firewall to scan whatever application/port you want to monitor. You will then all need to check for a firewall on the device itself (i.e. Windows firewall). One of the most common ports I needed to set this up was port 161 for SNMP.
Installation
Download the PRTG software from here
You can either download a trial with unlimited sensors for a 30 day period or you can download the free version which gives you 100 sensors. A sensors is a feature of a device being monitored. i.e. CPU usage is a sensor.
Install the software by following the wizard (I chose to install it to a drive different from the OS).
If necessary create yourself a certificate and apply it to the installation (this is optional). I created a friendly DNS name for the server too so that the IT team could access it easily: http://monitoring/index.htm
User Access
I always split user access into two roles, the day to day monitoring accounts and the administration. Fortunately PRTG integrates with Active Directory so this is easy. Create your groups in AD, I just created a PRTG_Administrators and a PRTG_Users group as below:
Create yourself a PRTG system account to initiate the link to Active Directory, this needs to be a Domain Admin. This is configured under Setup>Cores & Probes as below:
You then need to create groups corresponding to your Active Directory groups in PRTG. To link a group with your Active Directory groups simply create the group and in the Active Directory Group section choose the group you want to sync with.
Access Rights are inherited from the Local Probe group. Right click on the Local Probe and go to Edit>Access Rights.
You can configure it so that Administrators have full access and can make changes and that Users have Read access.
Monitoring Structure
I usually break down the structure by location or data center as below:
If you expand any of the data centers the structure within the data center is as below:
Network – This comprises all the routers, switches and firewalls for the site.
Physical Hosts – This is purely hardware data regarding VMWare ESXi hosts
Storage – This is data fed from SAN units either via SOAP script or SNMP
Virtual Machines – All critical data regarding virtual machines
Physical Server – This is data on physical servers that are not hosts but perform other functions (such as file services).
Phone System – SNMP related to the phone system
Inside each data center and device category you will find the corresponding list of devices. Each device then comprises a number of sensors relevant to it.
Sensors
The sensors are the core of the PRTG monitoring system. Each device has a number of sensors customised to monitor the devices particular function. For example the Physical Host shown below is an HP ProLiant server. This server is collecting all the relevant data from the server’s iLO card regarding the hardware. Should any of the hardware in the server fail it will change the sensor to red and send a notification about the failure.
Sensors can be added by clicking the Add Sensor button. You can then search for the type of sensor that you want to add from the templates. If no templates are available you can create a custom sensor using an .exe or script.
Custom Sensors
If a built-in PRTG sensor is not available it is possible to create custom sensors using scripts that you have written yourself. In the below example I created a sensor to monitor DHCP scopes and to warn us when they were getting full.
DHCP Sensor
1. Create a script that pulls data from a DHCP server with all scope information.
I used the below and saved it as C:\Scripts\DHCP_Monitoring\ExportDHCPScopes.ps1 on a domain controller
get-dhcpserverv4scopestatistics -ScopeId 192.168.22.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\192.168.22.0.csv -notypeinformation get-dhcpserverv4scopestatistics -ScopeId 192.168.24.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\192.168.24.0.csv -notypeinformation get-dhcpserverv4scopestatistics -ScopeId 192.168.25.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\192.168.25.0.csv -notypeinformation get-dhcpserverv4scopestatistics -ScopeId 192.168.26.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\192.168.26.0.csv -notypeinformation get-dhcpserverv4scopestatistics -ScopeId 192.168.27.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\192.168.27.0.csv -notypeinformation get-dhcpserverv4scopestatistics -ScopeId 192.168.28.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\192.168.28.0.csv -notypeinformation get-dhcpserverv4scopestatistics -ScopeId 192.168.29.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\192.168.29.0.csv -notypeinformation get-dhcpserverv4scopestatistics -ScopeId 10.99.0.0 | export-csv C:\Scripts\DHCP_Monitoring\Exports\10.99.0.0.csv -notypeinformation
The script puts the scope information into a .csv file in C:\Scripts\DHCP_Monitoring\Exports.
2. I then set this up to run as a scheduled task every 10 minutes.
The task action requires the argument:
C:\Scripts\DHCP_Monitoring\ExportDHCPScopes.ps1 -ExecutionPolicy Bypass
3. Next you need to write a script to pull this information from the .csv files and put it into a readable format in PRTG. The script I used was:
$ActualInUse = Import-csv \\dc01\c$\Scripts\DHCP_Monitoring\Exports\192.168.22.0.csv | Select -ExpandProperty AddressesInUse $ActualFree = Import-csv \\dc01\c$\Scripts\DHCP_Monitoring\Exports\192.168.22.0.csv | Select -ExpandProperty Free $PercentageInUse1 = Import-csv \\dc01\c$\Scripts\DHCP_Monitoring\Exports\192.168.22.0.csv | Select -ExpandProperty PercentageInUse $PercentageInUse = $([math]::Round($PercentageInUse1)) Write-Host '<?xml version="1.0" encoding="Windows-1252" ?>' Write-Host "<prtg>" Write-Host "<result>" Write-Host "<channel>Used Addresses</channel>" Write-Host "<value>$ActualInUse</value>" Write-Host "</result>" Write-Host "<result>" Write-Host "<channel>Available Addresses</channel>" Write-Host "<value>$ActualFree</value>" Write-Host "</result>" Write-Host "<result>" Write-Host "<channel>Percentage In Use</channel>" Write-Host "<value>$PercentageInUse</value>" Write-Host "<Unit>Percent</Unit>" Write-Host "<LimitMode>1</LimitMode>" Write-Host "<LimitMaxError>90</LimitMaxError>" Write-Host "<LimitErrorMsg>DHCP Address pool is low!</LimitErrorMsg>" Write-Host "</result>" Write-Host "</prtg>"
The top section in the script simply declares the variables and the red part then outputs the variables to .xml format that PRTG understands.
4. Once you are happy with the script put it in the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML folder.
5. You can now add the sensor, find the device and click the Add Sensor button:
6. Search for the EXE/Script Advanced sensor
7. Give the sensor a name and then select the script that you created at step 3. Select write EXE result to disk so that you have an error log if the sensor fails.
8. Select Continue and then click on your newly created sensor. Once it opens select the channel that you want to be warned about. In this example we want to know when the percentage of IP addresses in use is too high so select Percentage in Use.
9. Select ‘Enable alerting based on limits’ and then enter the thresholds you want to set.
DFS Replication Backlog Sensor
1. The below script cycles through all of the replication groups and replicated folders and reports back if there is a backlog. I have a scheduled task that runs this daily.
dfsrdiag backlog /rgname:ImportantdataShare /rfname:ImportantdataShare /smem:dfs01 /rmem:dfs02 >> c:\scripts\dfsr-backlog.tx
2. On the PRTG server there is a script setup that pulls the report ran in the first step and filters it for any mentions of a backlog. This is then exported to a file which is also encoded to a format understood by PRTG.
get-content \\dfs01\c$\Scripts\dfsr-backlog.txt | Where-Object { $_.Contains("Member <dfs01> Backlog File Count: ") } | out-file C:\PRTGdata\DFSR.txt -encoding ASCII
This is setup as a scheduled task that runs every day.
3. A File Content sensor is then created by clicking add sensor and searching for File Content.
4. Enter the File Name. If you are entering the name of a file on the PRTG server just enter the path as C:\Path. If you are entering a network path on the server where the sensor sits enter it as \Share\Path. For an administrative share it would be C$\Path.
5. Next enter the search string and choose a search method. I chose to use a regex expression as below as I wanted the sensor to error on all values found above 50.
[5-9]\d+|\d{3,}
6. Finally change the ‘Matches’ channel properties so that the upper error limit is 0. This means that everything above (number of matches found) 0 will cause the sensor to go into an error state.
Netflow Statistics
Netflow is supported by multiple network hardware vendors. It basically allows you to export statistics on all of the traffic flowing through your network device.
1. Enable Netflow on the device and set the exporter IP to the IP of the PRTG server
2. Create a Netflow 9 Custom sensor in PRTG and type in the port number that you set on the network device
3. Specify how you want the traffic broken down in the Channel Definition. I found that the easiest way to do this was to select log All stream data. You can then find a .csv file in D:\PRTG Network Monitor\StreamLog with all of your Netflow port data. You can then work through this identifying all the important traffic to monitor. The aim is to have as little unidentified traffic (other tcp/udp) as possible.
4. Once you have identified these ports you need to put it in a format that PRTG can understand. I created the below from the StreamLog and added it to the channel definition.
#2023:SMB (Protocol[TCP] or Protocol[UDP]) and (SourcePort[445] or DestinationPort[445]) #2024:SSH (Protocol[TCP] or Protocol[UDP]) and (SourcePort[22] or DestinationPort[22]) #2025:LDAP (Protocol[TCP] or Protocol[UDP]) and (SourcePort[389] or DestinationPort[389]) #2026:JavaRMI (Protocol[TCP] or Protocol[UDP]) and (SourcePort[1099] or DestinationPort[1099]) #2027:LDAP (Protocol[TCP] or Protocol[UDP]) and (SourcePort[389] or DestinationPort[389]) #2028:SQL (Protocol[TCP] or Protocol[UDP]) and (SourcePort[1433] or DestinationPort[1433]) #2032:WSUS (Protocol[TCP] or Protocol[UDP]) and (SourcePort[8530] or DestinationPort[8530]) #2033:Exchange (Protocol[TCP] or Protocol[UDP]) and (SourcePort[51719] or DestinationPort[51719]) #2034:CCTV (Protocol[TCP] or Protocol[UDP]) and (SourcePort[9437] or DestinationPort[9437]) #2035:PaloAltoPanorama (Protocol[TCP] or Protocol[UDP]) and (SourcePort[41049] or DestinationPort[41049]) #1006:IMAP (Protocol[TCP] or Protocol[UDP]) and ( DestinationPort[143] or SourcePort[143] or DestinationPort[220] or SourcePort[220] or DestinationPort[993] or SourcePort[993] )
5. The result is that your traffic is broken down in real-time by PRTG
Notifications
Notifications are configured under Setup>System Administration>Notification Delivery. A receive connector needs to be configured on your Exchange server with the IP address of the PRTG server.
Under Setup>Account Settings>Notifications setup a group called ‘Email to Monitoring Users’. This is configured as below to send emails to monitoring@youremaildomain.com if the sensor status matches any of the triggers.
The default sensor notification triggers are configured on the root object and can be set as below.
This is set to email email@youremaildomain.com its probably best to ensure this is a distribution list of users your want to know about these issues. The alerts will be emailed when the sensor is down for at least 300 seconds (5 minutes). When the sensor is up again another email will be sent.
Adding a new Device
The procedure to add a new device would be:
1. Expand the data center where the device is located
2. Right click on the device category and click Add Device.
3. Enter the DNS name of the device and enter the IP address. If the device is network equipment give it an appropriate tag to make it easier to find like ‘networkinfrastructure’.
4. If the SNMP details are different from the devices default turn off inheritance for SNMP and enter the appropriate information.
Troubleshooting
1. One of the most common problems is that a device can be reached on a ping sensor but none of the other sensors work. To fix this restart both the remote registry service, the Windows remote management service and the Windows Management Instrumentation service.
2. If notifications are not being received make sure that the device is inheriting the notification settings from the root. This should be pointing to your email monitoring group.
3. Some Cisco WLC devices require some additional template files from PRTG https://media.paessler.com/kb/2017/75561/data/Cisco+WLC+Templates+v0.2.zip Simply download them, extract them into the PRTG directory and restart the core service. You can then Just run an autodiscovery from template to find SSIDs, Aps etc.
