On 25.04.2022 14:41, David Lang wrote:
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.
Sure, there is also another layer of OS-level caching/buffering. But in
the end it all has to get written to the disk. ;-) I just think that
passing the events straight through rulesets from input to output (and I
mean the real destination, not to the files) is simply more
straightforward and easier to manage (after all you don't have to - for
example - deal with file rotation and so on). On the other hand, you may
run into some other problems when your rulesets get too complicated and
"run away".
_______________________________________________
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.
