docusign health monitoring

LM overly complicated my vision by adding the PropertySource and thus complicating the AppliesTo of the DS.

Hello, I’m the guy who originally discovered and wrote the monitoring for Atlassian based status pages. Nice to meet you.

Obviously, I have a custom version of the DS than what LM has in the exchange/repo. Among cosmetic changes like improvements to the graphs, my version has this AppliesTo:

hasCategory("StatusPageIO_Key_Exists") || statuspageio_key	

This allows me to add the statuspageio_key to any resource in my portal thereby adding status page monitoring to it. This allows me to monitor ConnectWise status on the same resource as my other ConnectWise monitoring DataSources (rather than having one for ConnectWise and one for ConnectWise’s status page). It allows me to add status page monitoring to my LogicMonitor portal resource, even though it doesn’t match any of the above AppliesTo options.

All I do is add a property called “statuspageio_key” (which isn’t really a key, more of an ID) with value “mwr4rgcd2g69” to any resource in LM. For clarity in reporting, since I don’t have any other DocuSign monitoring in LM, I added a resource for it, but you could just as easily add it to a collector, or your portal resource, or anything really. Testing DocuSign in my sandbox portal, I did eventually disable the Ping DS on it because it seems they block ICMP on status.docusign.com. 

If you’re running a collector-less environment, you might be able to get this in the SaaS-lite monitoring. I can’t see it though because we don’t take advantage of any of LM’s SaaS lite monitoring. It creates an additional group and an additional resource with required properties distributed through both; it’s bad. If it’s not in the list, you might request LM fasttrack it. It takes about 10 minutes of dev work to get it running on their side. 9 minutes of that is finding the logo to display in the UI.