This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

APM 4.0 Wish List

APM has come a very long way in a relatively short period of time. Does anyone else here remember the original Application Monitor? I rest my case. APM remains my most vital add-on component for NPM, and I don't know I ever lived without it. 

However, like all good things there's always room for improvement. Below is my list of what I believe would further enhance/refine the product; and quite possible redefine the future of APM.

This list is by no means comprehensive, so I encourage others to expand on the ideas outlined in this post.

 

More Monitors

Each new release of APM includes some number of new monitors. These are always welcome additions. Keep them coming guys! Here’s a short list of monitors that are currently absent in order of my own preference/priority.

FTPS & SFTP User Experience
NTP, SNTP, TIME Protocol User Experience
WINS (Windows Internet Name Service) User Experience
TFTP User Experience
RTSP (Real Time Streaming Protocol) User Experience 

 

Fix/Enhance Existing Monitors

The DHCP monitor supplied in APM 3.1 currently only works provided your NPM server resides on the same subnet as your DHCP server. While I'm sure this isn't a problem for some customers, others are unable to utilize this important monitor. I've made some suggestions in a previous thread how the monitor could be enhanced to work universally for all customers, regardless of configuration. At present, the existing DHCP monitor is a potential hazard to customers and at the very minimum should be addresses in a future release.

A welcome enhancement to the WMI, SNMP, and RPC Performance Counters would be the ability to convert incremental counters into rates. I've had several instances where performance metrics are presented as ever increasing counters. Because of this, I'm unable to trend this information over time because the counters simply climb indefinitely until the server reboots, resetting these counters to zero again. The idea of transforms, like exist for Universal Device Pollers, has been suggested and maybe there's some overlap here.

 

Power to the Geek
Following on the theme of NPM 10.0, I’d love to see a “Poll Now” button added to both the Application Details page for whole template polling, and the Component Details page for individual monitor polling. This would certainly help the engineer who’s troubleshooting application problems in the field to know sooner whether he’s resolved the problem.  On a similar note, additional information on the APM Component Details page that displays when the last polling took place would also be convenient.
 
Ease of Use Enhancements
Anyone who’s used APM for a great many hours like I have will appreciate subtle changes to how additions and deletions of monitors are made to templates. Little things like alternating row colors, mimicking green bar paperwould reduce eye fatigue and eliminate the need to hold a ruler to the screen when making monitor deletions from a template.
Working with very large templates can be a cumbersome process, sometimes referred to as an exercise in frustration and futility. I encourage whoever is responsible for UI decisions to consider working with APM templates of varying sizes before determining the final layout and design.  What makes logical sense for a template comprised of only five monitors, does not necessarily work for a template of 100 monitors or more.  Some very small changes could go a long way to making this process much less tedious. 
One such example would be the ability to delete multiple monitors from a template in one action. Perhaps a simple checkbox style multi-delete would suffice. Regardless of the how it’s implemented, I can speak from personal experience when I worked with an extremely large template that contained over 100 monitors that needed roughly 50% of them removed. It was a process that took a total of two hours to complete. Deleting each monitor individually and waiting for the whole page to refresh was enough to drive a man insane.
Moving the “Add Component Monitor” button to the top of the monitor list, instead of the bottom would be another small tweak that would make life a little easier.  In fact, adding monitors to a template in reverse order, I.E. “bottom up” would simply be a fantastic and refreshing UI choice. It makes little sense to scroll down to the bottom of the page to click the “Add Component Monitor” button, only to have the entire page refresh, to scroll down again to configure the new monitor. The UI elements that are actively being configured by the user, such as the case when the user adds a new monitor to a template, should be the focus of the page. Appending it to the bottom of the page, completely out of view of the user, and forcing them to scroll down to find it is most likely not the best usability design.
Templates are quite possibly the single best original idea ever to be implemented in APM. Especially how component monitors can be added/removed from Application Monitors without disassociating it from the original template is shear genius! One idea to improve upon its greatness would be to implement some function or ability to re-inherit from the original template. In an instance where someone gets a little heavy handed with the delete button on an Application Monitor for example, you can always re-add the monitor, but it will never again be associated with the original template.  This would also helpful should you want to revert back to managing your component monitor modifications at the template level without losing historical statistics.
Adding component monitor individually is a tedious task. Thankfully the need to manually create templates has been significantly in recent versions of APM. The new wizard driven template creation process is an absolute pleasure to use. However the need to manually create templates will always exist for one reason or another. It would be great if the process could be streamlined and simplified to make this task less painful.
I’ve noticed that you can add several monitors at once by selecting multiple checkboxes, but this only works if you select different monitor types. For instance, you can select one WMI Monitor and one SNMP Monitor and both monitors will be added to the template at once. But what if you just needed 10 File Size Monitors? You’d have to add each one individually. It would be a nice to be able to add more than one of the same type monitor in a single action.  Barring this possibility, if we could eliminate the screen refreshes when adding a monitor that might improve performance enough to make adding modules individually a bearable process.  Again I’m reminded of the pain involved when working with particularly large templates.
 
A Radical New Beginning
With NTA reaching product maturity, it might be worth considering the integration of NetFlow information into the APM dashboard. While these two products should continue to be separate, customers who own both APM and NTA should be able to derive additional value from owning both. Dynamic Netflow charts based upon user experience and TCP port monitors within the Application Details page would represent a terrific “tie-in” between these two great products. In the case of troubleshooting, this integration could also provide vital insight into the crucial next question. Why is this application performing so poorly?
To further expand upon the question of “Why is this application performing so poorly?” I believe APM needs to “Go Deep” to get to the root cause of the problem. As the Wireshark reference suggests, the answers are in the packets themselves.
By capturing, measuring, and monitoring specific filtered traffic generated from APM user experience monitors we can begin to paint a picture of the network as a whole. From the client, in this case the APM server, through the network to the destination server, all the way to the application itself. With that information we can begin to break down the network communication, identify latency sources, and isolate the root cause of the poor application performance.  Whether that be the network congestion, high server load, or poorly written application code.
It’s a brave new world out there and I’m excited about the future of APM! 

  • sounds right...

    I just created a template with 20WMI monitors, it was a pain to add each one individually so I saved the template to the computer and pasted the same component monitor in 20times, much faster than adding each one in individually but still a pain

  • Howdy All--


    I've marked this for the PM to review.

    M

  • Thank you for the thoughtful, detailed feedback. I am entering your UI pain points into our bug tracking system. We're working to make the user experience better with each release.

  • aLTeReGo, first of all, thanks for spending the time to write all this feedback up in such a well thought out and detailed post!   This is great information to have from a long time user of APM (and old AM module).   Your contributions really helped shape the direction of the product thus far, so we're hoping you think of it as a proud papa ;-)

    I'd like to schedule a call to go over all this feedback, but I'll leave you with some one liners so that community is in the loop with our thoughts in these areas.



    More Monitors

    Each new release of APM includes some number of new monitors. These are always welcome additions. Keep them coming guys! Here’s a short list of monitors that are currently absent in order of my own preference/priority.

    FTPS & SFTP User Experience
    NTP, SNTP, TIME Protocol User Experience
    WINS (Windows Internet Name Service) User Experience
    TFTP User Experience
    RTSP (Real Time Streaming Protocol) User Experience 



    I'll definitely add these to list.   As you know, more demand will help make these happen faster so others please chime with your top 5 as well.



    Fix/Enhance Existing Monitors

    The DHCP monitor supplied in APM 3.1 currently only works provided your NPM server resides on the same subnet as your DHCP server. While I'm sure this isn't a problem for some customers, others are unable to utilize this important monitor. I've made some suggestions in a previous thread how the monitor could be enhanced to work universally for all customers, regardless of configuration. At present, the existing DHCP monitor is a potential hazard to customers and at the very minimum should be addresses in a future release.

    A welcome enhancement to the WMI, SNMP, and RPC Performance Counters would be the ability to convert incremental counters into rates. I've had several instances where performance metrics are presented as ever increasing counters. Because of this, I'm unable to trend this information over time because the counters simply climb indefinitely until the server reboots, resetting these counters to zero again. The idea of transforms, like exist for Universal Device Pollers, has been suggested and maybe there's some overlap here.



    I'll make sure we look into both of these.   We'll need to get more details on the call.



    Power to the Geek
    Following on the theme of NPM 10.0, I’d love to see a “Poll Now” button added to both the Application Details page for whole template polling, and the Component Details page for individual monitor polling. This would certainly help the engineer who’s troubleshooting application problems in the field to know sooner whether he’s resolved the problem.  On a similar note, additional information on the APM Component Details page that displays when the last polling took place would also be convenient.



    Great idea!   For internal folks, this is being tracked as FB#4808



    Ease of Use Enhancements
    Anyone who’s used APM for a great many hours like I have will appreciate subtle changes to how additions and deletions of monitors are made to templates. Little things like alternating row colors, mimicking green bar paperwould reduce eye fatigue and eliminate the need to hold a ruler to the screen when making monitor deletions from a template.
    Working with very large templates can be a cumbersome process, sometimes referred to as an exercise in frustration and futility. I encourage whoever is responsible for UI decisions to consider working with APM templates of varying sizes before determining the final layout and design.  What makes logical sense for a template comprised of only five monitors, does not necessarily work for a template of 100 monitors or more.  Some very small changes could go a long way to making this process much less tedious. 
    One such example would be the ability to delete multiple monitors from a template in one action. Perhaps a simple checkbox style multi-delete would suffice. Regardless of the how it’s implemented, I can speak from personal experience when I worked with an extremely large template that contained over 100 monitors that needed roughly 50% of them removed. It was a process that took a total of two hours to complete. Deleting each monitor individually and waiting for the whole page to refresh was enough to drive a man insane.
    Moving the “Add Component Monitor” button to the top of the monitor list, instead of the bottom would be another small tweak that would make life a little easier.  In fact, adding monitors to a template in reverse order, I.E. “bottom up” would simply be a fantastic and refreshing UI choice. It makes little sense to scroll down to the bottom of the page to click the “Add Component Monitor” button, only to have the entire page refresh, to scroll down again to configure the new monitor. The UI elements that are actively being configured by the user, such as the case when the user adds a new monitor to a template, should be the focus of the page. Appending it to the bottom of the page, completely out of view of the user, and forcing them to scroll down to find it is most likely not the best usability design.
    Templates are quite possibly the single best original idea ever to be implemented in APM. Especially how component monitors can be added/removed from Application Monitors without disassociating it from the original template is shear genius! One idea to improve upon its greatness would be to implement some function or ability to re-inherit from the original template. In an instance where someone gets a little heavy handed with the delete button on an Application Monitor for example, you can always re-add the monitor, but it will never again be associated with the original template.  This would also helpful should you want to revert back to managing your component monitor modifications at the template level without losing historical statistics.
    Adding component monitor individually is a tedious task. Thankfully the need to manually create templates has been significantly in recent versions of APM. The new wizard driven template creation process is an absolute pleasure to use. However the need to manually create templates will always exist for one reason or another. It would be great if the process could be streamlined and simplified to make this task less painful.
    I’ve noticed that you can add several monitors at once by selecting multiple checkboxes, but this only works if you select different monitor types. For instance, you can select one WMI Monitor and one SNMP Monitor and both monitors will be added to the template at once. But what if you just needed 10 File Size Monitors? You’d have to add each one individually. It would be a nice to be able to add more than one of the same type monitor in a single action.  Barring this possibility, if we could eliminate the screen refreshes when adding a monitor that might improve performance enough to make adding modules individually a bearable process.  Again I’m reminded of the pain involved when working with particularly large templates.



    I've heard this from some other folks as well.   I'd like to drill into this in more detail on the call.



    A Radical New Beginning
    With NTA reaching product maturity, it might be worth considering the integration of NetFlow information into the APM dashboard. While these two products should continue to be separate, customers who own both APM and NTA should be able to derive additional value from owning both. Dynamic Netflow charts based upon user experience and TCP port monitors within the Application Details page would represent a terrific “tie-in” between these two great products. In the case of troubleshooting, this integration could also provide vital insight into the crucial next question. Why is this application performing so poorly?
    To further expand upon the question of “Why is this application performing so poorly?” I believe APM needs to “Go Deep” to get to the root cause of the problem. As the Wireshark reference suggests, the answers are in the packets themselves.
    By capturing, measuring, and monitoring specific filtered traffic generated from APM user experience monitors we can begin to paint a picture of the network as a whole.  From the client, in this case the APM server, through the network to the destination server, all the way to the application itself. With that information we can begin to break down the network communication, identify latency sources, and isolate the root cause of the poor application performance.  Whether that be the network congestion, high server load, or poorly written application code.
    It’s a brave new world out there and I’m excited about the future of APM! 



    I like the way you're thinking.  We've actually been considering some things along this line.  For example, the ability to show traffic analysis data (e.g. Top Conversations) from a server perspective versus (i.e. in/out of this server) from a NetFlow Source perspective. I'd definitely like to dig into your ideas on our call.

  • Top 5 of new monitors?

    Well, I know User Experience monitors are generally something that people like to hear.

    I guess User Experience monitors for the Top5 most used applications would be it for us then... (I guess it is not possible for every application though)

    Our top5 used applications would be:

    1.) Remote Desktop

    2.) Email/Exchange

    3.) DFS (I think thats already integrated with Download Speed Monitor?)

    4.) Printing (that one I dont think can have a real User Experience Monitor)

    5.) VoIP (which is already integrated with IP SLA Manager)

  • How about Weblogic? 

    JVM

    • JVM Free Memory
    • JVM Total Memory

    JMS

    • JMS Destination Availability
    • Messages Current

    JDBC

    • JDBC Pool Availability
    • Total Connections
    • Active Connections
    • Max Connections
    • Waiting For Connection Current Count
    • Failures to Reconnect
    • Failures to Reconnect per Minute

    Thanks,

    MC

  • and WebSphere - actually it would be nice if APM could support monitoring through JMX. I realize there is a knowledge base article on this (http://knowledgebase.solarwinds.com/kb/questions/1920/Monitoring+Java+Virtual+Machine+(JVM)+in+Orion+APM+Using+SNMP).

    When 60% of our applications are custom built Java apps running in Websphere, it would be nice to have more insight into those.

    I would also really like the ability to have the http/https user experience monitors be able to login, navigate to serveral locations within a site (multiple pages) and then logout (end-to-end) user monitor.

  • Supporting JMX and better out-of-the-box monitoring for Java based apps is definitely something we'd like to implement in a future release.  I'd like to hear more detail on your specific requirements, and will definitely reach out at some point in the near future.

    -Craig

  • I reply to this post with my specific APM java monitoring wishes, but I need to get them all written out and ensure they make since first.

  • MC_Tools,



    How about Weblogic? 

     

    JVM

     

    • JVM Free Memory
    • JVM Total Memory

     

    JMS

     

    • JMS Destination Availability
    • Messages Current

     

    JDBC

     

    • JDBC Pool Availability
    • Total Connections
    • Active Connections
    • Max Connections
    • Waiting For Connection Current Count
    • Failures to Reconnect
    • Failures to Reconnect per Minute

     

     

    Thanks,

    MC



     

    JMX Monitoring was recently added as part of the APM 4.2 release.