You are on page 1of 40

DYNATRACE REFERENCE GUIDE

TABLE OF CONTENT

1. 2.

DYNATRACE ______________________________________________________________

ARCHITECTURE ___________________________________________________________ 8 2.1 KNOWLEDGESENSORS _____________________________________________________ 8 2.2 DYNATRACE AGENTS _____________________________________________________ 9 2.3 DYNATRACE COLLECTOR __________________________________________________ 9 2.4 DYNATRACE SERVER ______________________________________________________ 9 2.5 DYNATRACE REPOSITORY _________________________________________________ 10 2.6 DYNATRACE CLIENT _____________________________________________________ 10 2.7 INTEGRATIONS API ______________________________________________________ 10

3. 4.

INSTALLATION ___________________________________________________________ 11 TOOL START-UP AND LICENSE CONFIGURATION _______________________________ 14 4.1 START-UP _____________________________________________________________ 14 4.2 LICENSE CONFIGURATION _________________________________________________ 15 4.3 AGENT INJECTION _______________________________________________________ 16

5.

UNIQUE DYNATRACE KEYWORDS ____________________________________________ 17 5.1 PURE PATH ____________________________________________________________ 17 5.2 DYNATRACE BYTE CODE INSTRUMENTATION __________________________________ 19 5.3 SENSORS ______________________________________________________________ 19 5.4 DISCOVERY RUN ________________________________________________________ 20

6.

SYSTEM PROFILE _________________________________________________________ 21

7. DASHBOARD AND DASHLETS _________________________________________________ 25 7.1 DASHBOARD ___________________________________________________________ 25 7.2 DASHLETS _____________________________________________________________ 26 7.3 TYPES OF DASHLETS _____________________________________________________ 26 8. MEASURES AND CHARTING __________________________________________________ 33 8.1 MEASURES _____________________________________________________________ 33

8.2 CHARTING _____________________________________________________________ 33 9. SESSIONS _________________________________________________________________ 35 10. INTEGRATION WITH LOADRUNNER ___________________________________________ 36 11. METHOD INSTRUMENTATION _______________________________________________ 37 12. MEMORY INSTRUMENTATION _______________________________________________ 39

1. dynaTrace
As IT has been forced to better align with business goals and application complexity has increased, the requirements for Application Performance Management (APM) have dramatically changed. Now, application quality and IT efficiency are seen as major business components and differentiators. dynaTrace provides Continuous Application Performance Management for business-critical Java and .NET applications across the entire software lifecycle. It is used by over 100 industry-leading companies to monitor, diagnose, and prevent performance issues in development, test and production. dynaTrace provides a unique architecture, which enables it to fulfill these requirements. Key aspects: Pure Path Technology for true global transaction trace & capture Integrated lifecycle approach to eliminate silos between development, test and production to shift problem resolution earlier in lifecycle Business transaction management paired with deep code-level diagnostics always-on 24x7 in production (to go beyond application monitoring) Open platform supported through a Community Portal to simplify integration with existing ALM tools and to easily enhance dynaTraces out-of-the-box functionality Smooth and effortless deployment, configuration and maintenance to achieve the lowest total cost of ownership (TCO) and fastest time to value of any APM system Benefits: Minimize performance issues slipping into production Isolate performance issues in live applications before they impact end-users Reduce Mean-Time-To-Repair of production application issues by 90%, to bring them back online quickly Identify performance issues early in the lifecycle, before they become significantly more expensive to fix. Accelerate problem resolution by more than 10x Minimize costs for managing application performance through an open platform allowing tight integration to maximize automation, and through automatic adaptation to dynamically changing virtualized application clusters Minimize software/hardware purchase and maintenance costs through effective scalability tuning Identify performance issues early, avoiding disruptive fixes or late re-architectures causing significant delays

Accelerate problem resolution by more than 10x: developers can spend more time developing features and functionality Eliminate and accelerate cycles between test and development

2. Architecture
dynaTrace is designed for usage across the entire application lifecycle, including development, test, staging and production. Its unique architecture enables global Pure Path transaction tracing to be always-on - whether during continuous integration, high-scale load testing or 24x7 production operations. Key for being able to turn Pure Path transaction tracing always-on is the fact that the dynaTrace Agents do not accumulate any data, but instead all diagnosis data is sent asynchronously and in real-time to the dynaTrace Server, which constructs the distributed Pure Paths. The dynaTrace Collector is fully optional and removes instrumentation burden from the dynaTrace Server, providing high-scalability, and enabling dynaTrace to trace transactions even globally across WAN environments.

2.1 KnowledgeSensors
KnowledgeSensors mark a transactions progress along its execution path and identify all transaction entry points (e.g., Java Servlet invocations) and method calls, as well as their sequence

and nesting. For each transaction, the KnowledgeSensors record not only pure performance metrics (e.g., response times, CPU usage) of an execution path, but also contextual information (e.g., method arguments, return values, exceptions, log events, IO usage, network traffic, objects created, SQL calls, remote calls, and synchronization delays) in order to enable precise root-cause analysis. In this way, KnowledgeSensors provide all the data included in Pure Paths. Plus, you can subscribe them also as dedicated performance monitors to allow time-based performance analysis. To support a smooth deployment and an easy administration, several KnowledgeSensors can be packaged into a single KnowledgeSensorPack.

2.2 dynaTrace Agents


The lightweight dynaTrace Agent injects the instrumented byte/IL-code (original code + KnowledgeSensors) into the target application automatically; no source code changes are required. The dynaTrace point and click auto-sensor assistant and visual class browser with auto-discovery help you to maximize visibility with minimum instrumentation and overhead. The level of detail for code-level transaction tracing can also be adjusted on-the-fly without restarting the target application using HotSensorPlacement. The dynaTrace Agent is also used to gather memory and thread dumps. Plus, it can be deployed and managed from a central location and requires only minimal system resources for sustained 24x7 operation. Finally, the dynaTrace Agents are capable of collecting dynamic monitoring data in-process from JVMs, CLRs and application servers via JMX, PerfMon and PMI.

2.3 dynaTrace Collector


The dynaTrace Collector instruments the target application through adding KnowledgeSensors into its byte/IL-code. It also reduces network payload and provides data security between the target application and the dynaTrace Server as it provides data compression and strong encryption (SSL/TLSv3). Thus, the Collector reduces memory and CPU usage on the dynaTrace server to collect all the diagnostics data. The dynaTrace Collector allows dynaTrace to efficiently scale from small application deployments to very large server clusters. It also enables global end-to-end transaction tracing across applications deployed over WAN environments, such as SOA applications or applications accessed through rich/fat clients deployed in e.g. remote branch offices. Additionally, the Collector also executes OSGi-based monitoring plugins (e.g., Unix, Windows, SNMP monitors) and forwards results to the dynaTrace server.

2.4 dynaTrace Server


The dynaTrace Server collects all diagnostics data including transaction traces, monitors and memory/thread dumps. The Server centrally creates the Pure Paths, which may span distributed JVMs/CLRs, and derives all aggregations from them, while preserving the atomic Pure Path information. This allows overhead on the target application to be sustained at a very low level of

only 3-5% while providing deep application visibility on a transaction by transaction basis. This makes dynaTrace ideally suited for usage in load test and 24x7 production environments, even in large clustered application environments.

2.5 dynaTrace Repository


The dynaTrace Repository stores historical performance data for forward- and backward-looking long range analysis.

2.6 dynaTrace Client


By providing an intuitive, platform-independent user interface, the dynaTrace Client guides IT employees through the processes of managing application performance. Team members can access dashboards, detailed diagnosis data and reports in real-time via contextsensitive menus that minimize GUI navigation steps. Interactive analysis of stored diagnosis data - including Pure Paths, memory dumps and monitors enables developers to fully reconstruct application hotspots in their local development environment to quickly understand a problems root cause.

2.7 Integrations API


Open interfaces allow easy integration into existing environments, such as Continuous Integration, load testing, or enterprise management systems. Plus, you can easily extend dynaTrace with custom instrumentation sensors and OSGi-based open source plugins, such as monitors, actions or notifications, which you may download from our Community Portal. Simply customize and deploy them using the Rapid Plugin Development Environment. Using the CodeLink plugin you can accelerate final problem resolution by directly accessing the source-code of classes and methods you have identified as being a bottleneck in your favorite IDE (e.g., Eclipse) without hassle.

3. Installation
dynaTrace deployment unit for different platforms:

dynaTrace client is available for MAC OS too! Supported Environments for Application Diagnostics Framewo rks Hibernate Struts Applets

Application Servers & Portals IBM WebSphere Oracle WebLogic MS IIS/ASP.NET

Operating Systems Microsoft Windows Linux (Redhat, SUSE) Solaris

Runtimes Sun JVM Oracle JRockit JVM BEA/Oracle RT

Databases Oracle IBM DB2 MS SQL Server

MS SharePoint MS COM+ Component Services for .NET Apache Tomcat JBoss Oracle Application Server SAP Netweaver J2EE SpringSource dm Server Adobe LiveCycle & ColdFusion Sun Java Application Server ATG Dynamo CoreMedia NewAtlanta ServletExec Macromedia JRun Borland Enterprise/Application Server Proprietary Servers & Clients

IBM AIX

HP JVM Microsoft CLR REMOTING RMI / IIOP RMI / JRMP RMI / T3 ORMI IIOP/ORBs JBoss Remoting .NET Remoting WCF .NET

All databases accessed via JDBC and ADO.NET

AWT/Sw ing/RCP Spring AOP Oracle Toplink Oracle Coherenc e BlazeDS others

HP-UX IBM z/OS & zLinux WEB SERVICES STACK IBM WebSphere Oracle WebLogic Apache AXIS & CXF WebMethods Glue SAP NetWeaver Oracle WS JAX WS Codehaus XFire Apache HttpClient Hessian .NET Web Services

MESSAGING IBM WebSphere MQ BEA T3 (RMI, JMS) Apache Active MQ JMS Tibco Rendezvous CICS MSMQ

Steps to install dynaTrace on windows machine (Note: SUD (System Under Diagnosis) is JAVA based and resides on the same machine) Invoke the dynaTrace dynaTrace<Version>.msi file. Click NEXT button on the below screen

Accept the License agreement and click NEXT

On the below screen choose JAVA APPLICATION button and click on NEXT. This option will install components like Server, Client, Collector, Agent and Sample application.

Click NEXT on the successive screens and finally click on FINISH to complete setup.

4. Tool Start-up and License configuration


4.1 Start-up
Go to startprogramsdynaTracedynaTrace 3.2dynaTrace Server and wait till you see Starting server took: <time in seconds> message (fig below), to ensure successful server startup.

Choose startprogramsdynaTracedynaTrace 3.2dynaTrace Client.

Its a good practice to sequentially follow the above two steps while using dynaTrace. dynaTrace License file comes with .key extension.

4.2 License Configuration


Make selections as per the number sequence, in the below snapshot, to activate the license.

4.3 Agent injection


dynaTrace Agent needs to be injected in to the server on which the application is running. The application can be Tomcat, Jboss, Websphere etc. They listen to the server activities and pass on data to collectors. Agent can be injected by running following command for Java 1.5 and above in java command line.

AgentName: Name of the agent. Server: Name of the server on which dynaTrace Server is installed.

Depending on the JVMs on which the application is hosted we need to add the Agents. E.g. If we have 2 JVMs we need to add two agents for proper monitoring of application performance. Agents can be created and placed in Shared library, from where everyone can use them directly or modify them and then use.

5. Unique dynaTrace keywords


5.1 Pure Path
The core of dynaTrace is its unique PurePath transaction tracing technology. It makes transparent the inner workings of Java/.Net applications, visualizing application dependencies and models, automating issue documentation, eliminating the need for issue reproduction, as well as reducing problem isolation, diagnostics and resolution times to minutes. It helps you find the answers you need to resolve performance problems that matter to the business quickly and reliably: Assess the impact of a problem Isolate the component causing the problem Identify the root-cause of the problem Problems are analyzed and diagnosed using either of the two transaction tracing methods: Outside-In: From the end-user perspective (e.g., poor response time) down to the method-level Inside-Out: From the code perspective (e.g., exception) up to the affected business transaction(s)

Unique characteristics of Pure Path: Tracing individual transactions dynaTrace goes well beyond just recording average values to measure data on individual transactions. Such precise diagnosis offers clear identification of the factors influencing the performance of specific transactions enabling isolation of outliers, which ensures precise problem identification. Real-time business-level to code-level visibility dynaTrace provides real-time visibility into transaction performance from end-user down to codelevel simplifying data interpretation. Besides performance metrics (response times, CPU usage), it also captures contextual data (e.g., method arguments, memory allocations, SQL, sync events, exceptions/logs) to identify precisely the code segment causing the bottleneck. End-to-end across globally distributed tiers Trace transactions end-to-end, even across globally distributed servers/tiers, whether Java or .NET, starting even at rich clients. Low overhead, small footprint on target servers

dynaTrace only instruments those methods that contribute to application performance and offloads data processing to the dynaTrace Collectors and Server. This not only enables flexible deployment, but also deep-dive diagnostics under production load levels paired with low overhead at 3-5% 24x7 always on. Shareable provide interactive reports to engineers

Provide interactive code-level reports of problematic transactions to development without having to be a Java/.NET expert. Developers only need to analyze the data relevant to the case within a familiar format offline without having to reproduce the issue, whether they are working in-house, or at a remote location using the included dynaTrace Client or free Viewer.

5.2 dynaTrace byte code instrumentation


This is a concept where dynaTrace induces code into the applications class files just before the class loader loads them. The code induced is a timing code which gives dynaTrace, details such as method invocation time, method exit time and time totally spent within the method. The agent shares these details with the collector which in turn passes the information on to dynaTrace server. Users view all the captured metrics through dynaTrace client.

5.3 Sensors
dynaTrace agents inject Sensors into the application which in turn are responsible for byte code instrumentation. Each Sensor consists of a set of Sensor rules and they are divided into: Sensor Groups: Sensors that are stored and available only in a specific System Profile Sensor Packs: Sensors that are deployed on a dynaTrace Server and available in all System Profiles on this dynaTrace Server. Sensor Packs are created and maintained by dynaTrace users Knowledge Sensor Packs: Sensor Packs created and maintained by dynaTace software GmbH or by the dynaTrace community

5.3.1 Sensor Rules


They define the classes and methods that should be instrumented. Sensor Rules can be either: Method Sensor Rules: these rules relate to the Java/.NET Method Sensor and collect method related information for PurePaths

Memory Sensor Rules: these rules relate to the Java/.NET Memory Sensor and collect object allocation information for PurePaths and Selective Memory Dumps

5.3.2 Method Sensor Rules


To diagnose performance issues deeper in the application, the Method Sensor Rule configuration is used to gather information about specific packages/namespaces, classes and methods. Method Sensor Rules which are added to a Sensor Group are prioritized by their order, top down. As traffic passes through the Sensor Group the rule that matches first is the first and only one applied to that traffic. It is recommended that only packages/namespaces, classes or methods which are really critical in terms of performance are added to a Sensor Group, otherwise there will be a surplus of non-essential information which has to be processed.

5.4 Discovery Run


This involves 3 steps: 1. Start the SUD 2. Perform some transactions on that application. 3. Restart the SUD Using sensors we can enable dynaTrace to not only instrument main classes, but also instrument the derived classes that inherit from base classes. This technique can be used for classes whose inheritance details are known during compile time. We perform step 1 to assure that instrumentation for all base and derived classes whose inheritance is know during compile time, step 2 to ensure runtime inheritance is built and step 3 to make sure that instrumentation is implemented for all the derived classes including the ones that are resolved during runtime. This is called Discovery Run. The code below demonstrates inheritance that is known during runtime, discovery run is used to instrument such runtime logic. class Base { private int a;

void show(){ System.out.println(The value is+a); } } class Derived extends Base { private int b; void show(){ System.out.println(The value is+b); } } class Demo{ public static void main (String args[]){ //Here, we are creating an object b of type Base using the Derived class type // This can be done since class Derived has all the properties of Base including its own //properties through Inheritance, i.e. the contents of Derived class is Super set to Base class. Base b = new Derived(); //During compile time, the object b is referring to Base class version of show() method b.show(); // But at runtime, the Derived version of the method show() will be executed hence, //the resolution of the object is not known at compile time, but is resolved at runtime } }

6. System Profile
A System Profile is an XML file that stores a representation of a configuration for diagnosis of a specific System Under Diagnosis (SUD). System Profiles to visualize the system tiers, including servers, clusters, and clients, as well as the granularity and location of sensor placements. System Profiles enable users to: Control and repeat diagnostics Configurations. Check that all dynaTrace Agents are running.

Visualize the system tiers, including servers, clusters, and clients together with its running dynaTrace Agent. Create Sensors which include objects and methods to be instrumented during the diagnosis. Create Measure Configurations Create Schedules Create Incident Rules Create Tasks Create Monitors Define different Configurations for one Agent Group (for example, one for preproduction, one for production). dynaTrace allows you to switch between the Configurations at runtime.

Steps to create system profile: In the dynaTrace client, on the cockpit, right click on System Profiles and select Create System Profile

On the next page, choose the profile name, e.g. Demo App, and retain the other settings as shown in the below page assuming that the application is JAVA based.

Click Add Agent Group button at the bottom right corner of the above screen. Enter Agent configuration name e.g. Demo App FE BE.

Now click on the Agent Mapping button on the above screen to see the below screen.

Now, 1st click Delete and then Add button (in above screen) to auto-populate the newly created agent group and enter agent name AppFEBE. The agent name must coincide with the way it is named in the application server, while being configured (Here, assuming that it is named as AppFEBE in the application server) and choose the value Starts from the LOV next to Agent Name.

Click Ok on the above screen.

Now all the events occurring through the agent AppFEBE gets stored in the agent profile Demo App FE BE (Assuming that all the default sensors are placed and applied).

7. Dashboard and Dashlets


7.1 Dashboard
Definition: A Dashboard represents a specific view on one or more dynaTrace Data Sources. With the introduction of Dashboards, the dynaTrace Client provides a powerful tool for the preparation of diagnosis data for different kinds of use cases along the complete lifecycle of a software application. dynaTrace Dashboards allow to filter, aggregate and annotate PurePath-related information for experts of different fields.

Dashboards help to document and reuse common diagnose practices and support the collaboration of departments. We can store the dashboard both locally and on server We can just build a dashboard and use any number of times by changing the source

7.2 Dashlets
The building blocks of a Dashboard are so-called Dashlets. A Diagnose Dashlet defines a reusable and configurable view on one or more dynaTrace Sessions. Dashlets inherit the properties of a dashboard but can be changed individually We can just build a dashboard and use any number of times by changing the source. We can drill down in the dashlets for more detailed analysis

7.3 Types of Dashlets


7.3.1 Performance Specific dashlets

API Breakdown Business Transaction Components Database Messaging Methods Naming Services Pure paths Sequence Diagram

Synchronization Tagged Web Requests Web Requests & Web Services

7.3.2 Event Specific dashlets


Exceptions GUI Controls Incidents Logging Runtime Suspensions

7.3.3 Runtime specific dashlets


Selective Memory Threads Total Memory

7.3.4 Important Dashlets


API Breakdown API Breakdown provides a view of accumulated performance data, broken down into different APIs and supports the isolation of performance issues at a high level.

Database dynaTrace uses a novel approach for diagnosing and tuning database access.

Memory Allocations The Memory Allocations view comprises the memory allocation events occurred within PurePaths

Pure Paths The PurePath Dashlet is the central representation of all captured PurePaths.

It is used for determining performance-critical methods and their position within the PurePath, in order to be able to recognize the cause of the performance problem.

Pure Path Hot Spots PurePath Hot Spots View gives a visual overview of the currently selected PurePath. It takes the natural tree order of the PurePath contributors and Displays duration metric.

Web Request dynaTrace uses a novel approach for diagnosing and tuning software components that handles Web Requests like Servlets and JSPs.

Web Services dynaTrace uses a novel approach for diagnosing and tuning Web Services.

Exceptions In Java programming language exceptions are used to provide error-handling capabilities for applications dynaTrace makes use of dynamic bytecode instrumentation to capture throwable classes, messages, and stack traces of java classes that extend java.lang.Exception.

Logging dynaTrace uses a novel approach for diagnosing logging calls executed by the Java Logging API, the Log4J Logging Framework. The Logging view shows an aggregated view of the logging events, grouped by the class and method that issued the logging event

Selective Memory Selective Memory Dashlet you can create or open Selective Memory Dumps and analyze the objects in the dump. A Selective Memory Dump uses memory sensor rules for object allocation book keeping.

Threads Using the Threads Memory Dashlet you can create or open thread dumps and analyze the stack of the threads. The view is divided into 3 areas. The Upper view is to create or view thread dumps for certain Agents The middle area provides information about dumped threads.

Low area shows the stack trace of the selected thread, and the monitors that the thread owns

Total Memory The Total Memory Dashlet provides snapshot information about currently allocated objects, regardless of the connection of the allocated objects to recorded PurePaths or to configured memory rules. The Total Memory Dashlet shows information about all objects that exist in the heap memory of the virtual machine at the time the memory dump was created

8. Measures and Charting


8.1 Measures
SUBSCRIBE: Is a process of making a measures persistent in repository. We can subscribe to system characteristics, layer/component response & CPU times, DB response times, JVM characteristics etc. You must subscribe for doing the following things 1)charting 2)alerting 3)business transaction analysis Dynamic measure gives us the privilege of adapting to any number of instances We can set thresholds for all the measures. There some default measures even if we dont subscribe such as CPU usage, memory etc.

8.2 Charting
Charting templates provide an easy way to get a quick overview of an application. The created templates contain preconfigured series suitable for most situations. By default for each Agent Group an individual sub-chart within Chart Dashlet is created We can chart any measure that has been subscribed Steps to create a basic chart Add a new chart dashlet Go to dashboard Properties. Go to General tab and change refresh setting to 10 sec (automatic option) to refresh chart every 10 sec. Save the Dash board with a meaningful name.

Add Chart Dashlet to this Dashboard. To add data to chart, right Click on the background of the chart and select Add Series option.

In the measure Picker window select the measure that you have subscribed to and add them.

Below is a sample line chart

9. Sessions
A session is a set of diagnosis data concerning a specific System Profile. Possible instances of a session are: PurePath Session: represents the combined information about PurePaths and Time Series within a given time period Memory Dump: contains analysis data about the number, size and class of allocated objects and their references Thread Dump: is a collection of data for thread analysis including CPU time information

Types of Sessions Live: A Live Session represents the current diagnosis data stored in the memory (RAM) of a dynaTrace Server, hence only one Live Session can exist per system profile. Only a PurePath Session can represent a Live Session. Stored: A Stored Session is a Memory Dump, a Thread Dump, a Sampling or a former Live PurePath Session that is stored at the hard disc. This means that a Stored Session can be located at a dynaTrace Server or at a dynaTrace Client. It is possible that multiple Stored Sessions correspond to one system profile. Offline: If a Stored Session is saved at the client's machine it is also called an Offline Session, because it can be accessed without connecting a dynaTrace Server.

Importing and Exporting Sessions : Every session (live/stored/offline) can be exported to a .dts-archive (dynaTrace session). A Stored Session can be restored by importing a .dts-archive. Importing and exporting can be invoked by using the Cockpit or the Session Browser dashlet. Additionally the import command is available as a button of the client toolbar and as an entry of the client's File menu. Session Browser : The Session Browser dashlet displays information of Stored Sessions available on the dashlet's data source.

A Stored Session can be a PurePath Session, a Memory Dump, a Thread Dump or a Sampling that is stored on a dynaTrace Server or offline on the client

10. Integration with LoadRunner


dynaTrace integrates well with load testing and monitoring products, especially on the transactional/request level.The Tagged Web Requests view lists web requests originated from load testing systems integrated with dynaTrace. The integration of dynaTrace with load testing systems enables to correlate generated web requests with the PurePaths.

Steps to Instrument LoadRunner scripts: Access the Utility that modifies LR scripts into the format understood by dynaTrace (dTScriptConverter4LR) Run the Utility by accessing LoadRunnerConverter.cmd Browse for the script folder and click Open. Select All Files and click Modify.

Go to script folder and check the scripts inside. All requests will have a dynaTrace header appended to them, as shown below:

11. Method Instrumentation


Method instrumentation is an art of choosing right methods to be instrumented. We are using dynaTrace to find the root cause of issue and naturally wouldnt want the tool to be an overhead. When method instrumentation is not done efficiently, it would cause over heads, hence, the entire purpose of using the tool is defeated. If we have intense knowledge of the application and code sections that could cause potential issues, then instrumentation would become a cake walk, but, if you are not aware, then below are the steps that would guide you to do method instrumentation.

Steps to create Method sensor packs and instrument the application: Create your own sensor group using the class browser: The Class Browser provides a convenient way to define Class Rules and Method Rules. A tree view which reflects the package/namespace structure of the classes loaded by the SUD is created, which enables the selection of packages/namespaces, classes, interfaces and methods. A Class Rule is generated for each selected tree node representing a package/namespace, class or interface, and a Method Rule is generated for each selected method node. This enables quick generation of multiple Class Rules and Method Rules. Based upon a SUDs loaded classes, which have been captured by a Discovery Run, the Class Browser provides the ability to select rules by simple mouse clicks.

If you are not sure about the specific classes/methods that are to be instrumented, you can choose a package, in the source code, under which you have a gut feeling that majority of the classes/methods, would be covered. This process is termed as shotgunning where we deliberately over instrument the code and slowly exclude the methods/classes that need no instrumentation Once custom sensors are added, they can be activated by HOT SENSOR PLACEMENT option (for JAVA 1.5 and above) or by restarting the application.

Once HOT SENSOR PLACEMENT or restart of the application is done, open the Pure Path dashlet available in the client. Look for pure paths that have huge size (sort in DESC by size), and drill down into the methods. Look for methods that are invoked many times (sort in DESC by count) but are doing very less in terms of response time and exclude them. Exclusion/Inclusion of rules needs no HOT SENSOR PLACEMENT or restart of the application to take effect.

12. Memory Instrumentation


We perform memory instrumentation on application suffering from constant high memory usage or out of memory issues. The normal practice in order to diagnose memory issues is to take a heap dump. This dump takes a snapshot of the heap at that point in time. Java provides an API to take Heap dumps, but, they are very expensive since they freeze all the other activities happening in the application till their completion. dynaTrace provides inbuilt memory packages that are not placed by default. Once these sensor packs are placed the application HAS TO BE RESTARTED and the concept of HOT SENSOR PLACEMENT doesnt work here. To overcome the over head issues in JAVA heap dump API, dynaTrace provides an easier and time saving utilities like:

Partial Heap Dump This utility does not take the snap shot of all the objects in the heap, it only captures the ones that are essential, and hence, the application is not stalled for a long time.

12 Full Heap Dump After analyzing all the partial heap dumps and locating the major bottleneck classes/packages, the full heap dump is taken to find the root cause. This heap dump is not as time consuming as the one provided by JAVA. Steps to perform Memory instrumentation: 13 Run the application suffering with memory issues. 14 Take 3-4 partial heap dumps to analyze the entities consuming enormous memory(e.g. float array) 15 Now take a full heap dump and get the details of the classes/packages, of the entity identified in the above step, involved in memory consumption. 16 Instrument the classes/packages identified to be consuming more memory. 17 Restart the application for the instrumentation to take effect. 18 Find the root cause of the issue.