Replies: 1 comment · 4 replies
-
|
Did you recently change the amount of workers for suricata? |
Beta Was this translation helpful? Give feedback.
-
|
Not recently. I had adjusted them a while back while still on 2.4. Right now I am using 8 each for af-packet and zeek with 28 cores total on the server. |
Beta Was this translation helpful? Give feedback.
-
|
Elasticsearch also has a fault now since nsm is filling up.
|
Beta Was this translation helpful? Give feedback.
-
|
You're running a standalone, you will want to keep some disk free for Elasticsearch data as well. You should probably back off your Suricata PCAP retention. All your functions, manager, search, and sensor are competing for disk space on /nsm. |
Beta Was this translation helpful? Give feedback.
-
|
I had left plenty of space for Elasticsearch, it just seemed like the PCAP storage "broke through" the ceiling. I took a risk and cleared out the suripcap directory and rebooted. So far everything seems to be fine. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Version
3.0.0
Installation Method
Other (please provide detail below)
Description
other (please provide detail below)
Installation Type
Standalone
Location
on-prem with Internet access
Hardware Specs
Exceeds minimum requirements
CPU
28
RAM
192GB
Storage for /
293GB
Storage for /nsm
10TB
Network Traffic Collection
span port
Network Traffic Speeds
1Gbps to 10Gbps
Status
Yes, all services on all nodes are running OK
Salt Status
No, there are no failures
Logs
No, there are no additional clues
Detail
Since I've upgraded from 2.4.211 to 3.0, it appears that Suricata isn't purging PCAP even after adjusting the max size. I'm sitting at 91%, which is well over what I have configured (70% of 10TB = 7K GB). The /nsm/suripcap directory is currently at 8TB in size.
Is there a way to force it?
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions