KIEKER: CONTINUOUS MONITORING AND ON DEMANDVISUALIZATION OF JAVA SOFTWARE BEHAVIOR

Matthias Rohr, Andre van Hoorn, Jasminka Matevska, Nils Sommer,Lena Stoever, Simon Giesecke, Wilhelm Hasselbring

Software Engineering GroupUniversity of Oldenburg, Germany

ABSTRACTSoftware behavior visualizations such as UML SequenceDiagrams are valuable to continuous program comprehen-sion and analysis. This paper introduces an approach andimplementation to the continuous monitoring and on de-mand visualization of software behavior, with a focus onmulti-user Java Web applications. Our tool, called Kieker,monitors response times and control-flow for selected oper-ations of a software application. The monitoring overheadis intended to be small enough to continuously monitor aselection of operations during normal operation. Besidesmonitoring, Kieker offers the reconstruction and visualiza-tion of models of current or past software system behav-ior in terms of UML Sequence Diagrams, Markov chains,Component Dependency Graphs, Trace Timing Diagrams,as well as Execution and Message trace models.

1 Introduction

Software is often considered a black box – it is usuallynot visible what happens inside it during operation. Al-though source code specifies dynamic behavior, the readingof source code is not a fast way to program comprehension.Software behavior visualizations are often more suitable toachieve program comprehension than source code. Soft-ware design documentation should contain software behav-ior visualizations, but incomplete and outdated softwaredesign documentation is common in practice. One strategyto get up-to-date software behavior visualizations withouttime-consuming manual reverse engineering is its genera-tion from monitoring data.

Debuggers, profilers, and some reverse engineeringapproaches (e.g. [2]) allow such a behavior analysis frommonitoring data, but often have a considerable impact onthe system performance, which is not suitable for continu-ous application.

Monitoring data may be incomplete and not be repre-sentative, because only parts of the system functionality arecovered during a monitoring period or the workload to thesystem was not representative. However, software behaviorvisualizations and models generated from monitoring datacan significantly reduce the time to get an understanding ofsoftware behavior.

In this paper, we introduce our tool Kieker for the

continuous monitoring of software systems during regularoperation and on demand visualization of internal behav-ior. Moreover, Kieker creates models of current or pastsoftware system behavior in terms of UML Sequence Di-agrams, Markov chains, Component Dependency Graphs,Trace Timing Diagrams, and Message and Execution tracemodels. This provides several different perspectives to sup-port program comprehension, and analysis. Examples foranalysis tasks that benefit from runtime behavior observa-tions are failure diagnosis, performance analysis, and auto-matic system management.

We demonstrate the monitoring and visualization ca-pabilities of Kieker in a running example that uses theiBatis JPetStore1, a Java multi-user Web application thatrepresents an online shopping store.

The paper is structured as follows: Section 2 de-scribes the conceptual models and visualizations that ourtool can synthesize from monitoring data. The general ar-chitecture and monitoring strategy of Kieker is presentedin Section 3. Section 4 discusses related work, before theconclusions follow in Section 5.

2 Modeling Software Behavior

This section presents the conceptual models and their visu-alizations used to express and visualize software behavior.Furthermore, our approach to mapping monitoring data tothese models is explained.

2.1 Conceptual Model

Figure 1 illustrates the entities of our conceptual model forthe behavior of software implemented using procedural orobject-oriented programming languages such as Java. Itincludes the structural entity operation, its runtime instanceexecution, the communication entity message, and traces,which organize related executions or messages.

Operations A core concept of the above-mentioned pro-gramming languages is to encapsulate and structure sets ofinstructions into operations. The terms function and proce-dure are often used as synonyms. According to UML 2.1.1[9], we use the term operation.

1http://ibatis.apache.org/

598-173 80

Message

isCall: boolean

1 *

MessageTrace

id: int

ExecutionTrace

id: int

Execution

Sender Receiver

1 1

1..* 1..*

i: intrt: longst: long

Operationname: Stringclass: String

11..*

11..*

Figure 1. Conceptual model.

Executions An execution denotes the activity of an op-eration triggered by a call during runtime. Executionsare in a one-to-many relationship to operations. An exe-cution e is a tuple (o, i, rt, st) consisting of an operationo ∈ Operations, a response time rt, a start time st,and an identifier i, which is a number to distinguish exe-cutions of the same operation (within the same trace). Weuse the convention of writing oi to relate to the entire ex-ecution. The special execution $ denotes the caller of anexecution sequence (i.e., a user or another execution in orout of the system). Therefore, the set of all executions isExecutions := (Operations×N×N×N) ∪ {$}. Aresponse time is the amount of time elapsed between thestart and end of an execution, e.g. measured in nanosec-onds.

Execution Traces The perspective of Execution tracesfocuses on executions and does not make interactionsbetween the executions explicit. An Execution traceE = (id, (ei)n

i=1) =: (id(E), seq(E)) ∈ N ×seq(Executions) is a pair of a trace identifier and a finitesequence (i.e., an ordered multi-set) of executions. A se-quence can contain same executions multiple times. Addi-tionally, the sequence of executions has to follow a particu-lar order to satisfy the call-return semantics of synchronouscommunication: the first occurrences of executions withinan Execution trace are ordered by start times and their lastoccurrences by end times (st + rt). An example for anExecution trace is:

(1,〈$,ActionServlet.doGet(..)1,CatalogBean.viewItem(..)1,CatalogService.getItem(..)1,CatalogBean.viewItem(..)1,ActionServlet.doGet(..)1,$〉)

Messages During runtime, operations are executed uponcall messages (CallOperationAction in the UML). In con-trast to the UML, our conceptual model includes returnmessages (messages with flag isCall:=false). TheUML distinguishes synchronous and asynchronous call ac-tions [9]. The execution that is sender (caller) of a syn-chronous call messages is blocked until the receiver (callee)completes and has returned the result. The sender of anasynchronous call message immediately proceeds withoutwaiting for return values. Asynchronous operation calls re-sult in multiple concurrent execution sequences. The ap-proach in this paper does not model asynchronous call mes-

$ ActionServlet CatalogBean CatalogService

doGet(..)

viewItem(..)

getItem(..)

(a) Scenario viewItem.

$ ActionServlet CartBean CatalogService

doGet(..)

addItemToCart(..)

getItem(..)

(b) Scenario addItemToCart.

Figure 2. UML Sequence Diagrams of two traces.

sages, to avoid additional monitoring overhead. A messageis either a call or a return action between two executions.The set of all messages is Messages := {Call,Return}×Executions×Executions. (Call, ai, bj) represents ai

calling bj and (Return, bj , ai) represents bj returning to ai.Let m = (y, ai, bj) be a message. By type(m) := y

we refer to the message’s type, by snd(m) := ai toits sender, by rcv(m) := bj to its receiver. We de-fine the inverse ¬m := (¬ type(m), rcv(m), snd(m))with ¬ type(m) := Call if type(m) = Return, and¬ type(m) := Return otherwise.

Message Traces Message traces describe dynamic be-havior in terms of call and return messages between exe-cutions within an Execution trace. Message traces have theadvantage of higher readability than Execution traces butare less compact.

A Message trace M = (id, (mi)ni=1) =:

(id(M), seq(M)) ∈ N × seq(Messages) is a pair of atrace identifier and a finite sequence of messages, whichmust meet certain well formedness conditions:

1. There are no duplicate messages:∀1 ≤ i, j ≤ n : mi = mj =⇒ i = j

2. A return must follow the corresponding call:∀1 ≤ i ≤ n : type(mi) = Return =⇒(∀i < j ≤ n : mj 6= ¬mi)

The Message trace corresponding to the former Executiontrace example is:

81

(1,〈(Call, $, ActionServlet.doGet(..)), (Call, Action-Servlet.doGet(..), CatalogBean.viewItem(..)), (Call, Cata-logBean.viewItem(..), CatalogService.getItem(..)), (Return,CatalogService.getItem(..), CatalogBean.viewItem(..)), (Re-turn, CatalogBean.viewItem(..), ActionServlet.doGet(..)),(Return, ActionServlet.doGet(..), $)〉)

2.2 UML Sequence Diagrams

A widely used dynamic architectural viewpoint is given byUML Sequence Diagrams, which allow to describe the in-teractions within object-oriented software systems. A Se-quence Diagram displays structural entities (e.g., objects,or classes), their executions (ExecutionSpecifications in theUML) on the lifelines below them, as well as call actionsand returns between execution blocks.

In Kieker, a particular UML Sequence Diagram cor-responds to the class of well formed Message or equivalentExecution traces (also called scenario in other literature)that have the same “shape” – Message or Execution tracesthat only differ in response and start times but share thesame sequence of interactions result in the same SequenceDiagram. Figure 2 displays two UML Sequence Diagramsgenerated by our tool based on monitoring data from theJPetStore. Figure 2(a) visualizes both the Execution traceand Message trace example.

2.3 Markov Chains

Markov chains provide a common stochastic means to de-scribe dynamic system behavior of multiple scenarios. Forexample, Markov chains are used in intrusion detection todescribe interactions between system components, and inreliability or performance analysis to characterize the uti-lization of components during service processing. A (firstorder) Markov chain is a probabilistic finite state machinewith a dedicated entry and a dedicated exit state. Each tran-sition is weighted with a probability. The sum of probabil-ities of outgoing transitions of a state must be 1. Giventhe current state, the next state is randomly selected solelybased on the probabilities associated with the outgoingtransitions.

As illustrated in Figure 3, Kieker can generateMarkov chains from monitoring data, where the states rep-resent a creation of a message within a trace and the edgesconnect following messages. The edges are labeled withthe relative frequencies that messages follow each other.A missing edge between two messages expresses that themonitoring data analyzed contains no trace with a sub-sequence containing only these two messages.

2.4 Component Dependency Graphs

Each software system can be considered a composition ofcommunicating components. Each component can pro-vide some services while requiring external services. A

R,ActionServlet.doGet(...),$

R,CatalogService.getItem(...),

CartBean.addItemToCart(...)

R,CartBean.addItemToCart(...),

ActionServlet.doGet(...)

1.0

C,$,ActionServlet.doGet(...)

0.5

R,CatalogBean.viewItem(...),

ActionServlet.doGet(...)

R,CatalogService.getItem(...),

CatalogBean.viewItem(...)

1.0

C,CartBean.addItemToCart(...),CatalogService.getItem(...)

0.5

C,ActionServlet.doGet(...),

CartBean.addItemToCart(...)

C,CatalogBean.viewItem(...),

CatalogService.getItem(...)

C,ActionServlet.doGet(...),

CatalogBean.viewItem(...)

1.0

1.0

1.0

1.0

1.0

1.0

Figure 3. Markov chain for the two Message traces illus-trated in Figure 2.

component A is dependent on component B, iff A uses/re-quires services provided by B. Dependencies among com-ponents can be described using weighted directed depen-dency graphs. Each component is assigned a node and eachdependency relation an edge. The edge is directed from acomponent using (calling) a particular service to the com-ponent providing that service. For the illustration, we ex-tend UML Component Diagrams by including labeled de-pendencies (see examples in Figure 4). The weight of anedge denotes the amount of requests for any service pro-vided by the called component.

During runtime a system executes different scenariosand thus activates particular instances of components. Theruntime dependency graph among instances of componentsat a particular point in time contains a subset of all possibledependencies of a system. Considering the possibility ofhaving a multi-user system, we can observe a strong vary-ing usage and thus varying dependencies among instancesof components. It is feasible to also determine the staticdependency graph for the system as a sum graph from allpossible execution scenarios.

Dependency graphs are required by some approachesto runtime reconfiguration[7], and root-cause analysis.

2.5 Trace Timing Diagrams

A Trace Timing Diagram is a bar chart providing a tim-ing view on an Execution trace. The x-axis representsthe elapsed time relative to the trace start time. Bars aredrawn for each execution grouped by the related operationsaligned to the y-axis. For an Execution trace E, an op-eration o is added iff ∃i, rt, st : (o, i, rt, st) ∈ E. Lete = (o, i, rt, st) ∈ E. A box of length rt is drawn starting

82

$

ActionServlet

1.0

CatalogBean

1.0

CatalogService

1.0

(a)

$

ActionServlet

1.0

CartBean

1.0

CatalogService

1.0

(b)

$

ActionServlet

2.0

CatalogBean

1.0

CartBean

1.0

CatalogService

1.0 1.0

(c)

Figure 4. Component Dependency Graphs: 4(a)viewItem, 4(b) addItemToCart, and 4(c) for bothscenarios together.

at time st. The operations are ordered descendingly by thestart time of their first execution.

Figure 5 shows Trace Timing Diagrams for two mon-itored traces of the scenarios viewItem and addItem,the UML Sequence Diagrams of which were given in Fig-ure 2. In contrast to a Sequence Diagram, messages be-tween called and calling executions are only given implic-itly by their start and end times (indicated by the verticaldashed lines). The boxes are labeled with the responsetimes.

3 Architecture

The architecture of Kieker is displayed in Figure 6. Tp-mon monitors the software under analysis (SUA) and storesmonitoring data into a database. TpmonControl allows toconfigure during runtime, e.g enable/disable monitoring.Tpan and its plugins analyze and visualize monitoring dataon demand. In the following, we briefly discuss the moni-toring and instrumentation strategy of Tpmon, describe themonitoring overhead, and outline how Tpan analyzes andvisualizes the monitoring data.

3.1 Monitoring and Instrumentation Strategy

The instrumentation strategy aims to be non-intrusive andto realize monitoring that imposes acceptable overhead,say less than 10%, for continuous operation. Tpmon re-alizes non-intrusive instrumentation by using Aspect Ori-ented Programing (AOP) [6] in order to avoid mixing ofSUA’s source code with monitoring logic. The idea of AOPis to isolate so-called crosscutting concerns, i.e. applicationlogic that is used in many places in a software system.

We use the AOP framework AspectJ in a particularway that requires small source code modifications (JavaAnnotations) to set monitoring points, as illustrated in List-ing 1. If the AspectJ agent is activated in the Java Virtual

0 1 2 3 4 5 6

Op

era

tio

n

Time (milliseconds)

CatalogService.getItem(...)

CatalogBean.viewItem(...)

4.64

ActionServlet.doGet(...)

6.49

$

6.49

(a) Scenario viewItem.

0 2 4 6 8

Opera

tion

Time (milliseconds)

CatalogService.getItem(...)

4.49

CartBean.addItemToCart(...)

6.73

ActionServlet.doGet(...)

9.04

$

9.04

(b) Scenario addItemToCart.

Figure 5. Example Trace Timing Diagrams.

Machine that executes the SUA then the monitoring logicwill automatically instrument Java methods if they are pre-ceded by the annotation shown in Line 2 of Listing 1. As-pectJ also allows instrumentation without annotations, butsource code annotations have the advantage that the devel-opers can see and modify the monitoring instrumentationin the source code of the SUA.

Listing 1. Line 2 annotates addItemToCart().

1 ...2 @TpmonMonitoringProbe()3 public String addItemToCart() {4 ...

Tpmon directly transfers monitoring data into a database.The measurement points record timestamps at the begin-ning and at the end of executions of annotated operations.Trace identifiers connect executions belonging to the se-quence of related executions (e.g., a user request). Thecomplete data analysis is performed by Tpan on a machinedifferent from those of the SUA. This keeps the monitoringinstrumentation and its overhead relatively small.

The database schema of the monitoring data is dis-played in the Entity-relationship Diagram (Figure 7). Eachentry in the database, called monitoring record, containstwo timestamps (tin and tout) that denote the start timeand end time of an execution, and attributes that describe acontext of the measurement (experimentid, operation, ses-sionid, traceid, vmid). The attribute “operation” names theoperation that corresponds to the execution monitored, and“traceid” is unique for executions of the same trace. Java

83

<<Component>>M

M

Software System with

Monitoring Instrumentation

DatabaseM

M

M

M

M

:Tpan

:TpmonControl

:Tpmon

<<Component>>

<<Component>>

Timing Diagrams

Markov Chains

Dependency Graphs

Sequence Diagrams

:SequenceAnalysis

<<Component>>

:DependencyAnalysis

<<Component>>

:TimingAnalysis

<<Component>>

:ExecutionModelAnalysis

<<Component>>

Figure 6. Monitored system, tool chain architecture, and output artifacts.

MonitoringRecord

autoid

experimentid

operation

tin

tout

vmidsessionid

traceid

Figure 7. Database schema for the monitoring data

Web application technology provides the concept of ses-sions (monitored as “sessionid”) that connect single userrequests. The “vmid” allows to distinguish different JavaVirtual Machines.

3.2 Monitoring Overhead

In order to evaluate a possible overhead induced by Tpmon,we determined and instrumented 20 operations of the JPet-Store.The workload, generated by the load test tool JMe-ter2 extended by Markov4JMeter3, was increased during30 minute experiments up to 80 concurrent users. We re-peated this experiment several times both with Tpmon en-abled and Tpmon disabled. The median performance over-head to the server-side response times was 9.3% (averageover all request types).

3.3 Analysis and Visualization

The component Tpan computes Execution and Messagetraces from the monitoring data. The assumption of Javacall-return semantics for synchronous communication al-lows the unambiguous reconstruction of the entities of ourconceptual model (Figure 1). The Execution and Messagetraces are the input for plugins that visualize or analyze themonitoring data. So far, plugins exist to create MarkovChains and Component Dependency Graphs from one ormore traces and to create UML Sequence Diagrams andTrace Timing Diagrams from single traces. Kieker usesopen source frameworks such as UMLGraph[12], GNUplotutils4, Graphviz[3], and R5.

2http://jakarta.apache.org/jmeter/3http://markov4jmeter.sourceforge.net/4http://www.gnu.org/software/plotutils/5http://www.r-project.org/

4 Related Work

Related work covers approaches for reconstructing dy-namic behavior diagrams through monitoring; for instancein the domains of reverse engineering [2, 8, 13], profilingand debugging [4, 10, 5], and monitoring [1].

Briand et al. [2] present an approach for reverse en-gineering of distributed Java software. Similar to our ap-proach, an AOP instrumentation is used to monitor runtimebehavior and generate UML Sequence Diagrams. How-ever, the Sequence Diagrams are more detailed: all op-erations are instrumented, objects are distinguished fromclasses, conditions (e.g., “if”) and loops (e.g., “while”) areinstrumented. This increases the monitoring overhead (e.g.,more than 100% execution time). This may not be criticalto reverse engineering, but is not suitable for the continu-ous application during regular operation as intended by ourapproach. Additionally, asynchronous and remote commu-nication is supported, which is not supported by our ap-proach yet. Another related tool is given by VET [8]. Italso allows to generate Sequence Diagrams from monitor-ing data and provides a Class Association Diagram, whichis basically a matrix visualization of the Markov Chainsof our tool. Shimba [13] and its component SCED cre-ates UML Sequence Diagrams from Java monitoring data,as well. In contrast to other approaches, Shimba combinesstatic and dynamic analysis to achieve better reverse engi-neering results. It requires to execute the SUA in the de-bugger JDebugger and is not intended for continuous oper-ation. Shimba goes beyond the capabilities of our approachby providing the synthesis of state diagrams from SequenceDiagrams.

The open source projects InfraRED [4] and GlassboxInspector6 use AOP as instrumentation strategy for moni-toring timing behavior and communication in Java appli-cations, as we do. The authors of InfraRED reported thatthe performance overhead was usually between 1-5% of re-sponse times in a wide variety of enterprise Web applica-tions and up to 10% if call trees are monitored in additionto performance metrics [4]. We experienced similar per-formance overhead using the same AOP implementation

6http://www.glassbox.com

84

AspectJ. Jinsight [10] provides several views for runtimebehavior analysis and performance engineering. Results ofJinsight are now part of the commercial tool Rational Ap-plication Developer for WebSphere7 and the Eclipse Testand Performance Tools Platform8, which uses the Java Vir-tual Machine Profiling Interface (JVMPI) to allow detailedperformance analysis. Harkema et al. [5] also use the JavaProfiling Interface, which might be too slow for continuousmonitoring during regular operation [11]. However, manyprofiling tools aim to provide detailed information to sup-port debugging such that performance overhead is only asecondary requirement, in contrast to our tool.

Industrial-strength commercial products are JXIn-sight9, which provides comprehensive monitoring and vi-sualization for distributed Java applications, and the profil-ing and debugging tools OptimizeIt10, and JProbe11.

The open source tool Java Debugging Laboratory(JDLab)12[1] provides similar monitoring data such as theTpmon component of our approach and allows to createcontrol flow graphs. In contrast to our approach, the instru-mentation is performed via the Java Virtual Machine De-bugging Interface (JVMDI). Advantages of JDLab are thatno source code of the system under analysis is required andthat a GUI can be used to specify monitoring points. Apossible disadvantage of the current implementation maybe the requirement to run the Java Virtual Machine in de-bugging mode.

5 Conclusion

We presented our tool Kieker for generating visualizationsand software behavior models such as UML Sequence Di-agrams, Markov chains, Component Dependency Graphs,Trace Timing Diagrams and Message and Execution tracemodels by monitoring Java applications. The monitoringcomponent of Kieker has reasonable low monitoring over-head to allow the continuous application in multi-user JavaWeb applications. Visualizations can be generated on de-mand for single traces (e.g., user requests) or over a timeperiod. The visualizations and models created by the mon-itoring data analysis component Tpan supports comprehen-sion of software behavior and failure diagnosis, or pro-vides potential input for automatic software managementapproaches.

Future work includes to distinguish multiple objectsof the same class and object operations from class opera-tions (i.e., static methods in Java). Furthermore, we plan tointegrate efficient monitoring for remote and asynchronouscommunication, such as RMI and Web services.

7http://www.ibm.com/software/awdtools/developer/application/8http://www.eclipse.org/tptp/9http://jinspired.com/products/jxinsight

10http://www.borland.com/de/products/optimizeit/11http://www.quest.com/jprobe/12http://sourceforge.net/projects/jdlabagent

References

[1] Sergej Alekseev. Java debugging laboratory for automaticgeneration and analysis of trace data. In Wilhelm Has-selbring, editor, Proceedings of the 25th IASTED Interna-tional Multi-Conference Software Engineering, pages 177–182. ACTA, February 2007.

[2] Lionel C. Briand, Yvan Labiche, and Johanne Leduc. To-ward the reverse engineering of uml sequence diagrams fordistributed java software. IEEE Transactions on SoftwareEngineering, 32(9):642–663, September 2006.

[3] John Ellson, Emden R. Gansner, Eleftherios Koutsofios,Stephen C. North, and Gordon Woodhull. Graphviz - opensource graph drawing tools. In Graph Drawing, pages 483–484, 2001.

[4] Kamal Govindraj, Srinivasa Narayanan, Binil Thomas,Prashant Nair, and Subin P. In AOSD 2006 - Industry TrackProceedings, pages 18–30, March 2006.

[5] M. Harkema, D. Quartel, B. M. M. Gijsen, and R. D. van derMei. Performance monitoring of Java applications. In Pro-ceedings of the 3rd International Workshop on Software andPerformance (WOSP ’02), pages 114–127. ACM, 2002.

[6] Gregor Kiczales, John Lamping, Anurag Menhdhekar, ChrisMaeda, Cristina Lopes, Jean-Marc Loingtier, and John Ir-win. Aspect-oriented programming. In Proceedings Euro-pean Conference on Object-Oriented Programming, volume1241, pages 220–242. Springer, 1997.

[7] Jasminka Matevska and Wilhelm Hasselbring. A scenario-based approach to increasing service availability at runtimereconfiguration of component-based systems. In Proceed-ings of 33rd Euromicro Conference on Software Engineer-ing and Advanced Applications (SEAA), pages 137–144.IEEE, August 2007.

[8] Mike McGavin, Tim Wright, and Stuart Marshall. Visualisa-tions of execution traces (VET): an interactive plugin-basedvisualisation tool. In Proceedings of the 7th AustralasianUser interface conference (AUIC’06), pages 153–160. Aus-tralian Computer Society, Inc., 2006.

[9] Object Management Group (OMG). Unified Modeling Lan-guage: Superstructure Version 2.1.1, February 2007.

[10] Wim De Pauw, Erik Jensen, Nick Mitchell, Gary Sevitsky,John M. Vlissides, and Jeaha Yang. Visualizing the exe-cution of Java programs. In Revised Lectures on SoftwareVisualization, pages 151–162. Springer, 2002.

[11] Steven P. Reiss. Visualizing Java in action. In Proceedingsof the 2003 Symposium on Software Visualization (SoftVis’03), pages 57–65. ACM, 2003.

[12] Diomidis Spinellis. On the declarative specification of mod-els. IEEE Software, 20(2):94–96, 2003.

[13] Tarja Systa, Kai Koskimies, and Hausi Muller. Shimba: Anenvironment for reverse engineering Java software systems.Softw. Pract. Exper., 31(4):371–394, 2001.

85