Observation on Check Point Log Collection
I had a recent support case that involved CheckPoint collection. The customer had a large check point environment. Some of the Check Point logs were being collected on time, but some were not.
The reasons for this were two fold.
Max Receivers needed to be increased if Check Point EPS is over 12K
In the Local Log Collector queues make sure that the Max Receivers in increased from 1 to 2. This setting can be found as follows on the Local Log Collectors. By default 1 Receiver can handle 12K events per second. If you have a large deployment then this may not be sufficient. Please note that a log collector is only rated for 30K EPS sustained, so you may need to think about your deployment if you have more than 30K EPS.
SA GUI -> Services -> Local Log Collector ->Explore View ->Event Processors and then the following tree. In the picture below Netflow is being edited but the same applies for checkpoint collection.
Persistent Connections batch up events into bundles of 1000 events
Not all the customer Check Point CMA's were busy. When persistent connections were used (Poll Interval set to -1) then events would be batched up into bundles of 1000 Events before being released. For low EPS Check Point devices, over night it was taking over 30 minutes for 1000 Events to be reached which would trigger an event source monitoring alarm.
The recommendation is only to use Persistent connections (Poll Interval set to -1) for high EPS Check Point devices. Use a normal poll interval (eg integer value >0) for low throughput check point devices.
Hopefully this will help someone!
- check point
- check point security
- Community Thread
- Forum Thread
- RSA NetWitness
- RSA NetWitness Platform
- rsa sa