Kieker 1.7 released

Today, we released version 1.7 of our Kieker framework for application performance monitoring and dynamic software analysis: http://kieker-monitoring.net/

  • Major changes
    • Adaptive monitoring: extended set of (de)activation patterns to support adaptive monitoring for custom probes. Before: limited to (de)activate monitoring for operation signature patterns.
    • New file system writers supporting (ZIP) compression
    • Minor modifications to the Kieker.Analysis API:
      1. Removed the `register` methods. Registration now implicit by passing context information to the plugin constructors. A legacy mode for the previous API is included in this version.
      2. Analysis projects can now have properties available to the plugins.
    • Bug fixes and improvements to code, tests, documentation, examples
    • Various improvements to the WebGUI (see separate `HISTORY` file)
  • Infrastructure:
    • Kieker releases now also published via Maven Central Repository (http://search.maven.org/)
    • Completely redesigned web site: http://kieker-monitoring.net
    • Live demo at http://demo.kieker-monitoring.net

Kieker Trace Analysis Tool with GUI

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.

Kieker Trace Diagnosis

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.

Predefined and customizable filters

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.

Predefined and custom analysis

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.

Dynamic and adaptive monitoring

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.

Different monitoring outputs

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