So if I get this right:
- If we keep the default “Message Processors Configuration” order (pipeline processor before message filter chain), this enabled access to any message fields in extractors or stream rules which have been created by pipeline rules, right ?
- If we change “Message Processors Configuration” order (message filter chain before pipeline processor), this disable access to any message fields in extractors or stream rules which have been created by pipeline rules, right ?
The only reason I decided to look into changing the OOTB “Message Processors Configuration” order, was because of the following scenarios:
While using a ‘Graylog Collector Sidecar’ for Windows and successfully dropping messages using a rule pipeline for winlogbeat messages based of winlogbeat_level == “Information” (we don’t want to hold on Windows info level in Graylog), I then decided to do the same for filebeat messages (from ad hoc Windows apps) based on extractors field adhoc_apps_level == “info”. This last pipeline rule was not dropping messages (like the first one did), UNTIL I reverse the order as explain in #2. Then, both scenarios worked.
How can I achieve the same scenarios (drop winlogbeat & filebeat ‘info’ messages) with keeping the default order as explain in #1.