Rules
Rules are a mechanism through which you teach indeni to alert about certain issues. A rule expresses the logic of analysis of one or more metrics and the contents of the alert that should be provided.
While this section will be updated and elaborated to help build rules, we have included samples of rules below.
Note that rules today are written in a very detailed language.
We will be introducing the condensed language (also known as DSL) soon.
Rules Training
Before you start exploring rules, watch these/wiki/spaces/IKP/pages/84582148 by Yoni.
Where can I find the rules?
/indeni-knowledge/rules
The rules directory has 2 main sub-folders:
- templatebased
Rules under the "templatebased" directory are based on pre-built templates.
The vast majority of rules are template based.
Our goal is to have 80%, or more, of the rules written using a small set of templates that are available.
This makes it easier for an IKE who wants to add a new rule.
Developed by IKEs
Rules: Template based - sync_core_rules
These rules tend to be more complicated, and a few examples of them are listed below under "Non-Template Rules".
Developed by engineering.
Rules: Non-templated (sync_core_rules)
Vendor-specific remediation steps (ConditionalRemediationSteps)
As you'll notice, the rules don't generally know what kind of device they are working on. If a device has the metrics that the rule is looking for, it'll attempt to run its logic on it. Furthermore, most metrics we have available are indeed cross-device, and so will be found on many types of devices. The rule will always use the same headline, description and remediation steps when alerting, no matter what the underlying device is. To further add additional remediation steps, the concept of ConditionalRemediationSteps was added. You'll find that template rules have this often, but also non-template ones. It looks like this:
|
This means, that if the underlying device is made by Cisco, we will add this text at the end of the remediation steps. The goal is to have these lines for each rule that may alert for more than one type of device, and to make sure we cover all potential types of devices.
ConditionalRemediationSteps("Determine the cause for the high CPU usage of the listed cores.",
ConditionalRemediationSteps.VENDOR_CP -> "VENDOR_CP Remediation Steps",
ConditionalRemediationSteps.VENDOR_PANOS -> "VENDOR_PANOS Remediation Steps")
ConditionalRemediationSteps(HighPerCoreCpuUsageRule.baseRemediationStep, Map(ConditionalRemediationStepKey(ConditionalRemediationSteps.VENDOR_CISCO, Some(ConditionalRemediationSteps.OS_IOS)) -> "VENDOR_CISCO+OS_IOS Remediation Steps ", ConditionalRemediationStepKey(ConditionalRemediationSteps.VENDOR_PANOS, None) ->"VENDOR_PANOS Remediation Steps ") )
Item-specific description
Some items should have very specific description information, to give more insight to the user. For this, we've added itemSpecificDescription in certain template based rules. Essentially, it matches the item name to a series of regular expressions. The first expression that matches, will be used to append information for the specific item.
New Vendor Specific Rules
For a new vendor, we need to add vendor string to RuleHelper.scala to support vendor specific rules.
Adding a new non-templated Rule
Add the new rule name to StaticRuleFactory. It's located in the server code: com/indeni/server/rules/manager/factory/StaticRuleFactory.scala
Disabling a rule from the GUI
There is not built-in way to disable a rule.
To work around this and still be able to enable the rule once again when the issue behind the ticket has been resolved you will simply need to comment out the entire rule.
This saves the code in the repo whilst telling Indeni that the rule does not exist.
When doing this you should add some information as to why you are disabling the rule.
Example:
/* This rule is temporarily disabled Ticket: IKP-xxxx Ticket title: RULE - Disable this_example_rule.scala Ticket description: this_example_rule.scala needs to be disabled. This rule should not be seen within the GUI. It is currently not working properly, awaiting correction of IS-xxxx before this rule can be enabled again. package ... import ... import ... case class this_example_rule(context: RuleContext) .... etc etc */
The problem now comes from proving that this rule is in fact disabled.
First you should try the filesystemloader in your indeni instance. Since the rule is now just a big comment the rule loader does not in fact see the code.
The rule being disabled can not be confirmed until a new Indeni version has been built.
Rule representation in the GUI
2 quick screenshots to clarify the correlation between the .yaml file and where it is presented in the GUI:
