Creation guidelines

Jeyzer monitoring rule creation is manual process for now done in 5 steps:

Step 1 – Define your rule

The first step is to translate the incident description within the rule.
It could be also that you need to perform preventive checks : memory settings, environment details, disk space availability, versions…

Rule sets
If you start from zero on your shared/master profile, you will need to create a new set of rules. Define first this information on a paper :

• Rule group name
• Rule reference id prefix such as MY-APP which will be shared by the rules.
  It is important as events will carry this information. Support will use it.
• Does the group of rules appliance rely on common static condition(s) ?
  If yes, you will use stickers.

Rules
To create a new rule, define first this information on a paper :

• Write first a narrative of the rule.
  It will help you to shape it properly and find the adequate Jeyzer rule.
• Does the rule require to generate gradually several events ?
  If yes, you will need to define several thresholds within the rule.
  For example, for a particular long running task, generate a warning event if it’s running more than 5 minutes, then later generate a critical event if it’s running for more than 15 minutes.
• Does the rule appliance rely on static condition(s) ?
  If yes, you will use stickers.
  You could have a rule which makes sense only on Windows (property card stickers) and for one or more versions of your library/application (version stickers). You could also agree to execute this rule only in a QA environment or as part of code analysis or performance benchmark exercise or even to indicate a draft/experimental rule state to prevent executing it in production (ambient stickers). This is very flexible.
• How many events need to be generated : one or several ?
  This applies both at process or thread level : it will determine the type of threshold.
  For example, if one type of issue can happening several times, I’m only interested to see it once : I will use then the global type (opposed to the session type). The same applies at the thread level with the action vs stack types.
• Define exactly the message to be communicated when the incident will happen.
  Who is the target ? The support service ? The production operation team ?
  Think about the remediation actions, the extra checks to perform, possibly some investigation actions like gathering some logs.
  If the detected issue has been in later release, mention it, including its fix ticket reference.
• If the issue relates to a multi-threading one, look at the JZR report to define a threading pattern.
• Is the incident described in any issue tracking system ?
  If yes, take note of the ticket reference to add it on the rule.
  On JIRA, your rule will then be able to update the ticket on the next incident occurrence.

Step 2 – Find the right Jeyzer rule

Once you’re ready, check the All Rules Reference List, you should find the right one to cover your incident detection : perform some key word search.
It’s also possible to end up with several candidate rules : choose the one that will generate the less events.
In some cases, you may need to enrich first the patterns of your shared/master profile to set up your rule on top of it.

Step 3 – Add the rule in your profile

Rule declaration is already covered in the shared and master profile documentation sections.

To write the rule content, best is to inspire from any existing rule set.
Rule set files are suffixed with _rules.xml.
For inspiration, you can for example look at the analyzer/config/monitor/rules/sample_rules.xml available within your Jeyzer installation : it lists all the rules.
And help yourself with the current documentation section : every single piece of configuration is explained in details in case of doubt.

Step 4 – Test your rule

You have probably the JZR recording of the incident.
Just generate a new JZR report with it : the Monitoring sheet must show it.
Make sure that the rule is correctly loaded and matched in the Monitoring Rules sheet.

Step 5 – Commit your rule

Store the rule in your SCM.
If the rule is about a generic issue on Java or on any open source product, please commit it on the Jeyzer base repository : your rule will be candidate for the next Jeyzer release.