Question about potential consequence of patch to rotate Suricata logs daily.

Question about potential consequence of patch to rotate Suricata logs daily.

[Adolf Belka]

Hi Michael,

I saw that patch

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=30ccb9ed80ee3ad70403794da4c937fd183b9bd8

had been created.

It seems to me that this change will mean that there will only ever be 52 days worth of logs for Suricata. The global value for rotate is 52 which is intended to give a tear's worth of data for the various graphs.

With the Suricata logs being rotated daily and with the same global rotate value ( there is no modified rotate value for the Suricata section) then there will only ever be 52 days worth of Suricata Logs. This will mean that the Suricata throughput graph will only show about 7 weeks worth of data when the Year option is selected.

Was this the intent?

If not then there probably needs to be a rotate entry in the Suricata section with rotate 393 to give a year's worth of data but then that will put back the same amount of logs for people who have very small disk drives.

If yes then maybe the Year option on the Suricata graph should be removed or changed to 7 weeks as the 52 days would then be around 7.5 weeks of data available.

It could also be that I am not familiar enough with the rotate package and therefore my concerns are not valid. So I am open to getting clarification.

Best regards,

Adolf.

Re: Question about potential consequence of patch to rotate Suricata logs daily.

[Bernhard Bitsch]

Hi,

the IPS graphs are generated from the iptables collectd samplings.
They are independent from the log files.
The log section of the WUI isn't touched, also. It depends on 
/var/log/suricata/{fast|alert}.log only.

BR,
Bernhard

Am 21.04.2026 um 18:20 schrieb Adolf Belka:
> Hi Michael,
> 
> I saw that patch
> 
> https://git.ipfire.org/? 
> p=ipfire-2.x.git;a=commit;h=30ccb9ed80ee3ad70403794da4c937fd183b9bd8
> 
> had been created.
> 
> It seems to me that this change will mean that there will only ever be 
> 52 days worth of logs for Suricata. The global value for rotate is 52 
> which is intended to give a tear's worth of data for the various graphs.
> 
> With the Suricata logs being rotated daily and with the same global 
> rotate value ( there is no modified rotate value for the Suricata 
> section) then there will only ever be 52 days worth of Suricata Logs. 
> This will mean that the Suricata throughput graph will only show about 7 
> weeks worth of data when the Year option is selected.
> 
> Was this the intent?
> 
> If not then there probably needs to be a rotate entry in the Suricata 
> section with rotate 393 to give a year's worth of data but then that 
> will put back the same amount of logs for people who have very small 
> disk drives.
> 
> If yes then maybe the Year option on the Suricata graph should be 
> removed or changed to 7 weeks as the 52 days would then be around 7.5 
> weeks of data available.
> 
> It could also be that I am not familiar enough with the rotate package 
> and therefore my concerns are not valid. So I am open to getting 
> clarification.
> 
> Best regards,
> 
> Adolf.
> 

Re: Question about potential consequence of patch to rotate Suricata logs daily.

[Adolf Belka]

Hi Bernhard,

Thanks for the clarification. So my worries were unfounded, good to know.

Regards,

Adolf.

On 21/04/2026 19:05, Bernhard Bitsch wrote:
> Hi,
> 
> the IPS graphs are generated from the iptables collectd samplings.
> They are independent from the log files.
> The log section of the WUI isn't touched, also. It depends on /var/log/suricata/{fast|alert}.log only.
> 
> BR,
> Bernhard
> 
> Am 21.04.2026 um 18:20 schrieb Adolf Belka:
>> Hi Michael,
>>
>> I saw that patch
>>
>> https://git.ipfire.org/? p=ipfire-2.x.git;a=commit;h=30ccb9ed80ee3ad70403794da4c937fd183b9bd8
>>
>> had been created.
>>
>> It seems to me that this change will mean that there will only ever be 52 days worth of logs for Suricata. The global value for rotate is 52 which is intended to give a tear's worth of data for the various graphs.
>>
>> With the Suricata logs being rotated daily and with the same global rotate value ( there is no modified rotate value for the Suricata section) then there will only ever be 52 days worth of Suricata Logs. This will mean that the Suricata throughput graph will only show about 7 weeks worth of data when the Year option is selected.
>>
>> Was this the intent?
>>
>> If not then there probably needs to be a rotate entry in the Suricata section with rotate 393 to give a year's worth of data but then that will put back the same amount of logs for people who have very small disk drives.
>>
>> If yes then maybe the Year option on the Suricata graph should be removed or changed to 7 weeks as the 52 days would then be around 7.5 weeks of data available.
>>
>> It could also be that I am not familiar enough with the rotate package and therefore my concerns are not valid. So I am open to getting clarification.
>>
>> Best regards,
>>
>> Adolf.
>>
> 
> 

Re: Question about potential consequence of patch to rotate Suricata logs daily.

[Michael Tremer]

Hello,

I think your concerns are important and I do share a lot of them.

We do have very inconsistent logging - or rather the rotation of the logs is not very consistent.

Your initial assumption is correct, that at the top of the configuration file, we intend to rotate 52 times a year which results in keeping logs for a whole year split into chunks of one per week.

That being said, some other logs are then marked to rotate monthly, e.g. /var/log/wtmp. So we would have up to 52 months of those. Why is that? I am not sure…

The motivation alone seems to be expected size. /var/log/wtmp does not grow a lot, so a rotation of a couple of bytes is not really worth it. Let’s do it weekly.

Suricata’s logs are actually growing really fast on some machines and people have been complaining about high disk usage, so I thought it would be more suitable to rotate once a day.

Generally I think 52 days is plenty of logging. If people prefer to store more than that, on the firewall itself is potentially not the best place to do so. There is a remote syslogging option available.

Some data, like the graphs or even the Suricata alerts are being stored separately and they do have other retention times.

Hope this helps.

-Michael

> On 21 Apr 2026, at 21:08, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Bernhard,
> 
> Thanks for the clarification. So my worries were unfounded, good to know.
> 
> Regards,
> 
> Adolf.
> 
> On 21/04/2026 19:05, Bernhard Bitsch wrote:
>> Hi,
>> the IPS graphs are generated from the iptables collectd samplings.
>> They are independent from the log files.
>> The log section of the WUI isn't touched, also. It depends on /var/log/suricata/{fast|alert}.log only.
>> BR,
>> Bernhard
>> Am 21.04.2026 um 18:20 schrieb Adolf Belka:
>>> Hi Michael,
>>> 
>>> I saw that patch
>>> 
>>> https://git.ipfire.org/? p=ipfire-2.x.git;a=commit;h=30ccb9ed80ee3ad70403794da4c937fd183b9bd8
>>> 
>>> had been created.
>>> 
>>> It seems to me that this change will mean that there will only ever be 52 days worth of logs for Suricata. The global value for rotate is 52 which is intended to give a tear's worth of data for the various graphs.
>>> 
>>> With the Suricata logs being rotated daily and with the same global rotate value ( there is no modified rotate value for the Suricata section) then there will only ever be 52 days worth of Suricata Logs. This will mean that the Suricata throughput graph will only show about 7 weeks worth of data when the Year option is selected.
>>> 
>>> Was this the intent?
>>> 
>>> If not then there probably needs to be a rotate entry in the Suricata section with rotate 393 to give a year's worth of data but then that will put back the same amount of logs for people who have very small disk drives.
>>> 
>>> If yes then maybe the Year option on the Suricata graph should be removed or changed to 7 weeks as the 52 days would then be around 7.5 weeks of data available.
>>> 
>>> It could also be that I am not familiar enough with the rotate package and therefore my concerns are not valid. So I am open to getting clarification.
>>> 
>>> Best regards,
>>> 
>>> Adolf.
>>> 
> 
>