hit count functionality

[Henrik_Noerr1]

Hey,

I am trying to understand the hit count functionality better in our environment. CPM Doctor lists that the hitcount table should not exceed 3 mill records. It doesn't seem like a hard limit, simply a recommendation.

Our table consist of 8.2 million records and is 1.8 gb - retention time is set to 1 year for each of our 10 domains holding around 300 firewalls

I see in the table that each rule has an  entry for each day for the duration of your selected retention in global properties.

Does SmartConsle work with this table when displaying hitcounts? summing up, and finding first and last hit from this table?

Last hit is very important to us, but if a rule had 18 hits the 20th of november 2022 I could care less.

This brings the question if this size is hurting our Smart Console performance. It's not very bad, but not good either...

Furthermore the table seem extremely inefficient. If a fireall or a rule is deleted - associated entries are not cleaned from this table.

only clean up seems to be when an entry falls out of the retention period. Furthermore there is one table for all domains in a MDS againt hurting queries.

I have a diamond engineer helping me out of this (6-0003562742) but maybe anyone had practical experience.

if you want to poke around:

psql_client monitoring postgres -c "select * from hitcount;" > mon-db.txt

[Expert@mdshost-01:0]# wc -l mon-db.txt
8273288 mon-db.txt

/Henrik

[_Val_]

Some answers:

1. Does SmartConsle work with this table when displaying hit counts? summing up, and finding the first and last hit from this table? - YES, this info is used by SmartConsole. All info is taken in, no exclusions.

2. If a firewall or a rule is deleted - associated entries are not cleaned from this table. Only clean-up seems to be when an entry falls out of the retention period. This is by design. There are ways to reset the table, if you need. 

Working with TAC on this sounds like a good idea.

[Henrik_Noerr1]

Hey @Val , Thanks for replying.

I would appreciate if this was communicated to and prioritized in the relevant product team(s).

I feel this is a missed opportunity for gaining quite some performance in Smart Console.

In larger environments, only maintaining the hitcount table based on date is really not enough in a large scale and evolving system environment. Resetting the hit count table as a whole is not really an option, which completely destroys any usecase like handling high volume rules or deleting unused ones

Thanks,

Henrik

[_Val_]

Reach out to your local Check Point representative (Account Manager) to open and RFE for this. Also can be done via Diamond Support.