1. Institute of Computer Science AGH Performance Monitoring of Java Web Service-based Applications Włodzimierz Funika, Piotr Handzlik Lechosław Trębacz Institute of Computer Science, AGH, Krakow, Poland

2. Institute of Computer Science AGH Agenda  Review of existing monitoring systems JIMS (JMX) Lemon (CERN) Mercury  Concept of a system monitoring WebServices idea (J-OMIS, OCM-G) metrics feasibility study architecture

3. Institute of Computer Science AGH Monitoring System Funcionality Monitoring of application is observing, analyzing and manipulating the execution of the application, which gives information about threads, CPU usage, memory usage, informations about methods and classes. A particular case is monitoring of distributed applications where an additional issue is the performance analysis of nodes.

4. Institute of Computer Science AGH Functional requirements  Goals monitoring Web Services distinguishing which objects are interface of WS accessing information about Web Services on a node  Communication related performance data size of SOAP message time of communication time of parsing a SOAP message  Events receive request start/end of creating/parsing SOAP message  Basis use the J-OMIS interface hold the existing functionality of J-OCM make use of experience with extending OMIS/OCM for parallel applications, grid computing and Java distributed programming.

5. Institute of Computer Science AGH JMX Infrastructure Monitoring System JIMS is a monitoring service for GRID’s, exposing the following parameters to the outside world:  CPU load,  Number of processes,  Memory usage,  Network interface utilization. It uses Java Native Interface, Java Management Extension, Dynamic Discovery Service and Web Services

6. Institute of Computer Science AGH JIMS Architecture JIMS Node JIMS Node JIMS Node Cluster User SOAP Gateway SOAP RMI

7. Institute of Computer Science AGH LEMON (CERN) Lemon is a scalable and flexible fabric monitoring system. Distributed clients launch and control local sensors, schedule measurements, collect data and send them to one or several repositories. The system provides sensors for common performance and exception monitoring. Main parts of Lemon are:  Monitoring Sensor measures data  Monitoring Sensor Agent exists on all nodes and provides transport to MR  Monitoring Repository (MR) with backend to Oracle, MySQL, flat file,…  Alarm Broker – daemon for handling exceptions and communication between alarm GUI and MR  Round Robin Database – is used to store and to manipulate data

8. Institute of Computer Science AGH Lemon architecture Alarm GUI Alarm Broker Monitoring repository backend Monitoring repository RRD Tool Framework USERS Monitoring Sensor Agent Monitoring Sensor Node

9. Institute of Computer Science AGH Lemon - Performance Monitoring  In Lemon there are several types of data: Performance metrics: CPU usage, load averages, memory us age, disk us age /performance, sockets, network, … Exceptions: High load, swap us age over 90%, service down,… Status information: Uptime, boot time, kernel version,… Heartbeat  Data is gathered with different frequencies from 60s to 1 day/on boot

10. Institute of Computer Science AGH Mercury ( GridLab ) The architecture of Mercury Monitor is based on the Grid Monitoring Architecture proposed by Global Grid Forum (GGF), and implemented in a modular way. The Mercury Monitor provides:  monitoring data as metrics,  pull and push model,  performance monitoring and steering,  monitoring of grid entities such as resources and applications,  emphasis on simplicity, efficiency, portability and low intrusiveness.

11. Institute of Computer Science AGH Mercury ( GridLab ) The input of the monitoring system consists of measurements generated by sensors. Sensors are implemented as shared objects that are dynamically loaded at run-time depending on configuration and incoming requests for different measurements. Local monitor employs a set of sensors, implemented as loadable modules, to collect information about the local node, including host status, applications, etc., and sends it to the main monitor. The monitoring service sends requests to local monitors.

12. Institute of Computer Science AGH Mercury architecture Tool MM LM Sensor node 2 Sensor LM Sensor node 1 Sensor

13. Institute of Computer Science AGH Idea Our monitoring system will be based on J-OMIS interface and its implementation, J-OCM. The work dates back to 1995 when OMIS, a monitor/tool interface specification was released. Java-bound OMIS is a monitor extension to OMIS for Java applications intended to support the development of Java distributed applications with on-line tools. J-OMIS specifies three types of services:  information (providing information about an object)  manipulation (allowing to change the state of an object)  event (trigger arbitrary actions whenever a matching event takes place)

14. Institute of Computer Science AGH J-OCM architecture Tool 1Tool 2 Node Distribution Unit Local Monitor (RMI Ext, JVM Ext) agent JVM agent JVM Node Local Monitor (RMI Ext, JVM Ext) agent JVM agent JVM Node

15. Institute of Computer Science AGH J-OCM Node Distribution Unit is part, which is still responsible for distributing requests and assembling replies. Local Monitor is a monitor process. LM’s extension provides new services defined by J-OMIS, which control Java Virtual Machine via agent. LM stores information about the target Java application’s object, such as JVMs, threads, classes, interfaces, objects, methods, etc., referred to by tokens. Agent uses JVM native interfaces such as JVM Profiler Interface, JVM Debugging Interface, Java Native Interface to access low-level mechanism for interactive monitoring of JVM.

16. Institute of Computer Science AGH Grid-enabled OMIS-based Monitor The OCM-G is a decentralized, distributed system, consists of two types of components:  Service Managers (SM)  Local Monitors (LM) SMs reside permanently, one on each site of the Grid, where are application processes to be monitored. LMs execute OMIS request accepted from SMs and send the results back. LMs handle only objects which are on the same host. The LMs use OS mechanisms to control the application processes.

17. Institute of Computer Science AGH OCM-G Monitoring Services The OCM-G provides:  Debugging services (services for suspending/continuing process, reading/writing processes’ memory, etc.)  Performance analysis services, for example: services for detecting the beginnings and ends of function calls, services for handling probes, which are used by the user to define and detect arbitrary events in an application, services for the creation and management of counters and integrators - efficient data structures which allow to buffer and preprocess monitoring information in the context of the application.

18. Institute of Computer Science AGH Components of our system It contains three kinds of components:  application monitor (AM),  node's local monitor (LM),  service monitor (SM). AM is embedded into the application (in our case Web Service or application, which use Web Services). It is used to perform monitoring activities in the context of the application. It uses JVM Tool Interface, starting with JDK 1.5, for monitoring JVM. Node's local monitor is created on each node, where there are Web Services to be monitored. LM receives requests from Service monitor and transfers this request to AM. LM sends a reply from AM to SM. Service Monitor resides permanently and exposes the monitoring services to tools.

19. Institute of Computer Science AGH Metrics Our monitoring system have t w o types of metric s :  static – for WebServices, intended for o bservation and analysis of SOAP messages sended to and from a Web Service (requests and responses) : number of WebServices on a node request time, transport time, cache access time, response time, SOAP create/parsing time, computing time size of SOAP message (sent, received) u sage ( node resources )  dynamic – oriented towards application s which use WebServices : function call, service invocation number of exceptions (errors)

20. Institute of Computer Science AGH Feasibility study To build the Web Service we use Jakarta Tomcat and Apache Axis. Jakarta Tomcat is the servlet container:  open source,  reference platform,  simplicity of use,  universal tool for deploying web applications. Apache Axis is an implementation of the SOAP protocol and enables creation of web services on Tomcat. J-OCM will be a low-level layer of the architecture extended by a special extension for web services.

21. Institute of Computer Science AGH Architecture Tools Service monitor node's local monitor Node node's local monitor AM Node WebService WebService Tomcat+Axis AM WebService Tomcat+Axis AM WebService Tomcat+Axis AM WebService Tomcat+Axis Service monitor

22. Institute of Computer Science AGH Thank You !