I saw this article: https://www.splunk.com/blog/2015/04/30/integrating-splunk-with-docker-coreos-and-journald.html
It look like an overkill for a simple task, isn't there a native way to ship journald logs to Splunk?
I know this is an older post, but I didn't see anyone yet mentioning that this looks to have been solved by journald support in recent versions of Splunk (starting in Splunk 8.1), correct?
I've posted about this in another question. this seems to have come up multiple times in questions and people are not upvoting or saying me too on these journald issues.
Splunk provides the TA for Unix / Linux but it's so out of date and doesn't collect these critical logs for systems using systemctl.
Expecting every customer to come up with some silly way of dumping journald to a file and importing it is absurd. We all need to start yelling at our Splunk reps about this issue.
Hi. I'm looking into gathering journal logs as well. I think the solution presented in the link you provide will not work. When the script for trimming the written to journal file start kicking in, Splunk will no longer be able to recognize the file, and will start to read it all over again from the start, if I'm not mistaken.
Another solution to the problem is presented here: https://answers.splunk.com/answers/554744/scripted-input-last-event-lost-journald.html
However I'm not sure if constantly tailing the journal is a good solution performance wise. Also, with this solution, if the UF goes down due to updates or failure, you will lose logs.
I think the best way to go is to somehow use the cursor field to keep track of where you are in the journal, and start reading from last seen cursor when the UF starts, but I haven't yet found a good script for this.
Have you found any better solutions?
Can someone from Splunk PLEASE give a serious answer to this question?
Journal logs from systemctl are not something that it makes sense to ignore, and as I've said in another post about this, should be part of the default TA_NIX support at this point, most distros use this and have for YEARS now.
Asking users to come up with some whack unsupported script to dump logs into a file is BS. you have plenty of scripted inputs in the add on for nix already, solve this in a standard way!
If you want to opensource the development of the nix TA, put it on github or something and start letting customers do it. Having it fragmented and undocumented is dumb.