El mié., 3 abr. 2019 a las 23:13, Gorman, Kevin via rsyslog (<[email protected]>) escribió: > > My desire for modularity comes from the fact that I need to use puppet to > configure many hosts, and numerous customer environments. Thus, I want to > define the destination address, etc.in one file, which will vary since it's > on systems that can be in another address space, the other side of the world, > and/or for another customer. Then because people are starting to ask for OS > type log files not managed via rsyslog.conf, I want another file for these; > it can be the same across all systems.
There is nothing bad with modularity per se. Just that many folks do not use it proper. and when troubleshooting we need to see the full config because all modules interfere with all others. This is non-trivial and it sometimes really pays to purchase some professional help getting it right ;-) > Finally I have an rsyslog.app.conf that has customer specific logs that are > static across that customer's product hosts. The largest number of logs > defined in an app conf file is 80 at the moment. I any case, if you provide it to customers, I think you should really work hard, and invest time, to become an expert on that matter. > > Currently the app configs are scattered across a large number of files using > the legacy syntax that repeat most of the same info (address, port, > protocol), which is ugly. I could cat all the files into one, but it's still > ugly. Imagine having many hundreds of little files similar to the following > with various addresses and filenames. A lot of duplicated information. > > $WorkDirectory /var/lib/rsyslog > $ActionQueueFileName nlsFwdRule0 > $ActionQueueMaxDiskSpace 1g > $ActionQueueSaveOnShutdown on > $ActionQueueType LinkedList > $ActionResumeRetryCount -1 > /path/to/files/my.file.log @@[2001:4888:a05:3154:e0:ff2:0:b01]:5544 You really should read the doc ;-) This does not work at all nor does it make any sense... Rainer > > Using this approach I go from ~80 files to 3 which is vastly easier to manage > in puppet. Very little duplicated information. > > -----Original Message----- > From: David Lang [mailto:[email protected]] > Sent: Wednesday, April 03, 2019 3:47 PM > To: Gorman, Kevin via rsyslog > Cc: Gorman, Kevin > Subject: Re: [rsyslog] [E] Re: Help with newer syntax a ruleset and forwarding > > If you really want everything to be sent, you don't need to use a specfic > ruleset at all, just have the action be in the main config and all logs, from > all inputs (or at least, all inputs that don't specify a specific ruleset) > will be processed by the main config. > > you could put a queue on the action instead of the ruleset. If there is only > one action in the ruleset, that would be equivalent, but if you later want to > do other things with these logs, you need to decide if you want them grouped > and all using one queue, or each action progressing independently (there are > times when each is the right answer, which gets back to why we can't have > every config, but much of the time a queue on the ruleset works best for > people. > > if you don't have other things happening locally with the logs, you can just > rely on the main queue and not have a separate queue defined on the ruleset > or the action. It's possible to make your system significantly slower in > attempts to make the config 'modular' (which is why you see us ask for the > full config so > frequently) > > David Lang > > On Wed, 3 Apr 2019, Gorman, Kevin via rsyslog > wrote: > > > Date: Wed, 3 Apr 2019 19:57:42 +0000 > > From: "Gorman, Kevin via rsyslog" <[email protected]> > > To: "Gorman, Kevin via rsyslog" <[email protected]> > > Cc: "Gorman, Kevin" <[email protected]> > > Subject: Re: [rsyslog] [E] Re: Help with newer syntax a ruleset and > > forwarding > > > > I want everything to go through the ruleset to the remote system. > > As I understand it, the inputs are each forwarded by the ruleset= and > > everything in rsyslog.conf is forwarded as *.* in the call. > > Then there's the question of where the ruleset gets called (if it matters). > > It's defined in a file read before the file inputs, so I'd think rsyslog > > might not like that. > > > > -----Original Message----- > > From: David Lang [mailto:[email protected]] > > Sent: Wednesday, April 03, 2019 2:51 PM > > To: Gorman, Kevin via rsyslog > > Cc: Gorman, Kevin > > Subject: Re: [rsyslog] [E] Re: Help with newer syntax a ruleset and > > forwarding > > > > On Wed, 3 Apr 2019, Gorman, Kevin via rsyslog wrote: > > > >> So I could get rid of the *.* and the ruleset= in the inputs as shown? > >> That would create a simpler config that works the same, meaning it > >> forwards anything configured, correct? I'm being pedantic I guess... > > > > yes, you want either the call, or the ruleset=, not both. If you want all > > your locally generated logs (and any logs from any other inputs) forwarded, > > then you want the call. If you only want to send the logs from the imfile > > sources, then you want the ruleset= lines and not the call. > > > > David Lang > > > >> # cat rsyslog.all.conf > >> > >> module(load="imfile" mode="inotify") > >> > >> global ( > >> parser.dropTrailingLFOnReception="on" > >> parser.escapeControlCharactersOnReceive="on" > >> workDirectory="/var/lib/rsyslog" > >> ) > >> > >> ruleset( > >> name="linux_forward" > >> queue.type="LinkedList" > >> queue.filename="FwdRule0" > >> queue.maxDiskSpace="1g" > >> queue.saveOnShutdown="on" > >> ) { > >> action( > >> type="omfwd" > >> target="2001:4888:a00:3154:f0:ff2:0:b01" # logserver VIP > >> protocol="tcp" > >> port="5544" > >> action.resumeRetryCount="-1" > >> ) > >> } > >> > >> call linux_forward > >> > >> > >> cat rsyslog.linux.conf > >> > >> input( > >> type="imfile" > >> # ruleset="linux_forward" > >> tag="ansible" > >> file="/var/log/ansible.log" > >> ) > >> > >> input( > >> type="imfile" > >> # ruleset="linux_forward" > >> tag="audit" > >> file="/var/log/audit/audit.log" > >> ) > >> > >> -----Original Message----- > >> From: David Lang [mailto:[email protected]] > >> Sent: Wednesday, April 03, 2019 2:34 PM > >> To: Gorman, Kevin via rsyslog > >> Cc: Gorman, Kevin > >> Subject: Re: [rsyslog] [E] Re: Help with newer syntax a ruleset and > >> forwarding > >> > >> On Wed, 3 Apr 2019, Gorman, Kevin via rsyslog wrote: > >> > >>> The *.* call linux_forward was the key. Much cleaner. Thanks! > >> > >> There was nothing in your old config to tell it to execute the ruleset, > >> you needed to either call the ruleset unconditionally (in which case you > >> don't need the *.*), or you needto add a ruleset="linux_forward" to each > >> of the imfile inputs. > >> > >> putting a call in unconditionally will send all logs, not just the ones > >> from imfile, to the remote system. > >> > >> it all depends on what you are trying to do. > >> > >>> I also see the audit logs in the debug log and at the other end in > >>> tcpdump. I don't see the messages in the remote log system data, but > >>> that's another issue and product receiving the logs. > >>> > >>> I added addMetadata to the module load and a metadata entry to the input > >>> but get debug errors. I guess metadata isn't supported in this old > >>> version or am I missing something else? > >>> > >>> ... > >>> rsyslogd: error during parsing file /etc/rsyslog.d/rsyslog.all.conf, > >>> on or before line 1: parameter 'addMetadata' not known -- typo in config > >>> file? [v8.24.0-34.el7 try > >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rsyslog.com_e_2207&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=stJ62L_yqJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=KmZ2o6OytdrJSRYlV7ukoXSDhbAGd-va7dY5DwHA4Us&s=uwoGMRPzHCxGkHFc_Vc-6dMRKey8VspWpXTBYgPnIrk&e= > >>> ] ... > >>> 1789.633979501:main thread : Called LogMsg, msg: error during parsing > >>> file /etc/rsyslog.d/rsyslog.linux.conf, on or before line 17: parameter > >>> 'metadata' not known -- typo in config file? > >>> rsyslogd: error during parsing file > >>> /etc/rsyslog.d/rsyslog.linux.conf, > >>> on or before line 17: parameter 'metadata' not known -- typo in config > >>> file? [v8.24.0-34.el7 try > >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rsyslog.com_e_2207&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=stJ62L_yqJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=KmZ2o6OytdrJSRYlV7ukoXSDhbAGd-va7dY5DwHA4Us&s=uwoGMRPzHCxGkHFc_Vc-6dMRKey8VspWpXTBYgPnIrk&e= > >>> ] ... > >> > >> I don't remember when addMetadata was added to imfile. we were at > >> 8.40 when we changed the naming scheme, 40-24 - 16 versions * 1.5 > >> months/version = 2 years between the version you are running and when > >> we changed our naming scheme to make it more obvious how old the > >> version is. :-) > >> > >> there were a lot of changes during that time, IIRC they included a > >> complete overhaul of imfile. > >> > >> check the docs shipped with RedHat to see if they mention addMetadata (and > >> do they define it on the module() call or the input() call) or try > >> upgrading to a more current version. > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.adiscon.net > >> _ > >> mailman_listinfo_rsyslog&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb > >> 6 > >> __0PomBTQ&r=stJ62L_yqJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=K3BnaRMXrvc > >> - > >> __JT_m56c2vp7KXDi6-shwSYLcnPXU0&s=vM8-Cf2VYSS-wKgKVFwpsAZc-p55gELsYyc > >> d > >> cK-I9LU&e= > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rsyslog.com_p > >> r > >> ofessional-2Dservices_&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6_ > >> _ > >> 0PomBTQ&r=stJ62L_yqJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=K3BnaRMXrvc-_ > >> _ > >> JT_m56c2vp7KXDi6-shwSYLcnPXU0&s=xXtdEP6M3dhV7zKEzW4ZHtJ7QOdQAs5BV_A3i > >> C 3Mk9A&e= What's up with rsyslog? Follow > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_rger > >> h > >> ards&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=stJ62L_ > >> y > >> qJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=K3BnaRMXrvc-__JT_m56c2vp7KXDi6- > >> s hwSYLcnPXU0&s=aLbxAt79Idm2rjQvo82bSszgyMihItBJ--ExLytXdNA&e= > >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > >> DON'T LIKE THAT. > >> > > _______________________________________________ > > rsyslog mailing list > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.adiscon.net_ > > mailman_listinfo_rsyslog&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6 > > __0PomBTQ&r=stJ62L_yqJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=rhijnK7_ZqfN > > D_NhOFbMs64arcpRShXm_A8yXlumF5k&s=jniFEq7QoOc_sLe-8MYwwKYLU51kGpxaGq_R > > ABeta6s&e= > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rsyslog.com_pr > > ofessional-2Dservices_&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__ > > 0PomBTQ&r=stJ62L_yqJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=rhijnK7_ZqfND_ > > NhOFbMs64arcpRShXm_A8yXlumF5k&s=hK4Bjb2wCwKe2vlkZVpXsS9Ggzy3T2WBwcvX96 > > -55zo&e= What's up with rsyslog? Follow > > https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_rgerh > > ards&d=DwIBAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=stJ62L_y > > qJWGrxRl6wWPMpHwvVUmOyXDBgn3Xxfk-6U&m=rhijnK7_ZqfND_NhOFbMs64arcpRShXm > > _A8yXlumF5k&s=4iswwQ022tzGwMPGh5NZowrMGKfw84hBNiGev0q_6-0&e= > > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > > LIKE THAT. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
