Channels
doorman
infrastructure
random
zercurity
community-feeds
fleet-dev
code-review
queryhub
apple-silicon
carving
tls
fim
goquery
zentral
aws
querycon
golang
zeek
file-carving
fuzzing
auditing-warroom
linen-dev
fleetosquery
plugins
jobs
arm-architecture
darkbytes
process-auditing
uptycs
android_tests
selfgroup
vendor-feeds
fleet
eclecticiq-polylogyx-extension
ebpf
website
core
general
macos
kolide
osctrl
extensions
foundation
sql
officehours
linux
windows
Title
z
Zach Zeid
06/01/2021, 5:10 PMIs there any benefit from having two of the same queries running at different intervals, one that is set to
snapshotdifferentialdifferentialz
zwass
06/01/2021, 7:03 PMSome folks see benefit from this. Snapshot queries are easy to interpret since they show the full state at once. Of course they generate more data to store in wherever your logging pipeline goes. Some folks do things like schedule a snapshot query for once a day and the same query as differential every 10 minutes (intervals just for example) and then you can reconstruct the state at any given time by "applying" the diffs to the snapshot.
👍 1
s
seph
06/01/2021, 8:08 PMIm not sure that works in practice. The diffs aren't based on the scheduled results so weird skew is possible.
I suspect people use snapshot to try to capture state and diffs to alert in specific conditions. But 🤷 I'm speculating.
a
Alexander
06/01/2021, 9:31 PMWe are using such scheme in our installation. In our model data loss is possible (and happens sometimes) in logs collector, so daily
snapshotdifferentialBut we don't use distributed queries. If you have and can use them, and don't need timelines, then you can consider to use fleet or kolide service to get the most current state of machine.
s
seph
06/01/2021, 9:54 PMHow do you reconcile the diffs with the snapshots? Or is your data seldom changing so it’s a non-issue?
How do you re-sync a diff stream that has dropped messages?
a
Alexander
06/01/2021, 10:26 PMYes, frequent changes require other pipeline and *_events tables. The scheme I described is for seldom changed, like installed packages, kernel modules, users list and it is applied to servers. Usually it is enough to just take latest from added and snapshot result in some time window. But if you want to use such pipeline in automation and "smart" alerts, than you have to fully rebuild the state of machine, applying incoming diffs to the last snapshot. Currently it is done only for the list of installed packages (used to track and check packages on servers over USN and NVD feeds).
We don't re-sync. Usually drops occurs during network problems or performance problems on logs collector. We have queues to soften impact of short outage, but cant do anything with long-time problems. So here we have to wait for the next snapshot.
Just to make it clear - logs collector is not where osquery sends logs. We have a service that gets logs from all osquerys, batches them, and sends to archive and logs collector. That service is much more stable than our current collector.
s
seph
06/01/2021, 11:57 PMYou may want to look at the epoch incrementing functionality
➕ 1
a
Alexander
06/02/2021, 12:49 PMI see. Can epoch be changed on some event inside osquery or only by config plugin?
z
Zach Zeid
06/02/2021, 12:50 PMepoch incrementing functionality?
a
Alexander
06/02/2021, 12:52 PMNo sure if got it right. Do you mean to use
schedule_epochs
seph
06/02/2021, 1:09 PMepoch changes are triggered by the TLS server (presumably also by the config plugin). I’m not aware of another way to change the epoch, but I haven’t gone digging too much.
Yes, the intent of the epoch stuff is to facilitate resyncing the diffs. You cannot correct sync snapshots and diffs that are separate queries. (You can kinda fake it, if you only care about adds, but there are dragons)