Our client would like to monitor ATM software which creates one process for each connected ATM on central server. The client will connect 200 ATMs in test environment soon but there should be about 2000 connected ATMs in production environment in the future.
Do you think Dynatrace is able to monitor it without significant performance impact on the ATM application? If yes, could you provide to me some best practices of configuration of Agent Group for this case?
Jakub, The short answer is YES this can be done. But keep in mind that this could require a bit more exploration and analysis to look at boot sequences of the injected ATMs, volume and frequency of traffic, etc. As I'm sure you know, there are limits to the number of monitored processes and a limit to the number of collectors. So it would also be worth looking at the OneAgent to determine if this would be a better fit, considering the network layout between the ATMs and the AppMon server.
Finally, there's the consideration of having multiple AppMon Servers. I would assume there's no reason all ATMs have to report to the same AppMon server, so a reasonable scaling option is to simply install multiple AppMon Servers to handle the architecture.
All this is a bit hard to do in a forum posting and is getting outside the scope of a sales cycle. It's more an enablement services activity. I suspect your limiting factor won't be the transaction volume, as I assume an ATM transaction volume is low. The more limiting factor will be the total number of Agents/collector (assuming you use collectors) and the number of collectors/AppMon Server. Also consider the problem of bulk restarts of the ATMs and that puts a hard load on the collectors. So perhaps you'll need to explore if they do rolling restarts or bulk restarts.
I know that doesn't answer your question directly, but hopefully gives you some items to consider and explore further with your client.
To make sure I understand your architecture: you have ATMs distributed out all over the place. These ATMs connect to a central server, and software on the central server will create a .NET process on the central server itself. If you have 200 ATMs out in the field, then you will have 200 .NET processes to monitor on that central server. And finally (just making sure), there will be no agent installed or any processes monitored on the ATMs themselves, right? Just on the central server. Does that capture things properly?
Assuming I have that right: Joe makes several great comments in his answer. In particular, you will need a good agent/collector/server design for the AppMon server, to stay below the connection limits. Also, I agree that transaction volume will be low in terms of what AppMon can consume, since ATMs work at the speed of human, so AppMon should not have any problem at all with the PurePath (transaction) data.As Joe mentioned, a services engagement could help you here.
However (this is why I wanted to make sure I understood your ATM app architecture): besides PurePath transaction data that's collected, there is other data (perfcounter process-level statistics such as CPU usage, GC stats, etc.) that AppMon will collect for each monitored process - by default every 10 seconds. Some additional design and testing should be considered (changing the collection interval, shutting down some or all of the statistics gathering, and so on) to minimize the impact to the central server. Doing the math, if each collection iteration created just a 0.5% CPU spike to collect and process that data, you can see what the impact would be with 2000 processes if they were all collecting data on the same cycle. Again, services can help with this design and configuration work.
I hope this helps,
Hi Joseph & Rob.
Thank you for answering my question. It is good to hear that it should be possible to monitor customer's ATM software.
Rob, you understand the architecture right. We will not install any agent on the ATMs themselves because the ATM itself is just a simple presenter and it will not be valuable for the customer.
I think that results of our tests would be interesting for others so I will share them when we will have some final statement.
It's worth noting that this post was from 2 years ago. At this time our flagship Dynatrace product would be a better fit for this use case. While AppMon would work, Dynatrace would work better. No AgentGroups to define, all automatic detection and injection of all .NET processes and more. If you're unclear on the difference between AppMon and Dynatrace, please reach out to one of our sales reps and they'd be more than happy to help explain the difference.
Hi Joseph H.
Have Dynatrace been deployed anywhere to monitor ATMs currently?
We have a client that is demanding this. The Architecture is the all the ATMs, communicate to the Front End Processor (FEP) server on a given port. FEP admins may not allow any agent on the FEP, so my questions are as follows?
1. Has agent method od Dynatrace Oneagent been deployed anywhere globally on the FEP to monitor ATMs and ATM transactions successfully?
2. Can DCRUM work and has it been deployed on FEP? and what type of transaction and/or performance metrics were derived from such deployments?