On Mon, 25 Apr 2022, Mariusz Kruk via rsyslog wrote:
Sure. I work with them, I know ;-)
It's just that for some, you can do the same but using rsyslog to process the
message (even filter some events out or trim them or do many other fancy
stuff) an send them directly to SIEM (by means of native SIEM API, not by
syslog)
instead of killing the server with IOPS. That's all.
fair point, but I'll point out that since rsyslog is buffering the writes to
disk, the IOPS load is not as high as you would think. It's sequential writes
and reads, and in practice should be just sequential writes as the reads should
be able to be served from ram (the files should be read shortly after they are
written, so should still be cached)
It would be interesting to look into the performance (CPU and I/O) of writing to
disk and having the files read in batches vs posting each message to the SIEM. I
think there are enough variables involved that it's not an obvious win either
way.
David Lang
_______________________________________________
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.
