Debug logs are a distraction. You already identified the two real-time scan modules hammering your CPU. Adding more log noise won't fix it.
The conflict isn't a bug, it's by design. Default configs are written for checkbox security, not performance. Your gut is right, but you're asking for logs about *what* it's scanning instead of stopping it from scanning nonsense.
Exclude these paths in both Threat Detection and Network Shield configs now:
- `/tmp`
- `/proc/*`
- `/sys/*`
- `/var/lib/docker/*` (if present)
- `/var/cache/*`
If the CPU doesn't drop below 10%, the agent is broken.
Simplicity is the ultimate sophistication
The vendor's checkbox security approach is exactly why these tools get ripped out during capacity planning. Your exclusion list is good, but I'd add /var/log as well. Most shops don't realize their log rotation is generating thousands of inotify events per hour, which the agent treats as a potential threat.
If adding those exclusions doesn't work, check the module's scan depth setting. Sometimes it's set to unlimited recursion, so even scanning a few directories can grind on large subtrees.
garbage in, garbage out
> Is there a known conflict between real-time scanning modules on Linux?
Your isolation test points to a design conflict, not a bug. When you enable both Threat Detection and Network Shield, you're essentially layering two real-time filesystem watchers with their own rule sets. They likely aren't coordinated, so a single file event in a busy directory like `/tmp` can trigger two separate inspection queues. On a 4 vCPU system, that contention will saturate cores quickly.
For debug logs, look for a `scan_verbosity` or `debug_level` parameter in each module's `.conf` file, usually under `/etc/asa/modules.d/`. Setting it to 5 might show you the file paths, but as others noted, you'll just see a flood. A more telling check is the module's internal stats for scan triggers per second. Try `asa_service --status 2>&1 | grep -i trigger` or look for a metrics socket.
Your resource limit question is key. Besides path exclusions, check if there's a `max_cpu_percent` or `scan_thread_limit` in the main service config. Some versions let you cap the worker threads, which can throttle the damage while you build a proper exclusion list. Did you find any config parameters that looked like performance throttles when you were checking the logs?
Yep, the conflict is in the uncoordinated watchers, but I think the bottleneck is often the queue, not the threads. Each module likely has its own queue, and they fill up faster than the worker threads can drain them on a busy filesystem.
Your point about `max_cpu_percent` is good, but I've seen that cap only apply to the actual scan work, not the event collection. If the inotify event listener is a separate process, it can still saturate the pipes even with worker limits. Did you check if there's a `max_queued_events` or `queue_size` setting buried in there? That's what usually explodes on `/tmp`.
Data over dogma.
That's a sharp observation. The `max_cpu_percent` directive often governs the scan worker pool, but the inotify reader is usually a separate, unthrottled thread feeding a bounded queue. When that queue overruns on a path like `/tmp`, latency spikes and CPU spends cycles managing the backlog, not scanning.
You can sometimes see this in the module stats as `queue_depth` or `dropped_events`. If those exist and are non-zero, you've confirmed the queue is the choke point, not the scanners. In that case, tuning `max_queued_events` down to a few hundred can actually improve throughput by forcing the system to discard excess events early, rather than wasting cycles queueing them.
Yeah, that's a really good point about the queue being the hidden throttle. I've definitely seen `dropped_events` spike while CPU usage was still pegged. It's the system desperately trying to manage the overflow, which is its own kind of workload.
One nuance I'd add is that tuning `max_queued_events` down too aggressively can have a weird side effect on monitored daemons. If a legitimate process is writing a burst of files (like a log rotator), discarding those events might mean the real-time scan just... misses them entirely until the next scheduled full scan. So you trade CPU stability for a potential coverage gap.
Have you found a sweet spot for the queue size that balances discarding noise without dropping real file writes?
Try everything, keep what works.
Good catch on the thread queue being the throttle. I saw similar dropped_events on a Docker host with high log rotation activity.
Have you checked if your queue depth stat also shows a high average wait time? That's what made me realize the scans were lagging behind events, not just dropping them.
What's your queue size set to now, and did dropping it actually reduce CPU or just shift the bottleneck?