1. Home
  2. Docs
  3. Recording
  4. Recording profile
  5. Recording attributes

Recording attributes

The recording profile has the following attributes :

  • profile : the profile name
<recorder profile="${JEYZER_RECORD_PROFILE}">
  • process_card : defines if the process card must be enabled.
    Whatever the recording method, a process file can always be generated.
<process_card enabled="${JEYZER_RECORD_PROCESS_CARD_ENABLED}"/>
  • time_zone : defines a custom time zone (*)
    Time zone must be a valid time zone id as defined by the Java TimeZone.
    Choose a small time zone code (UTC, CET..) as it is used in the recording file name.
    If not set, the process time zone will be taken if accessible : it is either issued from the jinfo execution or from the Java MX Runtime bean.
    Otherwise, the Jeyzer client process time zone will be selected.
 <time_zone id="CET"/>
  • period : the snapshot recording period in seconds.
    It is set by default to 30 seconds.
    For a production environment, it is recommended to set it to 30-60 seconds. You may reduce it to few seconds to track some particular problems.
  • start_delay : a delay duration in seconds applied before capturing the first recording snapshot
    This may be required if the monitored process requires time to initialize
  • output_dir : the recording snapshot directory
  • capture_duration : indicates if the recording snapshot capture time must be recorded
<snapshot period="${JEYZER_RECORD_PERIOD}"

(*) Which time zone origin?

Time zone can be taken out from different places (or origins) :

  • The monitored process itself
  • The Jeyzer Recorder configuration (as detailed above)
  • The Jeyzer recorder client when the Jeyzer Recorder agent is not used

The process time zone should be the preferred origin by convention : it allows you to correlate the JZR report events and data with any process log traces without doing any cumbersome time shifting.
The process should itself inherit from the server time zone to extend the correlations to system log files.
A good practice is to run everything in the UTC time zone.
Leaves the time_zone empty.

In some cases, you may prefer working with the end user time zone to perform easily correlations with their given feedback, in their local time zone.
In other cases, the process must be aligned with the time zone of a 3rd party (database server, external service) which is different from the one of the server hosting the monitored process.
Set the time_zone with the desired time zone id.