Edit

Breaking changes in 1.1

Changed default data-propagation behaviour

In previous versions data collected in instrumentation rules could already be used without explicitly defining it's propagation behaviour under inspectit.instrumentation.data. However, in this case the data would be automatically down-propagated and used as a tag, which comes with a performance penalty.

To avoid unnecessary propagation and usage as tag for e.g. temporary local data, the behaviour had to be explicitly defined:

inspectit:
  instrumentation:
    data:
      temp_variable: {down-propagation: NONE, is-tag: false}

As these definitions could be easily forgotten, we changed the default behaviour of data: It now does not propagate and is not used as a tag automatically. The exception hereby is (a) if the data is a common tag or (b) the data is used as a tag in any metric definition. Common Tags default to JVM_LOCAL down propagation and being a tag. When a data_key is also used as a tag in a metric definition, it defaults to being a tag but the propagation is not affected. You can still freely override the behaviour by configuring the settings for your data under inspectit.instrumentation.data. For details see the corresponding documentation section.

This is a breaking change because your configurations might not work as expected anymore. You now have to make sure that for each data, where you expect down-propagation to take place, you add a behaviour definition:

inspectit:
  instrumentation:
    data:
      down_propagated_var: {down-propagation: JVM_LOCAL}

The change of the is-tag setting usually should not affect you, as it automatically picks up tags from the metrics definitions.

Changed metric collection configuration

In previous versions Ocelot allowed the short notation in the configuration when defining the metrics collection.

#inspectit.instrumentation.rules is omitted here
example_rule:
  #...
  exit:
    method_duration:
      #action invocation here....

  metrics:
    '[method/duration]' : method_duration

This notation is now deprecated and has to be migrated to the explicit notation:

#inspectit.instrumentation.rules is omitted here
example_rule:
  #...
  exit:
    method_duration:
      #action invocation here....
    method_name:
      #action invocation here....

  metrics:
    '[method/duration]': 
      value: method_duration
      constant-tags:
        action: checkout
      data-tags:
        method_name: method_name

This is a breaking change because your configurations might not work as expected anymore. In previous versions tags were automatically picked up from the tag context at the moment of the metric recording. The new notation allows explicit and flexible definition of constant and data tags to be collected with their associated values. Staying with the short notation means that metric recording will only include addition of the common tags and values, thus most likely breaking the expected behavior.

More information about the new notation can be found in the collecting metrics section.

Changed EUM server tag configuration

In previous versions of the EUM Server, tags derived from beacon values were specified as follows:

inspectit-eum-server:
  tags:
    beacon:
      URL: u

This has been extended with the possibility to perform regex replacements, therefore the equivalent configuration now looks as follows:

inspectit-eum-server:
  tags:
    beacon:
      URL: 
        input: u

For the details on how to perform regex replacements see the EUM server documentation.