I have seen that the eve.json filename can be formatted this way filename: eve-%Y-%m-%d-%H:%M:%S.json but I would be interested on a no-time-dependant identification. Something like eve-1.json for the first log, and eve-2.json for the second one, and so on, increasing each time a new log file is created. The purpose of this is having the log files in order without time consideration. Ideally it would be persistent, I mean, when suricata starts would check for past logs in the directory and continue the count from the biggest one.
I have been checking and didn`t find something like this but just to make sure: There is nothing like this, right? Or something I could achieve something similar with?
I also have been checking the code to see if I would be able to develop it myself, I am still trying to understand the code so I might be really wrong but to achieve what I want it would be something inside
If I understand correctly, according to the documentation ( threaded-file-output , the files do get the name “eve.x.json” but the problem is that when HUP signal is sent the name is still the same, and I want it to increase x +1. This is because a log transporting issue that I am having, I want files to be in order(that’s why the increasing number) and not be named the same(for avoiding duplicated sending) , but time is probably inconsistent y my system.
Reading my post, I think I didnt explained it correctly so I am going to edit it to improve it.
I am currently not using logrotate because it changes the name of the original file when rotated. So when this was done, it was treated as a new file and it was transported again, creating duplicated logs. What I need is to directly create the file with a new name.
Then I guess I might have to develop it myself, is this SCLogFilenameFromPattern the correct way to start from?
You can get a close approximation to this. Assuming you don’t have the threaded option enabled (which is not enabled by default), set the filename to something like:
filename: eve-%s.json
this will use the UNIX time in seconds. On each HUP it will get a new timestamp. Your custom transporter/rotator may need some logic tho, like:
find the most recent log file
send sighup
transfer and delete most recent log file before the hup
Starting and 1 and working forward complicates things when the above should work just as well.