NetVizura already has a lot of optimizations regarding data size. For example, NetFlow Analyzer has data aggregations for defined time intervals (g1,g2, and g3 tables for examining data older than 30 days), but sometimes this is not enough. If you are storing data in TB, storing everything in fast NVMe storage doesn't make sense, mainly because of the costs. On the other side, you need to hold

Nowadays, everybody uses compression, deduplication, aggregation, etc., to reduce the pressure on storage and save the company money. In the EventLog world, you cannot delete or in any way modify the older data if you need it for compliance reasons. So, the only things left are compression and hot/warm architecture on the database side. This quick blog will concentrate on compression and

With NetFlow administration and configuration, there are always choices. This blog post will briefly introduce different protocols and their options, as well as real-world examples. Let's dive into two protocols being used today: NetFlow and sFlow.

NetFlow

We won’t discuss history but will instead jump right into the NetFlow protocol's current use and its differences. Currently,

With version 5.5, NetVizura moved the Eventlog Analyzer's data storage from PostgreSQL to Elasticsearch. This change delivered a more performant and virtually limitless scaling log analyzer. With the release of version 5.6, we have introduced two new features that will enhance your data storage and search capabilities.

For those unfamiliar with NetVizura EventLog Analyzer, here

We covered Fortinet's regular NetFlow and Syslog configuration in a different blog post some time ago. For some Fortigates, there isn't a NetFlow option. Instead, there are only Sflow configuration options on the machines.

If you have missed the previous blog post, here is the link - Fortinet NetFlow and EventLog configuration.

In the beginning, we need to configure the global options