Present State of the Instrumentation Record Language for Kieker

The instrumentation record language (IRL) is part of a model-driven instrumentation approach being developed in context of the iObserve project. The goal of this project is to forecast the behavior of cloud-based applications by simulation. The simulation utilizes the application model in conjunction with a usage profile. However, profiles defined at design time do not reflect the real system usage. Therefore, the models must be calibrated based on the observed behavior. Our model-driven instrumentation approach addresses this issue.

Since the last post on the instrumentation record language, additional requirements surfaced by analyzing all existing record structures currently included in the Kieker distribution. This lead to a more comprehensive list of language features and a more complex type system. Furthermore, properties in a few Kieker record types were found, which may either be great ideas to extend the language or reflect properties which do not belong to the record definition aspect. As no final decision has been made on those properties, they are described in the fourth section of this post to foster the discussion.

Language Features

The instrumentation record language (IRL) is a designed to represent monitoring records. Therefore, the language belongs to the domain of entity languages, such as the entity language of the JPA defined by special annotations and Java classes. However, the IRL is much more specialized for the needs of defining monitoring records. In short, the realized features are:

  • Definition of record types based on a set of primitive types and arrays.
  • A multi-inheritance typing system supporting inheritance of one parent record and additional property sets, which we call templates.
  • Default initialization of record properties, either by value or by constant.
  • Definition of constants usable during analysis.


The type system support multi-inheritance. In general this could be realized by simply specifying multiple parent structures, which would be a very clean approach. However, due to the present record structure, which is implemented in Java, we must differentiate between parent classes defining record types with properties and interfaces emulating record types with properties. Therefore, the type system provides template (type) and entity (type) to define interfaces and classes respectively.

In our type system, templates are ordered sets of properties, which may even come with initialization values, however, they are not instantiable entities for the instrumentation aspect language (IAL). Templates can inherit properties from any number of other templates, but not from entities.

Entities allow to define constants and properties and can have one parent entity where they inherit properties from. Furthermore, they can realize any number patterns. An entity can also be abstract, which means they are not instantiable in the IAL.

Properties declared in entities or templates have a primitive or array type, where arrays can have fixed or dynamic sizes. Furthermore, arbitrary data structures specified in the instrumented application can also be used as types. However, this feature alongside arrays are presently not supported by the Kieker infrastructure.

Code Generation

The generator is realized with the normal Xtext API, meaning, we have one central class defining the generator. However, to support multiple target languages, we use this central class only as a dispatcher calling dedicated generators for different languages and IRL data types.

The API for generators for different language types are described in AbstractPartialRecordTypeGenerator and AbstractRecordTypeGenerator located in the package.

Special Properties

Right now, there are three architectural properties present in the Java implementation of Kieker records, which are not covered by the language.

  1. Kieker defines interfaces to properties in multiple interfaces with the same signature. In the IRL this would imply defining a property in different patterns and all inheriting them in one entity. The type-checker of the IRL prohibits this, as it results in redefining properties. Redefining properties can make the record structure less comprehensible as two properties, declared in the same way, but with different semantics shadow one another. A user not aware of the situation will not be able to identify those cases and might use properties in the wrong way. However, there might also be pro arguments to support such multiple definitions.
  2. Only a few record types implement special operations (see #1101). These operations are only used in a few classes throughout the analysis framework and are mostly utilized in tests. Therefore, it could be argued that these methods should be moved to the filters requiring them. However, no final decision has been made on this point. Therefore, this feature is listed here.
  3. In one interface, getters are defined, which are then later implemented in a class where they realize aliases to another property emulating an alias or a renaming of properties. This can be helpful for users to understand the semantics of the properties better in certain contexts. However, it could also lead to confusion or even worse be used to change the semantics. Like the other two features, no final decision has been made.


The record language is presently only available from a git repository which can be accessed via our gitlab instance The site also includes a more precise documentation of the language and its features.