Golan Shem-Tov here with the solutions architects team at Quest.
Foglight 5.5 java cartridge brings new platform support and great new functionality. There was a lot of work done around reducing the startup time for the application servers and reducing agent overhead. A lot of the new functionality is targeted at giving users greater control over the behavior of the java agent monitoring and diagnostics capabilities and will enable users to diagnose performance problems faster than before. We are still focused on the context of the request and driven by the same guidelines that were specified in Hugh McEvoy’s blog “Why Request-Based Java Performance Management is better than the Alternative”
New product features:
1. Named method monitoring.
Many customers take advantage for the custom component definition to define a tier that is used for interacting with a 3rd party or a to see how much time is spent in logical areas of the application but what we have seen in the field is the need for monitoring specific methods on a 24X7 basis. In some cases that is due to legal requirements or SLA on specific methods and in some cases it is interacting with 3rd party system (credit check system for example) that is needed to be monitored constantly. We have added the ability to define specific methods, or group of methods to be monitored all the time.
The definition of the named methods is done in the agent_instrumentation.config (or instrumentation.config if you are working in the agent-override directory). As you see in Foglight 5.5 the commonly modified properties files are there at the root of the Java EE properties and the files that have more advanced properties that are almost never modified are under the “Advanced” folder.
Please note that you can use the named methods section to monitor a specific method(s) or for a class(es) and also use regular expressions. In this example was checking for a specific method that is used to search for patients.
NamedMethods = {
"searchpatients": MethodList(
include "com.bea.medrec.controller.PhysicianSession.searchPatients"
)
};
The information for named methods can be seen in the Java EE methods dashboard indicating the call distribution across servers, execution time and exceptional exits and how many request types have called this named method group.
2. Request based details for application tiers, technology components and object tracking.
With Foglight 5.5 we add the ability to fine tune and limit the overhead that comes with getting details for application tiers, technology components and object tracking to specific requests in the recording.config properties file.
Request Details rules section gives you the ability to define what level of detail you want to get about request(s) – Tier Breakdown, Component technology breakdown, Application Breakdown or ObjectTracking.
RequestDetailRules = {
/.*\/transfer\-.*\.jsp$/ : ("ComponentTechnologyBreakdown"),
/.*\/login\.jsp$/ : ("TierBreakdown", "ApplicationBreakdown", "ComponentTechnologyBreakdown"),
"/index.do" : ("ObjectTracking"),
};
According to the level of details selected you will be able to see the information in the requests dashboard.
3. Single trace enhancements.
A. In Foglight 5.2.4.5 we added the ability to run single trace and keep only traces that have a problem (over X seconds, throwing exception, timing out), but if you wanted to use it from a rule you had to do some scripting. With Foglight 5.5 we added the ability to trace request with criteria as an action on a rule out of the box.
When choosing the trace with criteria action you still need to specify the request name, duration, tracking SQL parameters (yes/no) and the criteria for keeping these requests (over X seconds, ending in exception or timeout.). This is a big step forward in having foglight diagnosing problems as the happen without the need for a user intervention.
B. With Foglight 5.5 you can now have a single trace reported on Java servers that report to different Foglight servers. This is very important in large environments where you have requests process across multiple servers who may also be reporting data to different foglight servers.
4. Safe Mode Instrumentation.
When doing Bytecode instrumentation we sometime have challenges with classes that do not behave well in the instrumentation process, some hibernate classes and some classes that serialize objects over RMI may throw errors when instrumented. With Foglight 5.2.x the solution in these cases was to exclude these classes from being instrumented with the understanding that there may be some information lost. Foglight 5.5 gives us the ability to use safe mode instrumentation for those classes. The safe mode classes section is located at the end of agent_intrumentation.config on the foglight server administration (or instrumentation.config if you are using agent-override) and will look like this
SafeModeClasses = ClassList (
include "com.globex.plan.MasterPlan",
exclude "com.globex.plan.dominate.world.",
include "com.globex.plan.dominate."
);
The standard instrumentation happens to be slightly more efficient than the safe mode instrumentation so we recommend only using safe more for the classes for which it is needed.
New Platform support:
The newly supported platforms are: JBoss EAP 4.3, JBoss AS 5.0, Oracle AS 10.1.3.4, WebSphere 7.0, WebLogic 10.3 on AIX 5.3., Windows 2008 Server [x86, x86-64]. We have dropped support for JBoss 4.0.0. (currently only supporting JBoss 4.0.[1-5]) and Windows 2000 Server. As always the full details for the supported platforms are available in the Foglight 5.5 - Cartridge for Java EE - Supported Platforms
Golan Shem-Tov