Hi team, is there anyway for the extension and osquery not to use as many resources. Our osquery configuration before we added the extension with its query was lower than 5% cpu on average, but now with it its has gone up to average around 40% combined and will spike higher. We are wondering if there is any method to lower this. Any help is appreciated

could you share more details which process is taking how much cpu when you see

40% combined

usage. at the same time, please share osquery.flags and osquery.conf being used.

Would also be great to know the filters. @Shane Sanborn are you seeing telemetry data that you think can be whitelisted thru the filters?

The two process I am referring to are the plgx extension and the osqueryd. It seems like they shot up this high during the execution of the queries. Also, I have added a lot of filters to lower the data we are sending, so all of the "noisy" data that is left is data that is necessary.

to start with, could you review

plgx_win.conf

and spread interval of scheduled queries to a higher time value.. most of the queries are scheduled for

"interval": 30

which may be eating up CPU.

A couple of quick optimizations I can recommend: 1. since you are apply constraints on some of the queries in plgx_win.conf, why not push those constraints as filters itself (include or exclude)? 2. Spreading the intervals (as already suggested) will help 3. Remote_thread is very noisy event. Would you want to consider going for an 'inclusion' based approach (on target process like lsass or others) instead of an 'exclusion' based? 4. file_time_stomp I believe is very chatty event too and the filter is very wide (e.g. *.exe). Would you want to tighten it to executables in certain folders e.g. 'downloads' or 'users'?

remote_thread isn't actually sending too much data with the filters we have on it just an fyi and also for file_time_stomp.. I'm not sure if the

*.exe

filter is even working because I am seeing data come in that has a target_path that doesn't include that.. do I have to provide like an exclude all filter for this to work or?

there is no separate filter implemented as

win_file_timestomp_events

.

win_file_events

filter should work for file timestomp events.

hey @himanshu I have worked on the filters and now have trimmed down the amount of events coming in and the osqueryd.exe process doesnt use as much resources, but the plgx process is using a lot of resources when it first starts up.. do you have any advice on this?

is it only on osquery start up? if yes, the extension must be doing some initialization steps including registering itself with osquery, setting up filters and other config.

It spikes on all osquery restarts at around 50% cpu but it does look like it spikes higher on the first start up..

what is it that is scheduled every 10 minutes in your configuration? can you please check

the osquery spike that happens every 10 mins is fine for me because its such a low percentage spike only going up to like 4% but its caused by one of largest queries that we have been using for years..

ok. please let us know what are those plgx queries

Hi Team, I have done some testing and nothing with changing the queries seem to help and even took off all the queries.. also I took off all the filters just to see and it was still just as high which I guess is expected.

So the spike you are seeing is what? ~50% on restart...is that correct? I mean, its only at the start time the spike is..and that's the current problem definition. Is that right?

No oh so I should clarify I thought the spike was on restart but it seems to be triggered on intervals.. even when I have no queries running that are related to the extension

hmm..thats concerning for sure. For the sake of test, would you try filters such that all events from all categories are excluded and the extension is not collecting anything...I am curious to know if this is something being triggered by an osquery action or something in the event collection path.

okay will try that today

Interesting. Let me look at your config. I believe you had shared it before.