|
Each custom rule should be tested before it is activated. The related documentation about how to test a rule is:
# Testing a Rule Documentation.
- If the rule is triggered with the incidents that the user tests, then an incident will be created at the Incidents tab.
- If the rule fails, the user can find further information at the Supervisor CLI:
1) Connect at the Supervisor CLI as root and type this command to see in real-time any logs related to rules:
tail -f /opt/phoenix/log/phoenix.log | grep -i rule
2) At the GUI, clone the custom rule and save it with a different name. Then export this cloned rule and once the rule’s XML file is obtained, delete the cloned rule from the GUI.
3) Import the cloned rule (exported in the previous step) at the GUI. Are there any errors or warnings in the logs at the CLI, while importing the rule?
4) Test the rule. Are there any errors or warnings in the logs at the CLI, while testing the rule?
- Points to Review:
a) Operators: ex. reptDevIpAddr != 10.90.2.9,10.90.2.10.
Only one value can be equal or not equal to something. If there are many values separated by a comma ',' IN or NOT IN should be used.
b) Review 'Group By' option at subpattern of 'Step 2: Define Condition' tab and at 'Step 3: Define Action' tab, the "Action" option.
c) At 'Step 3: Define Action' tab, ensure that there is an 'Incident Title' at the "Action" option.
|
