latency and performance safety

Continuous Build

The continuous integration for osquery is currently under development. The previous CI solution was unreliably failing builds due to network and memory issues.

The build will run each of the support operating system platform/versions and include the following phases:

• Build and run make test
• Attempt to detect memory leaks using ./tools/profile.py --leaks
• Run a performance measurement using ./tools/profile.py
• Check performance against the latest release tag and commit to master.
• Build docs and API spec on release tag or commit to master.

Virtual table blacklist

Performance impacting virtual tables are most likely the result of missing features/tooling in osquery. Because of their dependencies on core optimizations there's no hard including the table generation code in master as long as the table is blacklisted when a non-developer builds the tool suite.

If you are developing latent tables that would be blacklisted please make sure you are relying on a feature with a clear issue and traction. Then add your table name (as it appears in the .table spec) to osquery/tables/specs/blacklist and adopt:

$ DISABLE_BLACKLIST=1 make

For your build iteration.

Deployment profiling

Before deploying an osquery config use:

./tools/profile.py --config /path/to/osquery.conf --count 1 --rounds 4

To estimate the amount of CPU/memory load the system will incur for each query.

Wishlist

Query implementation isolation options.