In order to use the Common SaaS Check, I need to get the PRTG server added to the proxy, with a whitelist of URLs/IPs. I've looked at the sensor but I can't see the URLs.
This sensor is a great idea but it would be more useful if I could remove some of them: I'm not interested in Dropbox, Salesforce and GitHub, for example. It would also be useful if I could add my own.
Article Comments
I, too, would like to be able to add an additional SaaS check -- CrashPlan. Is there any way to do that? If not, can that be considered a feature request?
Jul, 2016 - Permalink
Hello and thank you for your KB-Post.
This is currently not supported and there are currently no plans to add this support in the future, please consider using an HTTP or HTTP Advanced sensor to query the HTTP Status of an URL(in the same way as the Common SaaS sensor does it except for not being multi-channel).
Alternatively, consider using the HTTP XML/REST Value Sensor to query the actual status of their systems if they offer a REST-Compatible XML/JSON API to confirm that it is working.
Best Regards,
Luciano Lingnau [Paessler Support]
Jul, 2016 - Permalink
Hi, I would like to monitor Office365, so I create a devices, as IP/DNS I PUT https://outlook.office365.com/api/*
Then I Added a Saas Sensor (checking O365)
The sensor doesn't retreive any data, is there something wrong?
Dec, 2016 - Permalink
Hello Carlascom,
thank you for your reply.
Please check your standard "probe device", the Common SaaS Check sensor will have been deployed there by default. Does this one work?
Please note that the URL's polled/monitored by this sensor will always be tested/monitored from the Probe device, not from the device on which it was deployed.
Best Regards,
Luciano Lingnau [Paessler Support]
Dec, 2016 - Permalink
Hello,
thank you for your inquiry.
The Sensor uses the following URL's, please mind the * wildcard:
As for the sensor's channels, the sensor is created by default (on all probes) with all channels, but you may delete and manually re-create the sensor, this will allow you to select only the services/providers which you want to monitor.
Note about proxy/firewalls: The queries performed by the sensor don't use an API Key or any sort of authentication. As a result, many of the websites reply with HTTP codes in the 4xx ~ 5xx range. Example: 401, 400, 403 and so on. The sensor has been adjusted to expect these codes as a valid response.
Firewalls and proxies may deny URL's with a 4XX error code (which is the expected reply, unless it silently drops the requests). This can lead to false positives, unreachable services (blocked by the firewall) would show up as "Working" in the sensor when blocked with a 4XX HTTP Code. The response times for these services would also be unusually low, since the sensor is actually measuring the response time of the denied message from the firewall/proxy.
Best Regards,
Luciano Lingnau [Paessler Support]
Jan, 2016 - Permalink