internal deployment guide

Deploying osquery in a new environment is designed to be as straightforward as possible. The deployment documentation should contain all of the information that you need to integrate osquery into your environment. If you have any problems along the way, please create a GitHub issue.

Performance

A top-level goal of osquery is for it to be performant enough to run on production infrastructure with the smallest possible footprint. The core osquery team at Facebook puts a lot of effort into ensuring that all code is rigorously benchmarked and tested for memory leaks.

All systems operations in osquery use underlying systems APIs exclusively. For example, the kextstat table in OS X uses the same underlying core APIs as the kextstat command. During the lifecycle of a long-running monitoring daemon, using system APIs instead of exec'ing to a system command has incredibly positive performance implications.

Whenever possible, osquery uses operating system streams to reactively perform actions. For example, if you wanted to know whenever a file changed, you could periodically poll for it's contents, or you could use inotify to tell you when the file changed. osquery includes a complete operating system publish-subscribe event framework which the core product uses extensively to provide more elegant, high-performance solutions to problem.

Customizing osquery

Deployment

Integration with internal infrastructure