Troubleshooting filtering events

What if FILTER or MATCH is not producing the desired results and you are unable to determine the problem by desk-checking or simple experimentation?

FILTER_TRACE

When TRACE(FILTER) is in effect FILTer and MATCH populate the universal field FILTER_TRACE that might be forwarded to the SIEM like any other universal field as part of any syslog message. FILTER_TRACE contains a trace of how FILTer or MATCH has proceeded to its logical conclusion with a string of the format nnx/nnx/nnx/...  where nn is the serial number described previously and x is either T or F to indicate whether it is evaluated as true or false. A value of FILTER_TRACE for a message for the preceding statement might be 2T/3F/1T/ that would indicate that filter serial number 2 – FIELDX(= value) – had evaluated true and filter serial number 3 – FIELDY(= value) – had evaluated false, causing the FILTER parameter – serial number 1 – to evaluate true. (FILTER and MATCH both return true to mean format and forward the event and false to mean filter out or downgrade the event so a MATCH all of whose comparisons are true returns true; a FILTER all of whose comparisons are true returns false.)

In the FILTER_TRACE value, the F indicator might appear alone or might be accompanied by either of two modifiers: Fc or Fm. The presence of a modifier indicates that the comparison was false because the field was missing (see Missing Fields). F with a modifier indicates that the field was missing because it was not present in the SMF or Event record, typically either because the SMF record was a subtype, IFCID or event type that did not include the field (Fc), or because the triplet for the section containing the field was zero (Fm). When the F indicator appears without a modifier it indicates that the field was present but the specified comparison was false.

You can leave FILTER_TRACE in place in FIELDS() until you are certain of your FILTer or MATCH specification. If TRACE(FILTER) is not in effect the overhead for FILTER_TRACE is very modest. You can turn TRACE(FILTER) on and off on the fly with the MODIFY command. For more information, see MODIFY command.

Message CZA0309I

When TRACE(FILTER) is in effect FILTer and MATCH assign a unique serial number to each FILTer or MATCH parameter and logical test. The number is logged in message CZA309I.

Example

Assume the hypothetical parameter file statement

SMF xx FILTER( FIELDX(= value) FIELDY(= value) FIELDZ(= value) )

When the preceding statement were parsed with TRACE(FILTER), in effect the CZA0309I output might be:

CZA0309I Filter serial 1: SMF xx statement[3]: FILTER(FIELDX ...)
CZA0309I Filter serial 2: FILTER[1]: FIELDX(= value)
CZA0309I Filter serial 3: FILTER[2]: FIELDY(= value)
CZA0309I Filter serial 4: FILTER[3]: FIELDZ(= value)

The meaning of the various CZA0309I fields is as follows:

CZA0309I Filter serial sss: type[sub]: parm(op ...)

sss is the unique serial number assigned to the logical test. It is used in the FILTER_TRACE value described later in this topic.

type is the parent parameter of the parameter (parm) that generated the logical test.

sub is the position of the parameter that generated the logical test (within its parent parameter). In the preceding examples:

  • FILTER(FIELDX ...) is the third parameter of the SMF xx statement;
  • FIELDX(= value) is the first operand of the FILTER parameter, and so forth.

parm is the parameter that generated the logical test.

op … is an approximation of the operands of parm.

CZA0309I messages might not be exactly one to one with the parameters you coded. For example, a single FILTer or MATCH parameter might itself generate multiple CZA0309I messages.


TRACE(FILTER)

Troubleshooting is facilitated by BMC AMI Defender TRACE specification TRACE(FILTER). See Using the TRACE facility. When TRACE(FILTER) is in effect, rather than actually filtering out an event, FILTer or MATCH downgrades the event’s SIEM severity to Debug and forwards it to the SIEM (and optionally logs it in any LOCAL data set). The presence of these events in your SIEM (and optionally any LOCAL data set) allows you to determine that the events in question were truly filtered out, as opposed to being missing because they did not actually occur, or because of an incorrect EXIT specification in SMFPRMxx.


Was this page helpful? Yes No Submitting... Thank you

Comments