I use the Business Process sensor to get a summarized sensor status for a whole business process that involves several business components.
I wonder how this overall sensor status is calculated from the single process components that I monitor.
Created on Oct 20, 2015 8:01:12 AM by
This article applies to PRTG Network Monitor 19 or later
The Business Process sensor allows you to get an overall status of a whole business process while monitoring several involved process components. This makes the Business Process sensor a powerful and also very flexible tool.
While administrators are generally interested in the states and data of every process component, employees of a company that are less technically inclined often do not need to see more than the summarized status of a process to know if it works or not. For example, an accounting manager is okay with the information “Our website works fine”, whereas a business infrastructure manager prefers to get exact information about the involved web servers, databases, and other hardware and applications.
This article describes how the Business Process sensor calculates summarized sensor and channel states from the states of single monitored objects.
With the Business Process sensor, you can create individual sensor channels from the monitoring objects that you have in your network. You can select single sensors or whole devices, groups, or probes for a specific business process channel.
Every object in a channel has its own status that contributes to the overall status of this channel.
The Business Process sensor decides for every monitoring object if it is in an "up" or "down" condition.
Note: The Business Process "up" and "down" conditions are different from the Up and Down states of a sensor. This is necessary for the Business Process sensor to be able to calculate summarized states. Have a look at the following table to see which sensor status leads to which Business Process condition (BP condition).
| Channel Object Status | Business Process (BP) Condition | Reason: Why does a given sensor status correspond to a given BP condition? |
|---|---|---|
| Up | Up | The monitored object works. |
| Warning | Up | The sensor may show a warning, but the monitored object works. |
| Down (Partial) | Up | This status is available in a cluster setup and is displayed if at least one cluster node reports that the sensor shows an Up status and at least one cluster node reports that the sensor shows a Down status. With at least one report stating an Up status, the monitored object is supposed to be working. |
| Unusual | Up | The sensor may show unusual values, but the monitored object works. |
| Collecting | Up | The sensor is still waiting for more monitoring data to definitely decide on the sensor status, but so far the monitored object works. This PRTG-internal status is visualized as Unknown in the PRTG web interface. |
| Down | Down | The monitored object does not work. |
| Unknown | Down | The sensor does not know if the monitored object works, for example because it has not yet received any data or because it has not received any data for a certain amount of time. |
| None | Down | The sensor has not received any monitoring data from the monitored object yet. This PRTG-internal status is visualized as Unknown in the PRTG web interface. |
| Paused | Down | The monitored object does not work and monitoring has been paused, for example actively by the user, by inheritance, or by executed schedules. |
| Acknowledged | Down | The monitored object does not work and someone already knows about it. |
The Business Process sensor calculates the percentage of the "up" and "down" conditions per channel.
For example, the channel Core Server Security contains 75 % of sensors that are in an "up" condition.
25 % Up Status + 25 % Warning Status + 25 % Warning Status = 75 % BP Up Condition
25 % of all sensors are in a "down" condition.
25 % Down Status = 25 % BP Down Condition
With individual error and warning thresholds, you can define the limits for the Up, Warning, and Down states for every channel.
Define the threshold in %.
This is what the sensor does to check which overall channel status it has to display:
Calculate the percentage of "up" conditions of a channel based on the objects it contains. As a result, you could translate this into the statement: “x % of the monitored objects work fine.”
Compare the calculated value for the "up" conditions of a channel to the Error threshold.
Compare the calculated value for the "up" conditions of a channel to the Warning threshold.
Note: If the indicated threshold points exactly to the borderline between two states, the sensor will display the more positive status. For example, if you enter 75 as a warning limit and you have 3 sensors in an Up status (75%) and 1 sensor in a Down status (25%), the sensor channel will display an Up status, not a Warning status because 75 % of the monitored objects work fine.
If these are your settings…
... this will be your result:
The reason is that you have 50 % of objects in an Up status and 50 % of objects in a Down status in your channel and your error limit is 51 %. The sensor checks “Do 51 % of the objects work fine?” and the answer is no. Because of this, the Core Server Security channel displays a Down status.
If you set an error threshold of 50%, the sensor would check if 50% of the monitoring objects work fine. The answer would be yes and consequently, the sensor would show an Up status.
If these are your settings…
... this will be your result:
The reason is that you have 75 % of objects in an Up status and 25 % of objects in a Down status in your channel and your warning limit is 76 %. The sensor checks “Do 76 % of the objects work fine?” and the answer is no. Because of this, the Core Server Security channel shows a Warning status, but not a Down status because 50 % of the sensors work fine.
Note: Every object in a channel has equal weight or importance, no matter if it is a sensor, device, group, or probe. If you want to give double weight or importance to an object, add it to the channel twice. If you want to give triple weight to it, add it three times.
In the following example, the SSL Security Check (Port 443) 16 sensor is added twice and has double weight.
The Core Server Security channel contains 80 % of sensors that show an Up status.
2 * 20 % Up Status + 2 * 20 % Warning Status = 80 % BP Up Condition
20 % of all sensors show an Unknown status.
20 % Unknown Status = 20 % BP Down Condition
Consequently, the overall Core Server Security channel status is Up, because 80 % of the sensors work fine and at least 61 % of the sensors have to work fine to not trigger a Warning status.
The Global State channel is the default primary channel of the Business Process sensor and summarizes the states of the individual channels. It always shows the status that all channels have or, if not all of the channels are in the same status condition, the “most alarming” status that one of the individual channels has.
For example, the Global State in Example B above shows a Warning status because one of the individual channels, the Core Server Security channel, shows a Warning status, too. Example A shows a Down status because one of the channels, the Core Server Security channel again, shows a Down status.
Generally, the Business Process sensor can have the following sensor states:
The order from the least alarming to the most alarming sensor status is the following:
(Unknown Status) < Up Status < Warning Status < Down Status
Created on Oct 20, 2015 12:26:06 PM by
Last change on Dec 9, 2020 2:59:50 PM by
Hello. Why The Business Process (BP) Condition is in "Down" state when the Channel Object Status is "Paused" or "Acknowledged". How I can change this condition? Use case: I need to know about BP "Down" states when only the specific sensors are in "Down" states, not for the device down. To do that, I set up Threshold of the BP channel to 99% error. But actually when one of the Channel Object status is becoming "Paused" by depensy settings of devices (for example - one host reboot), the BP Global State is becoming "Down" to.
Created on Mar 4, 2016 12:23:34 PM by
Hi Dimitry,
The sensor will indeed only ignore all other states except for the down status if you add the complete device to the channel definition of the business process sensors. Other states of sensors and channels will count into the down percentage, this cannot be changed. If you really are in need to define the down condition only for a certain sensor, the only workaround I see at this point would be to add a new device with this particular sensor and add it to the channel definition of the business process sensor.
Best regards, Felix
Created on Mar 7, 2016 12:59:17 PM by
Hi Felix, We don't think your statement 'The sensor will indeed only ignore all other states except for the down status if you add the complete device to the channel definition of the business process sensors' is correct. We'd definitely like it to be, but when we pause a single sensor on a device that has been added to a Bus Process sensor, the whole Bus Process sensor reports 'Down'. This is clearly not ideal. So we have to delete sensors instead of pausing them on such Devices.
Would it be possible to have an option on the Bus Process Sensor to make it work the way you describe? Mark
Created on Mar 6, 2017 4:42:08 PM by
Hey Mark,
Please excuse the confusion. I just tested it and I can confirm that the paused status is counted into the error condition of the sensor. Due to the complex internal structure of the sensor's code, this will not be changed I'm afraid. We will change the manual accordingly.
Best regards, Felix
Created on Mar 7, 2017 6:12:30 AM by
Last change on Mar 7, 2017 6:43:15 AM by
Is there a way to modify the Lookup to change this behavior? I would very much like to be able to pause sensors within a buisness process sensor without it being marked as down because of it.
Created on Dec 1, 2020 4:32:13 PM by
Hello,
I'm afraid that it's not possible to change how the Paused status is counted in the Business Process sensor, due to the complexity of the sensor's internal structure.
Kind regards.
Created on Dec 2, 2020 11:11:38 AM by
Please log in or register to enter your reply.
Add comment