Each of us has had that time in life where we were facing unresolved problems that were blocking every movement around, but after some time, a solution came in place and we moved forward with ease.
This time we’re encouraging you to share which "set-backs" or "problems" you found difficult and almost unsolvable until you started using Dynatrace?
We are very curious to hear different uses cases where Dynatrace was helpful and improved your working process.
Every answer will be awarded with 100 reputation points!
Over the course of my journey with Dynatrace we have had many 'Dynatrace Wins' as we called them. Several of these Wins captured the attention of @Andreas G. who then wrote up a use case about them.
Those are just a few of the many use cases that we have had over the course of our Dynatrace journey and while we always want to be issue free, we look forward and welcome any issue that might arise as we have full confidence that Dynatrace will not only detect and alert us of the issue, but also provide us the root cause of the problem thus allowing us to resolve it quickly while minimizing the impact to our customers!
I have several cases in which Dynatrace was clearly a game changer. My favorite one was at a Bank, with a team of several people trying to figure out why a new RPA solution wouldn't work for weeks . We did a PoC with Dynatrace and in a few minutes the solution was up & running. A little bit more detail is available at:
Before I started using Dynatrace, I believe the items below are some of the problems that I had, that were particularly difficult to tackle:
I have an interesting case from a customer that always stuck with me. Basically they had a database system where there was a primary instance and then some 'read replicas' that internal applications were supposed to use for reading data for reports etc...
A long term challenge they had was when apps would be reading large amounts of data from the primary instance which at times could impact performance and cause slowdowns in the main application that wrote to the database. It was difficult to identify where that load was coming from so they did not know which teams to contact internally to request that they use the right 'read' instance.
Using Dynatrace it was simply a matter of using the Service Backtrace tool on the database service to see which services and applications were calling it. This made it a simple task of reaching out to the owners of those services.
one of the quick cases that I met several times with different customers where we implemented the Dynatrace
we did a PoС. The Customer deployed the solution to the testing area.
They rolled out a new release and saw that the CPU load reached 100 on the hosts.
They tried all day to find the cause with their own monitoring tools, but they were not successful. Then they remembered that they had Dynatrace installed in this environment.
then they called me and we found the problem on the phone in 5 minutes.
The solution is as follows:
Dynatrace shows not just the CPU load on the host, but allows you to go deeper and understand which process and service is consuming it.
We found a problematic service, but we didn't stop there. Further, the Dynatrace allows you to see how much CPU time each operation consumes. In two clicks, we found an operation that consumed all the CPU.
Then there is a useful comparison function that allows you to compare an operation or service before and after a release. In our case, it turned out that the operation data was a new function of the application and after the release it broke.
We've already localized the problem, but we haven't stopped. Dynatrace allows you to decompose the operation time into methods in order to understand what problems at the code level caused the service to degrade. We localized problematic methods and committed them to development, which made improvements to the release