Proposal (which I can raise on GitHub as a bluepri...
# core
Proposal (which I can raise on GitHub as a blueprint, but wanted to post here for quick discussion first), since we'll have
, should we rename the original to
? The code should facilitate this "aliasing" without breaking people's existing queries. Essentially
will become a clone, of
and will not show up in documentation/schema listing, but the virtual table will exist.
👍 2
Makes sense to me
m Alessandro told me this last time but maybe you're asking a slightly different question
Like I guess they collect slightly different event fields and therefore he thought they are not interchangeable
Maybe we could come up with a small subset of columns that should be always present, and use those in the alias as some sort of interface
Mike is right, the bpf_process_events table already has some things that process_events can't easily have: duration (how much time it took to service the system call), ntime (nsecs timestamp of the syscall relative to the boot time, as provided by BPF), cid (cgroup id)
For most things we try to abstract the concept across operating systems. But there is too much nuance, configuration, and expectation setting with process eventing so it makes sense to have them technology specific. We can iterate though.
👍 2