How do you configure DC Rum to monitor cloud apps? The real question is, am I missing something! I configured my AMD for a new auto-discovered software service for a new cloud based app which I want to monitor (used forum article for WebEx cloud app). I still am not seeing this new software service in Traffic Discovery or Software Service explore.
The short answer is you will have to utilize something like Ixia's Cloudlens solution to feed that data to the AMD after that it should all work the same so long as the AMD sees the bi-directional traffic tcp traffic.
So traffic from Gigamon to the AMD wouldn't be the same? Our users access WorkDay from the intranet; I was told my our network team we were receiving the data. What's the long answer?
I believe Bill is thinking more about SaaS applications (e.g. Workday, Dynamics 365, etc). We're already exploring Dynatrace Synthetics and the Dynatrace SaaS Browser Plugin, but since they have DCRUM already in place and their users are largely from their intranet, we're exploring monitoring via DCRUM as well. Is there anything we need to do other than:
Yeah that process all sounds correct its really a matter of defining the correct services. If you are not seeing traffic I would capture a trace from the AMD and ensure you are seeing the correct addresse
The question has multiple answers that pertain to different scenarios. It looks that your case is about monitoring SaaS apps consumed on premises, like WorkDay accessed by the office users. If this is the case, then what you need is a feed of those users’ traffic to the Internet. If you have Gigamon in your data center, the Gigamon guys would have to set up its config to feed the outbound Internet traffic to the AMD. This way you will see all users’ activity with the Internet, including WorkDay and everything else. This may be lots of traffic, but that should be fine. Just remember to not enable all-traffic auto discovery on AMD because you will end up with the whole Internet gamut of servers discovered by the DC RUM:-) Stay with user defined software services, for the starter.
Next step would be to define software services to monitor and report as Workday. Their IP address range seems to be 184.108.40.206-220.127.116.11, so try putting this as the server IP address range in software service definition and use SSL non-decrypting decode for analysis. Why the non-decrypting SSL decode? Because Workday won’t be willing to share their SSL keys with customers, so there is no other choice than analyze what can be analyzed without decryption or use a man-in-the-middle appliance (e.g. from Gigamon) - but let’s leave that second option aside for now.
What you should get is volumetric data on all user activity and gauges of performance: connection setup time (including SSL), realized bandwidth when working with Workday sites. What you won’t get are per-named-transaction measurements (because these can’t be seen without decryption). Please remember that only your on-premises users will be measured this way, i.e. those whose traffic is visible to the AMD.
There are extensions and alternatives possible. For example, you man want to configure your cloud SSO provider address ranges in a similar way, or another SaaS application monitoring.
An alternative to this approach is the Dynatrace SaaS RUM agent - a Chrome plugin that has to be installed on your users’ browsers. This would allow regular Dynatrace RUM measurements from within the browser. But the plugin is a requirement.
I forgot to add: if you could share a tcpdump of someone's login to Workday, we could think about automating the Workday discovery as an application in DC RUM. It is safe to share such tcpdump, as it will be all SSL encrypted. What we need is insight into certificate names and server names requested by the client in SSL connection setup - AMD relies on looking taint these to automatically recognize the applications. We currently do it for Salesforce, SAP, Microsoft and several more, but we don't have patterns defined on AMD for Workday.
No. SSL analysis comes together with the SSL decryption, that's a single licensed option. Without this license we will only recognize it's SSL, but won't do any further analysis beyond generic TCP.