![]() Interesting stuff though! Maybe a FDW could connect Postgres to osquery, which could allow joining with local tables or other FDW-accessible data. That was an issue at Akamai - how to get historic as well as realtime with Akamai's Query system (. Marpaia, Did you consider using OpenTSDB?Īt CloudHelix, we did a Postgres FDW to OpenTSDB, which gives a time dimension as well. And it's great for borrowing each other's good ideas ) We're competing a bit, but it's OK to have multiple tools with varying goals. And I can tell their authors are solving some really hard problems. ![]() SQL is very natural to use for a lot of IT/Security people, and it's great to be able to transfer that knowledge to search tools. I brainstormed something similar last year but did not get around to it yet. I really like the SQL approach taken by osquery. Retrieving data at large scale is too expensive for Mozilla (bandwidth, storage, execution time), and we like to protect privacy. MIG takes this approach to keep the search very fast (parallel AMQP runs in seconds across thousands of endpoints). Privacy is preserved, but investigators need to manually retrieve files if needed. MIG does not retrieve data from endpoints, but instead focuses on answering yes/no questions.įor example: find hosts that have a file in /var/But it won't return the files themselves. There is a number of conceptual differences between MIG, GRR and OSquery. First, congrats to Mike Arpaia for shipping! That must have been a busy couple of months :) | name | path | cmdline | pid | on_disk | wired_size | resident_size | phys_footprint | user_time | system_time | start_time | parent | Use ".open FILENAME" to reopen on a persistent database. Osquery - being built, with love, at FacebookĬonnected to a transient in-memory database. Also look around /sys a bit.)ĭocker run -t -i imiell/osquery osqueryi Compare /proc/self/stat and /proc/self/status, and /proc/self/mounts and /proc/self/mountinfo. (The usual way this is worked around these days is separate files for each field, or files designed to be parseable, which is why Linux's /proc/*/ is such a mess. But in the specific case of text files with a single, well-defined structure, his own argument seems to imply that there's no sense in a second tool having to infer the structure on its own. I think there's validity to Rob Pike's argument in many contexts - for instance, you absolutely won't see me defending the semantic web over the greppable/Googleable one. This brings reliability and security benefits. For most implementations of "table", you can also have the data formats be well-typed. One advantage of "everything is a table" is that your structures are well-formatted and there's no risk of problems when you put a space in a pathname. It's also great for security holes (think CVE-2011-1749 and related issues arguably, see also Shellshock). This is great for getting things done quickly. "Everything is a file" means that you need to parse files to get useful data out (think things like /etc/mtab and /proc/mounts), which is closely tied to another UNIX philosophy, that tools should generate plain text and parse it using generic text-processing tools.
0 Comments
Leave a Reply. |