RocksDB: it's to be considered as an opaque, internal cache where data is temporarily stored when (mainly) events are being used
Its state, the data inside, could be subject to change in content and format at any time
that being said, there is a developer option that is useful for debugging; you can pass it to osqueryd to dump the whole database to screen
Do note that osquery outputs a stream of data, what you can capture by directly accessing the database is but a small view on what is the bigger picture
01/12/2021, 11:48 AM
Thank you for taking the time to answer! Got it for the database, something stills bugs me on the decorator thing though.
I actually tried this feature before, but it does not seem to be taken into account when using the one-off osquery tool
... is there a reason for this? Or am I missing something?
My actual goal is being able to determine the name of the original table from outside of the "osquery context" (e.g. when using an external database that ingested data from osquery). At the moment, I have the impression that all query results are dumped into the log file without knowledge of what query or table produced these results...
I thought about doing this using a separate file for each query (but osquery does not seem to support this use case) and by adding custom fields to each event, but it does not seem to work as I want it to.