File: rule-profiling.rst

package info (click to toggle)
suricata 1%3A8.0.1-3
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 240,704 kB
  • sloc: ansic: 357,736; python: 8,721; sh: 5,043; makefile: 2,411; perl: 570; php: 170
file content (46 lines) | stat: -rw-r--r-- 3,104 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Rule Profiling
==============

Suricata can generate a rules performance report at the end of each session, if
built with the ``enable-profiling`` option (see configuring :ref:`Rule profiling
<rule-and-packet-profiling-settings>`). With that option, the engine will also
generate profiling data for other engine modules, such as packet processing.

Rule profiling can also be enabled by building the engine with ``enable-profiling
-rules`` and using the unix socket to dump the report (see
:ref:`rule-management-rules-profiling`). This will enable profiling of rules'
statistics only.

Once the report is generated, it is stored in the default log directory used by
Suricata. If not changed, the filename will be ``rule_perf.log``.

A Rules Profile report looks like this: ::

  --------------------------------------------------------------------------
  Date: 9/5/2013 -- 14:59:58
  --------------------------------------------------------------------------
   Num      Rule         Gid      Rev      Ticks        %      Checks   Matches  Max Ticks   Avg Ticks   Avg Match   Avg No Match
  -------- ------------ -------- -------- ------------ ------ -------- -------- ----------- ----------- ----------- --------------
  1        2210021      1        3        12037        4.96   1        1        12037       12037.00    12037.00    0.00
  2        2210054      1        1        107479       44.26  12       0        35805       8956.58     0.00        8956.58
  3        2210053      1        1        4513         1.86   1        0        4513        4513.00     0.00        4513.00
  4        2210023      1        1        3077         1.27   1        0        3077        3077.00     0.00        3077.00
  5        2210008      1        1        3028         1.25   1        0        3028        3028.00     0.00        3028.00
  6        2210009      1        1        2945         1.21   1        0        2945        2945.00     0.00        2945.00
  7        2210055      1        1        2945         1.21   1        0        2945        2945.00     0.00        2945.00
  8        2210007      1        1        2871         1.18   1        0        2871        2871.00     0.00        2871.00
  9        2210005      1        1        2871         1.18   1        0        2871        2871.00     0.00        2871.00
  10       2210024      1        1        2846         1.17   1        0        2846        2846.00     0.00        2846.00

The meaning of the individual fields:

* Ticks -- total ticks spent on this rule, so a sum of all inspections.
* % -- share of this single signature in the total cost of inspection.
* Checks -- number of times a signature was inspected.
* Matches -- number of times it matched. This may not have resulted in an alert due to suppression and thresholding.
* Max ticks -- single most expensive inspection.
* Avg ticks -- per inspection average, so "ticks" / "checks".
* Avg match -- avg ticks spent resulting in match.
* Avg No Match -- avg ticks spent resulting in no match.

The "ticks" are CPU clock ticks: http://en.wikipedia.org/wiki/CPU_time