sap j2ee monitoring and management for administrators[1]

8/13/2019 SAP J2EE Monitoring and Management for Administrators[1]

http://slidepdf.com/reader/full/sap-j2ee-monitoring-and-management-for-administrators1 1/56

Astrid Tschense

PM System Management, SAP AG

SAP Java Monitoring andManagement for Administrators

Welcome

to SAP J2EE Server Monitoring and Management for Administrators.

This slide show presents you the tools SAP offers to monitor a system

landscape with one or more J2EE Engines and JAVA applicationsrunning on the engines.



! SAP AG 2003, TechED Basel 2003, SM102_EMEA, Astrid Tschense

Agenda (1/2)

Introduction

Tools Overview

! Administrator‘s and Expert View

! Granularity

Administrator‘s Daily Work:Techniques for Problem Detection

! Availability

! Statistics

" Distributed Statistics Records

" Java Application Response time Measurement

! State Monitor

" Monitor Service

" State Monitor in the Central System

! Log Monitor

" Logging" Log Viewers

" Log Monitor in the Central System

! Alerting

Agenda

So let‘s start with a glance on the contents to see what this slide show is

about in detail:

After a short introduction we will have allook at the tools that are at your

disposal to monitor an SAP system Landscape with one or multipal J2EE

Engines.

We will distinquish between tools for problem detection and tools for

problem analysis, that is, we distinguish between the Administrator‘s

daily work with a running system and the problem analysis in case that

an error has occured.




Agenda (2/2)

‚Expert View‘: Techniques for ProblemAnalysis

!Performance Trace

"Functionality

"View

!Single Activity Trace

"Functionality

"View

!Developer (Logging API) Trace

"Functionality

"Configuration

!SQL Trace

!Application Trace

"Functionality

"View

Summary

Info

Agenda II

You see that we‘ll get to the traces level then. In the end I will give you

some hints where you can find further information and who to contact if

you have questions on all this.




Introduction: SAP NetWeaver Layers

ABAP J2EE

System Management Layer

ABA

P

J2EESystem Management System Management

J2EE

DB and OS Abstraction

System Management System Management

Application Platform

ABAP

Data is permanently collected

by System Management Layers

for use by the CCMS

Infrastructure.

ntroduction

Presumably you know the SAP Netweaver picture.

nside the SAP netweaver box there is an application platform, the SAP Web

Application Server.

The application platform consists of an ABAP and a J2EE stack.

Both the ABAP stack and the J2EE stack have their System Management Layer.

They collect and display several kinds of data:

Like:

- Database data

- Operating system data

- Log data

- Statistical workload data

- Application data, etc.




System Management within the J2EE Engine

The display tools for the data collected by the J2EE Engine are both

CCMS and Visual Administrator.

J2EE Engine

Visual Administrator CCMSMonitoring

Logging

Performance

Data

Central System

System Management

On the left hand you see the CCMS Alert Monitoring Infrastructure.

Data from the monitoring programs (called data suppliers) are displayed and

evaluated in the central monitoring system. SAP provides an expert tool, the

CCMS Alert Monitor (transaction RZ20 ). Alternatively, you can use the Solution

Manager to display the data in a business process-oriented context.

With the help of a so called agent the J2EE Engine reports all the collected data

into the CCMS. The J2EE Engine has an own display tool, the VisualAdministrator.

But it is important that if you have a huge system landscape all monitoring data

can be seen in one place.




Views: ‚Administration‘ and ‚Expert‘

Administrator

View

Expert View

Application

Tracing

Vis. Adm.

Logs

DeveloperTraces

Vis. Adm.

Performance

Trace

Single Activity

Trace

Vis. Adm. CCMS

Developer

Trace

SQL

Trace

Vis. Adm.

Server

param.Application

param.

State Monitors

AlertingAlerting

Vis. Adm.

CCMS

Availability

Heartbeat

CCMS

Monitored Logs

/database_log

/network_log

/security_log

/server_log...

AlertingAlerting

CCMS

JARM

(JARM-

Impl.)

CCMS

DSRs

(Bytecode

Modification)

Statistics

Two different views

The administrator gets several kinds of data like system state information,

performance and alerts, all reported into the CCMS, so he or she can monitor a

system landscape with one or several J2EE Engines easily with the CCMS,

perhaps in addition with some autoreaction methods that are started when an

alert occurs.

If an alarm, that is, a read light, is coming up, then the expert has to dive

deeper into the programs and processes, so he looks at the traces. Which

traces he has to test for errors of course depends on the problem.

So we distinguish between problem detection, that can be done out of the

CCMS, because there one can get an overview of the system health. If you

have to look into details, then you take one of the expert tools to analyze the

corresponding traces.




Administrator’s Daily Work

Availability

Statistics

State Monitors

Log Monitors

When all the necessary monitors are configured, then the CCMS offers you a

pretty good control over the whole SAP system landscape.

What you have to do to configure your Monitor system right we will see in the

next chapters.




Monitoring Tools: Granularity

STATTRACE

Log Viewer

ST04

Performance Trace

Single Activity Trace

Developer Trace

SQL Trace

Problem

Analysis

Visual Administrator

Netweaver Dev. Studio

Application Trace

Remote Debugging

Detailed

Analysis

Development

Daily

Overview

Usage

ST03G

Solution Manager

RZ20


Availability Monitor

Aggregated Statistics

State Monitors

Log Monitoring

Coarser

Finer

ToolSourceLevel

So let‘s start

with the details. The granularity of the data is sorted from coarser to finer. In the daily

overview we have an availability monitor that shows the availability of the system in

percent and a so-called „heartbeat“. Then we have statistics, state monitors and log

monitoring.




Availability Monitoring

Description

! In productive system landscapes, the availability of components has

to be checked automatically.

! Using the so-called “Heartbeat” (GRMG), the administrator has a

central infrastructure to check the availability of the SAP J2EEEngine and JAVA based applications.

Functionality

! With SAP J2EE Engine 6.30, a GRMG application is delivered,

which reports availability information of the SAP J2EE engine itself

to a central monitoring system.

! JAVA based applications are now able to configure GRMG

monitoring automatically.

Availability Monitoring

It‘s obvious that you can‘t send a ping to each of your systems to ask: Hey, are you still

there?“ So in a system landscape we need an automatic control of the heartbeat of

the J2EE Engine and all the added JAVA applications.

The name of this ‚heartbeat‘ is GRMG: Generic Request and Message Generator.

The GRMG of the J2EE Engine itself is activated and displayed automatically after

installation of the system.




Monitoring

Architecture

GRMG

Infrastructure

Availability in %,

Heartbeat

Uploaded GRMG

configuration file

J2EE EngineHTTP

Server

ABAP

Application

SAP J2EE

EngineGRMG

Application

SAP Web AS

GRMG

Application

J2EE

Server

<?xml version="1.0" …

<!DOCTYPE Customizing<!ELEMENT customizing …

<!ELEMENT control(grmg…

<!ELEMENT …

SAP Web AS

Availability Monitoring: Using GRMG

GRMG Structure

GRMG consists of two parts, both of which are required for a functioning GRMG

environment:

The GRMG infrastructure is part of the monitoring architecture of the Computing Central

Monitoring System (CCMS). Its task is to send a request (the GRMG request) to the

GRMG application, to receive its response (the GRMG response) and to display this

response in an Alert Monitor (RZ20).

The GRMG application reports two values: a general availability and the heartbeat.

Therefore the GRMG application runs a specific test especially programmed for thecomponent(s) in question. In case of the J2EE Engine the tested components are the

HTTP Provider Service, P4 Service, EJB Container and Web Services.

The GRMG infrastructure is monitored itself, too. This allows you to differentiate, if an

error occurs, between errors in the monitored component and errors in the GRMG

scenario itself.




Problem Detection: GRMG Configuration in Vis Admin

GRMG Customizing Tab

In the Monitoring Service of the Visual Administrator you find a tab „GRMG

Customizing“. Every application running GRMG is listed here. In this example you

see the GRMG of the J2EE Engine itself. On the right side the customizing of this

GRMG is displayed. Selecting the edit button, you can change the customizing - for

example you can enter another scenario name („Scenname“), that‘s the name of the

GRMG node in the Alert Monitor RZ20.

To make your changes take effect save and upload the customizing file with the buttons

in the left part.




Problem Detection: GRMG View in RZ20

GRMG view in the Central System

This is the expanded GRMG tree in the CCMS RZ20. You get the availability

percentage, the heartbeat with a message and the time and data of the evaluation.




Techniques for Problem Detection

1. Powerful Techniques for Problem Detection:

# Availability Monitoring, based on Generic Request and

Message Generator (GRMG)

# Performance Statistics:

• Aggregated Distributed Statistics Records

• Java Application Response time Measurement

# State Monitoring shows health of server and application

parameters with traffic-light colours and thresholds

# Log Monitoring displays error occurrence in RZ20




Problem Detection: Distributed Statistics Records

Distributed Statistics Records (DSR)

The DSRs are statistical data, collected via Bytecode Modification.

DSRs are used in two different ways:

1. aggregated view: total Response time of incoming requests

2. finer granularity: Performance Trace – used for problem

analysis

The DSRs written by the J2EE Engine can be administrated in the

Visual Administrator in the DSR Service.

Distributed Statistics Records (DSRs)

are statistical records which are written by non-ABAP components. With DSRs, now

the complete SAP system landscaoe is covered with a network of statistical

information.

And this is how it works: The first component called in a business process creates a

passport. Among other things, the passport contains a globally unique identifier, and

information about the initial action and the user. The ID is written to disk together with

the statistical information. If another component is called during the processing of the

request, the passport is passed to the other component. This works for ABAP as well

as non-ABAP components. Therefore, the ID identifies all statistical information of the

system landscape, which corresponds to one logical unit of work (LUW).

DSRs are collected via Bytecode Modification, that is, the measurement units of DSRs

are statically implemented into the coding. DSRs offer two different views: first the

total response time of incoming requests and secondly a fine granular view on trace

level.




Appl icat ion

Client

J2EE

Engine

Database

Server


Processing time (1)

Database time (1)

Processing time (2)

Processing time (3)

Database time (2)

Response

time

User starts transaction

Server receives request

Server returns response

Client displays result

N e t w o r k

N e t w o r k

N e t w o r k

N e t w o r k

Wait time (waiting for a data base connection)

Wait time (JMS Queue)

‚black box‘

This detailed view is

offered with the

Performance Trace

In this graphic you see which times are recorded: The total response time begins whenthe server receives a request and ends when the server returns a response. The

whole right hand part of the graphic is a black box in the DSR view but can be seen

on the trace level we will talk about lateron.





Content-

Server Collector Collector

DatabaseDatabase

Central System

ST03G

J2EE

6.30

Server Instance

Content-

Server StatisticsStatistics

FilesFiles

DSR

Service

Hourly data pull

for statisticsaggregation

Aggreg.

statistics

STATTRACE

Direct call for

last minutes‘ loadDSR

Collector

Non-aggreg.

Single recorddisplay

CCMSR

Agent

the J2EE Engine, the DSR Service is responsible for managing the DSRs. You can switch the

DSRs on and off in the Visual Administrator, the default is “on”.

e statistics records are transferred to the file system of the host. The CCMS agent reads thestatistics files. There are three display variants:

First is to display Collector Aggregates After the Hourly Collector Run

e DSR collector aggregates the data during the transfer in its hourly background run

(background job SAP_COLLECTOR_FOR_NONE

_R3_STAT). The statistics records are then stored in the database and displayed in the Global

Workload Monitor (transaction ST03G).

Second possibility is to display the Collector Aggregates Between Hourly Collector Runs

So that you do not have to wait until the hourly collector run to display aggregated statistics filesthe Global Workload Monitor (transaction ST03G) provides the Last Minutes’ Load function,

which allows you to aggregate and display statistical data during runtime without storing it in the

database.

ou can also display Raw Data as Single Records

With single record display, the raw statistical data is displayed in the transaction STATTRACE.




Problem Detection: DSRs – Weekly Aggregation

day

week

Last

minute

Transaction STO3G in the Central System

In the Global Workload Monitor you see,

- Which action steps have the longest response and wait time

- What workload data is created when calling external components

- What the workload of individual users is and which actions a user has performed and

so on.

To all of these analyses applies, that

- You can choose the period for which you want to display data between day, week, and

month, or specify the Last Minute’s Load as you require.

- And you can display data for any component or optionally totaled for all components of

a type.




Problem Detection: JARM

Java Application Response time Measurement

of functional entities in Java applications

During the runtime of a request data is collected as a result of the API calls:

For each involved thread it is stored which

request, [subtask] and component, [action]

is currently processed. JARM is implemented during design time and can then be

activated in case you need to have a look on the application response time.

Component A Start

Component B End

Component B Start

Request End

Component A End

...

level1Monitor = TaskMonitor.getRequestMonitor ("MyUser", “…

level1Monitor.startComponent("Level1.Component A");

...

level1Monitor.startComponent("Level1.Bean 1");

...

beanMonitor = TaskMonitor.getRequestMonitor ("MyUser", "Bean…

beanMonitor.startComponent("Bean 1.Component A");

...

beanMonitor.endComponent("Bean 1.Component A");

beanMonitor.endRequest("Bean 1.Request A");

...

level1Monitor.endComponent("Level1.Bean 1");

Request

structure:

ARM – JAva Application Responsetime Measurement

an application you have to monitor is instrumented with JARM then you use another way tmonitor the response time:

ARM means, that the application coding includes Monitors on particular points like „star

component“, „end component“, and a lot of subtasks that get processed. The measured unit

are interpreted in 3 ways, that is

TOP 100 Display:

The most expensive requests are shown selected by different criteria like response time o

amount of transferred data. Additionally the control flow and the costs of the component

processed for each request is shown.

n Accumulation of Data

There you can think of average data for components or users like execution time, data transfe

…

hread Overview

An Overview about the current usage of threads by the JAVA application is given. It i

indicated which threads are active and which components are currently involved.

JARM data can be viewed in the Application Trace Service of the Visual Administrator, and th

CCMS RZ20.




Problem Detection: JARM Viewer

The JARM Viewer is

integrated into the

Application Trace Service

of SAP Web AS 6.40.

JARM Viewer

Starting with SAP Web AS 6.40 JARM data is shown in the Application Trace Service of

the Administrator tool of the J2EE Engine.

What you see here is the Request Overview in the upper part of the screen and details

of the marked request in the lower part.

The Request Overview shows the request name with the total response time. Then we

see no answer (minus one means no data) for outbound data. Components counts

the number of components involved, and component max time shows the name of

the component that needed most of the response time.

Other display options are the components overview and the user overview.




Problem Detection: State Monitoring

Monitoring the J2EE Engine itself

The Java personality of the SAP Web AS 6.30 provides monitoring of

the most important server parameters, hence offers a monitoring

architecture for accumulation, history and alert generation.

The most important monitored parameters are:

! Network Connections

! Memory Consumption

! Threads

! Classloaders

! JMX Adapter...

State Monitor

The J2EE Engine provides a monitoring architecture that accumulates data, creates

histories, and generates alerts.

The monitors created by the Monitoring Service of the J2EE Engine monitor all vital

server parameters. The monitoring architecture of the J2EE Engine 6.30 is based on

the JMX standard. This means that external tools can also access monitoring data.

The data for the monitored J2EE resources read by the monitors is displayed in the

Visual Administrator.




Problem Detection: Visual Administrator - Monitor Tree

Managers

Services

Applications

System

Performance

Monitoring Service

The SAP J2EE Engine Monitoring Service provides a runtime control for displaying the

monitored data. The data is listed in a tree view in the Monitoring Service"

MonitorTree tab of the Visual Administrator. The available sections are: Managers,

Services, Applications and System.

· According to the thresholds defined in the configuration the performance monitors

have a color state:

Green: The data is in the normal level (OK). No attention is needed.

yellow: A warning bullet. Shows that the values have moved to the next alert level and

soon some problems might occur. Some attention is needed.

red: An error bullet. The data values have moved to the error level. Special measures

have to be taken.

Grey means that no values are reported




Problem Detection: Monitor Tree and Tuning

Tuning

To each Monitor you find a history and a configuration button in the right part of the

Visual Administrator screen. If you see that e.g. thresholds, pool sizes have to be

changed you have to switch to the corresponding Manager or Service.



! SAP AG 2003, TechEDBasel 2003, SM102_EMEA, Astrid Tschense

RZ20: Alert Monitor Tree

Central Alert

Notification

All tree nodes

$ Represents one physical

or logical object

$ Summarizes alerts and

propagate to higher

nodes

$ Receive data and may

create alerts

$ Use data for analysis

alerts

Monitoring Tree Elements

Monitoring Attributes

Monitoring Object

View

Alert Monitor of the Central System

The CCMS has an object-based monitoring architecture that integrates information from the

entire SAP landscape to present an easy-to-manage overview of the condition of the SAP

Systems and their environment. The information is displayed in a tree-based structure.

The nodes of the tree-based structure are called Monitoring Tree Element (MTE ).

The information measured is combined with monitoring attributes. Monitoring attributes are the

leaf nodes of the tree. They represent physical characteristics or messages related to a

monitoring object. For each monitoring attribute, alerts are displayed if configurable threshold

conditions are met. The alerts are reported to the top of the tree so that the occurrence of an

alert can be seen even when the monitor tree is collapsed.

You can set an autoreaction method on each of the monitoring objects to receive e-mail, sms or

a pager notification in case of alerts.




Analyze Alerts: The Alert Browser

Alert browser

Doubleclicking a node shows

all corresponding alerts

The Alert Monitor has two views:

- Current status shows the present situation of the system.

- Open alerts shows the situation of the system in the past. This view is useful for analyzingany problems that occurred before the last system monitoring run.

The Current status view provides an overview of the current values of the systems that were

reported to the monitoring architecture. It displays the relevant values for all attributes, for

example, the performance value or the last report that was received.

The color of the monitoring object indicates its status, and is independent of any open alerts

that may exist for that MTE.

f you switch to the Open alerts view, i.e. the „History"-view, the system displays for each

monitoring object the most important, that is the most critical and the most severe, open alertregardless of the total number of alerts for that object.

You can set alerts to Complete once they have been resolved. The completed alert is then

removed from the list. After a certain time which can be adjusted, the open alerts are auto-

completed and removed from the open alerts display.














# Viewing logs

# Monitoring logs




Problem Detection: Logging and Log Viewer

As of release SAP Web AS 6.30 all Java components use the

same logging infrastructure

! Common API: logging.jar

" Everywhere the same concept of logging is used

" Distinction of logging and tracing

" Number of serverities

! Common configuration

" Deployment of application specific logging configuration

" Configuration supported by command line shell and visual

administrator

! Common viewer

" All logs independently whether they are written by the server

kernel, services, libs or applications can be viewed within the

same viewer

" Logs from all server nodes can be merged together

! Automatic properties

" Application name, thread id, user, DSR-passport

ogging Infrastructure

s of release SAP Web AS 6.30 all Java components use the same logging infrastructure.

he SAP Logging API provides a solution for tracing and logging with several additional features

compared to open source packages such as Log4J or the Standard Logging API of JDK 1.4.

The Java expert group has decided that this package is the official solution for tracing and

logging within SAP group.

ow that everywhere in SAP the same concept of logging is used we can also have a common

configuration, that can be done with the log configurator service in the Visual Administrator or

out of the SAP Netweaver Developer Studio or by command line.

the logs, may they come from server, services or applications or somewhere else, can be

displayed in the log viewer.

hey have the same kind of property information, so these logs can be compared and sorted by

application name, thread Id, user and passport and so on.




Log Viewer Types

3 Types of Log Viewers:

Integrated Log Viewer, included in the Visual Administrator

! Online tool where all the logs written from the Engine and the

running applications are automatically registered

! Customizing the properties, switch Log Monitoring on...

Standalone Log Viewer for central Log Viewing

! Consists of Log Viewer Server and Log Viewer Client. Logs from a

System Landscape can be viewed centrally in one Standalone Log

Viewer Client, if one Log Viewer Server runs on every host.

Command line Log Viewer

Usage: lv.bat delivered with Standalone Log Viewer

! Only for viewing local logs on console

! Can be switched on while deployment

! Converts binary data into human readable data

og Viewer 6.30

he Log Viewer is a display tool for several kinds of log files written by the J2EE Engine or its

applications. There are three different versions available:

he Integrated Log Viewer within the Visual Administrator, the Standalone Log Viewer, and a

command line log Viewer.

he advantage of the Integrated Log Viewer is that all the logs written form the Engine and the

running applications are automatically registered, because the Log Viewer server listens to

logging.jar and makes every log file available as it is created.

he Log Viewer can parse the logging.jar list format into columns. That allows merging severalslogs together. The records have timestamps that impose an order.

n the properties tab of the Integrated Log Viewer the Log Monitoring with the central SAP

System can be switched on.




2. Standalone Log Viewer

Solution II: Standalone Log Viewer Servers and one Log Viewer Client! Single point of access for support teams (customer, SAP)

! Log files accessible, even if the J2EE engine is down

! Version of the Log server can be higher that the version of the J2EE engine:

latest support features are available without changing the application

Log Viewer protocol (P4)

J2EE

6.30

Host I

Log Viewer-

Server

Log Viewer-

Server

J2EE

6.30

Host II

Log Viewer

Client S Router

SAP SupportSAP Support

Standalone Log Viewer

The WebAS server occasionally is down or you want to view a file that was not

registered with the server, but is in list format. What to do? You need to start your

own Standalone Log Viewer (client and server) and connect to it.

Per default the standalone Log Viewer version 6.20 is empty. You have to register the

log files you want to display. To do this, use the register_log script or add the log files

to the LogViewerServer.properties.

To monitor log files of another system, a Log Viewer server must run on that system. Its

logs can then be read remotely with a Standalone Log Viewer client on the

monitoring system:

In the monitored system the monitorable paths should be restricted to prevent from

misuse.




Future: WebAdmin in SAP Web AS 7.0

Future Solution: Web Administration Tool! Combines advantages of solution I and solution III

" All logfiles from all connected servers are automatically registered

" Can connect to standalone LogViewer server

" One tool for all releases

" Customer access without application sharing

S Router

http

JMX-Connector

J2EE 620

Host I Host II

TREX

Host III

WA-

Adapter

J2EE 630

WA-

Adapter

J2EE 630

WA-

Server

LV-

Server

CEN Server




Standalone Log Viewer vs. Online Log Viewer

Standalone

Log Viewer Client

Online Log

Viewer

Just to make the difference between the Standalone version and the online versionvisible:

In the standalone log tree there are only the logs I have chosen for display, whereas the

log tree of the online Log Viewer shows all the logs that are created with logging.jar.

And you can see the properties tab in the online version where you can set the

properties for automatic log file monitoring, configure the output-directories etc.




Log Monitoring Architecture

Log Monitoring

To monitor the logs registered in the online Log Viewer you can

choose between manual and

automatic Log Monitoring Activate the function „Create CCMSR agent templates for log file monitoring“ (1)

and check whether the right log file directory is entered (default: prfclog\logmon)

Central System

RZ20

Reads

sapccmsr.ini-

file

Reads

templates

Scans log files

for patterns

SAPCCMSR

Agent

! Creates monitor tree

alerts for found patterns

Reads

logmon.ini-

files

Log Monitoring can be started in two ways, automatically or manually. You shouldchoose this depending on how many logs you want to monitor. To start the automatic

process you have to set the flag for „Create CCMSR Agent templates for log

monitoring“:

! The Log Viewer creates the template files, inserting the log file path name, the search

pattern, and the color value.

! The log file template index is updated and stored.

! Then the Log Viewer writes into the CCMS Agent .ini-file to search for the index.

! When the CCMS Agent finds an index of log .ini-files it reads the templates and

creates the nodes in the CCMS log monitor tree.

! The CCMS Agent begins monitoring the logs named in the ini-files for text patterns

specified in the templates.

! When the agent finds one of the specified text patterns, it notifies CCMS on the R/3

system via an RFC.




Log Monitoring within RZ20

The alerts are transferred into the CCMS, transaction RZ20. In the view „Currentsystem status“ you can see whether an alert has been reported.

With a double click on the complete log file name an analysis method is started, and the

log file is displayed.




Monitoring Tools: Granularity

STATTRACE

Log Viewer

ST04

Performance Trace


Developer Trace

SQL Trace

Problem

Analysis


Netweaver Dev. Studio

Application Trace

Remote Debugging

Detailed

Analysis

Development

Daily

Overview

Usage

ST03G

Solution Manager

RZ20


Aggregated Statistics

Availability Monitor

State Monitors

Log Monitoring

Coarser

Finer

ToolSourceLevel

Short SummaryYou‘ve seen the tools for the daily overview: Statistics Monitor, Availability Monitor,

State Monitor and Log File Monitor. With the help of the CCMSR agent all this data is

visible in your central system.

Now we change the perspective and come to the expert and developer view, that is we

switch to the traces level.




Techniques for Problem Analysis

2. Powerful Techniques for Problem Analysis:

• Performance Trace to refine DSR information

• Single Activity Trace (SAT) to track a single activity runningover multiple components implemented with JARM

• Logs and Developer (Logging API) Trace

• SQL Trace

• Application Traces




Appl icat ion

Client

J2EE

Engine

Database

Server

Distributed Statistics Records vs Performance Trace

Processing time (1)

Database time (1)

Processing time (2)

Processing time (3)

Database time (2)

Response

time

User starts transaction

Server receives request

Server returns response

Client displays result

N e t w o r k

N e t w o r k

N e t w o r k

N e t w o r k

Wait time (waiting for a data base connection)

Wait time (JMS Queue)

Performance Trace Graphic

The performance traces are written with Bytecode Modification, like the DSRs that give

us a performance overview.

As we have seen before, the J2EE Engine is not transparent for the distributed statistics

records (DSRs), and only the duration of the processing from an entry point to an exit

point from the Engine is measured.

With the Performance Trace time is measured on module level, and you can activate

measurement exactly for the modules that are of interest for you.




Performance Trace: Brief Overview

Description

! Performance traces provide finer granularity of performance

information than DSRs

! Have to be switched on in case of a performance problem

Functionality

! For each module called by processing a piece of JAVA code,

additional performance information is written to disk

! Can be activated per module

! Data is transferred to a central system by usage of a CCMSR agent

! Analysis happens centrally in transaction STATTRACE




Performance Trace versus DSRs

SAP J2EE 630

HTTP RMI JMS IIOP

DBI

DB

Level of DSRs

HTTP Service Web Container JMS

EJB Container RMI

Connector

JDBC

Connector

Level of performance trace

Performance Trace Granularity

This graphic shows the difference between DSRs and Performance Trace. As the

performance trace provides duration information for the individual modules of the

engine you get a lot more information. You can activate a performance trace to be

able to analyze the performance of the J2EE Engine from the CCMS if irregularities

occur.

As default the performance trace is switched off. You usually activate it if you need to

see a request processing on module-level.




Activating Performances Traces in VA

Activate the Performance Trace in the DSR Service of VA

View the Performance Trace (DSR Trace) in TA STATTRACE

Performance Trace Activation

The performance trace can be activated in the DSR Service of the Visual Administrator.

Activate each module of which you want to measure the thread in- and out-time.

Additionally you can name a user the thread you want to see comes from.

To be able to display performance traces, you also require a central CCMS monitoring

system with a release status of SAP Web Application Server 6.40 or higher.

The transaction where the Performance trace is displayed is the STATTRACE.







• Single Activity Trace (SAT) to track a single activity runningover multiple components (Cross Component Trace)


• SQL Trace





Single Activity Trace/Cross-Component Trace


Using JARM implementation, you can analyze a single (user's) request to

find performance problems in an application or to understand the logical

processing steps inside an application.

Cross-Component Trace

Each request gets a passport that is transmitted between all involved

components. If each component writes ist own Single Activity Trace, the

whole processing can be viewed in an assembled Single Activity Trace.

Log Viewer

J2EE

6.30

Server I

LogsLogs

J2EE

6.30

Server II

LogsLogs

Request

assembly= Passport


If the JARM monitors that I’ve already introduced to you are programmed by the

developer and activated by the administrator, the whole program can be traced easily

for a single user’s request.

If the Single Activity Trace is switched on, the JARM data for this special request is

transferred to the logging API. The SAT is then displayed in the Log Viewer. With the

SAT you can analyze a single request inside an application. Each request is passed

on with a passport that shows the identity of the request. Each component a request

runs through writes a Single Activity Trace. Via this passport the SATs of thecomponents can be assembled to one cross-component Single Activity Trace.

SAT log files are displayed in a format different from general logs:

For example, the steps are displayed in hierarchical manner. You see in the structure

how deep a component is nested.









• SQL Trace





Logs vs. Traces

The administrator does regular

checks of the system via Logs.

Something wrong?

Need to see details?

In case of erroneous behaviour of the

system, Developers and Supportswitch on Traces.

Logging and Tracing – which is what?

Logs and Traces

Logs and traces are two manners of protocolling the events of your J2EE System. Logs

are usually addressed to an administrator of a customer system. All significant events

that occur on a cluster node of the J2EE Cluster are written to log files.

Traces show the details of the control flow - they are watched by developers and the

support organization. During normal operation developers and supporters are not

looking on a running system. This implies, that Traces have not to be written during

normal operation, but Logs do.




Configuration of logging and tracing - GUI

Log Configurator Serviceallows ‚on the fly‘-configuration of logs and traces

Parameters:Controllers: specify the severity to generate more or fewer log/trace messages

Formatters: change the format of the message

Destinations: change the output destination

Log Configuration

The J2EE Engine provides an easy and complex mechanism for configuring thebehavior and output of logging without having to write a Java source code. The Log

Configurator Service provides means for runtime management of the logging and

tracing configuration For example, when you want to generate more or fewer log

messages, you can change the diagnosis level they are in, like switching from error

to info, debug and so on.

Sometimes, you may also want to change the output destination or even the format of

the message. These all can be specified separately and dynamically integrated with

the program. No recompilation of the source code is necessary.

Really important is that this can also be done for Java applications. So application logs

can be configured according to your special needs.









• SQL Trace





SQL Trace via Log Configurator

The SQL Trace (Database Trace) can be activated in two ways:

1. You can switch the trace on in the Log Configurator of the Visual Administrator

•You can open the webpage http://localhost:<portnumber>/SQLTrace

...and view the traces in the Log Viewer :

SQL Trace

The SQL trace is an on demand log of all SQL statements that are issued against the

database through Native JDBC methods. The SQL trace can be switched on/off

dynamically in the administrator tool of the J2EE engine" Activating/Deactivating

SQLTrace. The log format is database independent. Besides the SQL statement text,

each log record contains information about the point in time when the statement was

executed, its duration, its input parameters and results (where applicable) as well as

certain context information (dbpool, user, etc.).

The SQL trace is especially useful for performance analysis. Mostly, performanceissues are caused by inefficient database accesses. In this case, SQL trace can be

used to show the issued SQL statements and their duration, thus helping to identify

inefficient SQL statements.




SQL Trace via Webpage „SQL Trace“

2. You can open the webpage http://localhost:<portnumber>/SQLTrace

Jump into

details

ithin SAP J2EE Engine 6.30 there are two possibilities for toggling the SQLTrace:

rst is within the Visual Administrator as you have seen on the previous slide. In the Log

Configurator Service you can toggle the SQLTrace for the current cluster node.

new set of files is generated each time the trace is switched on. Thus recent traces are availabl

for further reference. The different sets are identified by a trace ID, which consists of a time

stamp. The global trace ID additionally contains the SAP J2EE Engine cluster node ID.

he second possibility is a Web application which acts as trace viewer:

he SQLTrace Web application is pre-deployed on the SAP J2EE Engine during installation. Usin

the Web application, SQLTrace can be enabled for a selected or all cluster nodes.QL trace files are not deleted automatically. Please use the web application to clean up traces

that are no longer needed. You do this under SQL Trace File Administration.








• Logging API Trace

• SQL Trace

• Application Trace




Application Trace

Description

! The Application Trace is one of the most detailed tracing methods. It

can be switched on in case of performance problems of a single

JAVA program.

! Application Trace results are displayed in the Visual Administrator.

Functionality

! Without instrumentation effort, the application trace delivers detailed

time information on method level. It uses bytecode modification at

class loading time instead.

! No need of redeployment.

! Zero overhead, when application trace is switched off.

! External decompiler can be plugged for viewing the source code

Areas involved

! All JAVA based SAP applications.

Application Trace

The Application Trace provides application developers with a high-level, powerful tool for on-

the-fly debugging of J2EE applications. The necessity of a quick trace without having to set

up the Virtual Machine (VM) in debug mode, restart the container, or redeploy the

application is frequently proven.

Bytecode modification is used as the basis for application tracing. When an application is set

up in "bytecode-modified" mode, it is restarted and its new class loader knows that there

are changes to be made in the bytecodes. Once debugging is over, the application can be

started again in normal mode. The old classes and class loaders will be garbage-collected.

The profile-based settings of the Application Tracing Service are stored on the server and are

persistent. They can be used to tune the balance between optimizing speed and memory,

as well as to select the level of complexity of the data that is displayed.

You can use this service to trace your applications without having to do any programming

yourself. The runtime control provides you with everything you need for proper application

tracing.




Application Tracing – start in modified mode

Application Tracing (debugging) via bytecode modification

In the Application Tracing Service choose „start in modified mode“ from the contextmenue of the application you want to trace.

Click the settings button and choose a way of source code retreival and the other

setting options.




Application tracing – precise measuring of time

Microseconds

Run the application. Then you can for example view the invoked methods. The timemeasurement is in microseconds here.

If you choose „View source“ from the context menue the decompiler is displayed.

When you have finished the analysis of the trace restart the application in normal mode.

You do this again with the context menue of the application in the list on top.

sap j2ee monitoring and management for administrators[1]

Documents