HP RUM Best Practices

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.