Kieker Analysis (Tool) Migration

In the course of the migration of the old Kieker Pipe-and-Filter Architecture to TeeTime, we revise the Kieker analysis at several points. All steps of creating analysis models and work with them are now located in Kieker´s analysis component.

The following table given an overview of the new and the old analysis (tool):

	Feature	New Kieker Analysis	Old Kieker Analysis/Trace Analysis Tool
	Pipe-and-Filter framework	TeeTime	Kieker´s old internal one
	Pipe-and-Filter Configuration	Example configuration to demonstrate behavior kieker.analysisteetime.ExampleConfiguration More specific configurations have to be created	Dynamic class in the Trace Analysis Tool that creates a Configuration based on the user´s input. This class is very large
	Command Line Interface	currently not	yes
	GUI	currently not	yes
	Handling of Monitoring Records	Event Records Before, After, AfterFailed	should support all Kieker Monitoring Records
	Analysis models	Implemented with Eclipse Modeling Framework	Implemented in Java
	Statistics model	Separated to be more extendable	Statistics belong to entity
	Median as statistics property	yes, efficient implementation: insert: O(log(n) get: O(1)	no
	Statistics represented as time series	no, but some infrastructure exists	no
Traces	Creation of In-Memory Trace Models	yes	yes
	Creation of Traces/Call Trees (for Export)	Dot, GraphML, Blueprints	Dot, PDF from Dot
	Creation of Sequence Diagrams (Export)	no	Pic, PDF from Pic
	Aggregation of all traces	no (but very similar to operation dependency graphs so debatable if necessary)	Dot, PDF from Dot
	Aggregation of equal traces	yes, but currently no mapping to output formats	no
	Trace repair functionality	no	yes
	Distinction between Event and Execution Traces	no	yes
Dependency Graphs	Creation of In-Memory Model(s)	yes	yes
	Creation of Dependency Graphs (for Export)	Dot, GraphML, Blueprints	Dot, PDF from Dot
	Trace coloring	no	yes
System Model	HTML representation of System Model	no	yes
	Special treatment of assumed calls	no	yes, if desired
	Ignoring self loops	no	yes, if desired
	Selecting/Excluding of single traces and time stamps	yes	yes

The following major parts are missing for a complete replacement of the old Trace Analysis Tool:

• GUI/Command line interface
• HTML output of system model
• Sequence Diagrams

The integration of GraphViz, trace coloring, and support for other record types may also be considered as being important.

// TODO Proposal for a Webbased Trace Anaylsis Tool

Traces

Traces or call trees are trees of operation calls. They model the execution of sequential programs and, thus, start typically with a main() or Thread.run() operation.

Operation Calls

Operation calls represents an individual call of an operation (i.e., a function or method) a specific point in time. They also consist of additional information such as its execution duration or information whether its execution failed or not.

Operation calls can have "child operation calls". That are calls of operations that are called from inside this operation. In that way whole execution of a trace can be modeled.

Aggregated Traces

We aggregate traces to so called aggregated traces that are completely equal to each other. Completely equals means that they consists of the same called operations and these operations are called in the same order. The way how equivalence is defined is implemented generic and exchangeable.

Aggregated traces are currently represented as normal Traces. However, this should change in a later step and then, an own model for aggregated traces and also for their corresponding operation calls should be created.

Possible Implementation:

• Trace => Trace<OperationCall>, AggregatedTrace => Trace<AggregatedOperationCall>
• OperationCall and AggregatedOperationCall extend from AbstractOperationCall

Similiar Traces

Currently, we do not provide a method to aggregate "similiar" traces. However, this could be implemented in a later step.

Graph Export from Traces

Traces can be transformed to our graph model and then be exported to DOT, GraphML, and Blueprints.

System Model and Dependencies

The overall system model consists of system models at type level, at the assembly level, and at the deployment level.

Dependency Graphs

Using the system models, one can create dependency graphs. These graphs are by using our graph model and can then be exported to DOT, GraphML, and Blueprints.

Statistics

Statistics are not handled and stored in the model entities, but instead in a statistics model. This statistics model can be seen as a multi-dimensional map for model entities. The following sketch gives an example of such a statistics model:

•  Entity 1 (e.g., Deployment Context)
  • Response time
    • min: 25
    • max: 56
    • avg: 32
    • ...
•  Entity 2 (e.g., Component Type)
  • Response time
    • ...
  • CPU utilization
    • ...
• ...

As the example shows, the types of the entities have not necessarily be equal. And only a selected set of statistics have to be present for a given entity. 

Graph Model/Library

We developed a graph library to make the export of models as generic as possible. Therefore, we provide exporters to the DOT and the GraphML graph file format and, moreover, to a Blueprints model.

Typical Workflow: 

Transformer from Model (e.g., Trace) to Graph

Use one or more Exporter to export this graphs

Example Architecture

An example connection of the individual filters is shown in the following diagram: