Feature Request: for multiple "AND" conditions to detect an event

[hz2102]

Hi,

I am new to stackstorm and ghost2logger. And nice work David to provide this package.

Just wondering if there is any way to define 2 or more patterns with and condition.
Seems like in this current version there is only one trigger.pattern can be defined.

In some cases, we need to check multiple parameters, like interfaceX with recent state up or down.
I have tried with Regex and these type of events can be detected with ghost2logger.
But attaching this event to an action, we need to extract the interface name from the syslog message. And forward this info to another module like execute ansible playbook, to change that interface configuration.

I am not sure if any other way to do this, but if it is possible using ghost2logger it would be really nice.

Regards,
hz2102

[blag]

If I understand your question correctly, yes, this is entirely possible. The provided example rule even illustrates how to do this:

name: rule_1
pack: ghost2logger
ref: ghost2logger.rule_1
criteria:
    trigger.host:
        pattern: 192.168.16.1
        type: eq
    # implicit AND operator
    trigger.pattern:
        pattern: thing [0-9]$
        type: eq
...

All you have to do is provide more than one key/object pair in the criteria.

You can also create this in the StackStorm web UI in the "Rules" tab and using the "Add Criteria" button:

Note the "and" between the criteria - that indicates that both criteria must match to pass the rule and create a trigger instance. Furthermore, please note that the example rule and the screenshot I posted are not for the same rule.

[hz2102]

Thanks for the detailed explanation.
I think I cannot able to explain the problem correctly.

I am aware that there can be multiple criteria defined.

But I need to define multiple trigger.pattern, so when I add another trigger.pattern like following, the previous one seems to be re-written.

• you can see here the previous one is back to default value.

Regards,
hz2102

[hz2102]

To add an example, in my environment I can now detect the following syslog. Using two AND criteria, host IP and syslog message information.

<189>166: Aug 21 11:37:39.394 JST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3, changed state to down

What I need is, parse the affected interface and the fault information from this message, so what I thought, if I can define the criteria like,
trigger.pattern1 == GigabitEthernet.* (<- interface name only)
trigger.pattern2 == "changed state to down"
trigger.host == x.y.z.w
In this way, I can pass the trigger.pattern1 value to some other modules, like ansible to execute some commands, like "show interface GigabitEthernet1".

If the scenario is not clear enough please let me know.

Regards,
hz2102

[DavidJohnGee]

Hi, Sorry for any delay here. I've been off the grid to unwind! Ghost2Logger can be viewed as a two-step pipeline where Ghost2Logger binary itself does the regular expressions. Even if you change the operation type in the ST2 rule, the Ghost2Logger binary will always do regex. It was a huge amount of work to insert every kind of match type so went for the most useful and made it a documented limitation. I suspect I need to make it more clear, so thank you for the nudge. http://ipengineer.net/2017/05/stackstorm-ghost2logger-pack/ <http://ipengineer.net/2017/05/stackstorm-ghost2logger-pack/> Ghost2Logger -> ST2 Rule Engine regex eq / or regex Ok, next bit. With regards to the UI issue you are seeing, I ran into similar problems a few versions back (2.0 I think or 2.1) where on creating or altering rules and saving, the rule was not as I had set. Sometimes the rule needed deleting or the browser needed refreshing. Ghost2logger has no affect on the rules unfortunately, so I can't help you there. You should be able to record a short video on the problem then create an issue following the GitHub template with the ST2 core team. In terms of pipeline, the St2 rule-set is read unidirectionally from ST2 towards the Ghost2Logger binary and not the other way around. If the rule is deleted from ST2 then it is from Ghost2Logger, but not vice-versa. Hope all of that helps?! Thanks also for the kind words. I spent quite an amount of time building Ghost2Logger and it brings me joy knowing that someone is using it! Thanks, David

…

On 21 Aug 2018, at 05:55, hz2102 ***@***.***> wrote: Thanks for the detailed explanation. I think I cannot able to explain the problem correctly. I am aware that there can be multiple criteria defined. <https://user-images.githubusercontent.com/24771255/44380939-04693700-a549-11e8-9f92-56c72032bdc9.png> But I need to define multiple trigger.pattern, so when I add another trigger.pattern like following, the previous one seems to be re-written. <https://user-images.githubusercontent.com/24771255/44381068-92452200-a549-11e8-9746-aa283f8f8973.png> you can see here the previous one is back to default value. Regards, hz2102 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEFby2q-n8Xm4yu0YkFYa62yRD43KVV-ks5uS5KngaJpZM4WFD08>.

[hz2102]

Thanks, David. Hope you had a nice relaxing time^^

I may understand you wrong so please point me out if I am.
What I need, or I think if its available could make this package better is to have options something like following,

name: rule_1
pack: ghost2logger
ref: ghost2logger.rule_1
criteria:
    trigger.host:
        pattern: 192.168.16.1
        type: eq
    trigger.pattern1:
        pattern: link.*down$
        type: eq
    trigger.pattern2:
        pattern: ge-0/0/[0-9]*
        type: regex
enabled: true
tags: []

If its possible we can get two variables, {{trigger.pattern1}} and {{trigger.pattern2}}.
pattern1 is to know that something, eventually pattern2, is in a down state now.
By getting these two variables we can pass related info to our action module, say use ansible to get that interface info.

What I am facing is, I cannot define trigger.pattern more than 1 time. It may be a GUI problem, or it is the only way to define only one trigger.pattern per rule.

I will try to troubleshoot this problem and report back to St2 team if needed :)

Regards,
hz2102