valitydev/osquery-1
14
0
Fork 0
mirror of https://github.com/valitydev/osquery-1.git synced 2024-11-06 09:35:20 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update documentation about denylist schedule key (#6922)

Browse Source 
Attempts to clear up a common misconception about the functionality of
the `denylist` key.
This commit is contained in:
Zach Wasserman 2021-01-26 18:31:45 -08:00 committed by GitHub
parent 776eba97c8
commit 3d2d2ba0f5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/wiki/deployment/configuration.md
View File

@ -318,7 +318,7 @@ The basic scheduled query specification includes:
- `platform`: restrict this query to a given platform, default is 'all' platforms; you may use commas to set multiple platforms
- `version`: only run on osquery versions greater than or equal-to this version string
- `shard`: restrict this query to a percentage (1-100) of target hosts
- `denylist`: a boolean to determine if this query may be denylisted (when stopped for excessive resource consumption), default true
- `denylist`: a boolean to determine if this query may be denylisted (when stopped by the Watchdog for excessive resource consumption), default true
The `platform` key can be:
@ -331,6 +331,8 @@ The `platform` key can be:
The `shard` key works by hashing the hostname then taking the quotient 255 of the first byte. This allows us to select a deterministic 'preview' for the query, this helps when slow-rolling or testing new queries.
Note that queries are still constrained by the Watchdog when the `denylist` key is set to false. This means that setting `denylist` to false is _not_ sufficient to ensure a query will be run without resource constraints. Queries stopped by the Watchdog should be addressed by modifying the query SQL and/or Watchdog configuration until the limits are not exceeded.
The schedule and associated queries generate a timeline of events through the defined intervals. There are several tables `*_events` which natively yield a time series, all other tables are subjected to execution on an interval. When the results from a table differ from the results when the query was last executed, logs are emitted with `{"action": "removed"}` or `{"action": "added"}` for the appropriate action.
Snapshot queries, those with `snapshot: true` will not store differentials and will not emulate an event stream. Snapshots always return the entire results from the query on the given interval. See