Documentation for each keyword in stats.log file.
Suricata can produce alot of statistical information that can be very usefull when identifying errors and or performance issues. The contents of the statistics file is not very good documented. It lists the keywords and explains only a handfull. The wikipage can be found at: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Statistics
My suggestion is to document every keyword and its meaning so that for new users and administrators of Suricata sensors can quickly get started with debugging and performance related configuration by using the stats.log file as a source.
Updated by Peter Manev about 8 years ago
Could not agree more.
Could be partly related to -
Updated by Andreas Herz about 3 years ago
I've started to collect the list for the counters we have. It would be nice to have an automatic way to generate those but not sure how and if we can do that.
Writing down the description will still be a manual task but at least the rest should be generated.
The goal would be to have a page like this:
|capture.kernel_packets||packets||local||amount of packets received from kernel|
|flow_bypassed.bytes||bytes||local||flows bypassed in bytes|
|http.memuse||bytes||global||memory used for http in bytes|
At least the explanation what the value is (bytes, packets, something else) should be included as well as the description what the counter means (especially those not 100% obvious).
I grepped the code for the following parts to collect the available counters in the attached file:
I also added one line to cover what the app_layer counter can look like, please correct me if I missed an option:
I also skipped the napatech ones since I couldn't test them.
We can also group some together to avoid a huge duplication of some parts.
So any information for missing counters or suggestions how to make this more error prune due to automation let me know.
Updated by Victor Julien over 2 years ago
I think its easy to validate the script/greps by looking at actual output for live traffic or pcaps. So lets just get started with that and we can deal with any corner case later. More important to get the main ones covered. No need to block on getting things perfect.