OK. Let's start from the beginning. 1. Monitoring files this way requires your forwarder to run with root permissions in order to be able to read all those files. It might be problematic with your s...
See more...
OK. Let's start from the beginning. 1. Monitoring files this way requires your forwarder to run with root permissions in order to be able to read all those files. It might be problematic with your security team and is generally not the best idea (although it sometimes can't be avoided indeed). 2. Monitoring the .bash_history files is not the very good idea for monitoring user activity. You can easily manipulate the bash history, you can turn it off completely or bypass it. There are other ways to monitor user activity (some of them are more convenient, some not, I admit). If you want to limit yourself to just bash and have a log of bash history entries you can set the option syslog_history for bash and have it log to local syslog daemon - it's still not a great and fail-safe solution but it's way better than reading each user's separate file. 3. If you want to stick with your option of reading the .bash_history files, you should make sure your events are timestamped - if environmental variable HISTTIMEFORMAT is set, bash uses its contents to format the timestamp it includes in the history file. This way you can have your entries timestamped. You should make this variable persistent across your whole environment (set it in your /etc/profile.d/). Without it the behaviour will be as you're describing - the events are not timestamped so Splunk has no way of telling when the events are from. 4. I hope you don't have too many users on your box because you might run out of file descriptors if you open to omany files. 5. Oh, and BTW, 7.x has been obsolete for some years now so it would be time to consider upgrade