<div dir="ltr"><div><div><div><div>Hi David!<br><br></div>If a log message does not match any pattern for a parser, syslog-ng db-parser sets its .classifier.class to &quot;unknown&quot; regardless of the field&#39;s previous state. So if it matched on a previous parser, the next parser will overwrite it if it doesn&#39;t match on that. I think it&#39;s a bug rather than a feature, so could you please open an issue for that on github? <br>
<br></div>You can merge patterndb .pdb files easily with &quot;pdbtool merge&quot; command, which is shipped with syslog-ng. It&#39;s simpler than having junctions :).<br><br></div>Best Regards,<br></div>Viktor<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Apr 11, 2014 at 9:52 PM, David Hauck <span dir="ltr">&lt;<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Robert,<br>
<div class=""><br>
On Friday, April 11, 2014 12:19 PM, <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a> wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I guess the problem is that patterndb parsers were not thought to be<br>
&gt; used this way, and each parser sets the .classifier.class value based<br>
&gt; on its own rules, overwriting any previous values. Consequently,<br>
&gt; merging the patterndbs into a single file would definitely work.<br>
<br>
</div>As it turns out all of the pattern DBs here (these are just the stock files from: <a href="https://github.com/balabit/syslog-ng-patterndb" target="_blank">https://github.com/balabit/syslog-ng-patterndb</a>) define the same &#39;class&#39; (so the results of .classifier.class should always be &#39;system&#39; after running through each of the parsers, no?).<br>

<div class=""><br>
&gt; Another option could be a variant of your second idea: you use a<br>
&gt; single log statement, and embed the parsers into a junction, where<br>
&gt; each channel of the junction contains a filter (to process only the<br>
&gt; messages that the parser can parse), and one of the parsers.<br>
&gt; Something like:<br>
&gt; log {<br>
&gt;   filter(f_auth);<br>
&gt;   junction{<br>
&gt;     channel {filter (program(sshd)); parser(&quot;sshd&quot;);}<br>
&gt;     channel {filter (program(sudo)); parser(&quot;sudo&quot;);} ....<br>
&gt;   }<br>
&gt; }<br>
<br>
</div>Thanks, I&#39;ve tried this and it does appear to address this problem (notwithstanding the fact I mention above, where each pattern file specifies the same .classifier.class value).<br>
<br>
I&#39;m going to follow-up with another question related to boolean filters and embedded log statements since some of the follow-on filtering criteria now appears unexplainable.<br>
<br>
Thanks,<br>
-David<br>
<div><div class="h5"><br>
&gt; Robert<br>
&gt;<br>
&gt; On Friday, April 11, 2014 19:18 CEST, David Hauck<br>
&gt; &lt;<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Hello,<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve only recently dug into some more intricate &#39;syslog-ng&#39;<br>
&gt;&gt; configurations<br>
&gt; and had a question regarding &#39;log&#39; construct blocks where multiple &#39;parser&#39;<br>
&gt; references exist. I&#39;ve been trying to do something like the following<br>
&gt; (testing with the supplied example pattern databases):<br>
&gt;&gt;<br>
&gt;&gt; log {<br>
&gt;&gt;    filter(f_auth);<br>
&gt;&gt;    parser(&quot;login&quot;);<br>
&gt;&gt;    parser(&quot;sshd&quot;);<br>
&gt;&gt;    parser(&quot;su&quot;);<br>
&gt;&gt;    parser(&quot;sudo&quot;);<br>
&gt;&gt;    log {<br>
&gt;&gt;       filter(f_class_system);<br>
&gt;&gt;       ...<br>
&gt;&gt;    };<br>
&gt;&gt; };<br>
&gt;&gt;<br>
&gt;&gt; The problem I&#39;m having is that extracted values from matched rules<br>
&gt;&gt; appear<br>
&gt; to be lost when the matched rule exists in a pattern db *other than<br>
&gt; the last referenced parser() db*. Specifically, if a rule is matched<br>
&gt; in the &#39;sshd&#39; db above the following &#39;f_class_system&#39; filter (which<br>
&gt; attempts to match<br>
&gt; &#39;.classifier.class&#39;) *does not* match; however, if a rule is matched<br>
&gt; in the &#39;sudo&#39; db above the &#39;f_class_system&#39; filter *does* match.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m sure this is perfectly explainable, but I can&#39;t find any<br>
&gt; documentation/Google references specifically outlining this behaviour.<br>
&gt; Given the above and in order to work around this I assume I would have<br>
&gt; to, either: 1) combine all of the rules into a single db file, or 2)<br>
&gt; break out each &#39;parser&#39; reference into a separate embedded &#39;log&#39;<br>
&gt; construct (not ideal since the filtering et mechanics in each would be<br>
&gt; identical and for maintenance reasons I&#39;d like to consolidate these into<br>
&gt; a single &#39;log&#39; construct). Both options are less than ideal. Is there a<br>
&gt; better way?<br>
&gt;&gt;<br>
&gt;&gt; Really appreciate any help you might be able to offer.<br>
&gt;&gt;<br>
&gt;&gt; Thanks,<br>
&gt;&gt; -David<br>
&gt;&gt;<br>
&gt; __________________________________________________________<br>
&gt; ____________<br>
</div></div>&gt;&gt; ________ Member info:<br>
<div class="">&gt;&gt; <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
&gt;&gt; Documentation:<br>
&gt;&gt; <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
&gt;&gt; FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; __________________________________________________________<br>
</div>&gt; ____________________ Member info:<br>
<div class="HOEnZb"><div class="h5">&gt; <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a> Documentation:<br>
&gt; <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a> FAQ:<br>
&gt; <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</div></div></blockquote></div><br></div>