Osqueryd’s logging can integrate into your existing internal log aggregation pipeline, regardless of your technology stack, via a robust plugin architecture. You can use this to maintain insight into the security, performance, configuration and state of your entire infrastructure. The daemon takes care of aggregating the query results over time, and generates logs which indicate state changes in your infrastructure. The high-performance host monitoring daemon, osqueryd, allows you to schedule queries for execution across your infrastructure.
#Osquery on alpine how to
With the power of SQL and dozens of useful tables built-in, osqueryi is an invaluable tool when diagnosing a systems operations problem, troubleshooting a performance issue, etc.įor more information on how to use osqueryi, see the usage guide on the wiki. The interactive query console, osqueryi, gives you an SQL interface to try out new queries and explore your operating system. We’re also looking forward to seeing how the community uses the codebase to create even more interesting tools. We’re releasing several tools as a part of the open source release and we have more planned. Osquery’s modular codebase allows us to take advantage of existing concepts in new and interesting ways. Osquery is a framework we’ve used to create a few products and tools. For detailed documentation on how to create a table, see the guide on the wiki. Tables are easy to write, so we often encourage new contributors to develop a few tables as an introduction to the osquery codebase. There are many tables included with osquery and we’re creating more every day.
SELECT DISTINCT process.name, listening.port, listening.address, process.pid FROM processes AS process JOIN listening_ports AS listening ON process.pid = listening.pid This allows you to use generic tables to add context as you explore operating system state. Then, using the processes table from the last example, we can join the two tables together since they both expose the pid of the processes in question. This query finds all processes that are listening on network ports. Consider the following example, which uses data from both the “listening_ports” table and the “processes” table. One of the aspects of SQL that makes it so applicable to operating system analytics is the ability to join different tables together. Interacting with operating system state via SQL is fun and easy. SELECT name, path, pid FROM processes WHERE on_disk = 0 This is a common tactic used by malicious actors, so this should not return any results on your system, assuming your system isn’t compromised. The where clause of the query only returns processes where the original binary used to launch the process no longer exists on the filesystem. Specifically, this query returns all of the processes which are currently executing. This first example illustrates how you might use osquery to interact with the processes that are running on the current system. To best understand the expressiveness that is afforded to you by osquery, consider the following examples. Several tables already exist and more are being written.
SQL tables are implemented via an easily extendable API. With osquery, SQL tables represent the current state of operating system attributes, such as: This design allows you to write SQL-based queries efficiently and easily to explore operating systems.
Osquery exposes an operating system as a high-performance relational database. At Facebook, we’ve been working on a framework called osquery which attempts to approach the concept of low-level operating system monitoring a little differently.
Maintaining real-time insight into the current state of your infrastructure is important.
0 kommentar(er)
