Troubleshooting: High CPU usage after enabling all the security modules.

Oof, that CPU usage is rough. You've already found the main culprits by disabling modules, which is the right first step.

For debug logs, check if there's an `/etc/asa/asa.conf` or similar. Sometimes there's a `log_level = DEBUG` hidden in there. Also, you might try `strace -p ` on the main `asa_service` process to get a raw look at what syscalls are hammering the CPU, though it's a firehose of data.

Your gut about deep file scans is probably spot on. Have you considered setting up resource limits (`systemctl set-property`) for the service to cap CPU? Might be a decent band-aid while you figure it out.

>setting up resource limits (`systemctl set-property`) for the service to cap CPU

Capping the CPU is a bad workaround. It doesn't fix the performance bug, it just hides it and will likely cause real security events to be missed when the throttled service can't keep up.

Strace on a CPU-bound process is a decent idea, but the noise is useless unless you filter it. You need to target the busy threads. Try `strace -c -p $(pgrep asa_service)` first to see a summary of the top syscalls, then you can drill down.

Also, a debug log level might just fill your disk without telling you *why* the scanning is so aggressive. Check the module configs themselves. "Threat Detection" at default might be doing a full filesystem scan on every file event instead of a targeted check.

Solid point about resource limits being a band-aid. It's like lowering the temperature on a fever without treating the infection.

Your strace summary tip is gold. I'd add that after getting the syscall list, look for patterns around `openat`, `read`, and `stat` calls on specific paths. That often points you right to the overactive scan location.

On the configs, absolutely. The default "real-time" scanning scope in some of these modules can be way too broad. Sometimes you need to explicitly exclude system paths or build directories to stop the constant churn.

The syscall pattern is a good lead, but that assumes the process is stuck in a scanning loop. What if the high CPU is from inefficient pattern matching in the Threat Detection engine itself? You'd see the same `openat/read` calls, but the fix isn't about scan scope.

I've seen this with regex-heavy DLP rules on large files. The default rules might be poorly optimized, causing the engine to backtrack excessively on certain file types. That's a config issue, but not about which directories are scanned.

That's a classic symptom of real-time scanning going haywire on system directories. You're right to suspect it's churning through files, especially on a Linux host with frequent temp file creation.

Check your Threat Detection module config for the 'real-time scan paths' setting. The default often includes broad mounts like `/` or `/home`, which will hammer the CPU on any activity. Try excluding paths like `/tmp`, `/proc`, `/sys`, and your package manager's directories. Same logic for Network Shield if it's scanning sockets aggressively.

For deeper logs, there's usually a debug toggle in `/etc/asa/asa.conf` with a `verbosity` parameter. Set it to 4 or 5, restart the service, and watch the main log file for about a minute. It'll flood, but you'll see exact file paths being accessed. That'll confirm whether it's stuck in a loop.

Ah, the classic "enable everything" tax. Been there, burned out a fan. Good job isolating the culprits.

> Are there any debug flags or more granular logs

You're on the right path with the logs. In my experience, the config file is often at `/etc/asa/conf.d/` split by module. Look for a `threat_detection.conf` and `network_shield.conf`. There's usually a `scan_intensity` or `real_time_scan_depth` setting. Crank that down from "paranoid" to "vigilant" first.

For the logging, try `log_level = VERBOSE` in the main asa.conf. It's less spammy than DEBUG but might show you the file paths it's obsessing over. If you see it hammering `/var/log` or `/tmp`, you've got your answer.

The real conflict isn't between the modules, it's between their default "scan everything" behavior and a modern OS that never stops writing temp files. Start by excluding system caches and package directories.

The conflict you're hitting is pretty common with those two modules running default real-time scans. When Threat Detection and Network Shield are both watching file and socket events, they can end double-scanning the same system activity, which really punishes a 4 vCPU host.

> Are there any debug flags

Instead of just enabling debug logging, which will flood you, try targeting the module configs directly. Look in `/etc/asa/conf.d/` for the Threat Detection config and set `scan_mode = targeted` instead of `deep`. For Network Shield, there's often a `socket_scan_limit` parameter. Setting it to something like 100/s can stop the storm.

Also, check if your DLP rules are regex-based. A few poorly optimized patterns can make the engine backtrack like crazy, especially on logs or temp files. Try disabling just the DLP rules temporarily, not the whole module, to see if that calms the CPU.

The advice about narrowing scan paths is sound, but the real mistake is running real-time scans from a "lightweight" agent on system directories at all. Modern OS activity makes that a losing battle.

The debug log flood will just confirm what you already know: it's scanning constantly. Instead of chasing log entries, look at the module's *event source*. If it's using inotify on a broad path list, every temp file creation becomes a scan event. The energy is better spent building a sane exclusion list that reflects actual risk, not chasing log verbosity.

You're treating a design problem like a config tuning exercise.

> You're on the right path with the logs.

I think that's exactly the wrong path. Chasing verbose logs is just giving you a high-fidelity view of a flood you already know is happening. It confirms the symptom but does nothing to address the architectural nonsense of running deep real-time scans on volatile system directories by default.

Cranking down `scan_intensity` from "paranoid" to "vigilant" is still accepting the vendor's flawed premise that these scans should be ubiquitous. The better move is to question the scope entirely. Why is a security agent with a default config allowed to grind my CPU on `/tmp` or `/var/cache/apt`? Building an exclusion list isn't a tuning exercise, it's a forced correction for a product that doesn't understand its own operating environment.

You'll spend an hour filtering logs to find the noisy paths, then another hour building exclusions. Or you could just not run the module in a mode that's fundamentally incompatible with a working OS.

Have you checked if it's scanning inside container mount points? If you're running Docker or similar, the default paths might include the overlay directories under /var/lib/docker, which are incredibly busy. That would create a constant scan storm.

The real-time modules might not exclude those by default. Add that to your path exclusions list and see if the CPU settles.

> every temp file creation becomes a scan event

This is the core of the performance hit, and it's quantifiable. On a default CentOS 8 host I instrumented, the kernel generates over 1,200 inotify events per minute just from routine package manager and logging activity in `/var`. That's 20+ events per second before any user workload.

Setting the verbosity to 5 will indeed show you the storm, but as you said, it just confirms the diagnosis. The actionable data is the event rate, not the file list. A more surgical approach is to check the module's statistics output, if it exists, for `scans_triggered_per_second`. If that number is consistently above 10, you're in the pathological range where the scan overhead exceeds the cost of the I/O it's watching.

Your path exclusions are correct, but I'd add `/var/log/journal` and `/var/cache/yum` or `/var/cache/apt` specifically, as those directories have a uniquely high churn rate that provides almost zero security value.

You've pinpointed the two modules causing it, that's huge. The double real-time scan storm is brutal on 4 vCPUs. Before you dive into a debug log flood, try this quick check.

Look for a stats file or command, maybe `asa_service --status` or in `/var/run/asa/`. See if there's a counter for "inotify events" or "real-time scans triggered." If that number is climbing by hundreds per second, you've got your smoking gun. It's not *what* it's scanning, it's *how often* the scan triggers.

Your hunch about deep file inspection is probably right, but often it's the depth combined with a bad default path list. Add `/tmp`, `/proc`, `/sys`, and `/var/lib/docker` (if you use containers) to the exclusions in both module configs. That usually cuts the event rate by 80% right away.

Exactly. Checking the event rate is way more actionable than sifting through logs. I've seen that number jump into the thousands per second on a fresh Ubuntu install with Docker running.

One caveat: the stats command can sometimes be `asa-monitor --metrics`, not just `--status`. If you don't see it there, the module-specific conf files sometimes log their own scan trigger stats. A sustained rate over 20/sec is usually the threshold where performance tanks.

Debug flags won't tell you anything useful. You already know it's scanning too much.

The problem is your vendor's default config assumes you have unlimited CPU to burn on scanning `/tmp` and `/proc`. You don't. Build a real exclusion list and accept that real-time scanning everything is a fantasy sold to security teams.

Your 4 vCPUs are crying. Listen to them.