> I notice that mmleefparse is also a new module which is not mentioned > in the release notes.
Sry for overlooking this. > Could you provide a bit more details about what this is and why you It is a component used in log pipelines to fully ingest LEEF formatted messages, e.g. from Firewalls. It's one of the more important structured formats. (more relevant background a bit below). doc: https://www.rsyslog.com/doc/configuration/modules/mmleefparse.html > decided to enable it by default (especially since the git commit > message says it's a PoC)? I agree there is inconsistency - this is default on while e.g. mmjsontransform is not. Overall: I try to keep brief, pls ask further questions when needed. Maybe this is even something for a git hub discussion. Overall, rsyslog has been in use in log/data pipelines since the early 2000's, even when these terms were not yet coined. We see increasing adoption in especially JSON logging, with a preference of metadata-enriched logs. At the same time, many folks do not even remember that rsyslog can do this for 15+ years now. Probably because it is often complicated or some minor but important things are missing. One of our core projects is to address this and make log pipeline use not only efficient but easy to do. One way would be to put everything in liblognorm only. We have instead decided to do it by dedicated smaller modules for reasons. The new mmleefparse, mmsnareparese, existing e.g. mmjsonparse and the important mmjsontransform all address this need. We envision that over time almost everyone will need them - log enrichment at the edge is a hot topic, and so for a very good reason. At the same time, all these module binaries are pretty small. So it may make sense to include them directly in the base package. Pro is also that it enhances usability because it is always present (a typical complaint from rsyslog users is that they need to install additional component packages). An alternative packaging approach is to put all of them into an e.g. rsyslog-pipeline package. From my PoV reduces usability. I would also not be surprised if the binary size is not more than the metadata size itself. I am undecided and appreciate feedback. As a lightly related side note, yaml config-type artefacts are also being much requested. We are thinking hard to support this, at least in some places (upcoming enhancements to mmjsonparse for schema transformation might be such a place). How to do this packaging-wise is actually a larger concern for me (libyaml is almost on any system, but not necessarily on embedded - so disable yaml by compilation or make it a loadable functionality which requires internal interface and mock overhead). Bottom line: the IT logging landscape changes continuously, and rsyslog follows or leads these changes.To remain relevant, adaptation to new tech and trends is necessary, no matter of personal likes (e.g. I do not like yaml that much, but being forced to getting used to it, I see value). I hope this helps with the decision. And, as I said, feedback on the overall topic is highly welcome. Rainer _______________________________________________ rsyslog mailing list https://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.
