Keywords: Technology, Software, Diagnostics, Measurement, ITIL, System Management, HP, Mercury
It can be confusing.
Mercury (HP) offers several different "solutions" for use at various stages along its
Application Performance Lifecycle 
- Mercury's AD (Application Delivery) solution features functional GUI testing tools and LoadRunner to simulate load on test servers. It monitors servers under test using primarily external remote commands.
- Mercury's AM (Application Monitoring) solution
monitor servers under test using primarily internal probes running within servers.
It has the Business Process Monitor module to send out individual "synthetic" requests to evaluate response time (not create load) on servers in production use.
Radio buttons in the probe installation dialog
suggest that "Unified Probes" are "unified" in that a single installer installs them.
Mercury's documentation notes that AD and AM modes "are mutually exclusive" in that the probes
must be specifically re-configured 
to switch their use by only one environments along Mercury's "Lifecycle Solution" approach.
However, (through the miracle of modern science) to enable several products to use a probe at once,
"Enterprise" can be manually specified in the
ProbeID= property within probe.properties file
to override values updated by the installer:
- "AD" for Application Delivery mode using LoadRunner without Deep Diagnostics.
- "AM" for Application Management mode during "Production/Staging" without Deep Diagnostics.
- "AD,DeepDiagnostics" if a probe is to work with both LoadRunner and Deep Diagnostics.
- "AM,DeepDiagnostics" if a probe is to work with both BAC and Deep Diagnostics.
- "PRO" for Profiler only
- "Enterprise" for everything.
As the checkbox in the probe installer suggests, Deep Diagnostics can optionally be used by
Mercury's Suite of Diagnostics software
to provide selective, low-overhead, automated byte-code instrumentation without changes to source code.
It works like a telescope — examining servers at the various layers during
short burts of intense load.
unlike profilers 
which view only a single process,
Deep Diagnostics provides profile information under load
across multiple tiers of the system with low overhead.
- Unlike rstat.d daemons running within the UNIX operating system,
- Mercury's J2EE/.NET Diagnostics software need probes (the "systemmetrics" daemon) installed
- inside J2EE/.NET application servers, which must be started using JVM parameters
- the JRE Instrumenter identifies among the JVMs it finds.
- JVM Metrics
(which include Method invocation counts and transaction timings
collected from J2EE and .NET application probes
along with JVM heap size) are
- displayed by the "Mercury Diagnostics Profiler for J2EE"
that collects
like a microsope, examining the flow of individual transactions
as a free (as in beer) "technology preview" of
- LoadRunner (Performance Center) enabled with the
the Diagnostics Add-in for J2EE/.NET
and
- Transaction Breakdown Diagnostics Module
to analyze and graph metrics
from probes
- collected by a Mediator Diagnostic Server that (like an SNMP sink) collects probe data and sends
- filtered and aggregated metrics
to a
- Commander Diagnostic Server that maintains method call chains (call trees) at each resource layer by breaking down transaction data. The Commander also feeds data "samples" (values at a particular point in time) to the
- Business Logic Engine (BLE "Trinity") service of the
- Business Availability Center (BAC) product's processing server, which stores data into the Configuration Management Data Base (CMDB) based on Business Rules and status Objectives.
- Its "Dashboard" presents (over time) raw data organized as Key Process Indicators (KPIs) associated with end-user business processes and other configuration items (CIs).
- The BAC can dynamically configure diagnostics servers and use Analytics to display metrics and
- "agent-less" measurement data
that
- Mercury's SiteScope product
- collects from servers externally using OS commands through SSH (Secure Shell) connections.
- Sitescope's metrics are also available for use by LoadRunner and
- the Mercury Tuning Console
product which tracks the impact of server configuration changes on
metrics
- During load testing, the LoadRunner Controller collects data from rstat.d counters and controls
- load generators which
- emulate clients making requests intended to place load on servers.
- During production, the Business Process Manager (BPM) issues "synthetic"
- Vuser Business Process (BP) playback requests to obtain timings from the client point of view (not to generate load).
- Actual user activities are captured by the Real User Monitor (RUM)
- On a Mercury Deep Diagnostics for J2EE
(DD) Server
the Deep Diagnostics "Data Collector"
collects metrics
from probes and is controlled by the - Deep Diagnostic Console
- via "Agents" installed on servers participating in Deep Diagnostics.
Here is a concise and yet comprehensive free tutorial of the various products that Mercury (now a division of HP) sells to monitor computer systems. The quotes, ideas, tips, and tricks here are culled from manuals and lessons learned through experience earned during customization and testing work.
For Performance and Capacity Management Engineers:
| Your first name: Your family name: Your location (city, country): Your Email address: |
Top of Page 
| |||
