Features

The Kieker framework itself is developed in Java, but also offers adapters for multiple other programming languages.


The Kieker framework itself is developed in Java, but also offers adapters for multiple other programming languages, e.g.,

  • Java
  • .NET
  • Cobol
  • Visual Basic 6 (VB6)
The Monitoring output could be persistently saved into logs or directly processed via streams using a custom or standard message protocol.

The monitoring output can be persistently saved into logs, e.g.,

  • file system (async/sync)
  • database (async/sync)

or directly processed via streams using a custom or standard message protocol, e.g.,

  • TCP (sync)
  • JMS and JMX queues (async), with current support for
    • ActiveMQ
    • HornetQ
    • OpenJMS
  • AMQP writer and reader, with current support for
    • RabbitMQ
Kieker allows to change the instrumentation at runtime – either in parts or completely.

By default, instrumentation is static. This means, at runtime, once a method or resource is instrumented, the instrumentation cannot be removed, and if a method/resource is not instrumented, it cannot be instrumented.

Kieker includes functionality to change the instrumentation at runtime, which is denoted as dynamic instrumentation. Currently, the dynamic instrumentation can be configured via JMX and periodically polled configuration files. In this way, the monitoring can be enabled/disabled in parts or completely at runtime.

Dynamic instrumentation is a prerequisite for adaptive monitoring, which aims to plan and to execute the monitoring at runtime. This allows, for instance, to make the instrumentation more detailed when a performance problem should be analyzed.

Kieker Monitoring offers multiple ways of instrumentation for control flow tracing and system-level resource monitoring.

Kieker offers multiple ways of instrumentation for control flow tracing, e.g.,

  • Manual source code insertion
  • Automatic source code insertion via Aspect-Oriented Programming (AOP), e.g.
  • AspectJ. The insertion points can be defined
    • by annotations in the source code or via
    • pointcuts in an external configuration file (aop.xml) for better seperation of concerns.
  • Middleware interception, e.g., Spring
  • Servlet
  • CXF/SOAP

and resource monitoring, e.g.,

  • Sigar or Servlet to monitor
    • CPU utilization
    • Memory usage
Kieker provides several predefined and customizable probes to instrument and monitor your target application.

Kieker provides several predefined and customizable probes to instrument and monitor your target application.
For example, there are probes which collect

  • the execution times of method invocations including their fully qualified name
  • the behavior of different threads
  • resource information, such as the CPU utilization and the memory footprint

Furthermore, it is easily possible to define custom probes, especially based on predefined probes.
For this purpose, Kieker offers a user-friendly domain specific language called the Record Instrumentation Language (see the tab “Tool Integration”).

The analysis works on collected monitoring information and also during the monitoring.

There are two different ways to start a Kieker analysis. The first is to run and to monitor the software and afterwards to start the analysis. Alternatively, it is possible to run the monitoring and the analysis simultaneous.

It is easily possible to run a predefined analysis or to build a custom analysis for your own specific use case.

It is easily possible to run a predefined analysis or to build a custom analysis for your own specific use case.
For example, Kieker provides the following predefined analyses:

  • trace reconstruction and visualization
  • anomaly detection
  • architecture discovery and visualization

Since A Kieker analysis follows the pipe-and-filter architectural style, it is therefore easy to build your own analysis based on parts of predefined analyses.

Kieker provides several predefined and customizable filters to build you own analysis.

Kieker provides several predefined and customizable filters to build you own analysis.
For example, it offers filters for trace analysis, anomaly detection, and architecture discovery.
Moreover, Kieker provides filters for associated visualizations such as call graphs and dependency graphs.
Finally, it offers the ability to define your own filter to adjust your custom analysis.

Kieker provides a set of tools which supports in analyzing the monitoring logs.

Kieker provides a set of tools which supports in analyzing the monitoring logs.
For more information, see the tab “Tool Integration”.

Kieker provides a Eclipse-Plugin for monitoring and analyzing Java projects from within the Eclipse IDE.

Kieker provides an Eclipse-Plugin for monitoring and analyzing Java projects from within the Eclipse IDE.
The monitoring part allows to instrument and run Java-projects within Eclipse.
The analysis part allows to process a Kieker log folder by a user-defined Kieker analysis.

A domain specific language to define Kieker records.

Kieker offers a user-friendly domain specific language called the Instrumentation Record Language (IRL). It is used to define records in a language-independent way. The IRL compiler (as command line or as Eclipse plugin) is then able to generate these records in arbitrary programming languages. Currently, the compiler can produce records in Java, C, and Perl. The compiler is extensible for other languages. Therefore, we provide an API based on OSGI.

abstract event AbstractExampleEntity {
    int id
    string label
}
template TemplateExample {
    boolean templateActive
}

event ExampleEntity extends AbstractEntity : TemplateExample {
   byte byteValue = 2  // default values
   transient short shortValue // value is not serialized
   changeable int intValue // value can be changed in analysis
   auto-increment long longvalue // every read to the value increments the value
   double doubleValue
   float floatValue
   char characterValue
   string stringValue
   boolean boolValue
}
Kieker’s TraceAnalysis tool allows to discover and visualize architectural information from trace information collected at runtime.

Kieker’s Trace Analysis Tool allows to reconstruct and visualize architectural representations of the monitored systems from trace information collected at runtime. Currently supported architectural representations include

  • Software architectural diagrams
    • Sequence diagrams
    • Call trees (single traces, aggregation of trace sets)
    • Dependency graphs (container-, component-, and operation-level)
  • HTML output of the reconstructed system model
  • Textual trace and trace equivalence representations
    • Execution traces
    • Message traces

Diagrams can be exported into pixel and vector graphic formats (PDF, SVG, PNG, etc.).

The TraceAnalysisTool can be used via a command line interface and a dialog-based GUI.

The Kieker Trace Diagnosis is a JavaFX-based GUI which allows the user to analyze and interact with recorded traces.

The Kieker Trace Diagnosis is a JavaFX-based GUI which allows the user to analyze and interact with recorded traces.
It reads in the desired monitoring log, analyzes it, and finally visualizes it as filterable and sortable tables and tree views.
The provided views show operation calls, such as method invocations and SQL queries, (including type name, operation name, execution time etc.) and traces both aggregated and in detail.

The Kieker WebGUI offers an interface to build and execute Kieker-based analyses.

The Kieker WebGUI is a web application to manage, assemble, and observe pipe-and-filter-based analyses of the Kieker framework, employing existing and custom Kieker filters.

 

 

Icon made by Freepik from www.flaticon.com