I was reading on another KB article, that the good/failed column from a PRTG report represents the requests given to a certain period of time, however this still not clear to me since the reports we get from PRTG also show the "uptime/downtime".
The column for uptime/downtime are shown in green, while the "good/failed" show in red, the following is an example of what i see in some of the sensors information from a report:
uptime/downtime 100 % - 0 % [6d23h26m58s] [0s] good/failed 99.98 % - 0.02 % [10046] [2]
Then my question would be, how did we manage to get 100% uptime in that period of time, if we are seeing 99.98% response time? how do we calculate these percents?
Thanks for the help.
Article Comments
On a related topic, I have a couple of Website uptime reports one is yearly and the other one is a weekly report.
I manage to add more decimal places to the channel settings for all websites but im running in the issue that only the Yearly report will show all the decimals (3, since we are required to report 5 digits for audit purposes 99.999) for the "good/failed" column, but the Weekly report will only show the 2 decimals (99.99), is there any setting that i need to double check to see what i am missing?
The websites are the same on both reports so that means the settings are ok (i would think).
thanks.
Apr, 2013 - Permalink
Virgina,
Could you please try updating to the newest version of PRTG, I ran the same reports and could not replicate the issue.
If this does not work, please submit a ticket with some screenshots of the issue to support@paessler.com
Apr, 2013 - Permalink
Hello,
uptime means the uptime of course. For requests it's slightly different, because PRTG only accounts downtime between at least two consecutive failed scans. So if only one request fails, it's accounted as failed/bad request but does not effect uptime. If a scan fails, the sensor goes down. To be exact, with most sensors after a failed scan PRTG performs an immediate re-scan and if these both fail, the sensor goes into down state. But that gives no exact measurement for downtime, PRTG can't know how long the target is already down. So it takes at least one more scan following the scanning interval for PRTG to have a proper valid statement for downtime.
best regards.
Apr, 2013 - Permalink