Here’s the question that derails Application Performance Management projects:
“Who is going to use it?”
It’s the people, man! Dynatrace, Introscope, OpNet, Diagnostics, ExtraHop – sure there are differences among products, but the single common difference between success and failure is the person using the tool.
It’s really simple:
- If you buy tools, but don’t use them… they aren’t solving any of your problems.
- If you buy sophisticated technical tools but don’t have the prerequisite background or invest in training… they might as well be doorstops.
- If other teams use the tool but don’t share the information learned… nobody benefits (silos are bad)
Unfortunately, I’ve seen too many customers over the years make major investments in these tools – licensing, professional services, etc – and then ultimately look around and realize that after the consultants leave, there’s no one who can actually use them.
Some might say that Predictive Analytics and Automation will solve that – just put the brains in the software – but we aren’t there yet. With each new vendor into the market (New Relic, AppDynamics, for example), there is a focus on building a better mousetrap – more technology, more metrics. This is not making it any easier on Corporate IT, which is already cash-strapped and down to minimal staffing. For now, the best tool really is the one that will get used.
I was recently asked for an off-the-cuff list of best practices for implementing HP Real User Monitor. Here were my thoughts:
a) If possible, give RUM access to your help desk / tier 1 staff. That way, when an angry customer calls they have *real* data they can use to help that person.
b) Ideally, pair RUM with BPM and Diagnostics. RUM by itself is a great tool, but it really shines when you can go all the way from the end user through to the code level with HP Diagnostics.
c) Definitely use the linux probe. The windows probe can handle less throughput, is less tested, and has had more recent bugs – for example, in 9.21 there are some problems with field masking.
d) While it is possible to use either a span port or a tap, HP official supports only taps for production use.
e) Be cognizant of the traffic throughput you are intending. You may want to start with just a single application and then scale out from there as you are better able to gauge real-world conditions.
f) Running the Engine on a virtual host is fine. While it is possible to use a separate MySQL database, there’s no real advantage in it.
g) You will want to use exactly the RHEL 5 version recommended by HP for the probe. While I have successfully installed the RUM probe on Centos and on both Centos and RHEL 6 and 7, I do not recommend it as a) it is not officially supported by HP and b) the installer will get hung up on the openssl libraries
h) Make sure you have collected sufficient information about the applications you want to monitor in advance. The more you know about the urls / pages / transactions of interest, how sessions are created for your application, and any fields you want to either capture or exclude, the more relevant the information from RUM.