Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Eagle Topology failed to Start if it finds invalid Policy.

JIRA - EAGLE-95


Implemented Design

  1. Define new methods in the PolicyEvaluator interface - isMarkdownEnabled() and getMarkdownReason()
  2. It is PolicyEvaluator implementation's responsibility to determine if the policy is marked down or not. In our case, SiddhiPolicyEvaluator and MLPolicyEvaluator should implement this above interface.
    1. For SiddhiPolicyEvaluator, we can catch exception at createSiddhiRuntime method, then markdown this policy by setting two field (markdownEnabled - in case of SiddhiParserException exception & mardownReason - the exception message) in the SiddhiRuntime object returned. The ExecutionPlanRuntime will be made null and will not be attempted to start in case of an exception.
    2. For MLPolicyyEvaluator, at present there is no logic implemented to determine markdown and so will be returning false for isMarkdowEnabled by default.
  3. It is PolicyProcessExecutor responsibility to report markdown status back to eagle service. So at createPolicyEvaluator() and onPolicyChanged(), after creating/updating SiddhiRuntime we make a call to the Eagle WebService to update the markdown details for the policy maintained in the "alertdef" table. In the PolicyProcessExecutor.flatMap(), we check if the markdown is enabled or not to evaluate.

 

Proposed Design (drafts)

#1 Identifying an invalid query (Siddhiusing SiddhiCompiler)

AlertDefinitionAPIEntity class is used to define policy.

From the request payload, the policyDef tag contains the values of the type of the policy and the actual policy (given in bold below)

 

[{d
    “tags”: {
        “site”: “sandbox”,
“dataSource” “dataSource”: “hdfsAuditLog”,
“policyId” “policyId”: “testPolicy”,
“alertExecutorId” “alertExecutorId”: “hdfsAuditLogAlertExecutor”,
“policyType” “policyType”: “siddhiCEPEngine”
    },
    “desc”: “test alert policy”,
“policyDef”: “    "policyDef": "{"type":"siddhiCEPEngine","expression":"from hdfsAuditLogEventStream[src =='/tmp/private’private'] select * insert into outputStream;"}",
    “notificationDef”: “[{
        “sender”:”noreply-eagle@company.com”,
“recipients” “recipients”:”user@company.com”,
“subject” “subject”:”test alert policy”,
“flavor” “flavor”:”email”,
“id” “id”:”email_1”
    }]”,
    “enabled”: true
}]

 

The process of finding out whether a policy expression is valid/invalid can be achieved by using SiddhiCompiler.parseQuery().

The method will check if the given input expression is valid wrt expected syntax. If the policy is found to be invalid, it will throw SiddhiParserException with mentioning the error in the query. Based on this method output, we can define markdown status and markdown reason for the query corresponding to its policy.


#2 Updating Markdown details for the Policy in HBase

Approach #1 (will not be used as this makes Siddhi a dependency in the HBase data persistence flow)

From the HBaseStorage class, whenever a request comes in to persisted Policy details (request under the service name AlertDefinitionService), we could put a check on the query to see whether it is valid syntax WRT to Siddhi. This can be achieved using the parseQuery method of the SiddhiCompiler. Based SiddhiCompiler.parseQuery(String query). Based on the output, we can add another field, say queryCompiled and yet another field for error message if the query is not compiled.

Based on the above result, we can modify the inbound entities by adding markdown and markdownReason column values before persisting them.

Approach #2

Considering the policies are already persisted to HBase at this point before starting a topology.

When the topology starts, the AlertExecutor.init() will be called to populate the map of PolicyEvaluators. The map is updated regularly at one of these methods - init(), onPolicyCreated(), onPolicyChanged() and onPolicyDeleted(). At this point before making any change to the map, we could check for the validity of the policy and then update it accordingly in the HBase tabled against the policyID.


#3 Topology Starting with an existing invalid policy

When a topology is started, we will create a PolicyEvaluator for each of the active policies. A SiddhiRuntime is created for the PolicyEvaluator. At SiddhiPolicyEvalutor.createSiddhiRuntime(), when an invalid policy exists, it fails to create a ExecutionPlanRuntime object and the topology start fails.

We can skip the invalid policy by checking if the policy is valid or not by the above mentioned method and allocate null value to the ExecutionPlanRuntime in the returned SiddhiRuntime object. Also in the SiddhiRuntime, we will add a new boolean field  - markdownEnabled and set it before returning.

With this, we will not be modifying any PE objects in the PE map of AlertExecutor.

 

#4 Avoiding invalid policy at run time to process events

In the SiddhiPolicyEvaluator.evaluate(), we can check for the markdown flag in the SiddhiRuntime object (assigned in the above step) before the existing logic to send data.