The ability to trace transactions all the way down to find where the software is broken - database, web services, etc., and all the way down, with the trace dumps, to see where our application is broken.
When our app passes critical threshold, can quickly go to Transactions and/or Database views and immediately see the code areas causing the issue. Saves so much time in debugging our code and environments.
Improvements to My Organization
I can have my developers find bugs and fix them in one-tenth of time they used to take. It enables the stability of our product, and it's allowed me to keep human resources at a minimum so that we have a smaller number of people to do better things.
Room for Improvement
In Alert History, while you can see the trending in response time by Request Queuing, .NER CLR and Database, if you had the ability to see which transaction type was the slowest during the timeframe when the critical error occurred by displaying the info within the same “tool tip” hover window which currently gives me the time per request and number of transactions, i.e., if it had the additional correlation information of “StatusCode/403” which you can get from the Events Errors hover. This has the potential of saving a lot of analysis time going back and forth between views.
We didn't have any deployment issues.
I haven’t had any issues with stability.
It’s scaled for us. We’re still relatively small with just 16 servers.
Customer Service and Technical Support
When my IT manager did the initial install, they were very responsive.
It was straightforward, but the issue was the unfamiliarity of our IT manager outside the Microsoft world.
If you want to save money, go for it. Time is money, and it saves you so much time to be able to find issues and to fix them.