Documentation #1233


Documentation for each keyword in stats.log file.

Added by Andreas Moe about 7 years ago. Updated over 1 year ago.

Target version:
Affected Versions:


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:

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.


suricatastats.txt (6.88 KB) suricatastats.txt Andreas Herz, 07/08/2019 01:41 PM
Actions #1

Updated by Peter Manev about 7 years ago

Could not agree more.

Could be partly related to -

Actions #2

Updated by Andreas Herz over 5 years ago

  • Assignee set to OISF Dev
Actions #3

Updated by Victor Julien over 2 years ago

  • Assignee changed from OISF Dev to Community Ticket
  • Effort set to medium
  • Difficulty set to low
Actions #4

Updated by Victor Julien over 2 years ago

  • Target version changed from Documentation to TBD
Actions #5

Updated by Andreas Herz over 2 years ago

  • Assignee changed from Community Ticket to Andreas Herz
Actions #6

Updated by Andreas Herz about 2 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:

Counter Value type Scope Description
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:

  • StatsRegisterCounter
  • StatsRegisterGlobalCounter
  • StatsRegisterAvgCounter

I also added one line to cover what the app_layer counter can look like, please correct me if I missed an option:

* app_layer.[flow/tx].(failed_)$APPLAYER(_udp|_tcp)

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.

Actions #7

Updated by Andreas Herz almost 2 years ago

  • Tracker changed from Feature to Documentation
Actions #8

Updated by Andreas Herz almost 2 years ago

  • Status changed from New to Assigned
Actions #9

Updated by Victor Julien over 1 year 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.


Also available in: Atom PDF