Release Notes

3.2

3.1

3.0

2.7

2.6

2.5

2.4

2.3

2.2

2.1

Jeyzer 3.3

Release notes :

Jeyzer Analyzer

  • Locker name is now available in the UFO stacks. (JEYZ-101)
  • Bug fix JEYZ-96 : JZR report modules sheet generation failed when handling large module exports.
  • Bug fix JEYZ-97 : Dynamic monitoring rule resolution was failing when dealing with modules.
  •  Bug fix JEYZ-98 : Dynamic monitoring rule resolution was always executed when dealing with modules and process jars (performance optimization).
  • Bug fix JEYZ-99 : Reject the multiple JFR files analysis (provided in zip file)

Jeyzer Monitor

  • Zabbix publisher enhancements (JEYZ-100)
    Host name is now available in the Zabbix input template through the $host_name variable.
    Zabbix input files can now be kept for a period of time (instead or kept forever or deleted).
    Zabbix input file is now JSON based for immediate integration in Zabbix (previous one has been renamed as zabbix_data_flat.vm).
  • Monitoring event external id support (JEYZ-94)
    Monitoring events can now expose an external id for better display.
    This external id is unique in the scope of the current monitoring session or of the current JZR report generation.
    In standard, monitoring events do have a unique id (“Id”) composed of multiple key elements (time, rule, context..), not suitable for display.
    Use the “ExtId” attribute to reference it in the publisher templates.
    JZR report : use the “event_ext_id” to display it in the Sequence Monitoring sheet headers.
  • Operation and contention type support on the long running task events (JEYZ-95)
    The Zabbix zabbix_data.vm template is now exposing those events.
  • Contention type and high process CPU monitoring rule added (JEYZ-102)
    If the process CPU percentage is higher than given value respectively and some contention type is detected, generate event.

Jeyzer Demos

  • The Contention type and high process CPU monitoring rule is now supported inside the demos (JEYZ-102)

Jeyzer base repository

  • JMC master profile added
  • Dropwizard shared profile added
  • Micrometer shared profile added
  • Night Config shared profile added
  • Releases shared profile added
  • RocksDB shared profile added
  • Solr shared profile added
  • Spark shared profile added
  • Strati shared profile added
  • Truffle shared profile added

Upgrade instructions (Zabbix)

Zabbix setup : in the zabbit_setup.xml, replace the keep boolean value with a duration (hours, minutes).
ex : <input_file storage_directory=”${JEYZER_RECORD_DIRECTORY}/monitor/zabbix-inputs” keep=”48h”/>

Jeyzer 3.2

Release notes :

Jeyzer Analyzer

  • Advanced virtual thread analysis (JEYZ-93)
    Advanced virtual thread format is obtained with the Jeyzer Recorder Agent through the advancedmxvtagent method (JEYZ-92).
    Recording method features are now summarized here :
    Recording methodVT detectionVT visibleVT countVT CPU usageStandard MX figures
    JZR VT recorderyesyesyesyesyes
    JCMDyesyesyesnono
    JFRyesnorelativeyesyes
    JZR recorderyesnonoyesyes

    The Jeyzer virtual thread agent recording (JEYZ-87) can also be analyzed like any Jcmd recording.
    JZR report : headers can reference this format using the Advanced VT Agent category.

  • Contention types are now available in the UFO stacks. (JEYZ-89)
  • Bug fix JEYZ-88 : Repository URLs were invalid for the dynamic shared loading of profiles.

Jeyzer Monitor

  • Zabbix sender publisher support (JEYZ-86)
    Monitoring events can now be published to any Zabbix server.
    It requires to setup a Zabbix trapper on server side and install the zabbix_sender executable on the client side.
    The Jeyzer Monitor will call the Zabbix sender to publish the monitoring events through an input file (key value pairs).
    There must be at least one monitoring event to trigger the sending because Zabbix does not process empty input content.
    The input file is templatized with the zabbix_data.vm where the published event info can be fine tuned.
    Input files can be archived for debugging purposes in the JEYZER_RECORD_DIRECTORY/monitor/zabbix-inputs
    Events are published within a Zabbix “host” scope, which represents the server to monitor in Zabbix.
    The Zabbix “host” is defined through the JEYZER_TARGET_NAME environment variable (Jeyzer “host” scope).
    The Zabbix publisher configuration is defined in the zabbix_setup.xml file.
    The Jeyzer installer permits to activate and configure the Zabbix connection details.
    Zabbix connection details can also refer to environment variables.
    Edit then the zabbix_setup.xml to activate it and include it in your master profile.
    Those 4 environment variables could be set externally :
      ZABBIX_SENDER_PATH : Zabbix_sender executable path
      ZABBIX_HOST and ZABBIX_PORT : Zabbix connection details
      ZABBIX_SOURCE_IP : the Zabbix client IP address
    The JEYZER_MONITOR_ZABBIX_ENABLED environment variable permits to activate the publisher.
  • Trigger limit added on the contention type, function and operation global percentage rules. (JEYZ-90)
    There must be at least 50 active stacks in the recording to activate the rules.

Jeyzer Analyzer Web server

  • Bug fix JEYZ-91 : Display translator progress status messages only when applicable

Jeyzer Recorder Agent

  • Advanced virtual thread capture support (JEYZ-92)
    Captures also the process and system MX figures : CPU, memory, garbage collection…
    Configurable with the Jeyzer installer.
    To activate it manually, set the JEYZER_RECORD_DUMP_METHOD environment variable to advancedmxvtagent or edit the agent jeyzer-record.properties configuration file to set the jeyzer-record.JEYZER_RECORD_DUMP_METHOD.
    The dump format can be either txt (default) or JSON. The format can be changed in the standard_generation.xml : <advancedmxvtagent format=”txt”/>
    Technically, the virtual thread file dump action is called through the VM diagnostic mbean.
    Requires Java 21.

  • Virtual thread capture support (JEYZ-87)
    To activate it manually, set the JEYZER_RECORD_DUMP_METHOD environment variable to jcmd or edit the agent jeyzer-record.properties configuration file to set the jeyzer-record.JEYZER_RECORD_DUMP_METHOD.
    The dump format can be either txt (default) or JSON. The format can be changed in the standard_generation.xml : <jcmd format=”txt”/>
    Technically, the jcmd file dump action is called through the VM diagnostic mbean.
    The process card gets also generated.
    Requires Java 21.

Jeyzer Installers

  • The Zabbix publisher is now configurable. By default disabled. (JEYZ-86)
  • The Jeyzer Recorder Agent method (standard or advancedmxvtagent) is now configurable when the Jeyzer Recorder Agent is selected. (JEYZ-92)

Jeyzer Demos

  • The Virtual Threads demo now generates a Jeyzer advanced virtual thread recording. (JEYZ-92)
  • The Virtual Threads demo includes an additional test to cover the method synchronization through virtual threads.

Jeyzer base repository

  • Apache-HTTP-components shared profile added
  • AppDynamics shared profile added
  • Atmosphere shared profile added
  • Batik shared profile added
  • Datadog shared profile added
  • Derby shared profile added
  • Ehcache shared profile added
  • Elastic shared profile added
  • dnsjava shared profile added
  • Flink shared profile added
  • Hazelcast shared profile added
  • Infinispan shared profile added
  • Jolokia shared profile added
  • MapDB shared profile added
  • New Relic shared profile added
  • XNIO shared profile added

Jeyzer 3.1

Release notes :

Jeyzer Analyzer

  • Java 21 LTS support (JEYZ-85)
    Certified on the Amazon-correto jdk 21
    Tested on Oracle OpenJDK 21.0.0_35 and Azul zulu 21.
    The Docker distribution of Jeyzer is now running with the Amazon-correto 21 image.
  • Virtual thread analysis support (JEYZ-81)
    Virtual threads have been introduced in Java 17 and rolled out in Java 21 LTS.
    See JEP-425 for more details and https://docs.oracle.com/en/java/javase/20/core/virtual-threads.html.Jeyzer is supporting this new dimension and therefore permits to :
    – Display it in a convenient way by grouping the virtual threads having the same stack trace. That way, the unmounted threads are easily displayed.
    – Generate alerts (monitoring events) on the number of generated virtual threads as well as on on the virtual thread CPU usage.
    – Compute statistics, histograms and percentage calculations taking into account the the virtual thread related data (function, operation, count..)
    In Java, the standard exposure of virtual threads is still poor at this stage :
    – JCMD is the only tool that captures the virtual thread stacks as part of a file thread dump. But it is missing any other information such as the thread state and lock information.
    – JFR exposes virtual thread creation and termination events which gives an indication on the number of virtual threads.
    Virtual threads rely on native carrier threads which are always visible whatever the recording method : it gives an indication on the virtual thread usage. As well, it also permits to measure the CPU virtual thread usage when the recording method supports it.
    Recording method features are summarized here :
    Recording methodVT detectionVT visibleVT countVT CPU usage
    JCMDyesyesyesno
    JFRyesnorelativeyes
    JZR recorderyesnonoyes

    Changes in Jeyzer are :
    1. The Session details indicates if virtual threads are used and if those are visible (JCMD) or not (JFR, Jeyzer Recorder agent).
    2. The thread states “VT carrier” and “VT unmounted” have been introduced :
        The VT carrier state permits to identify native threads that carry virtual threads.
        The VT unmounted state permits to identify virtual threads that are currently dismounted.
    3. The task sequence sheet supports new headers (see the Charts one) :
           Native thread counter
           Virtual thread counter. Requires JCMD or JFR. In the case of JFR, value is relative as it may not reflect the reality if virtual threads were started before the recording
           Virtual thread created counter. Requires JFR. This reflects the count of jdk.VirtualThreadStart events
           Virtual thread terminated counter. Requires JFR. This reflects the count of jdk.VirtualThreadEnd events
           Virtual thread diff. Requires JFR. Counter difference of virtual threads since the last recording snapshot (or recording start time)
           Virtual thread pinned counter. Requires JFR. This reflects the count of jdk.VirtualThreadPinned events
           Virtual thread mounted counter. Requires JFR, JCMD or Jeyzer Recorder Agent
           Virtual thread CPU usage in percentage. Requires JFR or Jeyzer Recorder Agent
    Note that the existing Thread Counter header displays now the total number of native and virtual threads.
    4. The task sequence sheet supports the new row headers :
           Action stack size : includes the count of unmounted virtual threads
           Thread type : indicates if the thread is native, virtual, virtual unmounted or native carrier
    5. The task sequence sheet cells indicates the number of unmounted virtual threads as prefix
    The JFC configuration provided in standard now contains the capture of creation, pinned and termination events.
    Source JFR events index : https://sap.github.io/SapMachine/jfrevents/index.html

  • JCMD thread dump parser added (JEYZ-83)
    The JCMD thread dump parsing (txt and JSON formats) is now possible.
    JCMD thread dumps do contain only stacks and thread names. However, thread dumps can contain all the virtual threads (mounted or not).
    As the thread states are not available, the “Unknown” thread state has been introduced.
    PS1: JSON parsing seems less reliable than the txt one as very few virtual threads get captured in the first case.
    PS2 : the JCMD thread dump file feature has been introduced after Java 17. It is performed with the following command :
    > jcmd Thread.dump_to_file -format=<json|txt>
    The JCMD thread dump is time stamped using the local time zone.
  • JZR Report : Thread memory headers are now available in the Task Sequence sheets (JEYZ-84)
    3 headers have been added to measure approximatively the thread memory consumption :
        Thread memory : sum in Mb of the native and virtual thread memory consumption. Requires JCMD (virtual thread presence).
        Native thread memory : it is assumed to be around 2 Mb per thread
        Virtual thread memory : it is assumed to be around 1 Mb per thread. Requires JCMD (virtual thread presence).
    Headers are exposed in the Charts task sequence sheet.
  • JZR Report : Hiatus and Restart columns are now linked between them in the Task Sequence and Task Group Sequence sheets (JEYZ-75)
    User can move forward by clicking on the links which are located on the top time line.
    Feature can be disabled in the default_setup.xml :
  • The process card sheet now wrap the values for better display and hides the categories containing only unavailable values (JEYZ-79)
  • Bug fix JEYZ-74 : Repository URLs were invalid for the dynamic shared loading of profiles
  • Bug fix JEYZ-76 : Long graph display generates Excel repair warnings when its size exceeds 1100 cells
  • Bug fix JEYZ-78 : Jar files with “release” or “final” term in their file name were not identified as release versions

Jeyzer Monitor

  • Java 21 LTS support (JEYZ-85)
  • Virtual thread leak monitoring rule added (JEYZ-81)
    If unmounted virtual threads are visible for long time, generate the Virtual thread leak suspicion event.
    The leak here could be real one (especially if never released) or reflects a very long interaction that did unmount it originally.
  • Virtual thread presence monitoring rule added (JEYZ-81)
    If virtual threads are detected, generate the Virtual threads detected event.
    Initially provided to provide insights on the points to monitor (memory and CPU for virtual threads), it could also be used
    to provide recommendations on the Java version that provide a stable implementation of virtual threads.
  • Global virtual thread limit monitoring rule added (JEYZ-81)
    If global number of virtual threads is greater or equal to given value, generate the Global virtual thread limit reached event.
  • Virtual threads CPU consuming monitoring rule added (JEYZ-81) : it permits to detect high CPU usage at virtual thread level.
    If virtual thread CPU % is greater or equal to given value, generate the Virtual threads high CPU usage event.
  • Executor presence monitoring rule added (JEYZ-82)
    If the given executor is detected across current session, generate the Executor Presence event.
  • New standard monitoring rules :
    2 process card rules have been added to detect the virtual thread usage and visibility (JEYZ-81)

Jeyzer Analyzer Web server

  • Java 21 LTS support (JEYZ-85)
  • Improve the end user notification when zip recording is password protected (JEYZ-80)
  • Bug fix JEYZ-77 : Disable the enter key shortcut to prevent load warning message when filling the issue description field

Jeyzer Recorder

  • Java 21 LTS support (JEYZ-85)
  • To capture periodically the virtual threads, the jcmd-periodic.bat script is now provided (JEYZ-81)
    JDK 21+ is required to execute it.

Jeyzer Demos

  • Java 21 LTS support (JEYZ-85)
  • The Virtual Threads demo has been added to demonstrate the Jeyzer capabilities on the Java virtual threads.
        ThousandsVirtualThreads shows the unmounted virtual threads sleeping.
        ThousandsVirtualThreadsCPU shows the unmounted and running virtual threads sleeping.
        ClassicalSynchronization shows the synchronization handling in the virtual threads.
        ReentrantLockSequence shows the recommended locking way in the virtual threads.
        ReentrantLockDeadlockSequence shows the deadlock case of a virtual thread and a native one.
        ImageDownloader2 shows the unmounted virtual threads waiting for IO while downloading images from a remote server. Native side is also provided for time comparison with a 100 threads pool. Virtual side is performed twice using the Executors and StructuredTaskScope instanciators.
    Virtual threads demo comes up with a dedicated master profile and recording profile.
    It requires Java 17+ to be executed : the startup script must be updated with the right JDK/JRE.
  • The Executor presence monitoring rule is now supported inside the demos (JEYZ-82)

Jeyzer base repository

  • Atomikos shared profile added
  • Cache2k shared profile added
  • JNA shared profile added
  • OpenTelemetry shared profile added
  • Smooks shared profile added

Jeyzer 3.0

Release notes :

Jeyzer Analyzer

  • Analyzer is now open source, under Mozilla Public License 2.0.
  • Unix open file descriptors support (JEYZ-68)
    Open file descriptors are now supported in standard (JZR recordings only, issued from Unix).
    The number of open file descriptors and the open file descriptor usage can now be displayed in the sheet headers (see the Charts one).
    The open file descriptor usage is a percentage based on the max file descriptors limit (which is user specific. See ulimit -n).
    The max file descriptors limit is now also displayed in the property card sheet.
  • UFO stacks : provide an exclude pattern on small stacks (JEYZ-61)
  • Recordings can now be provided as gzip only. Previously, gzip recordings had to contain a tar file. (JEYZ-71)
  • Bug fix JEYZ-59 : JFR – parsing failed on missing jvmStartTime
  • Bug fix JEYZ-62 : Failed to parse tar files containing directories
  • Bug fix JEYZ-63 : Jstack and JstackHung parsers could provide invalid lock class names
  • Bug fix JEYZ-70 : Upon JZR recording analysis, ensure the full isolation of the 2ndary recording files when the analysis translators are configured to keep the intermediate files
  • Bug fix JEYZ-73 : JZR report generation fails when property card value size exceeds the max cell limit (32767 chars)

Jeyzer Monitor

  •  Monitor is now open source, under Mozilla Public License 2.0.
  • Shared profile monitoring rule added (JEYZ-72)
    If the given shared profile is detected, generate the Shared profile event.
    Recommended usage : deprecated library detection.           
  • Open file descriptor number monitoring rule added (JEYZ-69)
    If the number of open file descriptors is larger than a given value, generate the High open file descriptor number event.
    Valid only on Unix. Applies only on JZR recordings.
  • Open file descriptor percentage monitoring rule added (JEYZ-69)
    If the percentage of open file descriptors (based on the max file descriptor limit) is larger than a given value, generate the High open file descriptor usage event.
    Valid only on Unix. Applies only on JZR recordings.
  • The max file descriptor limit is now checked through a property card number rule.
    Valid only on Unix. Applies only on JZR recordings.
  • Contention type presence monitoring rule added (JEYZ-64)
    If the contention type is detected across current session, generate the Contention type presence event.
  • Quiet activity monitoring rule added (JEYZ-65)
    If there is no detected action, with the exception of principal functions (ex: JFR background activity) defined with the given pattern, generate the Quiet activity event.
  • Rule blocker sticker added (JEYZ-66)
    This is a new type of stickers which permit to disable a monitoring rule.
    It is interesting when overriding standard monitoring rules with more elaborated ones.
    One could also disable any standard rule that would not be suitable.
    The blocker rule sticker must simply be created by declaring a rule-block-<rule reference> in any sticker list.
    Example : rule-block-JZR-STD-015
    To test it, add it to the JEYZER_MONITOR_ANALYZER_STICKERS variable.
    To industrialize it, create your own list of stickers in the monitoring configuration and/or related sheets.
    <sticker_set list=”rule-block-JZR-STD-015, rule-block-JZR-STD-019″ group=”blockers”/>

Jeyzer Analyzer Web server

  • Security : Tomcat upgrade from 9.0.41 to 9.0.73
  • Bug fix JEYZ-60 : Upon empty recording file analysis, end user was not getting a relevant error message

Jeyzer Recorder

  • Unix open file descriptors support (JEYZ-68)
  • Bug fix JEYZ-67 : Jeyzer Recorder logging layer conflicted with the Jboss JUL logging manager

Jeyzer base repository

  • Artemis (AMQ 7) master profile added
  • Hive Server 2 (HS2) master profile added
  • IntelliJ master profile added
  • VMWare VCloud Director master profile added
  • Adobe shared profile added           
  • Artemis shared profile added
  • Byte Buddy shared profile added
  • ClassGraph shared profile added
  • Curator shared profile added
  • Felix shared profile added
  • Jaeger shared profile added
  • Jedis shared profile added
  • Jgit shared profile added
  • Joda shared profile added
  • JProfiler shared profile added
  • Kafka shared profile added
  • Karaf shared profile added
  • Kotlinx shared profile added
  • LMAX shared profile added
  • Okio shared profile added
  • Pax web shared profile added
  • Rabbit MQ shared profile added
  • Reactor shared profile added
  • Sling shared profile added
  • Vert.X shared profile added
  • ZMQ shared profile added
  • ZooKeeper shared profile added
  • Deprecation monitoring rules added in the Protomatter, NanoHTTPD, Lingo, jTDS, Jakarta Oro, JacORB, Joda and Jaeger shared profiles (JEYZ-72)

Jeyzer 2.7

Release notes :

Jeyzer Analyzer

  • Java 17 LTS support (JEYZ-58)
    Certified on the Amazon-correto jdk 17.0.4_8
    Tested on Oracle OpenJDK 17.0.2 and Azul 17.0.4.
    The Docker distribution of Jeyzer is now running with the Amazon-correto 17 image.
  • Serial garbage collector support (JEYZ-46)
    Serial garbage collector is now supported in standard (JFR and JZR) as it can be used on single processor machines or small VMs/containers.
    Limitation : JFR does not provide the associated memory pool figures (unlike the Jeyzer Recorder).
  • Locker rule priority increased to improve the automatic filtering (JEYZ-52)
  • The process card sheet now displays the GC old and young names (JEYZ-48)
  • The Session Info sheet displays now the list of matching shared profiles (JEYZ-55)
  • The JVM Flags sheet automatically hides the Default flags (JEYZ-56)
    The auto_filter_default_flags in the JVM Flags sheet configuration (jvm-flags.xml) permits to disable it :
  • The Top stacks sheet displays now the executor (JEYZ-54)
  • GC old and young names are now exposed as process card properties : jzr.analysis.gc.old.name and jzr.analysis.gc.young.name (JEYZ-48)
  • Bug fix JEYZ-43 : Capture time (duration) usage on the JRockit parser was used as a time stamp
  • Bug fix JEYZ-45 : Menu sheet displayed an invalid counter for the Task sequence group sheet
  • Bug fix JEYZ-49 : CPU Runnable vs CPU capacity monitoring rule did not manage the JFR CPU count
  • Bug fix JEYZ-50 : Jrockit parsing failed on variant
  • Bug fix JEYZ-51 : Invalid zip file error handling improved
  • Bug fix JEYZ-53 : JFR – thread events can be null
  • Bug fix JEYZ-57 : JFR – parsing failed on unexpected duplicate JFR thread events. Those duplicate events are now ignored.

Jeyzer Analyzer Web server

  • Java 17 LTS support (JEYZ-58)
  • JEYZ-44 : JFR 0.9 version -> emit warning with proper solution proposals when Java 8 (old) or 7 are used

Jeyzer Monitor

  • Java 17 LTS support (JEYZ-58)
  • New system monitoring rule : Garbage collector name (JEYZ-47)
    If the garbage collector (old or new) has of the given rule name, generate an event.
  • New standard monitoring rules :
    3 rules have been added to detect the serial GC usage (command line parameter, JVM flag and garbage collector type)

Jeyzer Recorder

  • Java 17 LTS support (JEYZ-58)
  • Serial garbage collector support (JEYZ-46)

Jeyzer Demos

  • Java 17 LTS support (JEYZ-58)
  • Serial garbage collector support (JEYZ-46)
  • The Garbage collector name rule is now supported inside the labor demo (JEYZ-47)

Jeyzer base repository

  • Apache HTTP client shared profile added
  • Apache HTTP core shared profile added
  • Apache openejb shared profile added
  • AWS shared profile added
  • Azure shared profile added
  • Bouncy castle shared profile added
  • Eclipse shared profile added
  • GraalVM shared profile added
  • IntelliJ shared profile added
  • Jackson shared profile added
  • Jodd-HTTP shared profile added
  • Latency utils shared profile added
  • Log4j rules added (CVE-2021-44228 detection)
  • MongoDB shared profile added
  • MSSQL shared profile added
  • Pulsar shared profile added
  • Qpid shared profile added
  • Quarkus shared profile added
  • Synapse shared profile added

Upgrade instructions (optional)

  • JZR report configuration for the JVM Flags sheet, if you did customize the jvm-flags.xml.
    To filter the large set of Default JVM parameters when the sheet is accessed, add the auto_filter_default_flags=”true” to the node.

Jeyzer 2.6

Release notes :

Jeyzer Analyzer

  • Automatic loading of master profiles (JEYZ-39)
    This new functionality permits to dynamically load a master profile based on a remarkable pattern found in the recording.
    In practice, the analysis is started using the generic profile in the Jeyzer Web Analyzer and will end up by generating the JZR report using the right applicative profile.
    This new functionality is possible thanks to the profile redirection mechanism : a generic profile (such as Portal) will usually provide the profile redirection
    while the applicative profiles (ex : AMQ) will provide one or several remarkable patterns.
    Those remarkable patterns are typically application package or class unique names (ex for AMQ : org.apache.activemq.console.Main).
    The master profile redirection is optional. If not defined, the current master profile cannot participate in a profile redirection process.
    The master profile redirection is only supported by the Jeyzer Web Analyzer.
    The JZR Session details sheet indicates if the profile redirection occured by providing the initial generic profile name and final applicative profile name.
    To support the profile redirection mechanism, add the following entry in the <profile>_analysis.xml in your generic profile :
    <analysis>
    <discovery>
    <profile_redirection enabled=”true”>
    To declare the remarkable patterns of an application, add the following entry in the <profile>_analysis.xml in your applicative profile :
    <analysis>
    <discovery>
    <profile_redirection>
    <id_patterns>
    <id_pattern value=”org.my_application”/>
    As part of this implementation, the existing discovery mode has been renamed as discovery rules and moved within the discovery configuration section :
    <analysis>
    <discovery>
    <discovery_rules enabled=”true”/>
    The discovery_mode section is however still supported as part of the backward compatibility.
  • JZR report : group sequence sheet (JEYZ-38)
    The group sequence sheet focuses on similar stacks and is therefore very useful when dealing with large multi-threaded/asynchronous based applications.
    Each group of similar stacks will have its own cell in the report for a given recording snapshot.
    When a group is observed on consecutive recording snapshots, the related cells get displayed on the same line : it constitutes a group action.
    The group sequence sheet is a new type of sheet inspired from the sequence sheet and therefore follows the same configuration structure.
    To display it, add the <sheet sheet_config_file=”${JEYZER_ANALYZER_CONFIG_DIR}/report/sheet/group-sequence/group-sequence-stack-groups.xml”/> in your JZR report configuration.
    To accomodate the display, new row headers and cell attributes have been created :
    Row header
    group_id : displays the group action id.
    group_size : displays the total number of stacks within the group action.
    Cell attribute
    group_size : displays the stack group size. Example : x25
    Group sequence sheets do not support freeze, CPU, memory and MX attributes as those do not make sense.
  • JFR analysis support extended (JEYZ-31)
    JFR can now be provided as zip file.
  • Analysis stack ordering support (JEYZ-36)
    It is now possible to sort the stacks in the analysis by thread name, thread id or recording appearance (original behavior).
    The sorting key (thread_name, thread_id or recording) can be specified in the analysis profile (<profile>_analysis.xml) :
    <thread_stack>
    <sorting key=”thread_name”/>
    If not available, the sorting key is defined in the default setup (default_setup.xml) which is thread_id.
  • The Task sequence lock_state cell rule is now displaying the class name on which the lock is put on. (JEYZ-33)
    It is appended at the end of the lock information, in lower font size.
  • Instana file format analysis support (JEYZ-32)
  • Bug fix JEYZ-35 : Task sequence default sorting was done in reverse order
  • Bug fix JEYZ-40 : JZR recording parsing failed when the analysis profile contains a txt file regex pattern
  • Bug fix JEYZ-41 : Failed to generate the Action distinct profiling sheet due to comparison violation error
  • Bug fix JEYZ-42 : The daylight saving time was incorrectly handled in the monitoring event time display

Jeyzer Analyzer Web server

  • Automatic loading of master profiles (JEYZ-39, see Jeyzer Analyzer).
    The profile redirection applies on the master profile repositories accessed by the Jeyzer Analyzer Web server,
    assuming those master profiles are configured correctly.
  • Improve the end user notification when recording contains no parseable files (JEYZ-37)
    Make the notification as a warning instead of error, and list the supported file formats.

Jeyzer Monitor

  • New system monitoring rule : Recording size
    If the number of recording snapshots (thread dumps) is larger or lower than the specified threshold, generate an event. (JEYZ-34)
    A default standard rule has been added to emit an info message to recommend going for a proper periodic recording instead of single thread dump.
  • New standard monitoring rule stickers :
    Environment : Java agent presence, windows service, debugging in progress..
    Analysis : recording size..

Jeyzer Recorder

  • Nothing new
    PS : the Jeyzer Recorder installer has been updated to ship the 2.6 version of the Jeyzer demos (as below)

Jeyzer Demos

  • The Demo features MX provides now remarkable patterns for the profile redirection (JEYZ-39)
  • The Recording size monitoring rule is now supported inside the demos (JEYZ-34)

Jeyzer Base repository

  • Automatic loading of master profiles (JEYZ-39) :
    – The Portal generic profile supports the profile redirection.
    – All base production master profiles do provide now remarkable patterns for the profile redirection.
  • Daml master profile added
  • Hybris (SAP product) master profile added
  • Postgresql shared profile added
  • Logback shared profile added
  • Instana (Java agent) shared profile added
  • Tanuki shared profile added

Upgrade instructions (optional)

  • Profile redirection :
    Update the <application>_analysis.xml file of your generic master profiles to add the profile redirection (as indicated above).
    Verification : generate a JZR report, in the Session info / Analysis section, check that the Master profile discovery field is set to active.
    Update the <application>_analysis.xml file of your application master profiles to add the remarkable patterns (as indicated above).
    Verification : generate a JZR report using a master profile configured for the profile redirection (like the Portal one).
    In the Session info, check that the Redirected master profile field is set with the application master profile.
    Update all the <application>_analysis.xml files to handle the discovery mode configuration declaration change (as indicated above).
  • Group sequence sheet
    Add the group sequence sheet to your JZR report definitions (as indicated above).
    Verification : generate a JZR report and check that the Stack groups sheet is now available.

Jeyzer 2.5

Release notes :

Jeyzer Analyzer

  • Display time zone support
    JZR report and all other communication media (JIRA, email, loggers and web) allow to display the time stamps in a time zone different from the recording one.
    This is particularly useful to correlate the detected events with applicative logs or end user feedbacks which are based on another time zone.
    This is also interesting with Java Flight Recordings as those are always in UTC time (although Jeyzer can use – through configuration – the process or a custom time zone as an alternative. See below).
    The display time zone can be specified through the Jeyzer Web Analyzer interface (see hereafter) when generating the JZR report and through the analysis profile configuration.
    In the JZR report, the time zone source will then be set respectively with either “user selected” or “profile”.
    If not specified, the recording time zone is taken if available (which is always the case for the JFR and JZR recordings) : time zone source will remain the recording one.
    If the recording time zone is not available, the local time zone is taken.
    The display time zone in the profile configuration is defined in the <application>_analysis.xml file :
    <time_zones>
    <!– Drives the date display in reports and other outputs. Optional –>
    <display_time_zone id=”${JEYZER_DISPLAY_TIME_ZONE_ID}”/>
    Time zones ids are Java ones (see bottom note)
  • JVM flags analysis support
    JZR report – the JVM Flags sheet lists all the JVM flag attributes : name, value, previous value, change date, origin (Default, Command line..) and type.
    Every field can be filtered. Lines which have a non default origin are highlighted.
    To display it, add the <sheet sheet_config_file=”${JEYZER_ANALYZER_CONFIG_DIR}/report/sheet/jvm-flags/jvm-flags.xml”/> in your JZR report configuration.
    The JVM Flags sheet will be displayed only if the recording (JZR or JFR) contains the JVM flags information.
    JVM flag monitoring
    Monitoring rules can be applied over the JVM flags to detect some specific value/pattern, compare numeric values or detect the absence of a flag.
    Those rules are the process card ones : Process card property pattern, Process card property number and Process card property absence.
    The JVM flag to monitor must be prefixed with “jzr.jdk.flag.”. Example : jzr.jdk.flag.HeapDumpBeforeFullGC
    Every Jeyzer analysis now includes a default set of JVM flag rules stored in the                               ${JEYZER_ANALYZER_CONFIG_DIR}/monitor/rules/jvm_flag_rules.xml
  • JFR analysis support extended
    Analysis time zone is now flexible. It can be either one of these sources :
    – Process : the time zone will be issued from the user.timezone (if available in the JFR recording)
    – JFR : the time zone will be UTC which is the JFR standard one
    – Custom : the time zone will be the one defined by configuration (custom attribute) which is a Java time zone id (see bottom note).
    By default, the process source is selected.
    If the time zone is not found or invalid, the analysis will default on the JFR one.
    As a consequence the JZR report will display the time zone source as “process” or “JFR” or “Custom”.
    The time zone configuration is defined in the jfr_uncompress.xml file :
    <time_zone source=”process” custom=”EST”/>
    JVM flags information is now parsed and analyzed.
    Openjdk 8 is now supported. Minimum version is 8u282+
  • Recording time zone specification
    When not available in th recording (typically when analysing a set of thread dumps), the recording time zone can be defaulted through the Jeyzer Web Analyzer interface (see hereafter) when generating the JZR report and through the analysis profile configuration.
    The recording time zone in the profile configuration is defined in the <application>_analysis.xml file :
    <time_zones>
    <!– Default recording time zone if not available in the recording. Optional –>
    <recording_time_zone id=”${JEYZER_RECORDING_TIME_ZONE_ID}”/>
    Time zones ids are Java ones (see bottom note).
    The recording time zone source will be set to “profile”.
  • The Session Details is now listing the display and recording time zones and sources, as well as the start and end date in both time zones.
  • TDA file analysis support (files suffixed with .tda containing only stacks in a jstack 1.5 style)
  • The Task sequence and Monitoring Task Sequence display the thread activity on larger columns in case of small recordings.
  • Bug fix JEYZ-22 : Add recording extension check based on the supported translator extensions
  • Bug fix JEYZ-23 : JFR support – recording time zone is taking the Jeyzer analyzer’s one instead of UTC (JFR standard)
  • Bug fix JEYZ-24 : JZR report – monitoring event times could be displayed using the analyzer time zone instead of the JZR or JFR recording one
  • Bug fix JEYZ-28 : Jeyzer Analyzer failed to parse thread names larger than 2000 chars
  • Bug fix JEYZ-29 : Jeyzer Analyzer failed to parse consecutive thread names (Jstack exotic case)
  • Bug fix JEYZ-30 : Jeyzer Analyzer failed to generate JZR reports with long sheet names

Jeyzer Analyzer Web server

  • Display time zone support
    The web interface permits now to choose the display and recording time zones.
    It is possible by de-selecting the “Time zone – automatic detection” check box.
    Time zone selection is allowed once the recording gets loaded.
    The recording time zone selection is possible only if that one is not found in the recording.
    The list of time zones is a representative sub set of the Java time zone ids (see bottom note).
    The recording and display time zones defined in the selected profile will serve as default values when the time zone is not chosen or cannot be deduced.
    If the “Time zone – automatic detection” is checked, the analyzer will attempt to deduce the time zones, otherwise use the default ones if any.
    The time zone widgets can be disabled through the JEYZER_WEB_PORTAL_TIME_ZONE_DISPLAY environment variable by setting it to false : in such case, the above automatic detection strategy will apply.
  • Bug fix JEYZ-25 : the start and end date of the JZR report link were not converted to the recording time zone

Jeyzer Recorder

  • Bug fix JEYZ-26 : JZR recording snapshot generation failed when an invalid time zone is specified on the monitored process command line
  • Bug fix JEYZ-27 : Jeyzer Recorder could use invalid time zone id in the snapshot file time stamps

Jeyzer Demos

  • Time zone is now covered inside the demos :
    Demo features is started in the US/Pacific time zone. Recording time zone is set with this value.
    The demo-features-mx profile is configured to display it in the US/Central time zone.
    Demo labors is started in the GMT time zone. Recording time zone is set with this value.
    The demo-labors profile is configured to display it in the IST time zone (Indian Standard Time).
  • JVM flags are now covered inside the demos :
    Demo features is setting the HeapDumpPath diagnosis flag : new value is visible in the JVM flags sheet.
    Demo Labors is setting the HeapDumpPath diagnosis flag and checks it through a dedicated monioring rule.

Jeyzer base repository

  • Jenkins master profile added
    Jnr-ffi shared profile added

Important

  • Time zone ids
    In Jeyzer, the time zones ids are the Java ones which are originally issued from the tz database.
    Official tz list is available at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
    Important : the Etc/GMT+2 is not GMT+2, but GMT-2 as per definition : in the “Etc” area, zones west of GMT have indeed a positive sign.

Upgrade instructions (optional)

  • Default time zones :
    You may add in the <profile>_analysis.xml under the analysis node this section :
    <time_zones>
    <!– Default recording time zone if not available in the recording. Optional –>
    <recording_time_zone id=”${JEYZER_RECORDING_TIME_ZONE_ID}”/><!– Drives the date display in reports and other outputs. Optional –>
    <display_time_zone id=”US/Central”/>
    </time_zones>
    As usual, you may put any environment variable (example here : JEYZER_RECORDING_TIME_ZONE_ID).
  • JVM Flags sheet
    You may add in the report.xml of your analysis profiles this report sheet section :
    <sheet sheet_config_file=”${JEYZER_ANALYZER_CONFIG_DIR}/report/sheet/jvm-flags/jvm-flags.xml”/>
  • JVM flag monitoring rules :
    You may add in any Monitoring Events like sheet this default set of rules :
    <rule_set file=”${JEYZER_ANALYZER_CONFIG_DIR}/monitor/rules/jvm_flag_rules.xml”/>
    as well as in any monitoring configuration (see <profile>_monitor.xml).

 

Jeyzer 2.4

Release notes :

Jeyzer Community license updated

  • Jeyzer is now released under the Jeyzer Community License Agreement Version 1.2
    What has changed : Jeyzer Monitor is now under trial period : until end of May for the current release.
    After this date, the JZR reports generated by the Jeyzer Monitor will be empty.
    The Jeyzer Analyzer is not affected and remains a free solution.

Jeyzer Analyzer

  • – JFR analysis support
    Jeyzer Analyzer can now analyse JFR recordings through an extra Jeyzer translator.
    Prerequisites :
    – JFR recordings must be made with Java 11+.
    – Jeyzer Analyzer must run under Java 11+.
    – JFR recordings should be generated using the JFC configuration provided within any Jeyzer installation.
    See the associated README file for more details about the JFR usage within your environment.
    By default the JFR translator is now active in the Jeyzer portal, template and demo profiles.
    To benefit from it on an existing profile (issued from Jeyzer 2.3 or below), add this line in the <application>_analysis.xml file :
    <translator type=”jfr” translator_config_file=”${JEYZER_ANALYZER_CONFIG_DIR}/translators/jfr/jfr_uncompress.xml”/>
    under the compression translator declaration.
    The translator will convert (“uncompress”) the JFR events into JZR snapshots.
    Once uncompressed, those will be processed by the other Jeyzer translators, such as the de-obfuscation one.
    The jfr_uncompress.xml defines the JFR analysis Jeyzer settings. Duplicate it if required for customization needs.
    The JZR snapshots resulting from the conversion are stored in the jfr_uncompressed directory.
    You may keep it for control purposes by setting the keep_files parameter.
    Example (jfr_uncompress.xml) : <jfr_uncompress keep_files=”true” directory=”${JEYZER_RECORD_DIRECTORY}/jfr_uncompressed”>
    For control purposes, the JFR events can be dump into distinct text files (per_type) and/or globally (all) through the dump_events settings :
    Example (jfr_uncompress.xml) :  <dump_events per_type=”true” all=”false” directory=”${JEYZER_RECORD_DIRECTORY}/jfr_dump”/>
  • JRockit Java Mission Control recording format is now supported.
  • Stack size interest strategy – meaning automatic filtering of useless stacks – constraint has been relaxed and made more configurable.
    The percentage of sample quiet stacks (meaning mostly waiting/sleeping) required to allow this strategy is now configurable. It was previously hard coded to 5%.
    Example (sample_app_analysis.xml) : <scan_coverage snapshot_samples=”10″ snapshot_sample_percentage=”30″
    Default value is five if the snapshot_sample_percentage attribute is missing.
  • JZR report : the Session Details sheet now includes the Jeyzer Recorder logging details and the Jeyzer agent version.
  • Process card monitoring rules : Jeyzer logging monitoring rules added for debugging active, console active.
  • Lock relationship support added on jstack 1.5 format
  • Bug fix JEYZ-14 : Sheet formats were only applying on the task sequence sheets. Now extented to all sheets (as per the original documentation)
  • Bug fix JEYZ-16 : Prevent false positive file delete warning on multiple deobfuscations
  • Bug fix JEYZ-17 : Strip code line failed on Java 11 Ubuntu stack
  • Bug fix JEYZ-18 : Jstack 1.5 file pattern relaxed
  • Bug fix JEYZ-19 : Display of large stacks could fail under certain conditions
  • Bug fix JEYZ-20 : Deadlock cycle detection failed on thread dumps issued from JMX

Jeyzer Analyzer Web server

  • JFR format support
    The JFR maximum file size is 100Mb. Change it through the JEYZER_WEB_UPLOAD_RECORDING_MAX_SIZE environment variable (affects also the zip/tar.gz files).
  • Error message display improved.
  • Bug fix JEYZ-15 : analysis failed when the Report id input field did contain a start or end space.

Jeyzer Recorder

  • The Jeyzer Recorder Agent is now deployed and integrated within a scaling recording and configuration structure (internal or external),
    meaning it is adapted for the monitoring support of multiple Java applications.
    Once installed, the agent is immediately usable by adding this parameter to the monitored application command line :
    -javaagent:”<Jeyzer home>/recorder/lib/jeyzer-agent.jar”=<Jeyzer home>/recorder/config/agent/jeyzer-agent.xml;jeyzer-record-agent-profile=<app name>
    Adding extra applications in this scaling structure has been simplified (5 minutes effort) : see the README-AGENT.xml for the setup instructions.
  • The Jeyzer Recorder now support default paths for the configuration repository and recording home.
    It is still possible to override it using the JEYZER_RECORD_APP_CONFIG_REPOSITORY and JEYZER_RECORD_APP_RECORDING_HOME environment variables or system properties.
  • The Jeyzer Recorder now support a default recording agent profile.
    It is still possible to override it using the JEYZER_RECORD_AGENT_PROFILE or to specify it on the -javaagent parameter (as above).
  • Logging framework has been made fully independant and neutral : Logback has been replaced by the Java Util Logging (JUL).
    The logging configuration is Jeyzer specific and therefore cannot interfere with any external logging configuration.
    Log file path is now determined dynamically (no need to set it anymore).
    Upon change, log configuration can be reloaded at runtime. Disabled by default.
    Log file and log configuration paths can be overriden through environment variables ot through -D start parameters.
    See the Recorder README.txt for more details.
  • Bug fix JEYZ-12 : Jeyzer Recorder failed to load its configuration on JDK 8 when Apache Xerces is on the classpath
  • Bug fix JEYZ-13 : Regain Java 7 compatibility

Jeyzer Agent 3.1

  • The agent parameter support and variable default value support (exposed hereafter) permit to instantiate directly the agent,
    while staying compatible with any environment variable or system property declaration.

     

    • Agent parameters support
      These parameters can be referenced by the agent variables.
      The variable resolution is performed in this order : internal agent variable, agent parameter (new), system property, environment variable
      Parameters are specified at the end of the Java agent argument, separated by a semicolumn.
      Example : -javaagent:”<agent jar path>”<jeyzer-agent.xml path>;param_key1=param_value1;param_key2=param_value2[…]
    • Variable default value support. Optional
      If the system property or environment variable contained in the variable value cannot be resolved, the agent variable will be set
      with the default value and the unresolved variable will be set as a system property.
      Example : <variable name=”jeyzer-agent-home” default=”C:\jeyzer-recordings”>${JEYZER_RECORD_APP_RECORDING_HOME}</variable>
      The jeyzer-agent-home agent variable and the JEYZER_RECORD_APP_RECORDING_HOME system property
      will be set with “C:\jeyzer-recordings”assuming JEYZER_RECORD_APP_RECORDING_HOME would not be
      set previously as system property or environment variable.
      System property and environment variable can be specified (and will be resolved). Inner variable resolution is however not supported.
  • Agent bootstrap logging
    Boot traces will appear in the console. Disabled by default.
    Add the -Djeyzer.agent.boot.debug=true on the command line to activate it.
  • Jeyzer agent version is now exposed as a system property (and recorded by the Jeyzer Agent)

Jeyzer Installers

  • The Jeyzer Recorder configuration repository path is now configurable when the Jeyzer Recorder Agent is selected.

Jeyzer Demos

  • Jeyzer demos do now also generate a JFR recording.
    It is available in the <recording home directory>/<demo profile>/jfr directory.
    It uses the customized JFC configuration jeyzer-demo.jfc file available in the <demo home>/config/jfr directory.
    The thread dump period is set to 5 seconds (like for the JZR recording).

 

Upgrade

Jeyzer Ecosystem 2.4 : install the new version and make it point to your profile repository.
To benefit from the JFR support, add this line in the <application>_analysis.xml file of your analysis profile(s):
<translator type=”jfr” translator_config_file=”${JEYZER_ANALYZER_CONFIG_DIR}/translators/jfr/jfr_uncompress.xml”/>

Jeyzer Recorder 2.4 : replace the previous installation directory with the new one.
You must replace the agent parameter in your application command line with this new parameter (the agent jar version has been removed):
-javaagent:”<Jeyzer home>/recorder/lib/jeyzer-agent.jar”=<Jeyzer home>/recorder/config/agent/jeyzer-agent.xml

 

Compatibility

Previous Jeyzer configurations remain compatible with this new version.

JZR recordings generated with previous Jeyzer versions remain compatible with this new version.

Jeyzer 2.3

Release notes :

Jeyzer Analyzer

  • JZR report – The memory pool header is now able to display one of several memory pools.
    Category syntax supports now multiple memory pools separated by “|” .
    Example : <memory_pool category=”PS Old Gen|G1 Old Gen:peak:used” display=”Old Gen Peak”
    It permits to make the profiles independent from the JVM memory model which is JDK version specific in standard : by default, the PS Old Gen and G1 apply respectively on JDK 8 and JDK 11.
    As a consequence, the chart serie names are now referring to the display name (lower case, with dashes) instead of the category.
    Example : <serie header=”memory_pool-old-gen-peak”/>
  • JZR report – The Monitoring Rules sheets can now display the rules based on :
    – the rule reference : each rule is listed only once (new).
    This is now the default if not configured.
    Sheets using the rule get listed, with a link access for each.
    Example (monitoring-rules.xml) : <display list_key=”rule_ref”/>
    – the sheet : each rule can appear several times, once per sheet (Jeyzer 2.2 and previous versions)
    Example (monitoring-rules-per-sheet.xml) : <display list_key=”sheet”/>
  • JZR report – The Profiling and Top stack sheets can strip the Java module prefixes on the code lines to gain in readability.
    It is stripped by default, except in the ATBI profiling sheet.
    Example (top-stacks.xml) : <java_modules strip=”true”/>
  • Deobfuscation : locks are now deobfuscated thanks to the Retrace-alt library upgrade to 1.1.3.
  • Stickers : security ambiant sticker added. Enabled in standard
  • Process card monitoring rules : Java release version, 2 JFR and 2 JMX parameters monitoring rules added
  • Security : Tomcat upgrade from 9.0.30 to 9.0.41
  • Bug fix : JZR report GC figures with G1 were invalid due to max not set on G1 young
  • Bug fix : JZR report heap percentage figure with G1 was invalid due to max not set on G1 young
  • Bug fix : duplicate file check was considering the recording descriptor files
  • Bug fix : Java module detection failed on JFR stacks (empty stack case)

Jeyzer Recorder

  • Jeyzer recorder configuration now support multiple Java memory and GC configurations.

Jeyzer Demos 

  • Jeyzer demo recorder configuration now support multiple Java memory and GC configurations.

 

Upgrade

Jeyzer Ecosystem 2.3 : install the new version and make it point to your profile repository.
You may update your JZR report configuration to support multiple memory models in parallel (meaning multiple Java versions) within the memory pool header.
Example : analyzer/config/report/headers/mp/memory-pool-old-used.xml
Check the <garbage_collectors> and <memory_pools> sections.

Jeyzer Recorder 2.3 : replace the previous installation directory with the new one.
You may update your Jeyzer recording profiles to support multiple memory models in parallel (meaning multiple Java versions).
Example : recorder/config/scaling-template/jeyzer-rec-configs/profiles/profile-template/profile-template_advanced_mx.xml.

 

Compatibility

Previous JZR report configurations : you must update the chart serie names that apply on memory pools.
Example : <serie header=”memory_pool-old-gen-peak”/>

JZR recordings generated with previous Jeyzer versions remain compatible with this new version.

 

Jeyzer 2.2

Release notes :

Jeyzer Analyzer

  • Java module support
    Prerequisite : the JZR recording must include the process-modules.txt file.
    Features :
    • New JZR report sheet : Modules
      The sheet displays each Java module with its name, version, open, automatic, requires, exposes, uses, provides and class loader.
      The sheet can include a graph of the modules : modules get dependency linked and each one shows its number of outgoing dependencies.
      Module graph display is css based and defined in the ${JEYZER_ANALYZER_CONFIG_DIR}/graph/static/style_modules.css
    • Deobfuscation configurations can refer to module versions with the ## prefix and suffix. Example : ##org.jeyzer.demo##
    • JIRA configurations and templates can refer to module versions with the ## prefix and suffix tokens. Example : ##org.jeyzer.demo##
    • Shared profile dynamic loading has been extended to rely also on the Java module name and version : if Maven is used, those will correspond to the artefact id and version of the Maven project.
      Loading is performed in the process module declaration order, always after the static ones and process jar path resolutions.
      As Java modules do not carry external information (like a Jeyzer profile repository id), all profile repositories get therefore scanned.
    • Java module support in the deobfuscation : migration to retrace-alt 1.1.2
  • JZR report – Task sequence : long stack display rule added. Cell text size gets increased if the stack size is larger than a threshold.
    Scope reduction to ATBI only is possible. This is a good alternative to the atbi_of_interest display rule (which is color based).
    Provided in the new Task sequence focus JZR sheet, loaded by the Portal master profile.
  • Mac zip file support
  • Bug fix : Jeyzer Analyzer on Windows failed to process Jstack thread dumps with time stamps containing column char in archive files.
  • Bug fix : Jeyzer Analyzer failed to process tar.gz recordings containing directories.
  • Bug fix : Task memory diff could be zero when task cumulative memory was higher than total consumed memory

Jeyzer Analyzer Web server

  • Issue description default value is now configurable through the JEYZER_WEB_DEFAULT_ISSUE_DESCRIPTION environment variable.
    If not provided, it is set to some default text.
  • Bug fix : Jeyzer Web Analyzer used the application_type to set the JEYZER_TARGET_PROFILE variable instead of the profile directory name.

Jeyzer Monitor

  • New advanced monitoring rules introduced by the Java module support :
    • Process module name absence. If no Java module name is matching the given pattern, generate event.
    • Process module name. If a Java module name is matching the given pattern, generate event.
    • Process module version absence. If one or more Java modules do not have any version, generate event.
    • Process module version. If the rule sticker(s) is/are matched, generate event. This rule must get associated to at least one process module version sticker. It has no check body and relies only on the stickers.
      Rule is similar to the sticker match rule.
    • Process module version snapshot. If one or more Java modules are snapshot modules (or any module having any alphabetic character as part of their version), generate event.
  • Stickers can now also be matched against a Java module version
    Below example would match any logback-classic Java module with a 3.0.x version :

Jeyzer Publisher

  • Jeyzer Publisher library is now released as a Java module named “org.jeyzer.publish”. It stays compatible with JDK 7 and 8.

Jeyzer Annotations (v2.1)

  • Jeyzer Annotations library is now released as a Java module named “org.jeyzer.annotations”. It stays compatible with JDK 7 and 8.
    Only used at compilation time, it has to be imported as a static module.

Jeyzer Recorder

  • Modules recording support. Java modules are printed in the process-modules.txt which ends up in the JZR recording.
    Optional and active only on Java9+.

Jeyzer Ecosystem

  • Azul Zulu JVM 8 and 11 support

Jeyzer Demos

  • Jeyzer demos are now released as a Java modules to demonstrate the module features in the JZR report and monitoring rules.
    Demos stay compatible with JDK 7 and 8.
  • The Jeyzer Labors now include 5 extra test scenarios related to the new module monitoring rules.
  • Bug fix : sh scripts failed to load the Jeyzer agent.
  • Bug fix : demo log file was created in an invalid directory.

Upgrade

Jeyzer Ecosystem 2.2 : install the new version and make it point to your profile repository.
You may update your JZR report configuration to add the modules sheet.
You may update your master profile to add any process module rule.

Jeyzer Recorder 2.2 : replace the previous installation directory with the new one.
You may update your Jeyzer recording profile to add the Java module collection.

Jeyzer Publisher 2.2 : update your Maven project files.

Jeyzer Annotations 2.1 : update your Maven project files.

Compatibility

Previous Jeyzer configurations remain compatible with this new version.

JZR recordings generated with previous Jeyzer versions remain compatible with this new version.

Jeyzer 2.1

Release notes :

Jeyzer Monitor

  • JIRA Cloud integration through the JIRA REST v3 API.
    Jeyzer Monitor will create or update JIRA items for the important encountered monitoring events.
    See the JIRA publisher documentation for setup instructions.
  • Monitoring rules do now provide an optional ticket field to store any ticket system reference (like a JIRA ticket id).
    Ticket value is used as part of the above JIRA integration to update existing JIRA tickets.
    Tickets are displayed in the JZR report Monitoring Rules sheet.
  • Bug fix : Monitor failed when stickers configuration was not set

Jeyzer Analyzer Web server

  • Email submitter default value is now configurable through the JEYZER_WEB_DEFAULT_SUBMITTER_EMAIL environment variable.
    If not provided, it is set to optional-email@domain.com. Set it to an invalid email value (without @) to force people entering it.

Jeyzer Analyzer

  • JZR report has been enhanced with a better cell comment display : comments get sized proportionally to their content.
  • Stacks are now displayed without empty Jzr fields in the JZR reports : improves the readability.

Jeyzer Demos

  • Master demo profiles moved to the Github demo repository
  • Labors and Features projects do include a JIRA configuration
    You just need to update its configuration to connect it to your own JIRA Cloud instance
    The JIRA authentication key generation is described here.
  • Labors demo can accept now a specific list of jobs to execute with the start parameter : jobs=<comma separated list of job names>
    To get the list of jobs, use the start parameter list.
  • Features demo theme is now aircraft related

Jeyzer Publisher

  • Ticket support on the applicative events (like JIRA ticket id)

Jeyzer Recorder

  • Ticket support on the applicative events (like JIRA ticket id)

 

Upgrade

Jeyzer Ecosystem 2.1 : install the new version and make it point to your profile repository.
You may update your master profiles to set up the JIRA integration.

Jeyzer Recorder 2.1 : replace the previous installation directory with the new one.

 

Compatibility

Previous Jeyzer configurations remain compatible with this new version.

JZR recordings generated with previous Jeyzer versions remain compatible with this new version.