Let's adapt our code and application


R&D can prepare the monitoring ground :

  • Create the master profile of your application
    Do not wait for others doing it : you must take the control.
  • Create the shared profile of your libraries
    Maintain and expose automatically your shared profiles

R&D can make the monitoring really easy with the Jeyzer Publisher :

  • Publish important events from your application
    To make possible the correlation with the technical events in the JZR report.
  • Publish data
    Counters, state, process information and options..

R&D can help identifying the issues right away :

  • Maintain and expose your own monitoring rules
    Known bugs on old versions which can be translated into Jeyzer monitoring rules? Do not wait to capture it and share it.
R&D can improve the QA cycle :
  • Integrate the Jeyzer Recorder agent and the Jeyzer Monitor within your QA tests.
    Get your JZR reports in case of issue.
    Find the performance bottlenecks.

Master profile

Any critical Java application should have its own Jeyzer master profile.
And this profile should be owned and maintained by the R&D team responsible for that application.
This master profile will contain the analysis profile and an optional monitoring profile.
This is a 30mn exercise to put it in place : just follow the creation instructions.
Once set, you won’t touch it anymore unless you add a new application dependency.
Those master profiles could be exposed to the external world (Support, IT..) : put it on a web or any repository server for free access from any Jeyzer Analyzer or Monitor instance.

Shared profile

Shared profiles cover the 3rd parties and dependencies.
If you have your own internal libraries, you should create the corresponding shared profiles and expose it.
Those shared profiles must be made accessible for the master profiles : put it on a web or any repository server.
This is a 20mn exercise to put it in place : just follow the creation instructions.
Basically, each Maven project will get its own shared profile : simple.

Analysis patterns

Master and shared profiles contain analysis patterns.
These analysis patterns can be initially defined through Java annotations to put onto the class and methods of interest in your application.
You just need to link with the Jeyzer annotations library and add to your build a Jeyzer profile update step.
This Jeyzer profile update is performed through either a Maven or Gradle plugin.
This is a 20mn exercise to put it in place : just follow the above annotation and plugin instructions.

Define event codes

Each event code refers to an important information such as a service interruption, an activity starting, cancelling..
Define all these codes for your application or service in one Enum class inheriting from the JzrEventCode interface.
As an example check this demo enum class for a fictive application.
Process this enum class with javadoc and you will get a code reference sheet to share with your customer support and IT.

Emit applicative events

Use the event codes to emit events from your application through the Jeyzer Publisher API.
These events can carry also contextual information like the activity parameters for example, or the error message for the connectivity issue.
Those events will be captured by the Jeyzer Recorder and end up in the JZR report, alongside with the technical events raised by Jeyzer.
The entry point is the Jeyzer Publisher and the place to emit events is the Monitor handler:

  JzrMonitorHandler jmonitor = JeyzerPublisher.instance().getMonitorHandler
         “MyApp”, MyApplicationEventCode.SERVICE);
  // Fire a one shot info event with contextual applicative info :
          new JzrStandardEvent(MyApplicationEventCode.MCY_MYA_01, “Standard start mode”))

The JzrStandardEvent class is a default implementation. You could create your own which must inherit from the JzrEvent interface.

Publish data

Publish process data through the Jeyzer Publisher and action data through the Action handler.
The action handler allows to declare a thread activity with a start and end. The Jeyzer report will consider it as an action.

Detect known issues

Production issues have signatures.

When it deals with your application or a library, you can capture this signature within a Jeyzer monitoring rule.
Of course, this issue will be fixed in the next version.. but any customer running the previous versions may encounter it as well.
So it is preferable to detect it upfront and provide the right remediation action.

The Jeyzer monitoring rule will be added to the master profile or the shared profile.
Jeyzer rules are described in the All rules reference list.
Use the stickers to make it version dependent.
The version check will rely on process card sticker which refers to a jar manifest property or a system property of your process/library.

Thousands of tests are possibly running every night on your application :
This is hidden treasure in term of how your application behaves from performance point of view.
This could also hide issues that will occur later in production.

As son as you have your master profile in place for your application, the next easy step is to put Jeyzer in your QA environment.
First deploy the Jeyzer Recorder Agent within your application.

Secondly, decide if you prefer to generate a JZR report on ad hoc basis or automatically.

  • On ad hoc basis, you will collect the JZR recording and analyze it through the Jeyzer Analyzer to get the JZR report.
    The Jeyzer Analyzer can reside anywhere : use the Jeyzer installer or deploy a Jeyzer Docker image.
  • On automated basis, you will deploy the Jeyzer Monitor in your QA environment.
    Every time Jeyzer will encounter a critical event, it will generate a JZR report and send it to your team for review.
    Remember that the Jeyzer Monitor  can monitor multiple processes in parallel.
    Jeyzer Monitor commercial license is NOT required as it is not commercial usage.

The JZR report will show you not only the critical events, but also the performance bottlenecks.