Data Collection
For monitoring solutions, they can only solve problems they can see. Are they collecting end user clicks? If not, then they cannot determine the impact to end users. Seems simple enough, but you should have an in depth conversation on the mechanism that they collect those statistics.Some tips on collection
1. If they do not have a library or agent somehow injected into the running process, they will not get root cause on the call stack. Examples:
![]() |
PurePath view from Dynatrace Application Monitoring |
- sync issues
- CPU consumption hogs
- exceptions
- correlating log messages to called transaction
2. If they do not have network based capture, they will not get network issue resolution. Example:
![]() |
Network heath breakdown from Dynatrace DCRUM |
- Retransmission issues
- Packet loss
- Network redirects
3. End user device capture was the biggest opportunity for business at velocity this year. The key call outs for this to be possible are:
![]() |
Visit capture screen from Dynatrace User Experience Management |
- SDK for native devices
- Ability to see non-web based transactions (think traditional thick client requirements)
- JS agents injected into browser/mobile browser*
Final Thoughts
All in all, the conference was a ton of fun. I was able to see what others in the industry are releasing into this space. I even got a demo of New Relics and AppDynamics portal:
Although a lot of organizations where touting the "root cause" messaging, I only saw some glimmers of others demonstrating a true root cause analysis. The more complex applications have become, the more powerful monitoring tools have started to pull away in this fight. I have yet to find the silver bullet for performance analysis, and probably never will, but the journey is very entertaining!
No comments:
Post a Comment