<%NUMBERING1%>.<%NUMBERING2%>.<%NUMBERING3%> PRTG Manual: Monitoring via Push

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 sensors can receive this data and alert 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 probe system. Usually, only the destination IP and port are required.

Push monitoring enables you to use webhooks to push messages to PRTG using HTTP. Wikipedia describes a webhook as a method of augmenting or altering the behavior of a web page or application with custom callbacks.

PRTG comes with sensors for push monitoring:

• HTTP Push Count sensor: counts the number of received messages.
• HTTP Push Data sensor: displays numerical values from received messages.
• HTTP Push Data Advanced sensor: shows received values and messages encoded in valid Extensible Markup Language (XML) or JavaScript Object Notation (JSON).

Use Cases

The push technology can be useful for monitoring in different cases, for example, when target devices do not allow requests via the usual technologies. The following scenarios are good examples of where to use HTTP Push sensors.

• Devices that cannot run a probe
• Appliances that are not accessible via Secure Shell (SSH) or the Simple Network Management Protocol (SNMP)
• Web servers that can periodically run certain scripts or PHP
• Migrating a lot of EXE sensors into one EXE script that manages the HTTP Push sensors and sends data to them. Some coding is required, see the Knowledge Base article: How can I monitor SCVMM hosts and VMs with PRTG?
• When monitoring Linux services, see the Knowledge Base: How can I monitor and automatically restart a service on a Linux host?
• If you need to push a lot of data to PRTG in short periods of time: the sensors have been tested with about 10,000 values pushed within one minute.

How to Use

Webhooks basically work like push messages. These are triggered by an event (for example, a new comment to a blog post) and send according information to a specified URL in real time. You can use this technology to push messages to the probe, and monitor count and content with HTTP Push sensors. Because webhooks use HTTP, you can integrate them without having to add new infrastructure to your network.

Recommended Configuration

Follow the steps below for a sample configuration of the HTTP Push sensors.

1. Add the sensors.
2. Define the URLs.

Step 1: Add the HTTP Push Count, HTTP Push Data, and HTTP Push Data Advanced sensors.

You can use the standard method to add sensors to your configuration.

1. Select the probe device or a device of your own.
   A device of your own has no practical advantage with HTTP Push sensors but it might be good for organizational purposes.
2. Click Add Sensor and filter for Push Message Receiver under Technology Used.
3. Select one of the HTTP Push sensors that fits best to your intended usage.

For more details, see section Add a Sensor.

You cannot use this sensor in cluster mode. You can only set it up on a local probe or a remote probe but not on a cluster probe.

Step 2: Define the corresponding URL to send HTTP requests to PRTG.

For the desired configuration to be properly sent to and received by PRTG, use the following URL formats.

HTTP Push Count Sensor

The HTTP Push Count sensor uses the following URL:

http://<probe_ip>:<port_number>/<token>

Replace the parameters <probe_ip>, <port_number>, and <token> with the corresponding values.

• The <probe_ip> is the IP address of the probe system with the sensor.
• The <port_number> is where the sensor listens for incoming HTTP calls.
• The <token> is used to define the matching sensor.

Example:

http://192.0.2.0:5050/XYZ123

You can use several sensors with the same port and identification token. In this case, the number of push messages is shown in each of these sensors.

HTTP Push Data Sensor

The HTTP Push Data sensor uses the following URL:

http://<probe_ip>:<port_number>/<token>?value=<integer_or_float>&text=<text message>

Replace the parameters <probe_ip>, <port_number>, <token>, and <integer_or_float> with the corresponding values. The &text parameter is optional: You can omit it.

• You can define the port number and identification token in the sensor settings.
• The probe IP is the IP address of the probe system with this sensor.
• The value can be an integer or a float value depending on the data of your application. You have to set the value type accordingly in the sensor settings. This parameter is the sensor value.
  If this parameter is missing, the sensor shows a Down status.
• You can optionally add a custom text message by replacing the parameter <text message> with your custom text. The text is shown as the sensor message. If there is no value but only a text, the text is shown as an error message.
  This text message has to be URL encoded (for example, the whitespaces in the sample URL below). Most browsers do URL-encoding automatically.

Example:

http://192.0.2.0:5050/XYZ123?value=0&text=this%20is%20a%20message

 
You can use several sensors with the same port and identification token. In this case, the data of push messages is shown in each of these sensors.

HTTP Push Data Advanced Sensor

The HTTP Push Data Advanced sensor uses the following URLs depending on the type of HTTP request.

• GET requests: http://<probe_ip>:<port_number>/<token>?content=<valid XML_or_JSON>
   
  The XML encoded value of the content parameter has to match the format as defined in section Custom Sensors.
• POST requests: http://<probe_ip>:<port_number>/<token>
   
  This HTTP request method sends the XML or JSON encoded HTTP body as POST data. The body has to match the format as defined in section Custom Sensors. For POST requests, use an HTTP content type other than application/x-www-form-urlencoded. We strongly recommend the HTTP content type application/xml or application/json.

Replace the parameters <probe_ip>, <port_number>, <token>, and <valid XML_or_JSON> (for GET requests) with the corresponding values:

• You can define port number and identification token in the sensor settings.
• The probe IP is the IP address of the probe system with this sensor.
• The content of GET requests has to be valid XML or JSON in the PRTG API format.
  The content has to be URL encoded (for example, the whitespaces in the sample URL below). Most browsers do URL-encoding automatically.

Minimum example for the GET method that returns one static channel value:

http://127.0.0.1:5050/XYZ123?content=<prtg><result><channel>MyChannel</channel><value>10</value></result><text>this%20is%20a%20message</text></prtg>

By default, values within the <value> tags in the returned XML or JSON must be integers to be processed. If float values are returned, you have to explicitly define this value type as defined in section Custom Sensors with <float> tags, otherwise the sensor shows 0 values in affected channels. Example:

http://127.0.0.1:5050/XYZ123?content=<prtg><result><channel>MyChannel</channel><value>10.45</value><float>1</float></result><text>this%20is%20a%20message</text></prtg>

You can use several sensors with the same port and identification token. In this case, the data of push messages is shown in each of these sensors.

More

KNOWLEDGE BASE

How can I monitor SCVMM hosts and VMs with PRTG?

• https://kb.paessler.com/en/topic/68767

How can I monitor and automatically restart a service on a Linux host?

• https://kb.paessler.com/en/topic/70771