List - As I continue to read through the forums and documentation, I hope I do not ask too obvious a set of questions below. Sometimes we can be staring at all the tools we need to solve a problem, but we simply have not yet imagined how to put them all together to achieve it. So when I say any and all input is appreciated, I really mean it.
I have an interesting problem where we intend to use rsyslogd to pull in messages from an enterprise and use it to route these messages to various destinations. I have some questions about how best to leverage rsyslog's capabilities. This solution is already half implemented. I'll first give some background and then ask a few questions. Any input or opinions are appreciated. I continue to read through the documentation and forums to absorb as much information as possible. Background: Logically, rsyslogd must make intelligent decisions about where to route these messages to based on what kind of device it is (router, firewall, server, etc). The challenges here are that 1. there is no comprehensive list mapping hosts to kinds of devices. 2. There are thousands of devices, and it will not always be possible to determine what kind of device it is based on the message itself. Architecturally, there are several rsyslogd instances running on two machines per region for redundancy. Each should be able to read the same configuration rules and potentially a) forward to the same destinations b) write to the same files. (There shoudl be no duplicate messages.). I wonder here if there will be a problem with many instances writing to the files. (The writing to files would only be for dev purposes anyway, but I should still konw the answer for completeness.. ) Questions: My approach to the logic will be to first compare a message to a list to see if the host matches an entry in the list. If so, then the type of device will be known and a decision can be made on routing it. When a match is found the last line in that rule or if stanza will be "stop" So, 1. Can I read a list from a file of pairs consisting of a) hostname and b) value, and then dynamically based on the value route to the iusing the correct rule? 2. I notice the call statement for calling a ruleset.. but can I source the ruleset from a file? can I build an array from a list of values in a file or a database? If a message is not in the list of hosts, then try to decipher what the message may have come from. (Strategies for creating regex based on this is a separate topic beyond the scope of this email. :-) For the purposes of this email, let's assume I can accomplish this task) 3. Once again I'd like to source in the rules from a file. This could simply be a sourcing in of the file so that the several .conf files for the respective rsyslogds can have their instance specific config and that config can reference the part of the config file that is common to all.. 4. As we discover what type of device a message came from, might there be a way to push the hostname onto a stack or into an array and also into a file (such as to the end of an external list of hostname/value pairs) ? 5. Finally, could I solve all of this with messages and queues and modules rsyslogd? For example, could I configure rsyslogd to create special "action" messages to represent actions rsyslogd should take to act on the "content" messages being routed through rsyslogd? As I said, the solution is already half implemented. I can solve the problem, but I would like to solve it in the best and most maintainable way possible, thus my questions. I don't mean to overly complicate this, but if a little extra complexity can get me a more maintainable solution, I'm all for it. Thanks in advance!, Justin _______________________________________________ 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.
