Bug#927736: Please build with --enable-pmnull
On Monday, 22 April 2019 7:09:17 PM AEST Rainer Gerhards wrote: > template(name="raw" type="string" string="%rawmsg%") > action(type="omfwd" target="example.com" template="raw") Nice, this is so short and elegant. :) Thank you very much, it solved my original problem. -- All the best, Dmitry Smirnov. --- It is a mistake to try to look too far ahead. The chain of destiny can only be grasped one link at a time. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#927736: Please build with --enable-pmnull
El lun., 22 abr. 2019 a las 11:00, Dmitry Smirnov () escribió: > > Hi Rainer, > > Thank you sincerely for your excellent work on Rsyslog. > > On Monday, 22 April 2019 6:34:27 PM AEST Rainer Gerhards wrote: > > As upstream maintainer I would be interested in your use case for pmnull. > > I'm not sure if I have a case yet. I'm trying to experiment with centralized > logs processing and forwarding. There are several rsyslogs on various servers > that forward everything (over RELP) to one Rsyslog instance where messages > are processed, converted to JSON and forwarded to Elasticsearch. > > While working with various types of messages originated from various places > (Docker containers, sockets, UDP and TCP listeners) I was trying to find out > the most effective way to process messages and to avoid things like RFC5424 > message inside RFC5424 (from double forwarding a message received by local > rsyslog, then passed to forwarding rsyslog). At some point I tried disabling > all parsers in ruleset to pass unmodified message to forwarding Rsyslog > instance. Unfortunately at that point I've found that "pmnull" is not built > in hence this bug report... actually, we have the "rawmsg" property. This is the message as it was received. All pmnull does is set "msg" to "rawmsg" (and use "" for many other properties). To forward the original content, you can simply do: template(name="raw" type="string" string="%rawmsg%") action(type="omfwd" target="example.com" template="raw") That's it. I wrote pmnull because some folks thought it would be nice to save 0.05% processing time by not unnecessarily parse the message. I even doubt it's that amount of performance enhancement as the messages need to be populated in any case... Rainer > > -- > All the best, > Dmitry Smirnov. > > --- > > Truth — Something somehow discreditable to someone. > -- H. L. Mencken, 1949
Bug#927736: Please build with --enable-pmnull
Hi Rainer, Thank you sincerely for your excellent work on Rsyslog. On Monday, 22 April 2019 6:34:27 PM AEST Rainer Gerhards wrote: > As upstream maintainer I would be interested in your use case for pmnull. I'm not sure if I have a case yet. I'm trying to experiment with centralized logs processing and forwarding. There are several rsyslogs on various servers that forward everything (over RELP) to one Rsyslog instance where messages are processed, converted to JSON and forwarded to Elasticsearch. While working with various types of messages originated from various places (Docker containers, sockets, UDP and TCP listeners) I was trying to find out the most effective way to process messages and to avoid things like RFC5424 message inside RFC5424 (from double forwarding a message received by local rsyslog, then passed to forwarding rsyslog). At some point I tried disabling all parsers in ruleset to pass unmodified message to forwarding Rsyslog instance. Unfortunately at that point I've found that "pmnull" is not built in hence this bug report... -- All the best, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part.
Bug#927736: Please build with --enable-pmnull
> Not sure what are you talking about. "pmnull" is a core module (not a > contributed one) and it does _nothing_ so there are no risks of enabling it. > > "pmnull" is needed to disable parsers because Rsyslog do not allow empty > parsers list... As upstream maintainer I would be interested in your use case for pmnull. Rainer
Bug#927736: Please build with --enable-pmnull
On Monday, 22 April 2019 3:56:45 PM AEST Michael Biebl wrote: > With all your recent wishlist bugs, can you please be a bit more verbose > why you need those modules. Are you planning to use those in production? To each wishlist bug I've included a link to documentation so you could read what those modules are for. IMHO that's better than what I could say about them. Yes, I'm hoping to use some of those modules in production if they are proven to be useful and trial will become possible once they are activated. > I'm usually reluctant to enable contributed (non-core) modules which I > won't use myself and am not able to test. Not sure what are you talking about. "pmnull" is a core module (not a contributed one) and it does _nothing_ so there are no risks of enabling it. "pmnull" is needed to disable parsers because Rsyslog do not allow empty parsers list... -- Regards, Dmitry Smirnov. --- It is a mistake to try to look too far ahead. The chain of destiny can only be grasped one link at a time. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#927736: Please build with --enable-pmnull
Am 22.04.19 um 07:49 schrieb Dmitry Smirnov: > Source: rsyslog > Version: 8.1901.0-1 > Severity: wishlist > > https://www.rsyslog.com/doc/v8-stable/configuration/modules/pmnull.html > With all your recent wishlist bugs, can you please be a bit more verbose why you need those modules. Are you planning to use those in production? I'm usually reluctant to enable contributed (non-core) modules which I won't use myself and am not able to test. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927736: Please build with --enable-pmnull
Source: rsyslog Version: 8.1901.0-1 Severity: wishlist https://www.rsyslog.com/doc/v8-stable/configuration/modules/pmnull.html -- Best wishes, Dmitry Smirnov. --- A man who knows a subject thoroughly, a man so soaked in it that he eats it, sleeps it and dreams it - this man can always teach it with success, no matter how little he knows of technical pedagogy. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.