Monitoring Your Network with PRTG - Custom Sensors Part 2
Articles in this series:
- Monitoring Your Network with PRTG - Overview, Installation, and Configuration
- Monitoring Your Network with PRTG - Custom Sensors Part 1
In my last “Custom Sensors Part 1” article, I covered what sensors are, the wire-format for custom sensors, and the main logic in our sensor we use for monitoring our BIG-IP GTM, LTM, ASM, and WA devices. In this article, I will continue on with the examples and walk you through what we are using for testing the website itself.
The Application
One may ask why the simple HTTP monitor is not sufficient to test our web application. The reason is that DevCentral consists of the following three applications stitched together with application logic and some iRule goodness:
- Main application CMS
- Wiki
- Blogs
I could have created several monitors for the various applications, but I wanted to come up with something that determined the overall “health” of the system. For our requirements, we wanted to have a single monitor aggregate the health of the various applications into a “global” health and a custom monitor turned out to be perfect for the job.
So without further ado, we’ll dig into the various logic and functions in my script.
Usage
The script only takes 2 parameters. The first is the address that we are testing against. I have several instances of this script running at the various layers in our network. I have it pointing directly at the app servers using an HTTP connection, and through our WA and ASM with HTTPS connections. This gives me a nice view of timings at various layers in our network for troubleshooting.
1: PS> .\DC-HealthCheck.aspx -Server -SSL
2: -Server - the IP address that we want to test our app against.
3: -SSL - a switch to tell the script whether to test HTTP or HTTPS.
Utilities
Since the main component of my custom sensor would be validating contents on web page requests, I created a function that would wrap the curl.exe command line. I could have done this with native .NET methods but I took the easy way out since I had a controlled environment with curl present. I made use of curl’s built in resolver to allow the script to make requests to https://devcentral.f5.com/s but allowing it to control which IP addresses it made requests to.
The Get-WebPage() function does the curl request, times the request, and builds a response containing the page content and the time it took to request the page. The time is used later on to give an “average” response time for the site.
The Build-Result() function, generates a PRTG Sensor item for the response to be included in the aggregate sensor output in the various component functions below.
1: function New-Response()
2: {
3: 1 | select "Content", "Time";
4: }
5:
6: function Get-Webpage()
7: {
8: param(
9: $Server,
10: $IP = $null,
11: $Url
12: );
13:
14: $Port = 80;
15: if ( $script:SSL )
16: {
17: $fullUrl = "https://${Server}${Url}";
18: $Port = 80;
19: }
20: else
21: {
22: $fullUrl = "http://${Server}${Url}";
23: }
24: $Output = "";
25:
26: if ( $IP -ne $null )
27: {
28: $sec = (Measure-Command {$Output = curl --insecure -sN --resolve "devcentral.f5.com:${Port}:${IP}" $fullUrl }).TotalSeconds;
29: }
30: else
31: {
32: $sec = (Measure-Command {$Output = curl --insecure -sNA $UserAgent --max-time 10 $fullUrl }).TotalSeconds;
33: }
34:
35: $R = New-Response;
36: $R.Time = $sec;
37: $R.Content = $Output;
38:
39: $R;
40: }
41:
42: function Build-Result()
43: {
44: param(
45: $Channel,
46: $Unit = "Custom",
47: $CustomUnit = "msec",
48: $Mode = "Absolute",
49: $Value,
50: [switch]$Warning = $False
51: );
52:
53: $Value = [Convert]::ToInt32($Value * 1000);
54:
55: $w = 0;
56: if ( $Warning )
57: {
58: $script:WARNING = $True;
59: $script:STATUS = "ERROR: At least one channel had an error";
60: $w = 1;
61: }
62: $s = @"
63:
64: ${Channel}
65: ${Unit}
66: ${CustomUnit}
67: ${Mode}
68: 1
69: 1
70: $([Convert]::ToInt32($w))
71: 0
72: ${Value}
73:
74: "@;
75: $s;
76: }
Testing the Database
The first layer on our stack is the database. We have a database healthcheck page that performs some connection metrics on the database itself without the overhead of the application code in our main applications. This function will call the Get-WebPage function with the db healthcheck URL and report it’s findings to the caller.
1: function Test-DB()
2: {
3: param($IP);
4:
5: $R = Get-WebPage -Server "devcentral.f5.com" -IP "${IP}" -Url "/dbhealth.aspx";
6: if ( $R.Content -match "Database Status: UP" )
7: {
8: $s = Build-Result -Channel "Database Connection" -Unit "Custom" -Value $R.Time;
9: $script:TIMES += $R.Time;
10: }
11: else
12: {
13: $s = Build-Result -Channel "Database Connection" -Unit "Custom" -Value 0 -Warning;
14: $script:TIMES += 0;
15: $script:BADCHECKS += "DB";
16: }
17:
18: $s;
19: }
Testing the Homepage
Now that the database has been checked, we’ll test out the main landing page for devcentral. The function is very similar to the database check except that it’s testing a separate URL in the request. The function also updates the $script:BADCHECKS variable with the check name if that check failed. This is reported to PRTG so that in the GUI you can tell which individual “channels” failed.
1: function Test-HomePage()
2: {
3: param($IP);
4:
5: $R = Get-WebPage -Server "devcentral.f5.com" -IP "${IP}" -Url "/";
6: if ( $R.Content -match "Welcome to F5 DevCentral" )
7: {
8: $s = Build-Result -Channel "Home Page" -Unit "Custom" -Value $R.Time;
9: $script:TIMES += $R.Time;
10: }
11: else
12: {
13: $s = Build-Result -Channel "Home Page" -Unit "Custom" -Value 0 -Warning;
14: $script:TIMES += 0;
15: $script:BADCHECKS += "HomePage";
16: }
17:
18: $s;
19: }
Main Sensor Logic
The main logic in the sensor calls the various “Test-*” functions for the database, homepage, wiki, and blogs. It then averages out the response times and builds a top-level channel for the “Avg App Response” time. This allows a quick glance on how the app is performing as a whole.
The response is then built with the response time channel and the channels for the various tests and the value is returned back to PRTG. For situations where one of the checks failed, a PRTG error is generated with the list of the failed checks in the error text.
1: param(
2: $Server = $(Throw "Server parameter is required"),
3: [switch]$SSL = $False
4: );
5:
6: $script:SSL = $SSL;
7: $script:WARNING = $false;
8: $script:STATUS = "OK";
9: $script:TIMES = @();
10: $script:BADCHECKS = @();
11:
12: $Tests = @"
13: $(Test-DB -IP $Server)
14: $(Test-Homepage -IP $Server)
15: $(Test-Wiki -IP $Server)
16: $(Test-Blogs -IP $Server)
17: "@;
18:
19: $t = $script:TIMES | Measure-Object -Average;
20:
21: $s = @"
22:
23: $(Build-Result -Channel "Avg App Response" -Unit "Custom" -Value $($t.Average))
24: $Tests
25: $($script:STATUS)
26:
27: "@;
28:
29: if ( $script:BADCHECKS.Length -gt 0 )
30: {
31: $s = @"
32:
33: 1
34: An error occured in the following checks: $([string]::join(',', $script:BADCHECKS))
35:
36: "@;
37: }
38:
39: $s;
40:
41: $rc = [Convert]::ToInt32($script:WARNING);;
42:
43: exit $rc;
Running/Testing the Script Manually
To test the script, put it in the %Program Files%\PRTG Network Monitor\Custom Sensors\EXEXML directory and run it from the command line. The results are below:
1: PS C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML> .\DC-HealthCheck.ps1 -Server ww.xx.yy.zz 2: 3: 4: Avg App Response 5: Custom 6: msec 7: Absolute 8: 1 9: 1 10: 0 11: 0 12: 1212 13: 14: 15: Database Connection 16: Custom 17: msec 18: Absolute 19: 1 20: 1 21: 0 22: 0 23: 416 24: 25: 26: Home Page 27: Custom 28: msec 29: Absolute 30: 1 31: 1 32: 0 33: 0 34: 1249 35: 36: 37: Wiki 38: Custom 39: msec 40: Absolute 41: 1 42: 1 43: 0 44: 0 45: 2688 46: 47: 48: Blogs 49: Custom 50: msec 51: Absolute 52: 1 53: 1 54: 0 55: 0 56: 494 57: 58: OK 59:
The Graphs in the GUI
When drilling into the PRTG GUI for the custom sensor I created, you’ll see that the output data is imported in and the channels created with the various times are added to the report timeline.
Conclusion
With the support for PowerShell, it’s very easy to build a custom sensor. If you have needs beyond the basic supported sensors, go ahead and jump in and write your own - it’s easy!