Dynatrace Reviews

My primary use case is to monitor business applications, mostly with Web front-ends, to provide access for end-users and consumers.

We have reduced our troubleshooting times and improved the way that we deal with most of the bugs in the applications. It's very easy to reach the root cause of the problems in the applications, due do the analysis with Dynatrace. The timeframe to update and fix the applications has been reduced a lot compared to what we had before Dynatrace.

It's the ease of deployment and ease in configuration. It's very comprehensive in its features to monitor end-to-end transactions.

I'd like to see more agents ready to be deployed. I know that it's possible to develop integration with Dynatrace API, but in day-to-day operations it's hard to do that kind of customization. So if they had more agents for more platforms and more applications, I think it would be better.

We have absolutely no problem with the solution. It's very stable.

In terms of scalability, my company is not that large, but it looks like the scalability is very good. We don't have any problems with scalability.

It's very good technical support. We don't have many issues with the product but when we have, we get very quick solutions. It's very good support. Nothing to complain about.

We used multiple solutions, the ones that came with the different applications. So a solution that monitored the database, and another solution for the application server, and a different one for the server hardware, and the connectivity. We had to integrate all the information that came from these separate solutions to come up with a conclusion about what was happening. This was the main driver that lead us to look for a real end-to-end solution. 

The business perspective had a lot of weight in our decision because it was hard for us to really correlate the components of the application, and how it impacted the business application and the business itself. These were the main drivers that lead us to buy this product.

In terms of the most important criteria when selecting a vendor, we usually look for a product or a vendor that has good positioning in industry reviews. With that, the pricing is very important. Also, the features. So it must be a top vendor with the best possible pricing and the features that fit our needs.

I was not really involved in the initial setup. I just coordinated the deployment. But it didn't need seem we needed to do too much for the setup of Dynatrace. We had to focus our efforts on group duplications, from a business perspective, but everything else was discovered and automatically set by the Dynatrace application itself. I don't think we had much trouble.

The real complexity that I've seen with Dynatrace is to learn how to navigate through all the options in the troubleshooting process. We have a lot of ways to evaluate the same problem. We had some difficulties in the beginning with the use of the product, but after some time and some experience we have overcome this problem.

I understand that due to comparisons we did, that Dynatrace is still kind of an expensive solution compared to others. But I recognize that they are ahead of the competition when we do a feature by feature comparison. We have a very stringent budget for an infrastructure solution. Maybe if they provided modules, a simple module with fewer features and a lower price, that would be very good.

CA, Computer Associates, was on our short list as well as BMC PATROL. These were the main vendors when it came for my evaluation. Some research was done and I received these vendors as the best options to evaluate.

We decided on Dynatrace, over Computer Associates and BMC, mostly because of the difficulties that we thought we would have after the setup of the product. Dynatrace was the most expensive, but we had almost no need for service, for Professional Services. We just did some training and we contracted some consulting hours and that was it. The deployment with Dynatrace seemed to be easier than the others. We needed to get results very fast, due to the size of the investment.

I would rate it with a grade of eight out of 10 because it's a very good solution. We got results very fast after the initial deployment, but I still find it very expensive. So we are still being questioned about the cost-benefit. The value that we have in Dynatrace - I don't think I will have this kind of budget in the near future - it's worth it now.

My main advice is to evaluate the effort to set up the solution, customize the solution, after acquiring it. I know that we had better pricing, lower pricing, with the other competitors, but as I talked to some other customers that use BMC and Computer Associates, everyone told me it was a long run until they reached the setup that they needed. And they still have a lot of maintenance. Every change in the thresholds of the applications, they have to come back to the standards and redo the setup, but Dynatrace does it all by itself.

Application process monitoring, and user-experience monitoring.

It's used for monitoring inside of applications, like JVM thread-level applications, plus the user. I monitor usage statistics, performance statistics, plus the user satisfaction level.

We got to know which modules of my application are used more by the customers, as well as which modules of my application are very slow. It has helped with my overall my performance statistics.

There are different phases of product development. In the testing phase I was not able to determine if things were going fine or what was going wrong in my application. But using this tool, I got to know - even before the customer got to tell me - this or that particular module was not working. 

Using this tool, I got to know the moment he got a page-out error on his screen. It told me, for example, a person in the US is facing this particular issue. Because the alert came, we worked on it, we resolved it and things were easy.

The moment he called us we just said, "Yeah, we have already acknowledged that issue and we have resolved it. You can just try it again." The person was happy. The customer's satisfaction has improved, overall.

We also got know many internal code bugs which could have caused memory leaks or other issues which we were not able to catch during that development phase.

We also got to know, on the network level, where the latencies were. If you go via Google, what Google says is that you have a number of things on which you should measure your performance. One is if there's an error or not. Dynatrace tells you whether is an error or not. Second is saturation, whether something is getting saturated. You should be aware of what is getting saturated. Dynatrace even tells you that. The third is if there is a latency. Network latency is also told to me by Dynatrace. So these are three things I got out of Dynatrace.

The performance features are most important ones. That would include reporting, you get reports on your performance data.

The next is the alerting feature. For example, my applications are going out on some thresholds. So I get alerts, according to the thresholds I set. I get that data via emails as notifications. That is another feature that we primarily use and we like from Dynatrace.

Also, it's easy to use. The usability is better in Dynatrace.

The fourth thing is: my customer is facing some issue. The linking is very good in Dynatrace. What happens in other monitoring tools is the linking is not proper. In those solutions, a person has to manually link many of the layers and what is happening in them, while in Dynatrace you get that from the very first visit. For example, if a person is visiting your website, from there it will traverse you to the end. If the application is a Java application, it will traverse you there, to the Method level. So that linking and traversing is better in Dynatrace.

If Dynatrace is capturing everything in your application, it has to "sense" that information, and that sensing needs sensors which we have to include in our applications. The more you apply sensors - the more details you want  - the more you have to increase the level of sensing. If I increase the level of sensing, my application's performance goes down, because something is there that is, again and again, checking each and every thing in the application. So that load on the applications increases.

So, many times my applications used to crash because Dynatrace was working on them. So that was a negative point. We had to remove some sensing; either we had to reduce the sensing or we had to remove Dynatrace immediately. So that is one thing we don't like about Dynatrace.

And the second is dashboarding. The dashboarding in Dynatrace is not very good. We have used other monitoring tools like AppDynamics. We are also using AppDynamics for some of our products. If I compare Dynatrace with those monitoring tools, the dashboarding is not as good. If I have to create a dashboard it takes me time, the experience is not that good. The automatically generated reports are good, but the dashboarding was something we were expecting but did not get.

Also, sometimes it happens that we are not able to capture things. For example, if a person is logged in from India, from the city of Mumbai, and is using a Chrome browser, and his email ID is xyz@abc.com. But what happens is, Dynatrace just fetches two pieces of the information, not all of it. Sometimes it gets it all, sometimes it doesn't. So that also came into picture.

The last and the most important, which we did not like about Dynatrace - and that's why we switched to other monitoring tools recently - was the support. We were not able to get proper, good support from Dynatrace. We had to raise a lot of tickets and then, one fine day their people would eventually come around and resolve the issues. The input we had to give them was very high. Support was very bad for Dynatrace, especially in the India region.

When you go for a monitoring tool, there are two types. One is SaaS. The SaaS version means that the monitoring tool is not deployed on your servers, they are deployed on their servers. The second one is on-premise.

We were using the on-premise and we were using very good servers for the Dynatrace deployment. Stability didn't come into picture. The version that they gave us was very stable. There were was no code bugs. Actually, there were some, but those were fixed immediately.

As far as on-premise was concerned it was fine.

Scalability was fine. We were using around 100 application licenses, 100 Java licenses. On that scale it was able to handle everything. There was no reason to scale it up. I'm not sure if it could be scaled up to 500 or 600 licenses. We didn't do that. It was able to handle the load in the one tier.

I rate tech support very low. The technical support was not that good. They were not very attentive whenever there were issues, even the critical ones. We were not able to find the proper support from their end so I don't rate it very well. A one or a two out of five.

Initially, we were using New Relic. But, after that we switched to Dynatrace because of the amount of functionality, the amount of troubleshooting it was giving us was more. That's why we shifted from New Relic to Dynatrace.

But once we saw the negative points of Dynatrace, we recently shifted from Dynatrace to AppDynamics. We are in a process of shifting all applications from Dynatrace to AppDynamics.

It was straightforward. It was was easy to add up. It was not complex at all, while the other monitoring tools are more complex than Dynatrace. Dynatrace was not that bad.

The licensing for Dynatrace is high. If you want to go for monitoring solutions, then why Dynatrace? If you have a particular budget, you can go for many other monitoring tools - apart from Dynatrace - and they can help you more and give more data than Dynatrace can.

And secondly Dynatrace also comes with a lot of issues, which I have mentioned elsewhere in this review, which can easily be rectified using other tools. It's not worth the money that you spend for Dynatrace.

Initially we were using New Relic itself. Dynatrace was one thing that we were evaluating. ManagingEngine was a new one at that time from what I recall but, I'm not sure which ones were part of the evaluation, because I was not totally a part of the PoC.

Apart from that, if you want to use on a system level, you can use Nagios, that's freeware. It's also good but, again, it is just a system monitoring tool. It's not an APM. So if you wanted to go for APM, then only New Relic. It was the one competitor for Dynatrace, at that time.

In terms of implementation, it's quite easy, now that there are many automation tools. So just integrate Dynatrace with the automation configuration tools. Just ask Dynatrace which integrations it has, for example Chef, or Puppet. If you integrate, the configuration will be easy.

Also, the configuration needs to be standard. The standards should be set initially. There should be a standard protocol; that needs to there. If that's not there, then issues may arise later on. These are some things which are advisable when you work with Dynatrace.

I would rate Dynatrace a six out of 10. When I consider all the negatives plus the positive points which I have already discussed, I end up at six, including the licensing and everything. 

Application monitoring to quickly troubleshoot production issues and determine the root cause, as well as non-functional performance testing in QA.

Dynatrace has helped us reduce outage times and severity of impact.

So far, we have not achieved the benefit of preventing issues.

Quick availability of multiple aspects of performance from infrastructure to application layers.

• Wider coverage of platforms supported.
• Better mapping to true business service rather than purely technical monitoring.

Experience with relationship/account manager has been really poor, it does not seem to be the firm's priority to support their customers.

Our primary use case right now is that we are dealing with the perfect days and non-perfect days.

We have a certain goal. E.g., for this financial year, we want to have 350 days of perfect days. The perfect days is where every application in the business should have low business impact, all applications should be available, and there are some other metrics that we want to know. 

We have constraints whether this is a perfect indicator, and saying whether it is a perfect day or not. There are some situations where one of the JVM is down, but the other processes, which do the same thing are up. In this case, pretty much there is no business impact. However, there is a technical issue, though no business impact. We can't sell this as a non-perfect day. Yet, it is a perfect day. 

Right now, we are using AppMon. Therefore, we are using AppMon to find out what metrics are available for us to see or indicate what is a perfect day or non-perfect day. That is one of the things. We are also using reactive stuff more for reactive stuff at the moment.

We are using AppDesk on user experience in indexes for customer satisfaction. 

We have been using for almost one year. It has been performing well.

The most valuable feature in AppMon is the PurePaths. Previously, we did not have this feature. The transactions using PurePaths are a good thing. 

We have like different teams like in a cross structure (DevOps, infrastructure, IT, product monitors, and developers), who recently joined the team. They are not aware of what are the missions their touching and what are the other components or services that they are depending upon. Because of all this, it has been very helpful for the developers who just joined the team. It can be explained, "Okay, this is our application. These are all the components that we are touching. Changing any of this might affect all these structural things. If we want to do any changes to this, we might need to put all this in our test cases, then QA it just to make sure we are not corrupting it."

In AppMon, the performance could be improved. That is the one thing I am most interested in. 

The other thing is the database. They might improve the database stuff a little bit more. The metrics and whatever that they are providing for database.

AppMon is lacking the AI that can be found in Dynatrace Managed.

Maybe last year, we had issues interacting with the MQs and the mainframe. They completely resolved this issue in 6.5, so we are now good.

We do not have downtime using Dynatrace.

It does scale well. 

Right now, we have some performance issues with Dynatrace AppMon, but the AppMon team is working closely with us registering the number of issues we are having and providing an extra set of tools that helps us to make the performance of the tool better.

One of the performance issue is when we are trying to bring up user data, such trying to bring up 20,000 or 50,000 PurePaths. That is where it is taking like five to seven minutes. When we are on a call, we do not have that much time. We want to make it approximately less than two minutes. They are doing a great job on that.

I would rate the technical support very well. They work with the inside their development teams to get us the best answer, as much as possible.

We have LoadRunner and Wiley. Our company has used Wiley for 13 years. 

They are one stop tools. If there is an issue, we have a team that always is on call: One should come from infrastructure, another from the data side, another from the product AVR, another from mainframe, and one person from Wiley saying, "These are the threats we have and open systems." So, we have five different people on a single call for a single issue. Sometimes we have 10 to 15 people on the call to figure out the issue.

With AppMon, looking at the translation flows and the PurePaths, we can with one or two members can identify and start to find where the problem is. So, this is a good feature.

The initial setup was straightforward.

We did have technical support help. During the first year, they have given us a resource, who has helped us in setting up the Dynatrace: getting some applications onboard, how to set up on dashboard, etc. This has helped us a little bit getting more familiar with the app and getting up to speed.

We have some demos on the Wiley, but they came very late to the table. Also, Splunk ITSI reached out to us.

For 13 years, we have been using Wiley. We definitely liked seeing the PurePaths being more helpful for us. As to Splunk ITSI, there is more configuration than AppMon. That is the reason we chose AppMon.

If you are implementing it for mainframe or MQ stuff, what are the things available and what are the other configurations that you need to set up.

Right now, we do not have AI capability. We are on AppMon. For us, it is about going and debugging the PurePath and looking into what is the issue: finding out the other use cases or root causes. It is pretty much manual. We are trying to moving from AppMon to Dynatrace Managed within the next six months. We are planning to do a debug on that. Going through all the videos and classes, it seems like Managed makes more sense for us and would be more helpful than AppMon.

If I had just one solution which could provide real answers, not just data, the immediate benefit for my team would be escape being pulled into a call and spending most of the time in analysis finding the root cause. If we are able to find the root cause and fix it immediately, that downtime would be less. That is the biggest benefit.

Most important criteria when selecting a vendor: customer support. That is most important, because companies do not have the tool knowledge initially, and someone needs support it or they need to hire someone. For companies like us, initially we onboard someone who has much more experience with the application inside the company, because we need some training on the customer support: when to support and what we need to do. 

The next one is writing the PoC, we have to find out whether it is satisfying all our use cases. So, if a system helps us with our issues, that would be great.

We’re using Dynatrace AppMon currently in our environment, and we’re using it for troubleshooting performance issues. We are mainly using it in the performance-testing environment, to try to reproduce a problem if we happen to see one in production, and find what the root cause is.

It's performing well, absolutely.

I’m not sure about the entire organization, but for my quality assurance, the mean time to resolution or to find a problem has been reduced dramatically now. I don’t have a percentage but, we used to take a week or more to troubleshoot an issue, now it can be done very quickly, probably in a day’s time.

PureStack, I just love it. It can give visibility from the end-user perspective right through to the code level. That's the most valuable feature.

Also the UI is amazing. We really like it.

I think Dynatrace is top-notch, it's well ahead of its competitors. I don’t see any features which another vendor or other products have which Dynatrace doesn't. I think Dynatrace is in pretty good shape right now. I don’t really have any features which I’m lacking right now, so it's all good.

In terms of new features, I’m excited about AWS monitoring, that Lambda function, and log analysis. We’re not yet on the cloud, but still it's a good feature. We are actually planning to move to the cloud, and my organization is actively looking for tools which can support monitoring. This will definitely be a value-added feature.

It's not a big concern for us at this moment.

We haven't used technical support.

For deep diagnostics we were using an HPE product or, then, a Microsoft product called Diagnostics. It was difficult to use that tool and connect the dots. It was per machine base, per JVM base, and was not really giving a holistic picture. But Dynatrace is doing that all for us. And PurePath, again, I just love that. That was missing.

I think one of the vendors helped us. We didn’t have any hands-on, but I think we did some Dynatrace University, we’ve been through some videos. And the vendor gave us some training, so we’re fine with that.

I’m a big advocate of AI. It seems that AI can join the dots sometimes for us, and that is helpful. Instead of spending the time to think and connect all the dots, AI can do that for us in the future, and can come up with a solution also. That will be nice.

In my previous company I did use siloed monitoring tools. We used HPE BSM, Business Service Management. There were two piece to that. One was infrastructure monitoring, host monitoring such as CPU, memory, using SiteScope. The other was end-user monitoring, synthetic user monitoring. Also, there was a piece called Diagnostics. The challenge was, although the two pieces, synthetic monitoring and the host monitoring, both were agentless, it didn’t give us the real root cause of issues. Diagnostics did but you had to go and install it, and it didn’t perform very well in production.

In terms of one tool, right now I’m seeing Dynatrace can do a lot of things: the entire DevOps, infrastructure, application performance monitoring, all that can be done using just one tool. Now they just released a new feature for log monitoring. I’m really excited to learn about that. If everything can be packaged in one, that would be nice. You wouldn't have to worry about different vendors and patches. And especially, they have a SaaS model. I’m a big advocate of SaaS. My company is not right there but eventually, I hope, when it gets there, I think you’ll see big use of it, and ease of use.

I think from the organization's perspective, probably the most important criteria when selecting a vendor would be the cost, and the tool, obviously. The tool is very important: quality of the tool, reliability, scalability, all those factors weigh in.

My advice would be, from the tool perspective, to look at this tool and its features: ease of use, scalability, and stability-wise this tool stands out. I understand organizations have a pricing factor, a cost factor. That is something you have to decide on. If you want a low-cost tool, there are different tools in the market, or do you want to settle with the best tool in the market but you'll spend a lot more money. Do your research, work with your peers, your leadership, understand which way they want to go. But definitely, as an engineer, I will always say you should go Dynatrace.

Our requirement is to monitor and manage application performance. Our primary solution is AppMon for application monitoring.

The performance comes with a little bit of overhead, but we are designing the solution that way. If my application allows to be within that overhead, we are using it.

I think one of the interesting parts is they are going to deliver, in the new release, artificial intelligence, which is like analytics that will improve the correlation technology: What is causing the problem? So that will help us to drill down the actual problem, more quickly, rather than analyzing from another tool's perspective.

For us is it is the PurePath technology which is helping us to drill down to what the root cause of the problem is. That helps us to escape the war room.

I would like to see machine learning, which will give it even more of an advantage. And the self-healing, which is there, I would like to see it even smarter, to get it to quick healing, itself.

Stability is very good. Initially, when some of the problems happen, say  application issues come up, if you haven't properly designed, then it's really breaking. But now it is quite mature to handle those things, so it is quite stable for us.

Because we are now we are moving out of AppMon to the Dynatrace tool, probably in the future the scalability will be really helping us.

We use the Dynatrace University, plus some of the guidance solutions. Generally these guys are quite experienced and they help us to understand properly. They cannot help our environment - we help them to understand our infrastructure. It's like handshaking with each other. It's good.

We used a lot of different solutions. Those other solutions didn't have the ability to focus on a problem. What we had was application performance monitoring and not measuring as well. They were mostly infrastructure monitoring, but we really needed some sort of DevOps tool, which would help us to really know where our problem is.

I was the architect, I designed from the very start. In terms of the setup, initially there was a little bit of a learning curve, but now, because the tool has been simplified, I think this learning curve is gone.

When you adapt a new tool, obviously the people and culture need to adopt it, so it will definitely be a challenge. We found it was quite challenging in terms of the learning curve. But now, after two or three years, it is quite mature.

I think we had quite a lot of different vendors, but the reason we went with Dynatrace was because they were number one in industry reviews, and there were a lot of features we really needed that were already in place.

The role of AI, when it comes to IT's ability to scale in the cloud and manage performance comes in when the complexity increases, because your stacks are high, so human intervention would be really difficult. That's the reason we need AI power. Dynatrace has that capability and we want to use it. So looking to the future, AI and analysis will help us.

We have used siloed monitoring tools in the past. The biggest challenge is that we don't actually have one view. Let's say a new application is launched or different tools, they have a particular focus for a particular problem solution. But when you don't have a major overview, one view, it is very difficult to find the solution. So Dynatrace helps in that we can easily get one view, correlate, and everything will be one single pane.

If we had just one solution that could provide real answers, and not just data, the way DevOps is going on, we would probably want to adopt that solution. It would really help us regarding the cultural change of DevOps; the tool would help bring us to that level.

Our most important criteria when selecting a vendor are, first, do they meet our requirements. Second, whether they have the right support for us, when we have a problem can they immediately eliminate it for us. They need to understand us and to have the skill set to remediate those things.

I would rate it a nine out of 10. There have been some improvement announcements, but overall they are doing a great job.

I would recommend Dynatrace to colleagues.

The primary use case is application monitoring. We are using APM to test for performance, bugs, and hoping to resolve the issues faster, and hoping to catch them before we go to production.

It's been great, it has helped us a lot. It can do more, but it's definitely helped us a lot and I'm a big believer in Dynatrace products.

First of all it's mitigating issues before they are in production, and if they do go into production, it's reducing the time to find the issue and actually resolve it. I believe, in the organization that we're in right now, that is challenged for resources and time, a product like Dynatrace helps immensely.

The PurePaths, because that's where somebody who is a non-developer can figure out where the problem is and send appropriate PurePaths, clean charts, or even the link to the developer. The developer can then look at it and figure out exactly where the problem is, this is the piece of code that took the longest time, and then resolve it.

Right now, since I'm primarily an AppMon user, so maybe the Dynatrace product addresses this: The challenge with AppMon is, what if you don't have an AppMon agent on a host, but it talks to the database. It talks to it, but I don't have either a host agent or an AppMon agent on it. That has been a challenge, but I believe the Dynatrace agent, the OneAgent, will solve that, potentially. You ask me three months from now, after we take a crack at the Dynatrace product, maybe my answer will be different, but I'm hoping that addresses some of the issues.

The configuration of the alerts, that's been a challenge in AppMon for me, right now. Some of the alerts are too noisy, but that might be my lack of some configuration. Again, it's just me primarily handling it, so that could be an issue. Somebody asked a question in one of the sessions, here at the Perform 2018 conference, about noise and how many alerts to your problem count, and the person doing the session answered right away saying, "I checked my dashboard before I came to this session and I had one alert on it." So I'm guessing that will resolve itself.

I think I like the direction it's going in, the only challenging part for me is to keep up with the name changes. But other than that, as far as stability, I think I'm happy with it.

I think for the deployments we have right now, it has not been a challenge. My goal is to increase the usage throughout the organization, maybe that's where I'll face some challenges, but at this point there are no challenges.

I have used technical support in the past and they are pretty quick to respond. The other thing is, the APM community is available, Andy answers pretty much any question I post pretty quickly, so I think that group community help is really good.

I have use siloed monitoring tools in the past. When I started at Nemours 17 years ago, I had custom scripts that I would use to apply to various servers. They were on the host level, but the deployment was challenging. How to tie in a CPU alert to application slowness is challenging, because you had to go to the timestamp, look at the log and say, "Okay, this might be the issue." Dynatrace tells you how it is, and I think that's the most important feature.

I'm the primary Dynatrace admin, if you want to call me that, and it was pretty easy. But keep in mind, my skill sets are probably unique in the sense that I understand applications well, so I know how to insert the agent - because we use AppMon - how we insert agent into JVM.

But I believe the new Dynatrace product is probably the way to go, because you don't need to actually talk to the application folks, you just deploy it on the host and you're done. I believe it's definitely going in the right direction. It is complex, it wasn't for me, but I can imagine it being complex for some people.

I don't know if there were any other vendors on my list because we've been users for about 15 years. We started out with a Vantage product that moved to server monitoring, and then we had the Gomez platform, and then you also had Dynatrace, but then they all came under the same umbrella. So we never really evaluated any other vendor. We had some of the free tools we used to use, like  Profiler, but from what I've heard from developers, nothing ever came close to this so I'm a fan.

If we had just one solution that could provide real answers, as opposed to just data, we could spend less time on troubleshooting and trying to figure out what the problem is, and actually do our jobs, which is to design, build, and develop software.

The criteria we look for when adopting an APM solution are ease of use, and does it truly get you down to the problem area - and I believe that Dynatrace does - and the third one, it's true for everyone, is the cost.

I would rate it a nine out of 10. I'm not giving it a 10 yet because I would like to see the Dynatrace product in action and truly want to understand it. If we move to Dynatrace, away from AppMon, are we missing out on something?

My advice would be go with Dynatrace.

I mostly just onboard different applications in the company under the Dynatrace platform. Occasionally, they will have issues, then I use AppMon in order to tell them what the issue is. It usually is something simple: The URL, this particular service is slow, or your database is not responding correctly. 

It is performing well.

It is different for me than other users. I like the PurePaths dashlet the most. This is mostly because (and I can count a handful at times where this has not been this scenario) as soon I open the PurePaths dashlet and sort by response time, there is the problem. Every time.

If the PurePaths dashlet pulls up 750,000 PurePaths, I really only needed to know about seven or eight of them. Then, being able to look into the code-level dive about it, that is just a sanity check. Just to make sure that it is the same issue multiple times, not a random anomaly where everything else was crap.

Also Errors dashlet, I use that a ton.

I would love to see a better data export, because AppMon's charting capabilities leaves a lot to be desired. The dashboarding capabilities leaves a lot to be desired. There are a lot of times, for example, at my last company, they wanted Dynatrace data in addition to a bunch of other stuff dumped into one place. It was not just performance metrics. The CEO wanted his business metrics in the same place as the performance metrics along with a lot of other stuff. However, Dynatrace could not export this type of stuff. 

You have about a 5,000 line limit or you have to set up your CSV file just exactly. DC RUM can do it. It might take like an hour sometimes, but DC RUM can do it. I would really like to see the ability to export, in Dynatrace and AppMon, in essentially in a nice format of whatever you want to whatever else. That would be fantastic.

For AppMon, there is always room for improvement: charting, dashboarding, and user management. However, that is pretty much our fault with LDAP. The onboard process itself is a pain, even though we have scripted so much it, it is just very repetitive. There is a lot of alerts and things like that out-of-the-box that do not need to be there or that just do not do the right things.

For Dynatrace, I feel like it just needs a lot more technology support. I know they are trying to essentially get rid of AppMon and move toward the Dynatrace way of doing things. However, we are a multibillion dollar bank. We are not up-to-date. We are not going to be microservices for a long time. We are not going to be container for a long time, and we are probably one the most expensive clients that they have.

We are the ones who are going to drive a lot of the money factor so they need to have that. They need to have integration between the current set of tools so we have the ability to onboard five or six apps, then we'll also put the AppMon agent on it and show people the difference between it. It needs to be better integrated.

All of our team will go to a five minute sales meeting, if they were like, "Look, you can do this with a script." We are sold.

We do not want to do any of the regular AppMon stuff. However, when you have to convince the CTO that we are going to completely rip out the entire monitoring solution which we just spent the last 15 years trying to get a process set up for, and now we are going to redo it. That is not going to go over well. That is not a good conversation. 

You need to have that ability to do MQ. I don't care who uses MQ, but apparently we do. If you can't look into those messages, then you just lost a half of our organization which can't be monitored with it.

With stability, I have never run into issues with Dynatrace causing an issue yet. 

I have run into AppMon causing issues. There have been a lot times when I have waited for a release. AppMon does the release, then it ends up taking down our application. Now, the fix is immediate, but I have already loss face. 

The last time, I took down the main application that lets you call tow trucks. It was just a monitoring loop, a simple thing. They fixed it in a patch. They knew about the issue and they told me immediately what the issue was. I got it fixed in 15 minutes. It took me six months to convince the team to install it in the first place and took me another seven for them to give me another shot at it. It was not a problem that showed up in QA, for whatever reason. So, I could not convince them that it does not exist anymore, because I could not show them any evidence that it existed in the first place. Let alone that I fixed it.

I have never been more confident in a tool because I've seen how easy it is for it to deal with the .NET Applets. That is a big problem in AppMon. Unless every single person is naming their Applets, the exact same way and following the exact same pattern, it becomes an issue. The new tool does not run into that at all. Similarly, you can script it so it just automatically blasts across the organization. As long as it has the PurePath capabilities, somebody who is running, for example, the actual web application that tells people their accounts, that might be a different, more in-depth use case for AppMon versus Dynatrace. So far, the scalability of the solution is phenomenal. 

Anytime I can't find the answer immediately in docs or answers, I just open a ticket. They are very good about giving you a response. 

Initially, I am talking about two or three years ago, I think they did not have enough personnel staffed there. Therefore, it would take them maybe two or three days to get to your ticket. Now, it is maybe the next day you will have a pretty reasonable answer and that is provided you did exactly what it says in the support ticket. For example, make sure you upload your support archive. Otherwise, you will burn a day and they will send you an email requesting you just upload this. That is shooting yourself in the foot, and that is not their fault. 

I have previously used siloed monitoring tools. I have used SiteScope. My current company uses ITCAM. They are okay. They get the job done.

At my previous employment, we used SiteScope and that was quite literally the way that I thought about it in day-to-day life, if you do not really give a crap about it, just put SiteScope on it. However, if you actually need to know if it is working, it needs to have Dynatrace.

I was always pushing for that sort of thing. There is stuff like Wiley where you are not getting 100% monitoring. There is another tool, one is a very new company, and it seemed to get the job done but that was only because we were using Citrix Xenapp. It was specifically able to decode the traffic for Xenapp and XenDesktop, which was what we were looking at. Apart from that, I have never had a situation where I was like, maybe we should not put Dynatrace on this. I have never run into that. 

I was not involved in the initial setup at my current company, but I was at a previous company.

For upgrading at my current company, that is in process. We are trying to figure out if it is better to blast it across the organization. We have five Dynatrace servers. They are all completely at capacity. They are all set at large. It is a really big deal for us to try to switch anything over. Right now, we are trying to figure out, do we just upgrade our collectors and hope for the best, or do we do it in QA and then in production? 

A lot of people do not run the right thing in QA. It is never the case that their QA is identical to production. So, is that a good indication? I have run into issues before when upgrading from 5.6 to 6.1 expecting that all the bugs were ironed out. That is when I took down that application. Now, I do not have confidence in this upgrade process.

For the Dynatrace Managed version, that setup process was incredibly easy. It took 15 minutes. 

Just go with Dynatrace. Just start with Dynatrace. Do not go into AppMon. Start with Dynatrace, because AppMon is going to give you so much extra stuff that 99% of your user base will not need it, including yourself.

You don't need AppMon. I am a hardcore AppMon guy and I am still saying this. It is a lot nicer to be able to start with the Dynatrace solution, be able to script everything, and start integrating the new thing than it is to try to do the old tool set. 

I started in the PDP program at Dynatrace. That was when they were still Compuware. Then they became Dynatrace, and I went to a different company, now I am at PNC. I have done the exact same thing for several years in different places.

In my current and previous positions, AI is not important when it comes to IT's ability to scale in the cloud and manage performance problems.

The previous company bought it, and they did not even set it up. I onboarded a bunch of apps. So, they were way too fledgling to try to start looking into it. 

What I would use AI for is if it could assist me in saying, "These are your common PurePath patterns." A lot of times in the ending part of an URL, they will have /apps, /data/, then they will put something lie the date or some big custom code. For example, we had one application for tow trucks, which would tell them the URL contained in PurePath, for the actual seven decimal place of the geographic coordinates of that tow truck.

This is not a good way to look at data. If the AI could tell me something about it, just mask it out, or just know this is the same type of data as these other ones and not worry about the extra text part of the piece. That would be the foremost use case for me. After that, I am not sure. 

I would need to use it a lot more to maintain my own trust factor in it before I would want to try to tell somebody that is asking me what the problem is. Just immediately saying AI says this. I do not have a high confidence enough factor in it, because I have never really used it.

If my organization had just one solution that could provide real answers, not just data, it would probably put me out of a job. Most of the time, when I get a ticket, they will ask me what the problem is. I will point out the problem, and it is something which is you need to code this better or you messed up these settings. Therefore, as far as helping me not have those mundane sort of tickets where I don't really want to waste my time with people. It is fine for the first few, but after the thirtieth or fortieth person, you tell them that you wrote this very poorly. It is better to just have some tool tell them that this is probably not the best way to do this.

That would be the initial benefit of the one solution. A part from that though, all I am doing is onboarding. The new Dynatrace already takes care of this. So, I am not really sure what my role would be afterwards. Right now, the APM is siloed off from the development teams. If you are going the full Dynatrace route with AI and getting the opportunity of the AIs already going to tell them what the issue is. Then, the APM team does not really need to exist anymore, apart from doing migrations.

Most important criteria when working with a vendor: That initial pairing of sales versus FTS. If I could reach out to them and get answers within a day, or better yet, within an hour. That is one of the best things because a lot of times that initial conversation can get derailed so quickly. You are not going to get more than five or ten minutes to pitch it to your boss. They are always at meetings. For example, my boss, at my previous place, I would be able to sit with him and talk to him about this thing. Then he would get, maybe, five minutes a week of his bosses level. That is the person who is going to sign the paycheck. 

Therefore, when he goes to a meeting, and it is a week later, he gives the spiel and has it all ironed out. Then, his boss asks him, "What about this?" Now, he does not know the answer, and I can't get the answer, then I need to get somebody on the phone stat to give him an answer. Otherwise, we have to wait another week. That is a big deal for us to have that communication open.