# osquery office hours 2022-11-22

YouTube Link: https://www.youtube.com/watch?v=KtsJGGkbzus

## Announcements and Highlights since the last
* objective by the see videos are up (Including Sharvil's)
* Vivek is here! Hi Vivek!

## Any Questions / Issues / PRs people want to discuss?

The intent of this section is to provide a clear time for community members to bring up _anything_.

Broad questions? Bugs? Deployment questions? Blocked PRs?

### Shutdown a log flushing

https://github.com/osquery/osquery/issues/7802

The carbon black folks ask about this

## 5.6.0

seph hasn't seen anything in the Kolide beta fleet. Anyone else?

Zach hasn't seen any issues in Fleet's internal testing.

It's stable.

## Merge approved PRs

There are at least five currently parked in Approved state:
https://github.com/osquery/osquery/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved

And what about the [bpf expirments](https://github.com/osquery/osquery/pull/7791) work? General sentiment is that this is fine to merge.

Discussion about when to merge. If there's a pre-release hanging out, do we want to merge? Argument to wait, is that it's easier to cut a 5.6.1. But seph and Zach are generally in favor of merging as soon as approved. If needed we can branch off the prior release tag.

## PR notifications in Slack

Some discussion about better notifications.

FleetDM likes "Toast". Assuming it doesn't need write access to osquery's repos, we're game to try.

## ETW events table / Process events

Discussion about process tables being unified or divergent. `process_events` was a single table that covered macOS OpenBPF, and linux auditd. But we've since diverged that to `es_process_events`, `bpf_process_events`. It sounds like we think we should keep diverging

Speaking of these divergent tables... It would be nice if we could name them `process_events_XXXX` so they sorted together. There's general support for this, unclear if we can support table aliases.

## High Volume Events

Dealing with high volumn events is hard. the SQL core doesn't handle it easily. It's hard to get the query timing right -- too slow you lose events. Too fast, and you overuse resources. What would it be like sending events straight to the loggers?

Pull vs Push. Pushing directly to the logger.

Discussion about what makes osquery osquery. For seph, osquery is about the sql. Pushing events straight to the logger, feels like it compromises what osquery is.

Alessandro is thinking about load. On linux, using containers, this is a _huge_ amount of events. Being funneled through a single osquery instance. It just can't handle it.

Do we think we're the right tool for that job? Do we want to be?

Zach points out that people _are_ using us for this. Clearly there's a hunger for it. We should not abandone these folks.

Zach enumerates a vision where osquery is a generalized endpoint agent for telemetry. Some SQL based, but some is stream based.

There are several cojoined discussions:
* Our events system doesn't scale, maybe it's basically no good today
* But people use it. Maybe for `diff`?
* What is it like just shoving events to the logger
* How do we augment the events

seph floats an idea around creating a third query type. Snapshot, Differencial, and Streaming. Streaming queries might not actually be implemented in sql, and they would run events straight to loggers. Discussion of whether or not this makes sense.

## Look At Open CVS / Security Tickets

[List of Issues tagged with Security](https://github.com/osquery/osquery/issues?q=is%3Aopen+is%3Aissue+label%3Asecurity)

## Look at old PRs

_(If there's time, we've been trying to re-visit old PRs)_

[Reverse Sorted List of PRs](https://github.com/osquery/osquery/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc)