Tech Tip - log ingestion problem (change log level to reduce log data)

[Wolfgang]

A lot of us knows the problem  with the error "Critical: data loss risk - at least one of your child accounts data might be capped, for drill down go to log ingestion view"

You got more log data then you paid already for. Following sk182394 - Cloud Log Analytics & Logging - Ingestion / Retention Solution you can add new license packages to have more disk space available for log data. But you can reduce your log volume if you change the log settings. The graph shows the log ingestion from an environment with around 20 sparc gateways.

Starting December 15. we changed the LogSetting from  "per Connection" to "per Session". We observed a significant change of the needed LogData. I believe it'is about twice or third less then before.

"per Connection" Log settings

new "per session" Log settings

You have to change this for every rule, The setting can be changed via API or via SmartConsole but not in the WebUI of the Infinityportal. 

Without "per Connection" some information is not visible, like NAT. (edit 2026-01-08)

With one of the newer releases the default LogLevel will change to session, but I don't know which version.

articles to investigate Cloud Logvolume

sk181096 - How to Optimize Quantum Cloud Logs

sk182394 - Cloud Log Analytics & Logging - Ingestion / Retention Solution

sk181549 - How to analyze logging rate to estimate daily GB ingestion quota required for Smart-1 Clo...

Log Ingestion

Log Sessions

[Chris_Atkinson]

Nice tip, R82.10 has some new options to help with similar.

[Tomer_Noy]

Indeed, in R82.10 we added a new setting under Settings => Policy Settings => Advanced called "Log Generation Mode".

If you set it to "Aggregated", it will default all rules to generate Session logs instead of Connection logs. You can still customize specific rules to generate Connection logs if needed.

This makes it much easier to switch to Session logs without going over all the rules, and remembering to set the right Track option for future new rules.

https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_LoggingAndMonitoring_AdminGu... 

[Alex-]

We tried this, but some data disappeared, for instance NAT. So I'd say it's to be enabled selectively and not as a whole.

[Tomer_Noy]

Indeed some fields were missing from Session logs, the most painful were various NAT fields.

In latest versions (I believe even in JHF) we added this data. I definitely recommend trying Session logs again if this was the past reason for avoiding it.

[Wolfgang]

@Tomer_Noy  do you have any reference in which JHF or version we can get NAT-Logs without connection logs. I checked this in Smart1-Cloud. Without connection log enabled I don't see any NAT related content.

[Tomer_Noy]

The enhancement exists in R82 JHF36 and R81.20 JHF111.
(listed under PRJ-60790)

https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/R82.00/Take_36.htm 

https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/R81.20/Take_111.htm 

[Wolfgang]

Thanks @Tomer_Noy for the information. Do we need the fix on the gateway and on SMS? And how about SPARC appliance, will be there a version for these embedded GAiA devices ?

[Tomer_Noy]

The fix needs to be installed on the gateway (so that the data will be included in the logs) and on the Log Server and Management (so that log data will be parsed and displayed properly).

Regarding Spark, it looks like it was ported to a certain firmware over R82.00.10, but I'm no longer an expert on that, so maybe @Amir_Ayalon can check if any Spark firmware includes PRJ-60790.

[Amir_Ayalon]

Yes, Spark latest GA R82.00.10 includes this fix.

 Build 998001559

https://support.checkpoint.com/results/sk/sk184357

Thanks

[Gaurav_Pandya]

Agreed. We have enabled logging on a per-session basis for specific rules, such as general internet and backup rules. This approach helps reduce the overall volume of logs while still capturing the necessary details. It’s important to choose the logging options carefully to ensure they meet your requirements.

[Hugo_vd_Kooij]

I must say it is a bit redundant to log both connection and session.

Have you consiedered just running with connections and not sessions?

[Alex-]

Sessions are required for SmartEvent. They are complementary to connections as they provide less technical information and more high-level data relevant for reporting. For instance, I just tried to change the logging of an S2S rule from "per Connection" to "per Session" and I don't see the Decrypt action anymore with IPSEC data, just a regular accept from the remote source to the local one.

Sufficient for reporting, less so for traffic analysis.

[the_rock]

Nice tip @Wolfgang 

[Vanness_Chen]

I am using a local Log Server, and I would like to ask which option—per connection or per session—is more effective in reducing the overall log volume.

The customer reported that in the same environment, Check Point’s log_export generates significantly more logs compared to other vendors, and their syslog server is unable to handle such a high volume of data.

[Tomer_Noy]

Per session is basically an aggregation of all similar connection logs, which will be sent immediately upon the first connection, then will update with an additional log after ~10 minutes if additional connections were spotted.

So per session can be much more effective in reducing overall log volume. In some cases it can even be a 90% reduction.

The amount of reduction greatly depends on the variation between the connection logs. If you have a few hosts making many connections over the same service to the same destination, then it will be greatly compressed. Access to DNS or NTP servers is  a great example of this.

However, if you have many connections and each is different, then session logs might be even a bit larger. It's uncommon, but can happen for example if you have a vulnerability scanner that is scanning your entire network over all ports (I've seen it happen 😀). For such cases you might want a specific rule with connection logs, or maybe even without logging at all.

Reducing the logs with session logs will also reduce log exporting rates.

Another thing to look out for is use of Accounting where it's not needed. This adds to the logs the amount of bytes transferred and can generate additional log updates.

One last thing, in R82.10 (recently released), we added new filters in the log view that can help you find rules that generate the most logs. That can help you pinpoint which specific rules will benefit from activating session logs.