Kieker Observability Framework

The internal behavior of large-scale software systems cannot be determined on the basis of static (e.g., source code) analysis alone. Kieker provides complementary dynamic analysis capabilities, i.e., tracing, monitoring and analyzing a software system’s runtime behavior — enabling application performance monitoring and architecture discovery.

Detailed information about Kieker is provided at http://kieker-monitoring.net/ and its documentation site https://kieker-monitoring.readthedocs.io/en/latest/

Citation

If you use this software, please cite

• Shinhyung Yang, David Georg Reichelt, Reiner Jung, Marcel Hansson, and Wilhelm Hasselbring (2025) "The Kieker Observability Framework Version 2". In: Companion of the 16th ACM/SPEC International Conference on Performance Engineering (ICPE '25), May 5-9, 2025, Toronto, ON, Canada. https://doi.org/10.1145/3680256.3721972

• Wilhelm Hasselbring and André van Hoorn (2020) "Kieker: A monitoring framework for software engineering research". Software Impacts, 5. https://doi.org/10.1016/j.simpa.2020.100019

• André van Hoorn, Jan Waller, and Wilhelm Hasselbring (2012) "Kieker: A Framework for Application Performance Monitoring and Dynamic Software Analysis". In: 3rd joint ACM/SPEC International Conference on Performance Engineering (ICPE 2012), April 22-25, 2012, Boston, Massachusetts, USA. https://doi.org/10.1145/2188286.2188326

BibTeX entries are provides as Kieker BibTeX file

Usage

Kieker releases (stable, nightly, etc.) can be downloaded from our website's Download Section.

Documentation on how to use Kieker can be found here: Kieker Documentation

Development and Contribution

Gradle is used as the build tool. A build.gradle file is provided. From the command-line, please use the provided Gradle wrapper script, e.g., on Unix-based systems, run ./gradlew clean build -x check -x test to build without executing checks and tests.

For issue tracking and bug reports, JIRA is used at https://kieker-monitoring.atlassian.net/.

Further instructions for developers are available at https://kieker-monitoring.atlassian.net/wiki/display/DEV/

Eclipse Setup for Contributors

• Get Gradle support by installing the Eclipse plugin "Buildship: ..." in version 2 or above.
• If you have already imported Kieker in Eclipse, delete it
• Import Kieker in Eclipse by importing it as gradle project (Eclipse will also import all submodules automatically)
• Whenever you change a build.gradle file, regenerate the .project and .classpath files for Eclipse by using "Gradle->Refresh Gradle Project"

Read our Confluence pages for more information.

Code Conventions

Read and follow our code conventions

Debugging and Logging Kieker's Execution

Kieker uses the Simple Logging Facade for Java (SLF4J) to support the logging framework of your choice. In order to see or store log messages, you need to bind a logging framework at deployment time.

A fast and flexible logging framework that can be used with SLF4J is Logback. In order to use it, you have to download it and add the following Jar files to the classpath:

• logback-classic-<version>.jar
• logback-core-<version>.jar

Moreover, you have to set up a logback.xml file for configuration and add its containing folder to the classpath. An example of such a file is provided below:

<configuration>
<!-- log to console -->
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<!-- for logging to files see: https://logback.qos.ch/manual/appenders.html -->

<!-- standard log level is "warn" -->
<root level="warn">
<appender-ref ref="STDOUT" />
</root>
<!-- set log level for TCP writer down to "info" -->
<logger name="kieker.monitoring.writer.tcp" level="INFO" />
</configuration>

Logbacks official documentation provides more information on how to use and configure it.