CEP的序列检测

时间:2015-09-02 12:32:11

标签: fiware complex-event-processing

在开发Fiware的Proton CEP时,我遇到了序列事件检测的问题。我将利用软件附带的DoSAttack示例项目来解释问题。

我对DoSAttack的原始副本进行了两次主要更改:

- 一个是让ExpectedCrash事件有3个以上的变量。这样我就可以在DoSAttackTRConsumer文件中记录触发它的3个值。

- 然后我还将代理的基数政策从单一更改为不受限制。这样,当TrafficReports进入时,事件可以连续多次触发(这可能是问题的根源)。

我测试了这个结果,我发现它工作正常。我可以在日志中看到触发检测的值是在前三个事件到达之后在事件之前到达的3个值的序列。 考虑到在这3个值上进行的测试仍然是原始的示例测试:(TR3.volume> 1.50 * TR2.volume AND TR2.volume> 1.50 * TR1.volume)。

如果我将测试仅仅(TR3.volume> 1.50 * TR2.volume),那么问题就出现了,例如,然后CEP没有正确保存TR1。现在TR1与TR2相同,所以cep失去了这个值的“记忆”。 更进一步,我进行测试,只是条件(3> 2),它始终为真,并应触发任何到达事件的检测。在这种情况下,当事件到达时,所有TR1,TR2和TR3都是相同的,并且CEP没有过去值的记忆,即使代理是Type:Sequence。

所需的应用是CEP将22个读数作为一系列输入事件接收,并在每个输入的值中仅分析该序列的第1,第8,第15和第22个值。但我发现我不能让CEP正确记住这些值,除非我在条件视图框中明确地测试它们。

分析到达的第1个,第8个,第15个和第22个值的正确方法是什么,每次新的到达时进行评估?

这是DoSAttack在改变之后的特异性:

{"epn":{"events":[{"name":"TrafficReport","attributes":[{"name":"volume","type":"Integer","dimension":0}]},{"name":"ExpectedCrash","attributes":[{"name":"Cost","type":"Double","dimension":0},{"name":"TR1","type":"Integer","dimension":"0"},{"name":"TR2","type":"Integer","dimension":"0"},{"name":"TR3","type":"Integer","dimension":"0"}]}],"epas":[{"name":"IncreasingTraffic","epaType":"Sequence","context":"3MinAfterStartUp","inputEvents":[{"name":"TrafficReport","alias":"TR1","consumptionPolicy":"Consume","instanceSelectionPolicy":"First"},{"name":"TrafficReport","alias":"TR2","consumptionPolicy":"Consume","instanceSelectionPolicy":"First"},{"name":"TrafficReport","alias":"TR3","consumptionPolicy":"Consume","instanceSelectionPolicy":"First"}],"computedVariables":[],"assertion":"3>2","evaluationPolicy":"Immediate","cardinalityPolicy":"Unrestricted","internalSegmentation":[],"derivedEvents":[{"name":"ExpectedCrash","reportParticipants":false,"expressions":{"Cost":"10","TR1":"TR1.volume","TR2":"TR2.volume","TR3":"TR3.volume"}}],"derivedActions":[]}],"contexts":{"temporal":[{"name":"3MinAfterStartUp","type":"TemporalInterval","atStartup":true,"neverEnding":false,"initiators":[],"terminators":[{"terminatorType":"RelativeTime","terminationType":"Terminate","relativeTime":"180000"}]}],"segmentation":[],"composite":[]},"consumers":[{"name":"SysTemCrashConsumer","type":"File","properties":[{"name":"filename","value":"/opt/tomcat10/sample/DoSAttack_PredictedCrash.txt"},{"name":"formatter","value":"json"},{"name":"delimiter","value":";"},{"name":"tagDataSeparator","value":"="},{"name":"SendingDelay","value":"1000"}],"events":[{"name":"ExpectedCrash"}],"actions":[]},{"name":"DoSAttackTRConsumer","type":"File","properties":[{"name":"filename","value":"/opt/tomcat10/sample/DoSAttack_TrafficReport.txt"},{"name":"formatter","value":"json"},{"name":"delimiter","value":";"},{"name":"tagDataSeparator","value":"="},{"name":"SendingDelay","value":"1000"}],"events":[{"name":"TrafficReport"}],"actions":[]}],"producers":[{"name":"TrafficReportFileProducer","type":"File","properties":[{"name":"filename","value":"/opt/tomcat10/sample/DoSAttackScenarioJSON.txt"},{"name":"pollingInterval","value":"1000"},{"name":"sendingDelay","value":"1500"},{"name":"formatter","value":"json"},{"name":"delimiter","value":";"},{"name":"tagDataSeparator","value":"="}],"events":[]}],"actions":[],"name":"DoSAttack"}}

生产者文件 DoSAttackScenarioJSON.txt 仍然是原始文件,未经改动:

{"Name":"TrafficReport", "volume":"1000"}
{"Name":"TrafficReport", "volume":"1600"}
{"Name":"TrafficReport", "volume":"2500"}

如果包含的值多于3,则可以看到问题的传播。

如果您需要更多信息,请与我们联系。

谢谢

1 个答案:

答案 0 :(得分:2)

Sequence 模式中,引擎会查找以特定顺序发生的事件实例。 在 Sequence(A,B,C)中,引擎查找三个事件实例,第一个是A类,第二个是B类,第三个是C类,其中:

(A's detection time) <= (B's detection time) AND (B's detection time) <= (C's detection time)

通常在序列模式中,事件类型不同,或参与者事件之上还有其他条件(如DoSAttack示例中所示)。

当您在序列中使用相同的事件类型时(例如,序列(A,A,A)),则可以在所有三个地方使用相同的事件实例,因为它保留上面列出的检测顺序。

此外,如果您对参与者事件使用&#34; consumptionPolicy&#34;:&#34; Consume&#34; ,那么在事件被用于检测模式后,它将不会用于此模式的未来检测。

这就是为什么当你有一个没有条件的序列(A,A,A),以及 A 类型的事件实例 A1 时到达时,它会导致模式检测,并且由于它具有消耗策略,因此将不会保留以供将来检测。稍后当 A 类型的事件 A2 到达时,它会导致另一个基于 A2 的检测。

此外,根据检测时间内的序列内置条件,可以检测到一系列事件,尽管其他事件到达之间。

请描述您想要检测的模式。也许你可以使用Trend或Aggregate EPA。