After upgrading to 3.0 I have noticed that occasionally the CPU usage will ramp up from my usual average of under 10% to around 20% and stay at that level until I restart asl.
Any ideas why or how to determine why?

Have you checked top to see what process is using the CPU time?

I am having the same issue

I have noticed that /var/ossec/bin/ossec-syscheckd has been running for hours and CPU usage is between 80 - 100%
The only way to get it down is to run asl -f -s or hit the fix button in the web interface.

I tried changing the values in

/var/ossec/etc/ossec.conf

<syscheck>
<frequency>72000</frequency>
</syscheck>

and

/var/ossec/etc/internal_options.conf

syscheck.sleep=5
syscheck.sleep_after=8

PS: I also find the web interface alot slower.

Yes I think for me the culprit was ossec-syscheckd
Also for me the web interface is much slower.

For ossec-syscheckd the amount of CPU it uses is caused by the number of files its monitoring and the time it takes to complete is driven by the sleep values, and the speed of your I/O bus and drives.

So, first check the directories you are monitoring to make sure you actually want to monitor all the files and directories syscheckd is configured to monitor for changes. For example, some Splunk installations put their logs in /opt, and /opt is monitored in its entirety by default. In configurations like this (putting your logs in /opt instead of /var, which syscheckd is configured to not monitor), would cause the HIDS system to monitor a *lot* of files that change repeatedly (and likely do not need to monitored for changes). This will drive up utilization as syscheckd is doing more work. So, check your monitored directories to ensure that you are not monitoring files you should not. Otherwise, if you have a situation like this, then you will see syscheckd doing a lot more work (unnecessarily).

syscheckd is also a prisoner of your I/O bus and drive speeds. If you have a slow or busy bus, or slow drives, it will take a lot longer for file integrity checks to finish. So if you do not have a lot of files being monitored by syscheckd, and its taking a long time to complete, check your I/O speeds for your drives and partitions for any contention.

Could you elaborate? Do you mean when you first log in, or do you mean after all the windows have loaded? And are you using RC4 or an earlier beta?

I am having this problem too. Could you please explain the difference in what is monitored in ASL 2 and ASL 3 by default as I have always just used the default that is set by ASL? This started yesterday after I upgraded to 3 and I never had this problem with 2. It is fine for a while and then the CPU jumps and stays up until I run asl -s -f.

I can see that similar behaviour as well.
In my case the process ossec-analysisd is causing the "new" load and it's constant.
The disk load is low and they are running fine.
How to tweak?
Thanks

Can you be more specific, how much cpu time is it using?

round about 10%. It jumps/varies constantly between 1-10%. but the frequency is so high that in average it consums about 10%.
What can I provide to give you more details?

10%? Thats probably normal then, its looking at a lot more events than 2.2 was.

Ok thanks. Do you have an approximate load increase deviation rate between ASL 2.2 and ASL 3.0?

In my case it's a "dramatic" difference because my server is not heavy loaded at any time.
That means ...my average CPU load with ASL 2.2 was ~5-6%
Now with ASL 3.0 it is ~10-12%
In total numbers that's an increase of ~100% more load.
But at the end just 10% more load for the system.
And if I have to take that medicine to be more secure I will take it for sure

Ah so one big change from 2.2 to 3.0 is that it can create diff's of files it watches & email you the results (so instead of just telling you a file changes, it can tell you exactly what changed).

By default its looking at /etc, and /var/www/vhosts (for files ending in .php, .js, and .html). Thats some additional file overhead, so you could start by turning the "Report" flag off on those 2 directories in the file integrity checks. I'll bet you that its hitting a big /var/www/vhosts, and that could be the culprit here.

Thanks Scott,

I will give it a try and disable this for /var/www/vhosts.
But as you said that it's normal I will re-enable it for better security afterwards.
If I need some additional CPU power I could disable it then.

You may not even want to monitor /var/www/vhosts. Keep in mind that 3.0 does real time change detection, so thats a pretty big tree. The code can handle it, but your CPU might complain. Currently we only alert (in /var/www/vhosts) if files that end in .php, .js and .html change. On a big box with lots of virtual domains, you may not want that, you may only want to monitor your own stuff.

So, if thats the case for you, either disable it entirely (delete it), or just monitor the directories for specific sites for changes that you have higher security requirements (like you own sites for example). Don't be afraid to add in ignores either for things like temp and cache directories if you think you might have .php, .js, etc. stuff in there you dont care about. The file integrity monitor exists to tell you if something changes, so you probably dont want to waste cycles on stuff you dont care about.