Skip navigation
67144 Views 9 Replies Latest reply: Apr 4, 2011 4:39 AM by mvlaovic RSS
chitambira Rank: Brown Belt 711 posts since
Oct 15, 2008
Currently Being Moderated

Jan 26, 2010 5:12 AM

Alerting rules Logic need redesigning!

I have realised that the logic of the alerting rules is somewhat not very flexible.

I would thing of a situation where one wants to filter out certain regexp string within event summary and prevent that event from alerting.

You can use "is not" for full match or "does not contain"

However, if you want to filet out 2 or more strings, its impossible because if you are filtering by summary (and many other fields), the rules are hardcoded to use "AND" between the filters.

It would be more useful if we could use "OR" since we would want a test for each summary filter. I wonder whether there is any particular problem that prevented dev from using both and and or as operators which a user can then choose from some sort of drop down menu.


Comments?

  • jmp242 ZenossMaster 4,060 posts since
    Mar 7, 2007
    Currently Being Moderated
    1. Jan 26, 2010 8:56 AM (in response to chitambira)
    Re: Alerting rules Logic need redesigning!

    You can use OR if you hack at the Zope level. More generally, I think

    the idea is you're not doing that level of filtering at the Alerting

    rule, but at the event mapping / transform part.

    --

    James Pulver

    Information Technology Area Supervisor

    LEPP Computer Group

    Cornell University

     

     

     

    chitambira wrote, On 1/26/2010 5:12 AM:

    I have realised that the logic of the alerting rules is somewhat not very flexible.

    I would thing of a situation where one wants to filter out certain regexp string within event summary and prevent that event from alerting.

    You can use "is not" for full match or "does not contain"

    However, if you want to filet out 2 or more strings, its impossible because if you are filtering by summary (and many other fields), the rules are hardcoded to use "AND" between the filters.

    It would be more useful if we could use "OR" since we would want a test for each summary filter. I wonder whether there is any particular problem that prevented dev from using both and and or as operators which a user can then choose from some sort of drop down menu.

     

    Comments?

    >

  • phonegi Rank: Brown Belt 446 posts since
    Apr 15, 2009
    Currently Being Moderated
    2. Jan 26, 2010 8:10 PM (in response to chitambira)
    Re: Alerting rules Logic need redesigning!

    jmp242 is correct. Zenoss has very powerful event filtering, but not so powerful alert filtering. Jane Curry's Event Management paper is by far the best source to learn what you can do with events. http://community.zenoss.org/docs/DOC-3538

     

    What exactly are you trying to accomplish?

     

    PG

  • phonegi Rank: Brown Belt 446 posts since
    Apr 15, 2009
    Currently Being Moderated
    4. Jan 27, 2010 9:09 AM (in response to chitambira)
    Re: Alerting rules Logic need redesigning!

    Actually, jmp232 did give you a solution in his original post:

    You can use OR if you hack at the Zope level.

     

    Currently the functionality you want is only available in Zenoss via Event Transforms. You have made it clear that you do not want to use that method. However, if you are willing to use the Zope interface instead of the Zenoss interface, you can accomplish exactly what you are looking for.

     

    1. Navigate to your alerting rule.
    2. Access the Zope interface by modifying the URL. Add "/manage" to the end of the URL. Hit <ENTER>
    3. Once in the Zope interface, select the Properties tab.
    4. Modify the where clause with any Python expression using any combination of field values. Field values are listed at the bottom of the page on the Message Tab within an Alerting Rule.
  • jmp242 ZenossMaster 4,060 posts since
    Mar 7, 2007
    Currently Being Moderated
    6. Jan 28, 2010 8:18 AM (in response to chitambira)
    Re: Alerting rules Logic need redesigning!

    Honestly, this sort of need never has come up for me, and rarely comes

    up in the forums. Maybe Enterprise customers with very specialized

    admins would need this, but I'm guessing most of the core users are SMBs

    who have much less granular personnel responsibilities.

     

    While it's less straightforward than an alerting rule, you could also

    use event classes like /special/storageadmins and use

    transforms/mappings to move such events there, and then alert on that

    specific class. You'd potentially get a benefit on an event view too in

    that you could easily limit which shows up for who...

     

    At this point, I think your need is a valid, but rare one. It's of

    course worth opening an enhancement ticket I think.

    --

    James Pulver

    Information Technology Area Supervisor

    LEPP Computer Group

    Cornell University

     

     

     

    chitambira wrote, On 1/28/2010 4:42 AM:

    The functionality is not available via Event Transforms, unless if you dont understand this issue clearly.

     

    You quoted right, jmp232 put it in the correct way, "a hack". The Zope hack is truely a hack, and not a very smart way of doing things. It may work for me, but what about the multitude of users who may need this functionality?

     

    Also even if you change the 'and' to 'or' in zope, the zenoss interface still displays 'and', how does one know the operator thats actually in effect without having to generate the events or worse, to wait and see?

     

    Also all subseqent changes to that alert rule will have to be done only via zope, coz if you change any other line and save in zenoss web interface, these 'or's will be reverted back to 'and's

     

    I  would have needed a very clean zenoss instance but it seems thats impossible, coz I think my zenoss code is now 40% way off the original code and its a pain when you want to upgrade etc.

     

    I just needed your views so that if a lot of users agree that this issue needs to be addressed, then we can pass it on appropriately as either bug, enhancement or feature request.

    >

  • jmp242 ZenossMaster 4,060 posts since
    Mar 7, 2007
    Currently Being Moderated
    8. Jan 28, 2010 11:16 AM (in response to chitambira)
    Re: Alerting rules Logic need redesigning!

    Don't forget that event transforms now cascade, so you could put at the

    lowest level of the transforms after your clever logic a final -> move

    to special class...

    --

    James Pulver

    Information Technology Area Supervisor

    LEPP Computer Group

    Cornell University

     

     

     

    chitambira wrote, On 1/28/2010 10:28 AM:

    ...Well said!, but let me say why i believe event transfroms are not a good approach to such a situation.

    I have these events classified under various event classes and in those classes, I have already transfroms which deal with certain aspects and a lot of clever logic is built in these transform. If I create a special class for each of these situations, then i lose on the logic within the transforms that I did. I dont want to repeat these transforms into your suggested special classes for a number of good reasons. So best way is to sort out the alert rules schema. The problem itself is with alert rules scheme and avoiding that, by trying something outside alert rules will obviously break something else.

     

    I will try and submit this as an enhancement request.

    Thanks

    >

  • mvlaovic Rank: White Belt 46 posts since
    Dec 21, 2010
    Currently Being Moderated
    9. Apr 4, 2011 4:39 AM (in response to jmp242)
    Re: Alerting rules Logic need redesigning!

    Hi

     

    I agree with chitambira. I also need OR (for complex filtering in summary field) and i agree that this has nothing to do with filtering EVENTS ona a event class level.

     

    These are two separate aspects (filtering events and filtering something in email alerts) and trying to acomplish one thing using another and claiming that this is the way it should be done is bogus!

     

    Here is my example i believe should prove that my case cannot be solved with event filtering (evant class mapping) to achieve what i want. (well, it could but it would be totally insane)

     

    I receive a linkDown trap. It holds a device and an interface that went down on this device. I map this trap to my /Net/Link class and apply a transform to enhance a summary field and to link an interface to evt.component.

     

    Okay so now i have an event class for my Linkdown events with these event fields i would like to point out to you:

     

    evt.device, evt.component (interface name), evt.summary (custom text saying interface <interface name> went down and it's description is <interface description> )

     

    So this is a single event class handling my linkdown alerts. and that's it. this is good. no need to do anything more here.

     

    Now, i want to email these alerts to network admin group but ONLY for those interfaces having (or NOT having) a certain interface description.

     

    Example:

     

    i want to email every linkDown alert (there are some alerting conditions set that are okay and standard) EXCEPT if event summary has some certain patterns regarding interface description, like "test ABC" or "telephone connection" or "link to building XYZ".

     

    If interface has ANY of these descriptions (now part of an event summary), the email should NOT be sent.

     

    So you see, my requirement has nothing to do with event classes. I want all those linkdown events to map to the same class and on the event class level, i don't make any difference based on interface description, they should all be treated the same, but when it comes to mailing them, then i WANT to treat them differenty, i want to be able to distinguish what to email and what not to email.

     

    And now we come to the point already described, there is no OR available in WHERE clause (except through zope) and everythig posted earlier stands. This is just my contribution to the fact that OR is needed and missing OR cannot be justified by saying "zenoss has a powerfull event filtering, and you should go and make your filtering there..."

     

    These are two different aspects of handling events, with different requirements.

     

    regards

     

    marko

More Like This

  • Retrieving data ...

Legend

  • Correct Answers - 4 points
  • Helpful Answers - 2 points