Osquery Logging: Pipelines to Your SIEM and Data Lake
A production log pipeline must preserve differential meaning, survive transport failure, control SIEM cost, and prove every delivery boundary.


The problem with osquery logging is not getting JSON off an endpoint. It is proving that the right rows arrived once, stayed searchable, and can still drive a decision when the transport breaks.
Most guides list logger plugins and stop. Production starts after that list. You need to choose differential or snapshot output, preserve a stable host identity, buffer during outages, control duplicates, track schema changes, split cheap retention from expensive search, and test the alert path. A pipeline that cannot detect its own data loss is not a security control. It is a hope with a dashboard.
Speed matters because attackers do not wait for pipeline repair. Verizon published its 2026 Data Breach Investigations Report in May 2026 after analyzing more than 31,000 incidents. Vulnerability exploitation led initial access at 31 percent, while the median time to fully resolve critical vulnerabilities reached 43 days. Endpoint evidence has value only when it moves from the host to the team that can shorten that window.
An osquery pipeline that can prove delivery
Collection is only the first hop. Each boundary needs a measurable receipt and a recovery path.
What does osquery logging produce?
Osqueryd produces status logs and query result logs. Status logs explain agent health, configuration errors, watchdog actions, and transport problems. Result logs contain rows from scheduled queries. Keep both. A result stream without status logs can look quiet when the agent is broken. Status without results proves only that a process is alive.
The default filesystem plugin writes JSON. On Linux and macOS, scheduled results normally land in/var/log/osquery/osqueryd.results.log. Windows uses its osquery log directory. The official osquery logging documentation lists filesystem, TLS, Windows Event Log, syslog, Kafka, Kinesis, and Firehose options. Multiple plugins can run at once, which is useful during migration but also doubles output by design.
Choose a stable host identifier before shipping anything. Hostnames change and can be reused. Theuuid option uses the platform UUID, while specified accepts an identifier supplied by your management system. Put business context such as environment, team, and criticality in decorators, but keep the endpoint identity independent of those labels. Ownership changes. Identity should not.
Should osquery logs be differential or snapshot?
Differential queries log changes between the current result and the prior result. On the first run, every row appears as added and the counter is zero. Later runs emit added and removed rows. This is the right default for services, users, browser extensions, startup items, and other state that changes slowly.
Snapshot queries send the complete result every interval. Use them when each result is a measurement that cannot be reconstructed from additions and removals, or when the downstream system needs a fresh complete set. Snapshots are expensive. A 2,000 row software inventory sent hourly from 10,000 hosts produces 480 million rows a day before enrichment.
Event tables are a third case. They already contain buffered records of activity, so your schedule drains the event store into results. Do not add a synthetic time value just to force differential output from a posture query. That pattern makes every row change on every run and quietly turns a cheap differential into a snapshot bill.
Preserve name, action, epoch, counter,unixTime, host identifier, and the columns object. Epoch and counter help distinguish a fresh baseline from a later change. If a parser flattens those fields without a documented mapping, investigators lose the semantics that make differential results useful.
Which osquery log transport should you choose?
Filesystem plus an existing forwarder is the conservative choice. Osquery writes locally. Fluent Bit, Logstash, Splunk Universal Forwarder, or another agent tracks the file offset and handles transport. This separates query collection from network delivery, gives you a local recovery window, and lets the same forwarder carry other endpoint logs.
Turn on bounded local rotation before the pilot. The official logger flags set the default rotation trigger at 25 MB and the default maximum at 25 files for result and snapshot logs separately. Files after the first rotation use Zstandard compression.
Those defaults allow about 625 MB of rotated result files and another 625 MB of snapshot files before compression changes the actual disk use. Set an endpoint disk alert below the point where the operating system is at risk. Local retention is a recovery buffer, not your archive. If the forwarder is down long enough to fill it, the oldest evidence will leave.
Direct TLS reduces moving parts when a fleet manager already implements the osquery remote protocol. It also couples buffering and delivery to the osquery process. The TLS and AWS loggers use buffered logging. The official flags set buffered_log_max to one million by default, after which old records are purged by timestamp when the buffer cannot drain. Monitor that queue. A large buffer delays loss. It does not prevent loss.
Kafka fits teams that already operate it and need independent consumers. Configure broker TLS, acknowledgments, compression, and topic ownership explicitly. “Send to Kafka” is not an architecture. Decide which consumer writes durable raw data, which normalizes for the SIEM, how each commits an offset, and how replay avoids duplicate alerts.
The osquery release history records that version 5.23.0, released April 25, 2026, added a header based authentication mechanism for remote APIs. Version 5.22.1, released February 25, made nonprintable byte escaping aware of UTF8 and noted that some query results would change from raw bytes to rendered characters. Both changes sit inside the last 12 months and both can affect a remote pipeline or parser contract. Test agent upgrades with real stored samples, not only a successful process start.
How do you size osquery logging before deployment?
Measure rows, average bytes per row, and retention by query name. Do not multiply a single daily total by the planned fleet and call it capacity planning. Quiet laptops, domain controllers, build hosts, and developer workstations have different event rates. Sample each group for at least a week.
The simple math exposes bad assumptions. Ten thousand hosts sending 30 differential rows an hour produce 7.2 million rows a day. At 800 bytes a row, that is about 5.76 GB before indexing and replicas. Twenty process events a minute from the same fleet produce 288 million rows and about 230 GB a day. One query design choice changed daily volume by roughly 40 times.
Put raw JSON in low cost object storage with enough retention for investigations. Send normalized fields needed by active detections to the SIEM. Keep a small set of dimensions at the top level: host identity, query name, action, event time, platform, and owner. Store the full columns object for detail. This split preserves replay without paying premium search rates for every field.
Control sensitive data too. Command lines, environment variables, browser history, user paths, and process arguments can contain credentials or personal information. The default filesystem logger uses restrictive file permissions, and the official flag warns that root output may contain sensitive data. Scope collection, encrypt transport and storage, limit access, and document retention.
How do you build a pipeline that detects loss?
Add a receipt at every boundary. On the endpoint, monitor osquery_schedule for executions and output size. For filesystem shipping, watch file age, offset movement, queue depth, and disk use. For TLS or Kafka, watch buffered record count, retry count, acknowledgments, and oldest pending age. At storage, count records by query and host. In the SIEM, fire a canary detection from a known test row.
Alert on absence by cohort, not by one global count. If an office closes for a holiday, laptop volume may fall while servers remain steady. If one operating system cohort drops to zero after an agent update, that is a release problem. Compare each cohort with its own recent baseline and deployment events.
Decide delivery semantics. Most pipelines are at least once, which means duplicates are possible after retry. Build a deterministic event key from stable fields such as host identifier, query name, epoch, counter, action, and a hash of columns. Deduplicate in the consumer while preserving the raw record. Exactly once claims usually move the duplicate problem somewhere less visible.
Run a quarterly failure drill. Block the transport on ten test hosts, wait for the buffer to grow, restore service, and confirm the backlog arrives without gaps or a storm of duplicate alerts. If two engineers spend four hours on the drill, that is eight hours to learn whether the recovery design works. Discovering the same flaw during an incident costs far more.
What schema should the SIEM receive?
Keep the raw osquery record immutable. Normalize a second representation. Map host identity, query name, action, event time, and platform into common fields, then place table columns under a predictable namespace. Do not force every table into one flat schema. A service and a browser extension do not share useful fields beyond endpoint and time.
Version the parser with the query pack and agent. Osquery 5.10 changed standard decoration values such asunixTime, severity, and line from JSON strings to numbers. Later releases continue to add columns and adjust results. Reject malformed records into a visible dead letter queue. Silent field loss is worse than a loud parse failure.
The final transform should add meaning, not only field names. Deep endpoint context with AI driven analysis is how Artemes AI decides whether a row matters and what remediation fits the host. A rules based pipeline can use the same principle. Join asset owner, exposure, approved software, recent change, and vulnerability context before creating work. Shipping more rows does not make a security team faster.
Frequently asked questions
Where are osquery logs stored?
Filesystem logging writes result, snapshot, and status files under the configured logger path. Linux and macOS commonly use /var/log/osquery. Windows packages use the osquery log directory under program data or the configured installation path.
Should osquery send logs directly to a SIEM?
Usually send a selected normalized stream to the SIEM and keep raw JSON in cheaper durable storage. Direct SIEM ingestion is fine for small volume, but event tables can make cost rise quickly.
What is the difference between status and result logs?
Status logs describe agent health and errors. Result logs contain scheduled query rows. You need both to tell the difference between “nothing changed” and “collection failed.”
How do you prevent duplicate osquery alerts?
Assume retries can duplicate delivery. Create a deterministic event key from stable record fields, deduplicate before alerting, and retain the original record for audit and replay.
The takeaway
Pilot five queries on each major endpoint cohort. Measure rows and bytes by query, choose the local recovery buffer, send raw data to durable storage, and forward only decision fields to the SIEM. Then break the transport on purpose and prove recovery. Osquery logging is finished when the pipeline can show what it delivered, what it dropped, and how it recovered. A green agent count is not that proof.
The fleet management guide covers central scheduling, the query packs guide covers versioned query sets, and the performance guide covers endpoint cost. Continue with the definitive osquery handbook for the full cluster. Our older article on AI alert triage explains why the last mile must reduce work, not merely move it.
See which of your findings actually matter
Artemes AI combines deep endpoint context with AI-driven analysis to show which findings are actually exploitable on your hosts—not just everything a scanner can list. We are onboarding early access teams now.

Alex Gibson
Alex writes about configuration drift, operational security evidence, endpoint telemetry, AI-assisted triage, and the practical work of turning signals into better remediation decisions.

