►
From YouTube: 2021-08-12 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).
A
Let's
wait
for
another
couple:
people
to
join
and
hey
introduce
yourself,
hey,
morgan!
Evan.
Do
you
have
a
link
to
the
agenda?
I
can
post
it
in
the
chat.
A
A
The
epf
summit
is
coming
up
august,
18
19th,
it's
going
to
be
exciting.
I
know
jana
is
speaking.
I
have
I
a
lightning
talk,
cool.
A
Okay,
should
we
start
maybe.
C
Yeah
might
as
well
get
started.
I
I'm
expecting
attendance
of
this
and
other
things
to
be
pretty
low
for
the
next
few
weeks,
just
due
to
vacations
like
even
internally,
it's
splunk
like
I
feel,
like
a
third
of
the
people
on
vacation
right
now,
yeah.
C
A
Yeah,
so
there
were
two
items
on
the
discussion.
I
promised
evan
I'll.
Let
him
introduce
himself.
I
don't
know
if
you
want
to,
but
you
have
to
you
have
the
stage
if
you,
if
you
want
to.
B
Yeah
I'll
quickly
introduce
myself.
I've
been
working
on
the
go
side
of
things
for
for
open
telemetry
and
I
have
an
interest
in
low-level
system
things.
I
haven't
done
a
lot
of
work
with
ebpf,
but
I'm
super
interested
in
potentially
learning
more
and
seeing
where
I
can
contribute.
A
So
the
I
think
that
two
items
there's
one
item
that
we
carried
over
from
last
week
and
we
ended.
We
ended
the
the
discussion
last
week
with
potentially
discussing
where
does
container
enrichment
come
from?
Does
it
come
kind
of
so
there
is
a
list
of
of
sorry
orchestrators
that
the
that
the
ebpf
proposed
contribution
that
collector
supports
right
now
and
there's
kind
of
what
I
understood
from
yana
is
that
there
are.
There
is
a
much
wider
support
in
other
and
other
hotel
infrastructure.
So
the
question
is:
do
we
re-implement
everything?
A
So
do
we
have
to
port
support
from
other
hotel
collectors
into
the
epf
collector,
or
can
we
reuse?
I
think
that
was
the
gist
of
the
conversation
I
didn't.
I
don't
think
there's.
D
D
A
I
see
so
with
as
the
receiver.
You
think
it
will
be
easier
to
leverage
some
of
the
other
metadata
that
is
collected
in
my.
D
B
C
I
think
effectively
and
jonathan.
You
know
the
most
about
this.
So
correct
me
if
I'm
framing
this
incorrectly,
but
the
the
discussion
is,
should
it
be
a
separate
process
that
itself
then
turns
things
into
otlp
and
sends
that
to
the
otlp
receiver
of
the
collector?
Should
it
be
its
own
receiver
being
its
own
receiver
is
generally
how
we've
structured
things
like
this
in
the
past,
there's
there's
a
lot
of
extensibility
there.
C
C
I
don't
know
it
definitely
seems
cleaner
to
me
that
it
would
be
another
receiver
granted.
It
is
written
in,
I
believe
in
c
plus,
whereas
I
think
almost
all
the
other
receivers
are
go
also.
It.
D
Probably
requires
definitely
requires
elevated
permissions,
so
separating
concerns
there
makes
sense
for,
for
logistic
reasons.
A
A
C
So
you
you
lose
some
of
the
benefits
of
having
a
receiver
where
people
can
then
arbitrarily
process
the
data
through
all
like
the
metrics
and
tracing
processors
within
the
collector,
because
you're
gonna
have
to
send
it
otp.
You
can
do
processing
then
on
that
otlp
step,
but
that's
gonna
be
sort
of
a
second
step.
I
I
would
suggest,
like
I
will
say
this
like
if
it's
structured
as
a
receiver,
it
will
be
perceived
as
a
community.
C
If
we
want
this
to
be
something
that
everyone
can
use,
which
I
think
like
ebpf
and
open
telemetry
is
something
we
want
everyone
to
use.
If,
if
they
desire
it,
a
receiver
is
probably
the
way
to
go
because
a
lot
of
people
just
say:
oh
it's
another
receiver.
I
already
use
like
a
bunch
of
different
receivers.
I'll
turn,
one
one
more
on,
as
opposed
to
like
here's.
This
janky
separate
thing.
D
It
is
a
jinky,
separate
thing,
a
datadog
what
we
found-
and
I
know
I'm
contradicting
myself,
because
I
was
very
pro
receiver
half
a
second
ago.
We
implemented
it
as
a
second
process
because
of
the
escalated
permissions
thing,
but
it
doesn't
run
itself.
D
So
there
are
ways
to
mask
it.
People
will
notice
people
do
notice,
but
but
there
are
ways
product
ways
to
to
sort
of
hide
this
you're
right.
D
Otherwise,
people
will
notice,
we
don't
re-implement
our
docker
check
logic,
we
collect
just
the
c
group
name
and
the
ip
address
and
and
a
time
stamp
tuple,
and
I
think
we
do
resolution
on
the
back
end,
which
won't
be
available
to
open
telemetry,
because
there's
no
common
back
end,
so
we'll
be
very
opinionated
on
forcing
people
to
write
back
end
logic
if
they
want
to
use
this
feature,
which
I
don't
think
is
great
for
open
telemetry
and
the
way
that
it
works
for
datadog.
C
So
we'll
need
someone
who
knows
the
collector
better
than
myself
to
like
talk
about
the
feasibility
of
basically
like
a
receiver
that
runs
as
a
separate
process.
It
might
be
possible,
it
might
not
be,
but
we
need
like
t
burner
bogdan
or
one
of.
E
C
Would
definitely
know
yeah
yeah
and
she
will
probably
have
some
pretty
well-founded
opinions
on
this
as
well,
because
she
was
here
last
week
when
we
were
discussing
it.
So
hopefully
we
see
her
next
week.
A
So
anything
that
can
reduce
friction
for
users
and
make
the
experience
better
kind
of
bad
I'd
love
to
implement.
As
long
as
it's
you
know,
it's
not
a
worse
technical
solution.
I.
C
Think
either
a
receiver
or
what
michael
just
described
like
a
like
a
receiver
that
appears
to
everybody
as
a
receiver,
even
if
it
technically
is
running
a
second
process
underneath
so
they
can.
We
don't
have
to
tell
people
that
the
collector's
now
running
in
like
full
trust
mode,
which
understandably,
they
wouldn't
love,
post,
red
hat
or
not.
Red
hat
sorry,
post.
E
B
Can
can
I
ask
a
question
about
that
like
to
maybe
explain
like
I'm
five?
Why
would
the
collector
need
elevated
permissions
to
receive
data
from
this
epps
is.
C
C
D
I
think,
and
again
morgan
actually
will
know
more
than
me
on
this,
but
I
think
receiver.
The
english
word
is
also
sort
of
a
misnomer
in
the
open,
telemetry
collector.
The
receiver
is
any
input
to
the
collector,
but
it
could
still
be
the
collector
reaching
out
to
an
endpoint
and
grabbing
something
and
in
ebpf
it
will
be
the
receiver
reaching
out
and
and
getting
information
from
the
linux
kernel.
D
But
it's
not
just
like
I'm
here,
listening
and
receiving.
B
C
C
D
Yeah
yeah,
if
yeah,
if,
if
we
can
do
it,
that's
what
worked
for
us.
A
Right
and
so,
if,
if
that
solution
works,
does
enrichment
does
the
does
the
collector
have
sufficient
kind
of
depth
in
in
the
telemetry
that
it
collects
so
does
it
have
information
about
every
container
or
only
containers
that
send
metrics
to
it?
For
example,.
D
A
Okay
as
well,
because
the
reason
I'm
asking
is
so
that
you
can
have
global
visibility
because
ebpf
is
going
to
send
you
the
collector
telemetry
for
all
the
containers
running
in
the
system,
not
only
ones
that
have
other
collectors
running
on
them,
and
so
you
want
to
make
sure
you
have
metadata.
For
you
know
the
process,
you
know,
process,
name,
process,
id
containers
and
so
on.
C
I'm
going
to
start
a
slack
thread
on
the
cncf
slack
with
on
hotel
ebpf,
which
we
have
a
channel
for
with
I'll
tag,
t
grand
and
bogdan,
because
they
know
the
most
about
the
collector.
I
think
and
just
ask
if
it's
possible,
to
have
receivers
run
as
a
separate
process
and,
if
so,
and
also
tychiana
and
if
so
like.
What's
what's
the
deal
with
that.
D
A
So
we
so
the
collector
right
now
tries
to
do
all
of
the
mergers
that
it
can
locally,
but
some
some
merges
are.
We
took
kind
of
design.
You
know
we
we've
designed
the
system
so
that
you
can
have
you
know
a
single
collector
that
contacts
the
kubernetes
master.
We
didn't
want
to
overload
the
kubernetes
master
by
subscribing
to
all
the
pod
updates
from
every
node
on
the
system,
so
metadata
from
kubernetes
has
joined
kind
of
just
yeah,
okay,.
A
A
A
So
when,
where
are
we
going
to
so,
for
example,
socket
statistics
currently
have
referred
to
an
identifier,
a
socket
id
and
the
socket
id
is
associated
with
all
the
metadata
for
the
socket
and
the
process,
but
it
tags
the
socket
the
process
that
it's
on
and
the
process
also
reports
metadata
the
process
tags
the
container
the
container
owns
metadata.
So
you
have
this
normalized
data
scheme.
A
We
found
that
data
scheme
to
be
very
helpful
in
reducing
the
volume
of
telemetry
that
you
need
to
send
back
right,
so
you
can
think
about
it
as
encoding
a
compression,
it's
it's
compression
workload,
specific
compression,
and
that
is
less
useful
as
a
user
going
through
logs.
If
you
want
to
stream
data
into
a
log
processing
system,
you
need
you
want
to
denormalize
or
denormalize
the
data.
A
A
A
So
right
now,
I
think
containers
is
are
not
kept
in
the
so
not
all
of
the
metadata
is
kept
for
all
of
the
entities
that
the
user
space
tracks,
and
so
the
collector
is
completely
capable
of
enriching
of
you
know,
decorating
all
of
the
telemetry,
with
all
of
the
context
that
it
has
to
denormalize
the
data,
although
not
the
way
it's
implemented
today,
because
not
if
we
haven't
the
purpose
of
of
the
state
in
user
space
right
now
for
the
collector
was
to
aggregate
metrics
so
that
you
can
you
get
metrics
at
the
10
millisecond
granularity
from
evpf,
and
you
aggregate
them
to
one
second
and
send
them
out
at
one
second
granular.
A
So
you
don't
keep
for
every
socket
the
ip
addresses.
For
example,
you
keep
the
you
keep
a
count
of
the
number
of
bytes
and
the
latency
and
so
on,
but
it
is
very
easy
to
add
this
extra
metadata
once
you
have
that
it
is
easy
to
just
to
send
out
messages
that
have
all
of
the
enrichment
context
for
every
for
every
statistic
report
right
like
every
every
signal
you
send
out,
and
so
I
think
that
is
the
that
is
the
plan
in
order
to
denormalize
data
in
the
collector.
A
B
So
so
my
comment
from
looking
at
the
otlp
protobuf
stuff
is
that
there
is
always
associated
a
a
resource
and
then,
with
that
resource
there
will
be
multiple
measurements
right.
So
some
of
what
you're
saying
sounds
like
you
describe,
maybe
the
socket
and
the
context
and
things
as
a
as
a
resource.
I'm
not
maybe
I'm
talking
out
of
my
head
because
I
don't
know
the
details
here
but
and
then
you'd
have
multiple
measurements
and
so,
when
you
actually
send
them
or
receive
them,
I
I
guess
I'll
leave
it
there
that
I
just
wondering
how.
A
A
A
D
D
C
Yeah
or
if
they
do
it's
wildly
different
yeah
implementations
yeah,
but
but
it
would
be
nice
right
like
like
you,
could
generate
a
but
far
better
understanding
of
a
system
with
it.
And
secondly,
you
could
also
reduce
the
amount
of
data
being
sent,
because
you
know
to
explicitly
stamp
resource
information.
You
could
reference
it
yeah,
but
yeah.
Well,
I
would
not
expect.
B
C
You
could
dramatically
like
your
your
trade-off
is
that
for
your
back-end
service
having
to
maintain
some
out-of-state
the
resources,
you
could
trim
the
metadata
sent
on
a
lot
of
these
things,
pretty
dramatically,
which
would
be
very
nice
so
one
day,
I'm
sure
we'll
get
to
it.
A
Yeah,
and
so
if
this
schema
is
not
compatible,
the
the
normalized
schema
is
not
compatible
with
how
how
open
telemetry
does
the
work?
Then
we
can.
We
can
we
can
denormalize
data.
I
think
compression
schemes
today
do
a
pretty
good
job
of
eliminating
the
redundancy.
So
what
you
would
have
in
your
data
is,
you
would
have
a
lot
of
these
lines
of
this
container
this.
This
sock,
this
process,
the
socket
and
with
all
the
metadata
of
well.
A
I
guess
if,
if
we
let,
if
we
let
the
open
telemetry
collector,
do
the
the
enrichment
on
the
on
on
the
containers
right,
that's
what
we
were
talking
about
receivers
in
line
versus
kind
of
a
different
process.
If
we,
if
we
can
have
the
containers
enrichment
be
done
by
open
telemetry,
then
we
still
have
process
information,
socket
information,
so
ip
addresses
and
then
and
then
the
metrics
and
you
you'd
want
to
you'd
have
like
these
types
of
reports,
the
the
data
will
be
high,
but
it
might
compress.
A
So
the
is
that
a
good
is
that
a
good
plan.
This
is
what
we
were
hoping
to
do.
A
A
You
know
you
can
you
know
the
the
evp
collector
als
already
exposes
kind
of
these
lines
of
saying
this
is
the
processor
like,
like
the
open
telemetry,
already
keeps
metadata
for
collectors,
so
you
could
have
the
denormalized
data
flow
in
and
then
do
the
enrichment
in
the
in
the
open,
telemetry
collector
and
the
other
possibilities.
What
I
talked
about
a
couple
minutes
ago,
which
is
there's
already
state,
being
kept
in
in
the
seat
of
plus
code,
and
you
can
denormalize
there.
A
B
Yeah,
I'm
sorry,
I
haven't
read
either
of
these
stocks
either
that
you're
talking
about.
But
one
question
I
do
have
is
what
is
the
expected
frequency
of
data
delivery
in
this
sort
of
case
for
ebpf?
Are
you
talking
about
like
once
a
second
you
said,
you're
aggregating
at
10,
millisecond
intervals
and
then
setting
once
a
second?
Is
that
the
type
of
thing
you're
talking
about.
A
What
we're
doing
okay,
so
the
current
udf
collector,
which
is
configured
to
is
from
ebtf.
You
receive
10
millisecond
measurements
on
every
socket
that
is
active,
then
aggregate,
the
user
space
aggregates
it
c
plus
code
aggregates
it
to
one
second
granularity
and
then
every
socket
that
was
active
on
the
system.
You
get
a
report
at
one
second
granularity.
It's
configurable,
I
believe,
there's
a
there's
configuration
switch.
A
You
can
tweak
it
to
five
seconds,
and
so
whatever
you
need
but
yeah,
that's
the
granularity
currently
and
you
get
like
per
socket
information.
B
A
Yes-
and
the
question
is:
do
you?
Is
it
the
case
that
you
have
reuse
of
the
same
socket
if
you
have
reuse
of
the?
If
you
have
just
a
handful
of
sockets
that
are
open
with
a
lot
of
traffic,
then
that
reduces
your
telemetry
but
frequently
in
interactive
systems.
They
just
open
tons
of
sockets,
so
it
doesn't
really
matter
what
granularity
you
have
for
that.
You
know
not
not
significantly.
It
just
depends
on
the
workload.