►
From YouTube: 2022-07-20 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
D
B
E
D
C
One
of
you
guys
want
to
drive
that
that
today,
just
a
heads
up
that
I'm
I'm
back
this
week
but
next
week,
I'm
out
again
so.
E
Nothing
like
that.
Actually,
I
work
only
not
like
all
open
source.
E
Yeah
only
this
one,
I
think
this
is
good.
I
wanted.
I
just
left
that,
because
for
the
traditional
maintenance
approver
to
take
a
look
into
it,
as
there
is
another
issue
created
by
petrol
like
we
should
get
the
same
for
asp.net,
that's
the
reason
I
did
not
merge
and
left
it
there.
So
we
can
take
a
look.
A
I
think
the
dotted
framework
we
should
have
kind
of
separate
research
tasks
for
more
than
mysql
data,
but
we
should
cover
somehow
mongodb,
probably
ready.
Yes
and
more
so
I
will
create
a
separate
issue
later
to
cover
all
of
them.
If
we
find
solution
for
one
of
them,
we
probably
find
solutions
for
all
of
them.
Correct.
E
So
I'll
just
leave
it
here.
So
if
they're
like,
we
will
wait
for
one
more
day
and
then
we
will
just
go
ahead
and
watch
that
so.
B
C
But
just
just
if
they
have
the
proper
binding
redirects,
then
we
should
be
able
to
make
it
work
in
the
framework.
A
A
C
D
Okay,
moving
on
now
to
the
issues
and.
E
I
clearly
agree
with
the
discussion
that's
going
over
here.
I
think
this
is
a
better
candidate
for
us
to
bring
in
the
sig
then
sorting
out
here
the
bigger
topic
for
discussion.
C
Yeah,
I
I
also
prefer
the
current
behavior,
because
I
think
we
should
treat
observability
as
a
feature
of
the
application.
You
know,
so
I,
as
a
I'm,
a
developer,
putting
observability
in
my
application.
I
want
to
be
sure
that
that's
working,
you
know
I
don't
want
the
application
limp.
I
understand
not
breaking
the
application
after
they
start,
but
at
start,
if
doesn't,
observability
doesn't
have
observability.
The
application
is
broken.
E
So
we
will
have
already
a
old
implementation
in
those
several
thousands
of
hat
which
is
running
there.
So
if
we
need
to
safely
replace
that
to
the
newer
implementation
like
we
cannot
get
that
done,
because
if
it
goes
and
crashes
their
application,
they
were
not
aware
like
it's
either
the
world
implementation
or
the
new
open
telemetry
is
what
is
causing.
Death
will
be
unnecessarily
breaking
many
people.
So
it's
always
a
debate
when
it
comes
to
this
one.
E
C
So,
but
if
we
keep
the
the
current
behavior
but
have
some
escape
valve,
that
makes
it
more.
I
know
that
it's
kind
of
unwanted
on
us
to
implement
that
that,
in
a
sense
that
we
have
to
track
where
it
could
run,
but.
C
I
I
I
still
think
that
that
at
least
should
be
to
still
break
the
applications.
You
know
it's
a
bad
configuration,
so
we
could
perhaps
do
things
like
for
things
that
require
change
the
project.
We
could
do
things
like
try
to
not
bring
some
instrumentation
that
we
know
that's
broken
or
kind
of
hey.
C
For
instance,
I
know
that
the
code
that
we
wrote
for
mongodb,
for
instance,
if
we
fail
to
load
the
dependence
we
are
gonna
keep
the
application
is
gonna
keep
running
yeah.
The
application
is
gonna
keep
running,
but
we
are
gonna
log,
a
bunch
of
errors.
You
know.
C
Instrumentations
in
general,
don't
break
the
application
in
that
way.
The
problem
is
for
things
like
is.
I
start
upload
thing.
I
think
that's
the
main
issue
that
we
will
have.
You
know.
E
I
I
completely
agree
with
you
follow
like
or
very
simply
we
can
do
it
by
default
cache.
It
provide
an
option
to
turn
it
off
like
whoever
wants
to
control
it
in
the
way
they
wanted.
They
can
set
that
environment
variable
to
control
it
that's
the
right
thing,
but
by
default
I
agree
with
you.
We
should
crash
and
let
the
users
know,
but
if
someone
wants
to
different
biggest
questions.
B
A
A
C
Raj
the
scenario
that
we
describe,
who
controls
kind
of-
let's
say
the
enumerations,
this
kind
of
thing
is
the
user
directly
or
when
they
click
that
button
that
is
already
chosen
for
them.
It's.
E
A
kind
of
distro,
so
we
add
that
we
don't
give
the
control
saying
that
you
add
these
many
environment
variables,
so
it's
all
pre-decided
on
that
button
click.
These
are
the
things
I'm
going
to
connect.
You
know
like,
for
example,
the
asp.net
telemetries
and
strategic
line
televisions,
nothing
else,
so
it
happens.
Based
on
that.
C
So
so,
in
your
sense,
from
your
perspective,
let's
say
the
safest
thing
to
do
on
that
scenario
is
kind
of
have
a
let's
call
lax
mode
right
that
you
kind
of
oh
okay.
I
have
this
wrong,
I'm
to
ignore
I'm
going
to
log
and
go
ahead.
E
Correct
and
we
have
a
kind
of
a
troubleshooting
page,
the
web
page,
which
will
show
the
status
saying
that,
like
what
does
enable
what
is
not
enabled
and
everything
based
on
that.
B
D
D
E
So
very
very
we
will
take
a
very
simple
example
in
our
case,
like
we
enable
all
the
instrumentations
by
default.
Now
so,
while
loading,
the
mongodb
library,
we
ran
into
an
issue.
So
what
my
ask
is
that
we
skip
we
log
and
continue
there
because
mongodb
not
lonely.
B
C
Exactly
I,
I
think
there
is
the
separation,
because
on
the
bottom,
you
guys
control
the
environment
variables,
so
that
should
be
a
hundred
percent
right
for
the
version
that
you
have.
Okay,
what
we
are
afraid
is
kind
of
okay.
We
passed
that,
but
then
we
crash
the
application
because
of
the
dependence
or
instrumentation
instrumentations
should
not
crash
the
app
we.
We
need
to
be
sure
that
also
we
have
good
failure
paths
for
those
in
the
sense
that
let's
say
we
load
that
a
type
dynamically.
C
B
D
E
C
Okay,
okay,
I
I
think
one
case
that
we
need
really
to
pay
attention
is.
I
think
we
are
good
with
the
additional
depth,
but
I
think
there
is
the
possibility
of
some,
let's
say,
between
called
different
applications.
With
some
strength
set
up,
we
failed
to
load
something
you
know
and
that
perhaps
could
crash
the
app.
C
I
think
there
is
a
path
for
that,
but
typically
when
we
load
these
things
from
the
instrumentation,
we
do
a
splist
load
on
the
type
and
if
we
fail,
we
fail,
we
handle
that
failure
and,
as
I
said,
we
should
do
that,
keep
also
in
mind
performance
of
the
failure
case.
You
know,
but
yeah
yeah.
I
think
I
think
that
that
is
the
the
reasonable
path
for
that.
For
this
then,.
D
B
B
E
C
C
You
know
we
can
work
around.
B
Raj
sorry,
paulo
I
joined
the
submitting
and
the
whole
dotnet
sdk
meeting
like
zeke
agreed
that
this
instrumentation
is
not
good.
Okay
and
I
do
not.
I
think
that
code
blanche
is
working
on
that
and
he
tries
to
push
the
stack
exchange
ready
to
use
activity
source
or
do
something
there,
but
yeah.
It's
like
a
little.
D
D
C
D
B
E
D
C
C
B
C
Yeah,
I
think
I
think
you
are
right.
I
think
it's
just
because
I'm
so
used
that
you
have
those
files
there.
You
know
that
I
kind
of
automatically
when
I
want
to
verify
things
I
kind
of
automatically
go
there
and
now
you
have
to
create
a
file,
but
then
I
think
I
get
used
to
it
too.
C
C
I
I'm
sure
that
the
dot-net
runtime,
the
native
components,
are
able
to
emit
the
event
source.
They
are
so
that's
why
I
think
about
that,
but
I
think
it's
reasonable,
at
least
for
the
managed
components
where
avoid
this
working.
We
get
aligned
with
the
sdk
yeah
sounds
good.
B
B
B
An
intermediate
step,
if,
if
it
occur
that
using
this,
I
don't
remember
right
now
what
is
emitting
even
sources
if
I'm
using
even
sources
from
native,
is
harder.
C
Know
that
the
components
for
the
runtime,
the
native
ones,
they
generate
the
natives.
Okay,
they
generate
event
source
events.
You
know
so.
C
Yeah,
so
you
should
be
able
to
specify,
consume
them
and
use
the
same
thing
to
generate
the
files.
So
in
principle
it
should
be
possible.
You
know,
but
the
thing
is
I
don't
know
if
the
runtime
thing
had
the
interest
of
mick
that
easily
exportable.
E
B
Yeah
yeah,
I
see
only
one
troublesome
scenario
that
right
now
this
I
think
that
I
don't
know
how
was
it
called
this
self
self
diagnostics,
something
writer
or
whatever
is
on
the
hotel
side.
So
if
something
crashes
on
the
native
side
and
doesn't
get
into
bootstrapping
and
setting
the
self
diagnostics,
then
the
only
way
to
diagnose
the
problems
would
be
to
attach
this.
I
don't
know
this
even
listeners
or
whatever
from
outside
right.
The
process.
C
Yeah
and
the
worst
part
is
that
the
listings
that
people
have
already
available
as
tools
they
don't
they
are
not
good
for
logs.
You
know
perfect
view.
This
stuff
is.
B
C
E
Or
we
can
do
something
we
can
take
the
rotation
rolling
logic
from
this
and
put
it
in
the
auto
instrumentation,
so
that.
E
C
So
yeah,
I
I
think
separating
the
nature
from
the
manage
makes
a
lot
of
sense.
I
agree
with
robert.
E
D
E
I
need
just
wondered
like
and
code
blind's
agreement
on
that
before
because
it's
super
simple
to
create
a
pr.
So
you
just
wanted
to
like.
B
Regarding
the
first
one,
it's
already
merged
in
the
auto
sdk,
the
only
thing
is
the
only
problem
is
that
we
are
waiting
for
the
release.
I
don't
know
if
there
will
be
a
release
before
november,
maybe
there
at
least
some
patch
or
thing
no.
B
B
C
So
in
one
of
those
meetings
that
we
kind
of
very
roughly-
I
think
it's
true,
perhaps
for
that,
but
we
talked
about
kind
of
the
goals
for
the
zero
three,
because
we
we
we
did
that
for
zero.
Two
kind
of
how
we
are
going
to
add
the
mongodb,
you're
gonna,
add
metrics,
and
did
we
talk
about
what
are
kind
of
the
high
level
goals
for
zero?
Three.
E
As
follow
like
zero
three,
we
want
to
get
it's
completely
about
instrumentation,
getting
all
the
instrumentation
support
by
default.
The
auto
instrumentation.
E
And
I'm
in
parallel,
working
with
the
dotnet
team
for
logs
also
locks
does
not
seems
to
be
very
simple
because
it's
not
on
a
listener
based
it's
based
on
instance,
so
slowly
working
by
creating
a
small
prototype
and
checking
with
them
how
we
can
collect
things
so,
but
probably
once
we
are
released
the
next
beta
I
should.
I
should
have
something
ready
from
them
to
move
forward
in
that
place
for
our
next
beta.
B
E
So
if
you
are
good
with
this,
when
I
have
one
more
more
but
for
a
discussion-
and
I
can
just
move
on
to
that-
so
as
we
are
like
adding
a
lot
of
instrumentations-
I
I
have
a
questionnaire
on
that
because
currently
in
microsoft,
like
the
our
telemetry
products,
does
not
have
many
instrumentation,
so
it's
a
distro
with
a
very
less
instrumentations
in
it.
So
as
we
are
heading
there
are
two
things
comes
into
picture.
E
One
is
the
the
increase
in
startup
time
and
as
more,
the
instrumentation
brings
down
the
rps
of
an
application
so,
like
I
just
want
to
check
whether
like
in
both
in
splunk
and
neural
like
like.
Is
there
like
framework
you
use
to
identify
the
perf
impact
at
a
ci
level
to
do
this
because
we
are
adding
without
knowing,
for
example,
today
we
are
introducing
my
sequel
like
taking
a
dependency
on
another
library.
E
So
how
is
that
impacting?
Do
you
have
anything
to
measure
that
at
this
point.
A
A
B
I
remember
also
some
discussions
around
go
open,
telemetry
go,
I
don't,
but
basically
there
were
several
concerns
because
all
of
all
of
the
seek
wants
to
have
some
benchmarks,
one
of
the
pro.
So
there
was
some
attempts
to
do
in
github
actions,
but
the
environment
is
very
unreliable
because
of
the
containers
of
the
machines
etc.
So,
basically
the
perf.
Basically
it
occurs
that
github
actions
is
not
a
good
place
to
execute
the
benchmarks.
C
Yeah
that
that's
that's
a
very
good
point
too.
I
I
this
we.
We
know
that
they
are
not
reliable
to
run
on
github
actions,
so
the
question
becomes
the
only
way
that
I
can
see
make
this
kind
of
relatively
relatively
I'm
not
sure
it's
kind
of
doing
a
lot
of
bass
runs
on
the
same
vm
and
then
just
measure
the
difference
on
that
vm.
You
know.
So.
Yes,
that's
my
experience
as
well
yeah.
C
So
I
think
I
think,
because
we
would
like
to
have
some
strategy
about
this
in
the
long
run
we
should
kind
of
because
this
question
is
a
question
that
a
lot
of
sophisticated
customers
have.
You
know
and
you'll
be
good
to
have
at
least
some
either
or
a
ballpark
number
that
we
can
give
or
something
that
they
we
are
ready
to
kind
of
facilitate
their
creating
and
testing
by
them
themselves.
You
know
so
we
we
have
what
piotr
described
and
we
are.
C
We
are
kind
of-
let's
say
starting
on
that
path,
but
we
run
the
tests
right.
It's
not
something
that
they
can
see.
We
it's
our
public.
What
we
do
to
to
run
the
tests.
It's
our
open
source,
but
when
you
run
on
infrastructure
that
splunk
pace
right,
so
the
user
can't
run
directly
that
test,
but
we
perhaps
could
use
that
as
a
basis
for
kind
of
this
validation.
C
The
question
also
goes
to
kind
of
because
we
are
leveraging
a
lot
of
the
instrumentations.
C
C
I
think
my
take
is
kind
of
we
should
put
kind
of.
I
don't
know
I
I
would
say
kind
of
I
issue
with
a
bunch
of
tasks,
because
I
think
there
is
a
big
kind
of
possibility
and
alternative.
So
for
us
to
have
something
to
track
and
what
you
are
going
to
have
and
when
you
know
I
don't
think
that
soon
we
can
commit
to
anything
in
this
area,
but
I
think
it's
good
to
track.
E
Sure
the
reason
I
got
this
like
point
is
like:
if
we
go
to
the
open,
telemetry
sdk,
they
work
behind
a
design
motive,
saying
that
zero
are
locations
in
most
the
pieces
and
in
a
less
time
they
won't.
They
don't
want
to
impact
the
application.
For
example,
if
you
look
at
it
in
the
open,
telemetry
or
the
contrary,
repo,
we
have
a
genuine
exporter.
E
That's
the
exporter
that
microsoft
internally
uses
to
collect
telemetry.
So
that
does
not
do
any
allocation
at
all.
Most
of
the
allocation
happens
in
the
stack
and
everything
and
it
writes
to
the
etw.
It
does
not
do
any
so
serialization
wise
also.
It
is
very,
very
fast
actually
so
when
the
sdk
is
in
that
way,
we
also
need
to
ensure
that
when
we
are
facilitating
to
auto
instrumentation,
we
don't
break
those
puff
criterias
by
adding
whatever
is
needed
at
least
having
a
bench.
C
Yeah,
for
instance,
allocation
benchmark.
Then
we
can
run
anywhere
right,
so
we
we
could
do
that,
but
then
I
I
get
back.
We
should
be
using
those
on
the
instrumentations
directly
right,
so
the
sdk
also
did
the
the
people
that
work
that
did
that
for
the
contributor
do
we
have
benchmarks
running
for
the
instrumentations
on
the
contrib.
E
I
don't
think
so.
The
the
reason
is
they
can
very
simply
say
because
in
the
contrary,
every
project
has
a
owner
apart
from
the
maintainer
or
the
approvers,
so
they
are
the
responsible
persons
for
that.
So
in
the
worst
case,
if
instrument
is
not
performing
it
like
open,
telemetry,
sdk
and
maintenance
or
approval
may
not
be
responsible
for
it.
C
D
C
Yeah
yeah,
I
think
I
think
yeah,
let's
open
an
issue
and
try
to
track.
You
know
I
I
it's
needed
it's
ideal,
but
it's
a
lot
of
tasks
and
a
lot
of
work
to
get
this
so.
E
No
not
at
this
point
I
I
think
it's
good
to
have
it
because,
as
it
is
more
close
to
the
instrumentations,
I
just
got
that
point
over
here.
B
So
just
to
sum
up
just
to
sum
up,
so
you
you
think
about
knowing
what
is
the
like,
initialization
overhead,
what
is
like
the,
for
example,
overhead
of
the
instrumentations
and
what
is,
for
example,
some
of
the
memory
over
here
regarding
the
locations
etc,
because
all
of
these
things
could
be
probably
like
benchmark
exclusively
right,
yeah
in
a
different
way.
E
C
E
E
B
E
Like
we
say
all
instruments
like
chris
created
an
issue,
so
we
need
to
spend
some
time
going
through
that
and
understand.
What's
our
priority
for
our
next
beta,
because
we
don't,
we
have
not
made
that
decision.
Yet
we
are
randomly
creating
issue
yeah.
We
will
just
get
that
done
and
then
decide
the
date
when
we
want
to
release
the
next
beta.
C
Yeah
one
thing
that
I
would
say
is
that,
because
we
are
adding
a
bunch
of
new
instrumentations,
we
really
kind
of
when
we
have
the
next
release,
we
should
really
kind
of
trying
to
get
the
open,
telemetry
community
very
wide
talking
about
it.
You
know,
because
then
it's
more
interesting,
I
don't
think
you'll
be
yet
to
the
point
of
talking
to
the
dot-net
runtime
blog,
but
for
the
open,
telemetry
itself.
E
Okay,
that
makes
sense,
like
I
think,
when
you
called
out
that
that
isn't
like
open,
telemetry,
auto
instrumentation,
which
had
some
issue
actually
when
we
say
automatic
instrumentation,
it
was
giving
something.
I
don't
know
how
to
fix
that.
E
One
of
the
program
manager
called,
and
he
said
like
not
able
to
understand
for
dot
net
automatic.
If
we
look
at
it,
it
speaks
about
adding
a
package
and
everything.
I
don't
know
what
this
comes.
Yeah.
A
A
E
C
No
no,
but
I
I
I
agree
with
you.
What
we
see
for
java
is
the
what
I
will
call
for
automatic,
correct
and
the
dotnet
should
be
the
same.
You
know,
but
yes,
that's
kind
of
thing
that
we
need
to
get
the
message
and
kind
of.
I
think,
with
this
next
reviews
we
are
gonna,
have
many
more
instrumentations
and
very
popular
stuff,
so
I
think
we're
in
a
better
position
to
kind
of
spread.
The
message.
B
D
E
I
think
that's
all
we
have.
We
are
going
to
end
10
minutes
early.