Currently (as I understand it):

osquery_label_update_interval

and

osquery_detail_update_interval

both default to

1h

. An idea to improve this: • support per-query intervals (e.g., in the list of label queries, allow queryA to run once per hour and queryB runs once every 24h) I know that intervals here are highly correlated to load, so this might not actually be feasible.

Probably separate idea: • For label / detail queries, it would be nice to support

run-once

semantics (to only collect the data one time). It would be good to be able to have different intervals for labels for different Teams. I expect at least the interval part of this will already be supported when teams comes out 🤔 • For scheduled queries / if fleet adds auto-updating client (like launcher), it would be good if there were a way for the launcher to support

run-immediately

(optionally?) where scheduled queries are run once right away, as well as at every

interval

afterward. This is a perpetual annoyance of mine at osquery, and I have some ideas around why it's not supported right now 🤷‍♀️

run-once

^ There are certain attributes in some environments that we never change. To be more specific, in this env, hosts are created from an AMI and are immutable. If there is ever any change, a new AMI would be build, the original instances destroyed, and new ones spun up to replace the original (old versioned) instances.

And we could reduce the overhead of running osquery by only collecting the information once, as that's the only time it would be necessary.

why would it be helpful to support per-query update intervals?

Mostly that there are some attributes that never change or very infrequently change, so it's not useful to run at the same interval as other queries.

Are both the details and label use cases related to the updating the groups of hosts that are targeted?

Sort of related, not exactly the same. For details: collecting metadata about a host, some of which could only infrequently change (and needs different intervals). For labels: this is definitely for targeting hosts, but some attributes very rarely change, and we want to reduce overhead where we can.

I also now better understand the pain point for unnecessarily updating attributes. Thank you for the explanation. Is solving the “reducing osquery overhead” problem closer to a nice-to-have? A somewhat related question: Does providing proof of reducing osquery overhead allow for increased confidence in osquery’s performance and thus an easier time convincing other individuals of installing the agent? Or is there a different ultimate goal for the reducing of overhead?