capture_loss vs. pkts_dropped vs. missed_bytes

Mark Gardner <[email protected]>
Newsgroups gmane.comp.security.detection.bro
Message-ID <CAG=_CgCde+J_vavsGhOEDkH0EaZ=uqkOJ3LQ-1hp_gfNKabLRg@mail.gmail.com>
I am still tuning our new Zeek cluster: an Arista switch for load balancing
with 4x10 Gbps links from a Gigamon and 10 Gbps links to the sensors, five
sensors (16 physical cores with 128 GB RAM each) using af_packet, 15
workers per sensor, and a separate management node running the manager,
logger, proxy, and storage (XFS on RAID-0 with 8 7200 RPM spindles, 256 GB
RAM). Output is JSON (for feeding into an ElasticStack later).

The average capture loss was <1%  early on with spikes to 50-70%. We
increased the af_packet_buffer_size from the default (128MB) to 2GB and
capture_loss is gone.
$ zcat capture_loss.10\:00\:00-11\:00\:00.log.gz | jq .percent_lost |
statgen
 Count         Min         Max         Avg      StdDev
   300      0.0000      0.0000      0.0000      0.0000

Next, I looked at the missing bytes from the conn.log which doesn't look
too bad:
$ zcat conn.10\:00\:00-11\:00\:00.log.gz | jq .missed_bytes | statgen
 Count         Min         Max         Avg      StdDev
  5488      0.0000   5802.0000      1.7332     92.9547
Out of the 5488 records, only two were non-zero (5802 and 3710)  and for
both of those the missed_bytes == resp_bytes (service: ssl).

But even with the above, the pkts_dropped in stats.log is extremely high:
$ zcat stats.10\:00\:00-11\:00\:00.log.gz | jq .pkts_dropped | grep -v null
| statgen
 Count         Min         Max         Avg      StdDev
   900     3564854    18216752  5762446.99  1591145.34

So even though there was no capture_loss and almost no missing_bytes, the
pkts_dropped is huge. Is this something to be concerned about? If so, I am
not sure how to go about figuring out the problem. What should I do next?

_______________________________________________
Zeek mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/zeek
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.