PRTG Manual: Monitoring via HTTP
The Hypertext Transfer Protocol (HTTP) is a standard application layer protocol and the basis for data communication in the internet. HTTP is a request-response method for client-server architectures, where the client sends a request and the server processes and responds to the request.
Monitoring via HTTP is useful if you want to monitor websites or web servers. It enables you to keep an eye on the availability and download times of a website or the performance statistics of a web server. There are also a lot of other possible use cases for HTTP sensors. For example, you can request any Application Programming Interface (API) that is reachable via HTTP and monitor returned values. This approach makes it possible to include almost any type of device or application into your monitoring.
PRTG comes with built-in sensor types for HTTP monitoring:
- Cloud HTTP Sensor
- Common SaaS Sensor
- HTTP Sensor
- HTTP Advanced Sensor
- HTTP Apache ModStatus PerfStats Sensor
- HTTP Apache ModStatus Totals Sensor
- HTTP Content Sensor
- HTTP Data Advanced Sensor
- HTTP Full Web Page Sensor
- HTTP Push Count Sensor
- HTTP Push Data Sensor
- HTTP Push Data Advanced Sensor
- HTTP Transaction Sensor
- HTTP XML/REST Value Sensor
- REST Custom Sensor
- Monitor the availability and loading times of a website
- Monitor the source code and specific content of a website
- Test the login, purchasing, and shipping processes of a web shop
- Monitor performance statistics and activity of Apache web servers
This type monitors the availability of a website or a specific website element. For example, the HTTP sensor shows how long the HTML code of a website takes to load. If the sensor shows a loading time that is much longer than expected, then the website may not be responding or may be unavailable.
The HTTP sensor uses different HTTP requests to request the given URL.
- GET: requests the website directly
- POST: sends post form data to the URL
- HEAD: requests the HTTP header only, without the actual webpage body, saving bandwidth
The HTTP Advanced sensor also monitors the availability of a website, along with other parameters such as bytes received, download bandwidth (speed), and time to first byte, which shows you how fast your web server responds. This sensor lets you use a (custom) user agent when connecting to the target URL and lets you send custom HTTP headers to the target URL.
The Cloud HTTP sensor monitors a web server from various locations across the globe. For example, the URL of a website to measure the loading time of a page’s source code or the URL of a page asset to measure its availability and loading time. It also shows the global average response time.
The Cloud Ping sensor also monitors the availability of your website.
The Common SaaS sensor monitors the availability of your cloud services and is an important pillar for unified monitoring.
This type monitors internal values of a web server based application or changes to specific content on a website. The HTTP Full Web Page sensor measures the time it takes to download a webpage including all embedded page elements, such as Flash content, images, etc.
This monitoring option can create a lot of bandwidth traffic, depending on the page size and the scanning interval.
Additionally, the HTTP Content sensor monitors a numerical value returned by an HTTP request. A ‘change’ notification can optionally be triggered to notify you of changes to the content.
For example, consider a URL http://www.example.com/status.html that returns a PHP script with the current system status in a simple HTML page.
Description: Script gives back current status of disk free (%) and CPU usage (%).
You would configure the HTTP Content sensor using
- the script URL from above,
- value type Float,
- and number of channels 2.
The sensor calls the URL with every scanning interval and only regards the two values in square brackets [ ], handling each of them in one sensor channel. The additional description text and HTML tags are not necessary. In this example, they are added in case a human calls the URL.
If you define the number of channels as 1, the sensor will read only the first value. The second value will be ignored. Using 3 as number of channels will result in a sensor error message.
To be notified when the website content changes, you first need to configure a Trigger 'change notification' in the sensor's settings and then the notification itself.
See section Sensor Notifications Settings for more information.
The HTTP Transaction sensor checks if a web shop is working as expected: with a series of requests, you can simulate the login, purchasing, and shipping processes, for example. Only if all actions can be completed successfully in a row, the check returns an "OK" message. If anything goes wrong, you are immediately alerted and can react instantly to avoid loss of earnings for your company because the web shop is unavailable or very slow.
Apache Web Server Monitoring
The HTTP Apache ModStatus PerfStats and HTTP Apache ModStatus Totals sensors monitor performance statistics and the activity of an Apache web server using mod_status over HTTP. Among other HTTP sensors, these sensors allow you to enter credentials for webpages that need authentication and allow you to choose the necessary authentication method.
PRTG also provides the option to monitor the security of your website by checking the status of SSL certificates and the security of a connection.
- SSL Certificate Sensor: monitors the certificate of a secure SSL/TLS connection. It displays whether a certificate has been revoked, or is trusted as root authority, or is self-signed, for example.
- SSL Security Check Sensor: monitors the SSL connectivity to the port of a device. It tries to connect to the specified TCP/IP port number of a device with various SSL/TLS protocol versions and shows if a specific protocol is supported.
PRTG provides the option to monitor passively received data. For this purpose, you can set up a device in a way that it automatically sends the data to PRTG. Specific sensor types can receive this data and alarm you based on your individual settings. For example, all Linux/Unix and most network devices support remote devices generating data, which has to be configured on each device, and sending the messages to a PRTG probe system. Usually, only the destination IP and port are required.
See section Monitoring via Push for more information.
You can also monitor other types of data from your website, for example the number of website visitors via the HTTP XML/REST Value sensor. The sensor lets you monitor values within the returned XML code, provided your web analytics tool has an XML export option. The HTTP Data Advanced sensor access a web server and retrieves XML or JSON encoded data.
The REST Custom sensor queries a REST Application Programming Interface (API) endpoint and maps the JSON or XML result to sensor values. The mapping rule has to be available as a REST configuration file in JSON template (*.template) format according to the API definition.
For details about the return value format, see section Custom Sensors.
The HTTP sensors show their status depending on the HTTP status codes that they receive. By default, the sensor states are the following:
HTTP Status Code
HTTP Sensor Status
Warning (Yellow, Down (Red) for too many redirects)
4xx Client Error
5xx Server Error
You need to configure your HTTP sensor(s) manually only if you want to change these default reactions. In this case, you can change the sensor status based on limits and/or keyword checks.
- Server Name Identification (SNI): You can configure SNI, which has to be a Fully Qualified Domain Name (FQDN) and must match the configuration of the target server. For details, see the Knowledge Base article My HTTP sensors fail to monitor websites which use SNI. What can I do?
- Protocol Version: You can choose the HTTP protocol version that the sensor will use when connecting to the target URL.
- Authentication Method: You can define if the configured URL needs authentication, enter credentials, and choose an authentication method.
- Custom User Agent: You can enter a string to be used as user agent when connecting to the target URL.
- Custom HTTP Headers: You can send custom HTTP headers to the target URL.
See the following Knowledge Base articles for troubleshooting and other tips for monitoring with HTTP sensors.
- Which user agent should I use in the HTTP Advanced sensor's settings?
- HTTP Full Web Page sensor is “unable to navigate”. What can I do?
- What to do when I see a CreateUniqueTempDir() error message for my HTTP Full Webpage Sensor?
- Where can I find more information about the HTTP XML/REST Value Sensor?
- Why does my HTTP XML/REST Value sensor return a 404 error?
- My HTTP sensors could not create an SSL secure channel and are down. What can I do?
These sensor types are great tools to monitor your website’s availability and performance and to keep you up-to-date with real-time information.
Knowledge Base: Which HTTP status code leads to which HTTP sensor status?
Knowledge Base: My HTTP sensors fail to monitor websites which use SNI. What can I do?
Knowledge Base: Which user agent should I use in the HTTP Advanced sensor's settings?
Knowledge Base: How can I monitor internal values of a web application with PRTG?
Knowledge Base: What is the difference between "HTTP" and "HTTP Full Web Page" Web Server sensors?
Knowledge Base: Configuration Tips for HTTP Transaction Sensors needed
Knowledge Base: Is there a tool available that can help me building queries for the XML/Rest Sensor?