Pega's POV on the use of Dynatrace to monitor environments
I am working in an environment where the enterprise tool of choice for monitoring of environments is Dynatrace. This has caused and continues to cause a lot of challenges investigating ‘problems’ that Dynatrace sees, but don’t appear in any of the Pega logs. By means of example, the StacklessUnsupportedOperationException.
From a Pega perspective, keen to get your view point on Dynatrace for the purpose of monitoring Pega Applications. We’re well aware of the tooling Pega offers, such as PDC and AES, and not after a recommendation to use those instead. What I’m looking for is a recommendation as to how to use Dynatrace effectively. Dynatrace is the tool of choice for a number of enterprises, and hence would like to understand how we can use Pega effectively in this enterprise wide monitoring architecture.
There will be, I’m sure other clients will use Dynatrace for this purpose too. Hence, raising this here in order to get a standard view and approach for applying to all implementations where Dynatrace is the tool of choice.
What is Pega’s recommendation as to how to get the best out of Dynatrace as a monitoring tool?
***Edited by Moderator: Pallavi to update platform capability tags***
Simon, as you say there will be other clients using dynatrace, so I imagine what your asking is for other peoples experience with Dynatrace rather than Pega's.
Dynatrace is not a tool we would formally test the application with (to my knowledge) as we use our internal tooling.
There are many tools such as Dynatrace, Wiley, App Dynamics etc which customers use with varying degrees of success.
On site I have seen Dynatrace used poorly and well, it depends on the knowledge of dynatrace and Pega. Monitoring everything in Dynatrace can add in a performance hit so wouldn't be recommended.
You also need to be careful as some exceptions seen in Dynatrace but not in Pega are due to being handled in the application (DB updates v inserts as an example) this can lead to weeks of chasing false positives.
I see dynatrace as good for monitoring , infrastructure, JVM and Integrations, ive seen customers deploy Dynatrace UEM and Portals stop working due to the way the Pages are monitored, in that instance compression was turned off and it worked again but was naturally slower than before.
A lot of what you want to do will be driven by how the organisation uses the tool anyway and what they want and need to achieve and at what cost to performance as all monitoring has some cost.
It may be you have a agreed level of monitoring in production, and if dynatrace is used in lower environments it may be more aggressively monitoring in those environments to support bug fixing of a particular issue, however many organisations only want to use it in Prod due to licensing.