►
From YouTube: 2021-07-29 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Hey
jonathan,
this
is
my
first
time
joining
the
ep,
the
edpf
working
group-
I
don't
know
if
maybe
this
is
the
first
time
it's
meeting.
This
is
the
first
time
it's
meeting
exciting.
C
This
was
also
a
new
thing
on
my
calendar:
jonathan,
I'm
a
co-worker
of
you
at
splunk,
so
I
don't
know
if
we've
talked
but
maybe
maybe
we've
been
on
calls
together.
Yeah
I
just
saw
my
calendar
and
I'm
primarily
going
to
lurk.
I
don't
work
in
ebpf.
I
haven't,
but
I'm
very
curious
about
it
and
yeah
wanting
to
learn
more.
B
So
great
I
work
at
google,
my
I
don't
work
in
edpf
either.
I'm
actually
interested
in
how
this
relates
to
in-process
tracing
efforts,
regardless
of
whether
they're
implemented
with
edpf.
A
B
Let's
see
hi
morgan
or
silent
morgan.
A
D
So
we're
trying
to
figure
out
why
our
air
conditioning
in
this
house
is
still
wimpy,
and
it
turns
out
that
the
filters
that
they're
using
on
the
central
ac
and
heating
system
are
like
three
times
as
restrictive
for
airflow
as
what
is
specified
by
the
furnace
manufacturer.
D
E
A
A
C
A
Together
with
pleasure,
we
can,
there
is
a
code
base
that
is
being
has
been
discussed
as
a
potential
contribution
to
open
telemetry
with
ebpf
contribution,
with
with
that
focuses
on
ebpf
telemetry
collection.
A
This
is
something
that
personally,
I've
been
working
on
for
the
past
several
years
as
part
of
a
startup,
we
had
been
thinking
about
open
sourcing
it
for
ages
and
now
kind
of
a
startup
has
been
acquired
into
splunk
flowmell
if
you're
familiar,
and
if
we
would
very
much
like
to
contribute
this
to
the
community
and
get
more
engagement
so
that
this
could
be
kind
of
the
the
infrastructure
that
we've
built
can
be
useful.
For
you
know,
rightly,
hi
michael.
D
A
A
We
used
to
call
the
flomo
collector
and
we
kind
of
where
you
know
would
like
to
modify
to
open
telemetry,
evps
but
they're,
subject
to
kind
of
discussions
in
this
work
group
to
make
sure
that
the
the
collector
is
is
useful
kind
of
you
know
widely
useful
just
going
through
the
the
the
features
and
making
sure
that
it
fits
like
across
the
community.
G
A
Okay,
so
I
gave
him
a
little
background
on
the
the
kind
of
immediate
kind
of
immediate
impedance
for
the
work
group,
but
I
hope
this
is
something
that
I
wanted
to
raise
for
the
group
on
what
you
would
like
to.
How
would
you
like
to
frame
this?
This
work
group
kind
of
just
ask
all
around
what
you
would
like
to
to
get
out
of
it,
so
to
make
sure
that
we
can
kind
of
accommodate
everybody,
so
the
I
think
that.
E
I
mean
I
can
I
can
go
first,
if,
if
that's,
okay
and
and
again,
I
think
you
know-
we've
all
had
discussions
about-
you
know
how.
How
do
we
actually
get
started
on
the
discussions
and
and
a
couple
of
areas
that
I
would
like
to
recommend,
which
would
also
help
us
in
you
know
again
getting
more
contributors
from
aws
to
contribute
is
a
couple
of
things,
one
that
understanding.
E
Clearly,
you
know
how
we
can
generalize
the
flo
mill
pipeline
so
that
general
ebpf,
you
know,
metrics
being
ingested
from
different
sources,
can
be
ingested
as
well
as
having
an
overall
design
discussion.
Really
that
needs
to
be
had
in
this
work
group,
which
you
know
outlines,
at
least
in
high-level
vision
of
the
architecture,
given
that
we
are
working
in
an
in
an
environment
where
there
are
multiple
frameworks
for
ebpf
that
are
supported,
and
you
know,
janna
can
go
into
a
lot
more
detail
on
the
ebpf
side
itself.
E
In
terms
of
the
you
know,
the
type
of
metrics
which
flowman
already
handles
versus
you
know
other
frameworks
like
pixie
and
others,
which
also
are
emitting
you
know
or
handling
different
types
of
metrics
right.
So
that's
an
area
that
I'd
like
to
see
a
bit
more
design
and
architecture
work
coming
from.
E
You
know
the
work
group
here
and
also
concretely
having
at
least
a
high
level
backlog,
which
is
identified
for
being
able
to
take
different
components
or
different
parts
of
a
component
and
building
them
out
right
because
again,
it's
easier
for
contributors
to
get
involved.
E
G
Yeah,
not
everybody
is,
I
think,
quite
informed
about
you
know
what
is
the
scope
and
the
use
cases
that
we
are
considering
right
now
and
in
the
future
right
like
yeah
johnson,
your
design
lock
is
great
like
the
initial
proposal,
but
maybe
we
we
need
some
sort
of
like
a
short
list
of
these
are
the
things
that
we
will
be
enabling
and.
G
E
F
G
F
Specifically,
not
metrics
for
us,
we,
we
we're
pretty
opinionated
on
on
these
being
events,
because
of
various
differences
between
time
series
and
events
for
us.
B
So,
given
that
open,
given
that
the
open
telemetry
log
spec
is
not
yet
finalized,
does
that
mean
that
the
events
so
does
that
mean
that
whatever
notion
of
event
comes
out
of
people?
I
guess
two
things.
One,
whatever
notion
of
event
comes
out
of,
ebpf
tooling
will
evolve
as
the
log
as
the
log
spec
approaches,
stability,
that's
one,
and,
to
the
extent
that
people
do
want
summary
metrics
out
of
these.
E
Yeah,
I
mean
that's
a
very
good
point
because
and
and
the
question
I
would
raise
their
punia
to
you
and-
and
you
know,
just
in
general,
isn't
is
that
is
the
conversion
from
events
to
logs
really
the
right.
The
best
way
to
go,
because
you
know
again,
as
as
you
know,
events
are
a
different
animal
altogether
in
many
ways,
and
even
though
there
is
an
kind
of
an
observability
mantra
of
you
know,
having
three
signals
in
in
the
protocol.
E
Perhaps
events
is
not
really,
just
you
know
can
cannot
necessarily
be
completely
transformed
into
logs,
and
this
you
know
use
case
also
shows
up
in
the
real
user
monitoring
events
world
that
you
know
we
are
also
working
in.
So
there
are
other
use
cases
where
you
know
again.
That's
another
area
that
needs
work
in
the
data
model
and
and
yes,
if
we
are
able
to
converge
it
nothing
like
it,
but
that's
an
area
that
needs
work
right
and
then
the
data
model
and
how
that
handles
ebpf.
E
B
I'll
try
to
summarize
that
I
think
that's
a
that's
a
great
that's,
a
great
kind
of
way
to
to
to
kind
of
break
down
the
problems.
So,
first
of
all
are
these
are
the
are
ebpf
events
modeled
as
hotel
events
or
as
logs.
B
That's
kind
of
the
order
question
and
then
what
what's
the
relationship
to
metrics
if
any
yep
right
like?
Is
there
like
a
semantic
relationship,
but
we
don't
specify
how
the
metrics
come
about
or
is
there
like
an
operational
relationship
right
and
and
who's
doing
that?
Okay,
exactly.
F
G
G
Events
like
some
like
role
stuff,
you
know,
maybe
jonathan
you
can
give
a
couple
of
examples.
I.
G
E
G
G
Bolton
has
a
very
like
opening,
I
think
strong
opinion
about.
Like
you
know,
logs
and
events
are
the
same
thing
in
his
mind
like
I'm
also,
you
know
I
was
wondering
like
what's
the
context
about
it,
to
you
know,
just
kind
of
like
be
more
informed
about
the
background
of
you
know
that
way
of
thinking,
because
you
know
I
I
see
it
it's
slightly
different.
I
take
a
look
at
the
destination
in
the
end
of
the
day,
right
like
where
I
I
want
to
plug
my
login
exporters.
G
To
so
that's
like
how
I'm
like
differentiating
the
signal
types.
I
I
don't
know
if
it's
a
good
mental
model
or
not
like
that's,
why
I
feel
like
it
might
be
useful
to
have
events
but
yeah.
I
agree
that
they
will
very
look
similar
to
the
logs.
So
is
it
for
to?
You
know:
have
that
like
type
of
differentiation.
B
Something
so
is
it
fair
to
say
that
that
question
I
mean
it's
a
it's
a
it's
a
foundational
question,
but
it
has,
but
the
ebpf
working
group
alone
cannot
answer
that
question
right.
Yeah.
E
I
mean,
but
that's
the
idea
right,
that
we
would
have
the
use
cases
and
the
examples
clearly
defined
which
apply
to
ebpf.
You
know
for
the
customer
which
we
take
to
the
specs
sig
for
for
deliberation
and
acceptance.
If
we
are
proposing
a
change.
B
So
this
actually
kind
of
connects
to
the
reason
why
I
came
to
the
meeting
it
sounds
like
ebpf
is
well
modeled
as
a
structured
event,
you're
saying
real
user
monitoring
is
another
use
case
for
structured
advance,
yeah
and
perhaps
profiling.
Data
is
another
use
case
for
structured
events
or
its
own
signal
type.
So
it
sounds
like
we
now
have
multiple
cases
where
we
could
invent
a
new
signal
type
or
we
could
say
structured
events
subsumes.
All
these
things.
B
E
G
To
start
with,
like
maybe
logs
as
our
signal
type
and
like
evolve
into
something
else,
just
to
be
a
bit
pragmatic
is.
Is
that
a
huge
concern
like
because
it's
gonna
be
a
breaking
change,
but
I
think
flo,
whatever
we're
going
to
do
here,
is
not
going
to
be
maybe
much
more
enough
for
a
very
long
time.
D
D
D
Code
for
this
that
works
right
and
we
can
extend
it,
but
we're
not
going
to
get
events
in
hotel
until
logs
ships
and
that's
going
to
be
a
while.
So
like
that,
I
I
would
prefer
like
yeah.
We
have
something
that
works
for
now
and
we
just
go
in
knowing
yep,
there's,
probably
eventually
going
to
be
an
event
spec
and
we're
going
to
redo
part
part
of
this
when
that
happens
and
that'll
be
ebpf
v2
or
something.
E
Yeah,
but
that
means
also
that
you
know
you
have
to
keep
in
mind.
You
know
what
the
breaking
changes
are
and.
G
E
Short
term
versus
long
term
right
I
mean
that's
something
that
I
I
agree
with
the
strategy
in
general,
but
I
just
saying
that
there's
work
that
needs
to
be
done.
D
D
E
G
E
B
E
Yeah,
that's
my
understanding
that
it
would
land
in
into
the
collector
as
a
component
which
can
ingest
evpf
events,
ebpf
metrics.
F
So
I
do
think
there's
a
little
bit
of
nuance.
There
too
right.
There's
this
there's
the
receiver
and
there's
also
this
affordance
to
to
have
a
receiver
right
is
the
the
flowmill
collector
the
ebpf
component
or
or
do
we
need
a
harness
where
anybody
can
write?
You
know,
evpf
probes
at
the
receiver,
level,
right
and
and
receiver
is
still
an
abstraction.
It's
not
a
specific
collector
and
you
can
use
the
flowmill
corrupt
collector.
F
B
E
B
My
kindergarten
question
is
the
ebpf.
Collector
is
a
piece
of
c
plus
plus
code,
and
the
open,
telemetry
collector
is
a
piece
of
go
code.
So
what
is
like?
What
is
the
thing
like?
At
the
end
of
the
day?
Will
there
be
some
go
shim
in
the
in
the
open,
telemetry
collector
that
expects
the
ebpf
collector
to
also
be
installed
like.
E
Right
or
as
michael
was
suggesting,
you
know,
there's
a
harness
of
you
know
hashem,
as
you
said,
that
that
exists,
which
is
overall,
you
know,
kind
of
and
again
we're
getting
into
implementation
here.
But
yes,
it's
a
very
practical
question
and
I
do
envision
that
honestly.
B
B
B
Well,
the
other
kind
of
other
extreme
I
have
heard
for
this
kind
of
problem
is
to
say,
look
why
don't
you
have
whatever
thing
you
are
doing?
Export
otlp
and
the
collector
is
not
running
a
sub
process.
The
collector
is
unaware
of
it.
All
that's
happening
is
that
your
thing
is
aware
of
what
you,
because
you.
F
E
B
A
It
yeah
exactly
thank
you.
I
wanna
tell
you
how
the
poc
works
the
what
what
we've
done
is.
We
took
the
kind
of
a
standalone
collector
kind
of
what
you
can
call
you
can
think
about.
A
Like
open,
telemetry
evpf,
it's
a
container
that
you
can
run
on
on
your
systems
and
with
the
configuration
you
can
direct
it
to
the
open,
telemetry,
collector
and
right
now
the
interface
between
the
two
is
oklp
logs
and
and
then
the
open,
telemetry
collector
doesn't
need
to
care
about
kind
of
how
you
set
up
your
how
you
set
up
your
sorry,
evps
collector
right,
like
if
you're
running
on
on
a
non
kubernetes
environment,
you
run
an
rpm,
maybe
with
the
open
elementary
collector,
it
doesn't
have
to
they're,
not
they're,
not
deeply
intertwined.
C
Is
a
component
on
the
instrumentation
side
right
that
has
to
be
accounted
for
because,
typically,
the
collectors
on
a
separate
machine
machine,
whatever
that
is
separate,
compute
unit
somewhere,
but
still
this.
This
working
group
is
also
going
to
cover
the
instrumentation,
I'm
what
I'm
calling
the
instrumentation
side,
but
really
the
the
origination
side.
I
guess
got
it
so.
B
And
then
the
piece
that
lives
in
the
collector
is
doing
data
transformations
and
the
the
thinking
right
now
is
that
the
data
transformation
is
it's
specific
to
ebpf.
It's
not
expressed
in
terms
of
existing
primitives
that
the
collector
has
for
data
transformation.
Is
that
right.
E
I
think
paneer,
the
answer
is,
we
don't
know
yet
we
have
to
actually
evaluate
this
and-
and
you
know,
figure
out
what
that
integration
means,
because
I
think
that
that's
the
mission
of
this
work
group,
as
far
as
you
know,
I
can
see,
because
we
really
need
to
clearly
define
okay.
What
are
the
use
cases
we
are
trying
to
address
here?
How
can
we
leverage
you
know
the
flow
mill
code
base
and
components?
You
know
the
functionality
and
and
how
do
we
best
build
a
end-to-end?
E
You
know
experience
using
the
existing
functionality
of
the
collector,
or
perhaps
you
know
doing
some
mods
but
being
able
to
integrate
so
that
we
can
ingest
ebpf.
A
I
think
the
what
I
I
would
like
to
ask
you
if
what,
if
what
would
if
the
following
would
be
useful,
what
we
could
do
is
next
time
I
can
present
to
the
team
kind
of
the
schema
and
the
the
the
kind
of
the
entity
schema
and
the
the
kind
of
how
telemetry
is
currently
composed
inside
the
flomo
collector
and
exposed
to
open
telemetry,
and
we
can.
We
can
reason
about
kind
of
use
cases
of
how
this
might
be
processed.
G
Yeah
yeah,
I
think
it
would
be
very
useful,
yeah
yeah
is
there
a
way
to
also
like
have
a
google
doc?
It's
so
much
easier
to
comment
on.
You
know
it
would
be
super
useful.
A
A
google
doc
on
schema.
E
E
Mean
so
much
one
of
the
good
practices
that
we
have
kind
of
followed
in
other
word
groups
again
just
just
for
is
that
we
do
actually
do
design
proposals
or
any
proposals
that
you
know
we
want
to
read,
and
maybe
this
is
the
amazon
style,
but
for
having
a
google
doc
available
for
everybody
to
be
able
to
read,
comment
and
then
also
discuss
in
the
sake.
E
So
maybe
that
would
be
useful,
given
that
you
know
we
are
dealing
with
and
then
going
to
work
through
some,
you
know
again
heavyweight
areas
where
we
need
to
define
okay.
This
is
the
this
is
our
assumption.
This
is
how
the
scheme
is
going
to
work.
This
is
how
we're
going
to
interface
with
the
data.
This
is
how
we're
going
to
interface
with
the
you
know.
These
are
the
apis
that
we
can
leverage
with
the
collector
different
components.
So
again,
I'd
like
to
recommend
this.
B
Jonathan
again,
in
the
spirit
of
continuing
to
ask
kindergarten
questions,
the
the
flowmeal
readme
answers
very
admirably
how
to
plump
the
data
from
the
flumil
collector
into
the
open,
telemetry
collector.
But
you
know
I
was
looking
at
the
it
says
like
configure
the
otlp
receiver
and
then
it
doesn't
say
anything
about
processors
and
exporters.
So
it's
hard
to
tell
like
great.
Now
I
have
some
logs
in
and
now
I
have
some
logs
in
some
schema.
B
But
what
can
I
do
with
them
right?
Because
right
now,
they're
just
draw
events
and
it's
it's
left
as
an
exercise
to
the
reader
that
they
can
create
their
own
processors
to
do
something
with
these
logs.
So
if
you
can
help,
I
think
it
could
be
helpful,
at
least
to
me
to
see
a
motivating
example.
G
I
think
there
are
two
cases
right
like
you
can
export
them
in
in
the
back
end
process
them
that's
what
I
think
flowmill
has
been
doing.
The
second
option
is
like
you
know,
we
will
document
the
schema
and
we
will
probably
like
publish
some
processors
at
some
point
to
you
know,
produce
some
metrics
or
other
stuff,
but
mainly
you
know.
I
think
it
will
be
up
to
the
also
developers
like
since
the
schema
will
be
out
there.
You
can
just
write
your
own
aggregations
and
write
your
custom
processors.
G
D
Quick
question
about
slow
milk,
because
I
actually
don't
know
this
like
jonathan-
does
flammable
only
export
logs
today.
Does
it
does?
Does
it
export
like
any
like
metrics
natively.
A
Explicitly
exports
logs
okay,
so
even
if
you
have
some
some
things
that
you
might
consider
metrics
like.
A
Sent
and
bytes
you'd
get
a
log
saying
bytes,
you
know
it's
structured,
so
you
have
it
it's
a
json,
so
you
get,
bytes
is
15.
Bytes
number
drops.
D
Is
one
packet
drop,
I
mean
so
to
me
in
the
absence
of
an
event,
data
type
in
hotel,
which
we
already
talked
about?
What
probably
makes
sense
is
like
things
that
look
and
smell,
like
metrics,
should
probably
just
be
made
native
metrics
in
hotel
right
things.
D
F
Yes,
there
are
metrics
time
series
have
a
cardinality
concern
where,
if
you
want
to
have
two
a
tuple,
be
your
primary
key,
cardinality
tends
to
explode,
right
and,
and
ip
addresses
are
very,
very
short-lived
in
the
clouds
or
sometimes
so,
for
the
use
case
of
networks
being
able
to
do
to
and
from
doesn't
work
well
as
time
series.
F
E
That's
a
very
good
point,
michael
and
and
that's
you
know
and
again
that's
exactly
the
reason
why
you
know:
there's
implementation
details
where
events
as
a
unit
make
more
sense
than
you
know,
taking
a
point
in
time
with
a
metric
right.
So
again
it's
the
usage
also
and
logs
doesn't
necessarily
address
that
same
concern.
Either
I
mean.
E
F
G
I
think
there's
yeah,
there's
like
something
actually
like
I
wanna
add
like
maybe
you
know
when
we're
thinking
about
processors
or
aggregations,
it
should
be
like
modifiable
or
it
should
be
like
there
should
be
rules
right
like
so.
You
pick
your
pick,
the
dimensions
you
care
about,
or
if
you're
you
know
you
know,
the
the
cardinality
is
not
gonna.
You
know
blow
up
things
that
you
should
be
able
to
aggregate.
So
that's
another
conversation
to
have,
and
it
would
be
nice
to
have
a
dock
where
we
can
discuss
this
type
of
use.
Cases.
E
Yeah,
okay,
I
think
johnson
we're
at
time.
Sorry
I
mean,
I
think
this
is
a.
G
E
E
You
know
cadence
for
the
team.
I
can
jonathan
you
and
I
had
discussed
it
right,
but
just
wanted
to
get
general.
I
think.
E
G
E
Because
that's
something
that
you
know
I!
I
have
brought
this
up
in
the
log
sig
where
I've
discussed
this.
You
know
with
the
logs
folks
who
are
working
on
logs
implementation.
I've
discussed
you
know
with
tigran
and
others.
So
again,
at
least
in
the
log
sig.
You
know
there
has
been
some
discussion,
but
I
do
think
you
know
we
have
to.
You
know
take
that
to
the
specs
and.
G
It
is
also
this,
let's
also
discuss
that,
like
you
know,
we
may
eventually
start
with
logs
as
a
prototype
and
eventually
maybe
see
if
they
are
comfortable
or,
if
that's
a
big
concern.
Yes,
exactly.
E
Exactly
I
mean
right
now,
obviously
I
can
say
that
you
know
there
is,
as
you
said,
you
know
also
that
there's
a
strong
you
know,
focus
towards
or
tilt
towards
using
logs
for
anything
that
is
not
metrics
or
traces
so
that
obviously,
that
bias
exists
today
on
the
project,
and
you
know
rightfully
so,
but
again.
If
there
is
a
compelling
enough
case
and
use
cases,
then
we
should
definitely
consider
events
being
you
know
its
own
own
thing
anyway,
I
mean
I,
I
know
we're
over
time
thanks
everyone
thanks
again
thanks
everyone
yeah.