12 Replies Latest reply on Jul 31, 2014 2:29 PM by Daniel Gibson

    How do refine rules actually work?

    Daniel Gibson

      To All MRL rule gurus,

       

      I am new to ProactiveNet and MRL but I am diving into the language and trying to manipulate the events in the Refine Phase.

       

      From the documentation it states that the way a refine rule works is that if you match your ECF then the event then gets passed into the next Phase (Regulate) but if your ECF does not match the event is discarded.

       

      I am not seeing it work that way and I am unsure why.

       

      What I am attempting to do is Refine and ECF to only NOTIFY_EVENTS...here is the simple code.

       

      refine refine_drop_all_but_notify_events: PATROL_EV($EV)

              where [ $EV.p_class == NOTIFY_EVENT AND $EV.p_catalog == AS_EVENTSPRING ]

              {

                      strtolist($EV.p_origin,'.',$FLDS);

                      $EV.mc_object_class = listgetelt($FLDS,1);

                      $EV.mc_object = listgetelt($FLDS,2);

                      $EV.mc_parameter = listgetelt($FLDS,3);

              }

      END

       

      So I guess I am too green to understand how refine rules work.  I see other refine rules in my mcell-log when I dynamically enable trace...but I thought if I listed this refine rule last in the .load file it would have priority and therefore drop the PATROL_EV event if the ECF did not match.

       

      Can someone please explain in detail what it is I am missing with regard to discarding events in the Refine Phase?

       

      Any and all help would be appreciated...

       

      Thanks,

      Danny

        • 1. Re: How do refine rules actually work?
          Lori Brown

          I'll be interested to see others weigh in.  Are you thinking of a filter rule?  From my documentation, a refine rule adds extra information - maybe slots need data added or changed somehow.

          • 2. Re: How do refine rules actually work?
            Daniel Gibson

            According to the documentation you can discard an event in any of the first four phases...refine, filter, regulate or new.

             

            ev_processing_rule_phases.jpg

            • 4. Re: How do refine rules actually work?
              Daniel Gibson

              OK so why doesn't this specific detail not EXIST! in the BPPM manuals.  The way an event is discarded in a Refine rule is based off aspect of the confirm_external() primitive.  Which is used to execute an external program and PASS the event if the external program returns a zero return (result) code or discard (NOPASS) the event if the external program returns a non-zero return (result) code.

               

              This seems too be a very IMPORTANT and CRITICAL piece of information regarding Refine rules.  This is buried in the confirm_external() primitive reference and nowhere to be discussed in the Refine Rule section itself...unbelieveable.

               

              So now I have two refine rules.  The first in the .load file is as follows:

               

              refine drop_all_but_as_eventspring: PATROL_EV($EV)

                      where [$EV.p_class != NOTIFY_EVENT OR $EV.p_catalog != AS_EVENTSPRING ]

                      {

                              confirm_external('/opt/bppm/BPPMAgent/pw/server/bin/refine_drop.pl',[]);

                      }

              END

               

              Where the refine_drop.pl just exit(254);

               

              And the second refine rule is as follows:

               

              refine populate_slots_from_p_origin: PATROL_EV($EV)

                      where [ $EV.p_class == NOTIFY_EVENT AND $EV.p_catalog == AS_EVENTSPRING ]

                      {

                              strtolist($EV.p_origin,'.',$FLDS);

                              $EV.mc_object_class = listgetelt($FLDS,1);

                              $EV.mc_object = listgetelt($FLDS,2);

                              $EV.mc_parameter = listgetelt($FLDS,3);

                      }

              END

               

              So it should be working and I am seeing the drop_all_but_as_eventspring being called in the mcell-log with trace ON but it is not discarding the events.

               

              The second refine is matching the appropriate ECF and modifying the slots as expected...

               

              Now can anyone explain how I can increase the tracing to see whether the refine rule is actually calling the refine_drop.pl and seeing its exit(254)???

              • 5. Re: How do refine rules actually work?
                Daniel Gibson


                So I see both refine rules being called but not JOY!

                 

                20140730 113548.198685 mcell: RULES: BMC-IMC110801I: refine_drop_all_but_notify_events.mrl, 20: refine drop_all_but_as_eventspring: PATROL_EV #40131: Rule execution starting with

                $EV = 0xa54d498 (class: PATROL_EV,   event_handle: 40131, mc_ueid: its-patrol-t3.mcis.washington.edu@140.142.249.47:3181.1404838475.24233)

                 

                20140730 113549.240439 mcell: RULES: BMC-IMC110801I: refine_notify_events.mrl, 20: refine populate_slots_from_p_origin: PATROL_EV #40132: Rule execution starting with

                $EV = 0xa54cef0 (class: PATROL_EV,   event_handle: 40132, mc_ueid: its-patrol-t3.mcis.washington.edu@140.142.249.47:3181.1404838475.24241)

                 

                20140730 113549.240977 mcell: RULES: BMC-IMC110203I: refine_notify_events.mrl (24;4): populate_slots_from_p_origin:  $EV.mc_object_class = FILESYSTEM

                 

                20140730 113549.241195 mcell: RULES: BMC-IMC110203I: refine_notify_events.mrl (25;4): populate_slots_from_p_origin:  $EV.mc_object = root

                 

                20140730 113549.241400 mcell: RULES: BMC-IMC110203I: refine_notify_events.mrl (26;4): populate_slots_from_p_origin:  $EV.mc_parameter = FSCapacity

                 

                20140730 113552.340009 mcell: RULES: BMC-IMC110801I: refine_drop_all_but_notify_events.mrl, 20: refine drop_all_but_as_eventspring: PATROL_EV #40133: Rule execution starting with

                $EV = 0xa54db80 (class: PATROL_EV,   event_handle: 40133, mc_ueid: its-patrol-t3.mcis.washington.edu@140.142.249.47:3181.1404838475.24242)

                 

                20140730 113553.362228 mcell: RULES: BMC-IMC110801I: refine_notify_events.mrl, 20: refine populate_slots_from_p_origin: PATROL_EV #40134: Rule execution starting with

                $EV = 0xa54d6f0 (class: PATROL_EV,   event_handle: 40134, mc_ueid: its-patrol-t3.mcis.washington.edu@140.142.249.47:3181.1404838475.24250)

                 

                20140730 113553.363156 mcell: RULES: BMC-IMC110203I: refine_notify_events.mrl (24;4): populate_slots_from_p_origin:  $EV.mc_object_class = FILESYSTEM

                 

                20140730 113553.363435 mcell: RULES: BMC-IMC110203I: refine_notify_events.mrl (25;4): populate_slots_from_p_origin:  $EV.mc_object = root

                 

                20140730 113553.363969 mcell: RULES: BMC-IMC110203I: refine_notify_events.mrl (26;4): populate_slots_from_p_origin:  $EV.mc_parameter = FSCapacity

                • 6. Re: How do refine rules actually work?
                  Charles Kelley

                  Hi Danny,

                   

                  The refine rules simply refine an event (i.e modify slot values), then it moves on to the next rule phase (Filter). 

                   

                  You could use confirm_external() if it was necessary to confirm via an external command/script.  If it's not necessary to call an external script, then that is overkill.

                   

                  If you modified the status to CLOSED in the refine rule phase the event would be discarded, because of the 'EventAutoClose=Yes' parameter in the mcell.conf.  With that parameter set to Yes (the default), any event closed at or before the new rule phase is dropped (and in implicit duplicate detection performed, the first duplicate found is closed).

                   

                  If you simply want to filter certain events, the easiest way is to just use a filter rule.

                   

                  You can also discard events via the drop_new pimitive in the New rule phase (or, again, set the status to CLOSED).

                   

                  Charles

                  • 7. Re: How do refine rules actually work?
                    Daniel Gibson

                    Well thanks for the response Charles,

                     

                    Yes I understand I can use the other phases to discard events but I think you are missing the point.  The documentation clearly describes the ability to discard an event from the Refine phase based off the exit status of the confirm_external() primitive.  It is not working..."why not" is where I am now.  I am testing each Rule Phase so I have a clear and precise understanding of how they work or don't work.  If the doumentation states something should work so, then it should work so...or is it broke?  If it is broke then development needs to address the issue and resolve.  Otherwise the ticket I opened (ISS04337830) is useless and therefore why do I need to pay BMC a yearly maintenance fee.

                     

                    I am not being difficult, I am being thorough so I can actually utilize the product to its fullest potential.

                     

                    Danny

                    • 8. Re: How do refine rules actually work?

                      My responses in-line as >>

                      Also, I'm rolling all your questions into this one response.

                       

                      You wrote: I am new to ProactiveNet and MRL but I am diving into the language and trying to manipulate the events in the Refine Phase.

                      >> Welcome to MRL

                       

                      From the documentation it states that the way a refine rule works is that if you match your ECF then the event then gets passed into the next Phase (Regulate) but if your ECF does not match the event is discarded.

                      >> From the doc: (ECF) determines whether an action or assignment must take place for the event under analysis...(I'm leaving off the rest because it isn't relevant). The ECF determines if the rule body is processed or not.  If the event matches the ECF, then the rule body is implemented against the event.  Otherwise the event skips to the next rule.

                       

                      >> Confirm_external and get_external are primitives (functions) designed specifically to be executed in refine rules, however, one would not typically use an external script to validate whether or not an event should be stored.  There are more efficient methods to discard events.  For example, filter rules are designed to drop events.

                       

                      I am not seeing it work that way and I am unsure why.

                       

                      What I am attempting to do is Refine and ECF to only NOTIFY_EVENTS...here is the simple code.

                       

                      refine refine_drop_all_but_notify_events: PATROL_EV($EV)

                              where [ $EV.p_class == NOTIFY_EVENT AND $EV.p_catalog == AS_EVENTSPRING ]

                              {

                      strtolist($EV.p_origin,'.',$FLDS);

                      $EV.mc_object_class = listgetelt($FLDS,1);

                                      $EV.mc_object = listgetelt($FLDS,2);

                                      $EV.mc_parameter = listgetelt($FLDS,3);

                              }

                      END

                       

                      >> Here is what your rule is doing: if PATROL_EV has a slot p_class with a value of NOTIFY_EVENT and a slot of p_catalog with a value of AS_EVENTSPRING, then, execute my rule body, otherwise, do nothing.

                       

                      If your purpose is to drop the event, this won't accomplish that, what this will do is move values into mc_object_class, mc_object and mc_parameter if the event matches the ECF.

                       

                      So I guess I am too green to understand how refine rules work.  I see other refine rules in my mcell-log when I dynamically enable trace...but I thought if I listed this refine rule last in the .load file it would have priority and therefore drop the PATROL_EV event if the ECF did not match.

                       

                      >> In your next post you have included the rule phases and noted that events can be discarded in refine, filter, regulate and new rules phases.  This doesn't mean that an event that fails to match an ECF is discarded.  This means that there are ways to drop an event in all of those phases.

                       

                      >> In the next post you ask:

                      OK so why doesn't this specific detail not EXIST! in the BPPM manuals.  The way an event is discarded in a Refine rule is based off aspect of the confirm_external() primitive.  Which is used to execute an external program and PASS the event if the external program returns a zero return (result) code or discard (NOPASS) the event if the external program returns a non-zero return (result) code.

                       

                      >> The manual is correct, confirm_external will drop an event if the called external program (which has to be stored in $MCELL_HOME/etc/<cell>/kb/bin/A or l2 for Linux (I think you are a linux shop) returns a non-zero exit status.  Here is a simple example:

                       

                      This refine rule will drop an event if the called script: test_script stored in $MCELL_HOME/etc/<cell>/kb/bin/A returns a non-zero exit status.  The script is very simple.  It changes directory to the directory name stored in slot mc_object.

                       

                      Here is the script test_script:

                      #!/bin/bash

                      cd "$mc_object"

                      exit

                       

                      Here is the rule that executes confirm_external:

                      refine test_confirm_external : MSEND_EV($EV)

                      where [ $EV.status equals OPEN ]

                      {

                         confirm_external('test_script', [$EV.mc_object]);

                         opadd($EV,'','Test succeeded') ;

                      }

                      END

                       

                      >> The rule states, for MSEND_EV where status is OPEN, perform a confirm_external and opadd, otherwise, do nothing and move on to the next rule.

                       

                      Now when I send an MSEND_EV event to the cell using the following command:

                      [root@bppmisn1 rules]# msend -n bppm_bmc -a MSEND_EV -m "testing confirm external for /opt" -r CRITICAL -v -b "mc_object='/opt'"

                      BMC Impact Poster 9.0.22 (Build 231177686 - 11-Aug-2013) [l2]

                      Copyright 1998-2012 BMC Software, Inc. as an unpublished work. All rights reserved.

                      Message #1 - Evtid = 771979

                      [root@bppmisn1 rules]# mquery -n bppm_bmc -a EVENT -w "event_handle: equals 771979" -s msg

                      BMC Impact Query 9.0.22 (Build 231177686 - 11-Aug-2013) [l2]

                      Copyright 1998-2012 BMC Software, Inc. as an unpublished work. All rights reserved.

                      testing confirm external for /opt

                      >> The test confirms that the event was added to the cell. It returned the message "testing confirm external for /opt".  I validated this two ways:

                      1) the event appears in the console

                      2) the msend script returns a message: Message #1 - Evtid = 771979. The event handle assigned by the cell to the event is 771979.  I then use that result to validate the event exists by running an mquery (as demonstrated above).

                       

                      >> Next, I send a bad event:

                      [root@bppmisn1 rules]# msend -n bppm_bmc -a MSEND_EV -m "testing confirm external for /baddirectory" -r CRITICAL -v -b "mc_object='/baddirectory'"

                      BMC Impact Poster 9.0.22 (Build 231177686 - 11-Aug-2013) [l2]

                      Copyright 1998-2012 BMC Software, Inc. as an unpublished work. All rights reserved.

                      Message #1 - Evtid = 772210

                      [root@bppmisn1 rules]# mquery -n bppm_bmc -a EVENT -w "event_handle: equals 772210" -s msg

                      BMC Impact Query 9.0.22 (Build 231177686 - 11-Aug-2013) [l2]

                      Copyright 1998-2012 BMC Software, Inc. as an unpublished work. All rights reserved.

                      >> The event handle, 772210 doesn't exist, therefore the event was dropped from the cell.

                       

                      >> You go on to say:

                      This seems too be a very IMPORTANT and CRITICAL piece of information regarding Refine rules.  This is buried in the confirm_external() primitive reference and nowhere to be discussed in the Refine Rule section itself...unbelieveable.

                      >> I understand your frustration   Confirm_external and get_external are rarely used and most KBs make no use of these primitives.  Refine rules are for refining.  Perhaps the document writer might have written it differently to be clearer.  They might have said for example: Use refine rules to enrich values into or modify values in an event. Incidentally, there is a primitive called confirm_external that has the capability of dropping an event in the refine rule stage.

                       

                      So now I have two refine rules. The first in the .load file is as follows:

                       

                      refine drop_all_but_as_eventspring: PATROL_EV($EV)

                              where [$EV.p_class != NOTIFY_EVENT OR $EV.p_catalog != AS_EVENTSPRING ]

                              {

                      confirm_external('/opt/bppm/BPPMAgent/pw/server/bin/refine_drop.pl',[]);

                              }

                      END

                      >> This rule states: for PATROL_EV where p_class is not equal to NOTIFY_EVENT or p_catalog is not AS_EVENTSPRING then run this script and evaluate the exit status.  If the exit status is zero, keep the event, if non-zero, drop the event.  Keep in mind that your script won't actually be executed since you have an incorrectly formatted rule.  Scripts and programs invoked by the cell using execute, confirm_external, etc. must be stored in $MCELL_HOME/etc/<cell>/kb/bin/A (if it is a shell script) or $MCELL_HOME/etc/<cell>/kb/bin/l2 (if it is an executable binary on linux).

                       

                      Where the refine_drop.pl just exit(254);

                       

                      And the second refine rule is as follows:

                       

                      refine populate_slots_from_p_origin: PATROL_EV($EV)

                              where [ $EV.p_class == NOTIFY_EVENT AND $EV.p_catalog == AS_EVENTSPRING ]

                              {

                      strtolist($EV.p_origin,'.',$FLDS);

                      $EV.mc_object_class = listgetelt($FLDS,1);

                                      $EV.mc_object = listgetelt($FLDS,2);

                                      $EV.mc_parameter = listgetelt($FLDS,3);

                              }

                      END

                       

                      >> This rule states, for PATROL_EV, where p_class equals NOTIFY_EVENT and p_catalog equals AS_EVENTSPRING, enrich the event slots mc_object_class, mc_object, and mc_parameter, otherwise, do nothing but move on to the next rule.

                       

                      >> The behavior I would expect from the two rules, is that if the event matches the first rule, execute confirm external, but generate an error for the incorrectly formatted invocation of the primitive.  The next rule will enrich NOTIFY_EVENTS.

                       

                      >> Here are a few suggestions.  NOTIFY_EVENTS generally are sent by Patrol Notification Servers.  Assuming you are using a PatrolAgent that is fully capable of sending the event directly to the cell (no mcxp in the mix), then you can shut off all event classes except the notify event using the following PCM rule:

                      PATROL_EV

                      "/EventSetup/Format/BiiP3/active" = { REPLACE = "0" },

                      "/EventSetup/Format/BiiP3/catalogs/0/active" = { REPLACE = "0" },

                      "/EventSetup/Format/BiiP3/catalogs/AS_EVENTSPRING/active" = { REPLACE = "0" },

                      "/EventSetup/Format/BiiP3/catalogs/AS_EVENTSPRING/types/REMOTE_NOTIFY_EVENT/active" = { REPLACE = "1" }

                       

                      This eliminates having to write the rule in the first place.

                       

                      Here is a refine rule that parses NOTIFY_EVENTS:

                      refine set_mc_host_for_RNE : PATROL_EV($EV)

                      where [p_class: equals 'REMOTE_NOTIFY_EVENT']

                      {

                         # We will parse the message field. The field contains all the information we need. I removed some values from sample event.

                         #

                         #msg=' Windows Service RAY_WEBB on host raywebb01 is Down

                         #Remote Event Details: #raywebb01,192.168.46.130,3181,3181,NT_SERVICES,SERVICES_RAY_WEBB,RAY_WEBB,/NT_SERVICES_CONTAINER/NT_SERVICES_CONTAINER#,ServiceStatus,ALARM,3,11/20/2012,12:18:54,Eastern Standard Time,0.00 ,0.60,1353429155 1353429456,46.30,3716,,NT 6.0 Service Pack #2,3,3,,,V3.8.50i

                       

                         # store the original arguments in p_args

                         $EV.p_args              = [ $EV.msg ] ;

                         $RESULT1                = strtolist($EV.msg,char(10)) ;

                         $RESULT2                = listgetelt($RESULT1,2);

                         $RESULT3                = substring($RESULT2,22) ;

                         $RESULT4                = strtolist($RESULT3,',');

                         $EV.mc_host             = listgetelt($RESULT4,1);

                         $EV.mc_host_address     = listgetelt($RESULT4,2);

                         $EV.pes_tcp_port        = stringtoint(listgetelt($RESULT4,3));

                         $EV.pes_udp_port        = stringtoint(listgetelt($RESULT4,4));

                         $EV.mc_object_class     = listgetelt($RESULT4,5);

                         $EV.p_application       = $EV.mc_object_class;

                         $EV.mc_object           = listgetelt($RESULT4,6);

                         $EV.p_instance          = $EV.mc_object;

                         $EV.pes_icon_name       = listgetelt($RESULT4,7);

                         $EV.pes_parent_instance = listgetelt($RESULT4,8);

                         $EV.mc_parameter        = listgetelt($RESULT4,9);

                         #$EV.p_status            = listgetelt($RESULT4,10);

                         $EV.mc_origin_sev       = listgetelt($RESULT4,10);

                         $EV.mc_parameter_value  = listgetelt($RESULT4,11);

                         $EV.pes_alert_date      = listgetelt($RESULT4,12);

                         $EV.pes_alert_time      = listgetelt($RESULT4,13);

                         $EV.pes_tz              = listgetelt($RESULT4,14);

                         $EV.pes_last10          = listgetelt($RESULT4,15);

                         $EV.pes_ave10           = listgetelt($RESULT4,16);

                         $EV.pes_last10_ts       = listgetelt($RESULT4,17);

                         #$EV.pes_last10_tp      = add_to_list(listgetelt($RESULT4,18));

                         $EV.pes                 = stringtoint(listgetelt($RESULT4,19));

                         $EV.pes_user_defined    = listgetelt($RESULT4,20);

                         $EV.mc_host_class       = listgetelt($RESULT4,21);

                         $EV.pes_alarm_min       = listgetelt($RESULT4,22);

                         $EV.pes_alarm_max       = listgetelt($RESULT4,23);

                         $EV.pes_custom_id1      = listgetelt($RESULT4,24);

                         $EV.pes_custom_id2      = listgetelt($RESULT4,25);

                         $EV.p_agent_version     = listgetelt($RESULT4,26);

                         $EV.pes_patrol_home     = listgetelt($RESULT4,27);

                         $EV.p_catalog           = listgetelt($RESULT4,28);

                         $EV.p_class             = listgetelt($RESULT4,29);

                         $EV.p_status            = listgetelt($RESULT4,30);

                         $EV.p_class_group       = listgetelt($RESULT4,31);

                         $EV.p_type              = listgetelt($RESULT4,32);

                         $EV.mc_origin           = $EV.mc_host || ':' || stringtoint(listgetelt($RESULT4,3));

                         $EV.mc_origin_class     = "PATROL Agent" ;

                         $EV.p_agent             = $EV.mc_host;

                         $EV.p_agent_port        = stringtoint(listgetelt($RESULT4,3));

                         $EV.mc_tool             = $EV.mc_origin;

                         $EV.msg                 = substring(listgetelt($RESULT1,1),29) ;

                      }

                      END

                       

                      Finally, if I wanted to drop an event, I would use a Filter rule to do the dropping and forget about confirm_external:

                       

                      filter drop_me : NOPASS

                      PATROL_EV($EV)

                      where [ $EV.p_class not_equals 'NOTIFY_EVENT' AND $EV.p_catalog not_equals 'AS_EVENTSPRING' ]

                      END

                       

                      Hope that helps!

                       

                      Rick Floyd

                      • 9. Re: How do refine rules actually work?
                        Daniel Gibson

                        Hi Rick,

                         

                        Thanks for the information, it really helps having someone who is familar with the tool.  I also went through your parses NOTIFY_EVENTS...even though the line "$RESULT3 = substring($RESULT2,22) ;" assume REMOTE_NOTIFY_EVENT: I get your drift...nice little parser...thanks.

                         

                        First of all, the fact that a specific directory is required for the confirm_external() doesn't make sense since the documentation clearly states the following:

                         

                        Actions are defined in .mrl files located in the kb/bin directory and listed in .load in that directory. The action programs or scripts can be located in kb/bin/A or kb/bin/Arch directory. They can also be located anywhere else on the system.

                         

                        But I went ahead and tried your suggestion and modified the refine as shown below, placed the simple shell script in the kb/bin/A directory, re-compiled the rules, killed the cell and restarted.  I have again tested and the events still do not get discarded.

                         

                        refine drop_all_but_as_eventspring: PATROL_EV($EV)

                                where [$EV.p_class != NOTIFY_EVENT OR $EV.p_catalog != AS_EVENTSPRING ]

                                {

                                        confirm_external('refine_drop',[]);

                                }

                        END

                         

                        The refine_drop shell script only performs an exit...no brain surgery here...

                         

                        #!/bin/sh

                        exit 254

                         

                        This rule compiles fine and doesn't complain in the trace file that its incorrectly formatted but it didn't complain previously either when I specified the complete path.  It doesn't complain about the fact it cannot find the script...

                        My guess is that this portion of code in the refine phase is broken.  I am performing such a SIMPLE test with virtually nothing involved except two refine rules and one simple shell script it seems unlikely this couldn't be duplicated on another system.  The BPPMAgent version I have installed is: BMC ProactiveNet Integration Service 9.5.00 build 251215503

                         

                        The mcell-log trace does not show any error conditions:

                         

                        20140731 074411.814296 mcell: RULES: BMC-IMC110801I: refine_drop_all_but_notify_events.mrl, 20: refine drop_all_but_as_eventspring: PATROL_EV #41002: Rule execution starting with

                        $EV = 0x91e7c90 (class: PATROL_EV,   event_handle: 41002, mc_ueid: ITS-DCOM-TEST6@172.21.243.80:3181.1406145740.1399463)

                         

                        20140731 074411.817390 mcell: RULES: BMC-IMC110801I: refine_drop_all_but_notify_events.mrl, 20: refine drop_all_but_as_eventspring: PATROL_EV #41003: Rule execution starting with

                        $EV = 0x91e87d0 (class: PATROL_EV,   event_handle: 41003, mc_ueid: ITS-DCOM-TEST6@172.21.243.80:3181.1406145740.1399466)

                         

                        So at this point I will try on a Windows box and see if it works...

                         

                        Thanks again for your help,

                        Danny

                        • 10. Re: How do refine rules actually work?

                          I agree that this is a bug with confirm_external on BPPM 9.5.  I've confirmed the behavior with the Linux version of the cell.  With confirm_external functions defined in the body of the rule, the function doesn't fire and the body of the rule terminates at the point where the confirm_external() primitive is invoked.

                           

                          I created the following rule:

                           

                          I send a test event using:

                          msend -n ep1a -a MSEND_EV -m "testing confirm external for /baddirectory" -r CRITICAL -v -b "mc_object='100';mc_object_class='TEST'"

                           

                          I get the following result from a query of mc_operations: (note I sorted the operations log in order)

                          0x53da6dde,test.mrl:refine test_confirm_external,,,ECF processed

                          0x53da6dde,test.mrl:refine test_confirm_external,,,function not yet fired,

                           

                          Basically, the ECF is processed, the first opadd before confirm_external is processed but the opadd after confirm_external is not processed.  This leads me to believe that the confirm_external is causing the rule to terminate.  This is running on cell version 9.5 SP1.

                           

                          Hopefully this helps to have confirmation.  However, as stated previously, this approach to validating a rule is not advised.  It is not a best practice and it would lead to poor event processing performance.

                          1 of 1 people found this helpful
                          • 11. Re: How do refine rules actually work?

                            Trapped error in trace:

                            20140731 111414.663213 mcell: RULES: BMC-IMC110085E: Error 405 occurred during processing of event  1618: *** RUNTIME 405 *** Illegal call : unknown predicate re_confirm_external/2.

                             

                            20140731 111414.663264 mcell: RULES: BMC-IMC110082E: Processing of refine_test__test_confirm_external(MSEND_EV,0x98d6498) aborted (position in sources: )

                            • 12. Re: How do refine rules actually work?
                              Daniel Gibson

                              Hi Rick,

                               

                              Thank you for the confirmation.  That helps tremendously knowing its a bug and not my approach.  Again I am not sure that when you say "Best Practice" that this is not an approach I want to take is realized yet.

                               

                              My intention is to minimize Policy based event management and instead use strictly a rule base approach as follows:

                               

                              Filter events at each source to minimize event generation (this is not just BMC events, in fact we have more non-BMC events in our environment)

                               

                              HA Cells pair for each event source (could be more pairs per source depending on numEvents)

                              Refine Phase

                              • Match ECF
                                • Query enrichment DB
                                  • successful query --> populate slots with enrichment data
                                  • unsuccessful query --> write event to centralized syslog server then discard event

                               

                              Filter Phase

                              • Match ECF
                                • Verify slot requirements
                                  • successful --> PASS
                                  • unsuccessful --> NOPASS (write event to centralized syslog server then discard event)

                               

                              Regulate Phase

                              • Match ECF
                                • Either Form1 or Form 2 utilized on a case by case scenario.  This type of regulate phase seems most appealing where logs from an application like Weblogic where all the app servers are seeing the same problem downstream (database issue) and are spewing events.  I can see using this phase to regulate these events, generate (send) a custom event and discard the originals...not sure yet but this would definately be a later implementation
                                • Discards will be logged to centralize syslog server

                               

                              New Phase

                              • Match ECF
                                • DeDup Phase either new or update
                                • Discards will be logged to centralized syslog server

                               

                              Abstract Phase

                              • Match ECF
                                • Used to establish relationships between multiple events to generate a single abstract event based of specific deDup slots defined
                                • Visual collectors defined to display abstracted events and their parents
                                • Later implementation as specifics will have to be discovered over time

                               

                              Correlate Phase

                              • Match ECF
                                • Used to establish correlations between diverse events from multiple sources
                                • Later implementation as specifics will have to be discovered over time

                               

                              Execute Phase

                              • Match ECF
                                • Based on specified slot values perform actions by passing event data to our notification system
                                • Based on specified slot values perform actions by running remote ssh commands on mc_host to populate additional data into event to help isolate root causes
                                • Advance features to TBD in later implementations

                               

                              Threshold Phase

                              • Match ECF
                                • Used to detect certian number of like events based off dup_detect facet
                                • Update propagate flag
                                • Advance feature will be implemented in later implementation as need arises

                               

                              Propagate Phase

                              • Match ECF
                                • Based on propagate flag being set
                                • Forward event to higher level cell
                                • Increase severity of event (escalate)

                               

                              Timer Phase

                              • Match ECF
                                • Used to escalate event if severity is matched
                                • Used to close events based on time and severity
                                • Later implementations based off discovered needs

                               

                              Delete Phase

                              • Match ECF
                                • Will be in later implementations, not sure how I would use immediately
                                • Perhaps others have good ideas on how to best use

                               

                              I know I will have some Policy based event management including Dynamic Data Tables and Match Tables but will only know once I start proto-typing.

                               

                              Anyway again thanks Rick for your help and input...I will take it to heart.

                               

                              Hopefully I can continue on now to test the other phases so I understand their specific functions and behavior...

                               

                              Thanks,
                              Danny