Collecting “good enough” data is key in managing performance impact.Īlso, consider the impact of the queries you’re using to collect your event data. For example, when monitoring processes, there may be frequent but low-value processes such as awk and sed which can be ignored, reducing work for the host. If the utility is configured loosely to generate more events, then the utility performs more operations to generate events and osquery parses and stores more events.Ĭapturing only the events you need will cut down on the amount of work the host needs to do. What do I need to consider when configuring evented tables? Performance impactĬapturing event data generates performance overhead from both the utility and osquery. In the osquery schema, the table is marked with an "evented" tag near the table name.You can tell that an osquery table is evented in two ways: How do I know whether a table is evented? For most evented tables, osquery works great out of the box with the utility’s default configurations, but some use cases may require adjusting the utility configuration. At the osquery level, you can specify what information is ingested, presented, and transmitted. At the utility level, you can specify what data is captured. This separation between osquery and the utility means that some evented tables rely on configurations for the utility to determine which events will be generated. The data can then be filtered and transformed via SQL and shipped to a log destination with the scheduled query functionality.įor the purposes of this article, we'll use the term "utility" to mean the underlying OS component that osquery subscribes to for its various evented tables. Osquery receives the data, converts it into an event row, and buffers them (in the internal rocksdb store) in the process_events and socket_events tables to await querying. For example, on Linux, the audit framework generates and broadcasts process and socket event data. ![]() Instead, it reads and formats event data generated by various OS components. Osquery does not generate the events itself. We’ll also cover basic information about commonly-used evented tables to help you get started. In this guide, we’ll go through the concepts, considerations, and best practices for setting up evented tables - focusing on osquery. You can configure osquery to capture certain types of information, which will be stored in the relevant *_events table for later analysis. Instead of displaying the point-in-time state for your host, osquery's evented tables store the host's historical data. ![]() This is where osquery's evented tables can help. Actively watching and diffing tables could be challenging even with automation, especially for short-lived or high-churn processes. However, this snapshot means you have to check the table repeatedly if you want to view data over time. Osquery can let you see the state of your computers right now.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |