►
From YouTube: 2022-05-25 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
C
B
C
C
C
C
C
I
think
the
apart
from
that
there
are.
C
C
C
C
E
So
my
thoughts
on
this
as
far
as
the
next
beta
release
goes,
I
don't
think
it's
necessary
to
include
yeah
by
code
instrumentation
that
supports
metrics.
I
think
we.
C
E
Release
that
at
a
later
point
in
time,
specifically
when
we
talk
about
graphql,
I
believe
we've
got
another
issue
out
there
talking
about
how
what
we're
doing
with
that
is
not
outdated.
As
far
as
the
semantic
conventions
are
concerned
too,
for
spams,
and
so
it
might
make
sense
to
get
the
span
side
updated,
and
I
don't
even
know
if
there's
any
conventions
defined
yet
for
the
metrics
for
for
graphql,
and
so
that's
either.
Something
that
we're
going
to
want
to
proto
prototype.
B
So
just
my
comments
from
my
study,
because
I
initially
put
the
comment
my
idea
around
creating
this
issue.
Maybe
I
have
made
the
wrong
title
and
it's
not
described
it's
not
to
actually
include
new
bytecode,
matrix
instrumentation,
but
just
to
have
some
kind
of
high
level
idea.
B
It
can
be,
of
course,
changed
later,
but
some
initial
design
idea,
even
from
like
client
perspective,
meaning
that,
for
example,
if
we
would
like
to
add
matrix
instrumentation
for
graphql,
would
it
be
included
into
the
existing,
auto
instrumentation
or
would
add
a
separate
like
instrumentation,
so
that
the
user
could,
for
example,
enable
only
spans
instrumentation,
auto
instrumentation,
only
metrics
instrumentation,
or
if
there
will
be
those
two
together.
Always
that
was
my
first
question
and
like
and
it's
here,
because
our
current
configuration
and
parameter
variables
are
like
per
signal.
B
And
I
do
not
know
the
answers
like
at
first
glance.
I
probably
it
will
be
better
to
have
per
span
per
and
parametric
separate,
auto
instrumentations,
but
I
know
how
hard
it
will
be.
It
will
be
even
to
implement
it
to
have.
You
know
regit
like
two
times
one
fourth
span
since
second
for
metrics
and
make
sure
that
it
doesn't.
I
don't
crash
together.
I
have
no
experience
here.
C
Yeah,
the
one
thing
that
we
need
to
keep
in
mind
is
what
chris
brought
up
like
the
semantics
for
this
one.
What
is
the
metric
that
we
are
going
to,
even
if
we
are
planning,
for
example,
we
have
a
request,
duration
in
asp.net.
We
know
that
is
the
metric
that
we
need
to
track.
We
don't
know
for
graphql
like
what
is
that
needs
to
be
tracked,
so
at
least
I.
B
Is
instrument
so
you
just
if
you
scroll
down
my
one
thought
was
if
you
scroll
down
a
bit
the
a
pop-up
into
his
instrumentation
section,
instrumentation
section,
so
we
have
like
like
right
now:
hotel.net
automatrix,
disabled
instrumentations
and
traces
disabled
instrumentations
and
I
started
to
think.
Maybe
it
would
be
easier
for
us
to
have
like
something
like
auto
bytecode,
disabled
instrumentations,.
C
B
C
That's
what
yeah,
I
think,
that's
a
good
thing,
I
I
would
say
yeah
as
we
as
you
called
out.
This
requires
like
a
little
designing
from
that
aspect
from
in
our
project.
E
E
Do
we
need
two
different
instrumentation
assemblies.
Can
we
get
away
with
two
different
instrumentation
points
into
the
same
method
or
do
those
have
to
be?
E
B
B
C
B
E
Yeah
and
robert
since
you're
just
prototyping,
you
can
probably
ignore
the
semantic
convention
idea
if
you
want
to
just
create
some
random
metric
for
with
graphql,
just
just
to
to
show
what
the
behavior
could
look
like.
Yeah,
because.
B
B
C
So
this
is
the
first
time
I'm
doing
this.
I
might
need
help
from
both
of
you,
robert
and
chris,
so
which,
where
to
start
on
this
board,.
C
So
this
one
like,
I
had
a
question
actually
so
I
thought
it's
good
to
have
all
the
materials,
but
I
I
just
want
to
have
a
thought
here.
Actually
the
question
do
you
think
like
because
there
was
a
question
like
I
asked
before
two
weeks
like
saying
that
if
there
is
an
sdk
already
in
the
project
like
we
agree
that
we
need
to
step
back
and
don't
do
anything,
that
was
the
discussion
and
we
we
stopped
it
as
we
hit
the
time.
C
So
if
that
is
the
case,
we
don't
need
to
solve
this
issue
at
all.
We
don't.
If
we
find
open
telemetry
sdk,
we
don't
even
need
to
load
the
open
like
auto
instrumentation
library
at
all,
so
this
issue
goes
off
in
that
way.
Is
that
what
we
want
to
achieve,
because
we
were
thinking
on
top
of
this,
we
are
doing
something
and
what
I
realized
after
that
conversation
is
like
if
we
find
an
like
app
with
an
open,
telemetry,
sdk
already
instrumented,
auto
instrumentation
will
do
nothing.
C
That's
what
I
understood
from
the
other
day,
conversation.
E
I
think
there's
a
little
bit
more
to
it
than
that,
so
it
comes
down
to
so
they're
already
using
the
the
sdk
to
instrument
their
application.
So.
C
E
What
are
the
reasons
that
they
would
be
using
this
project,
and
so
one
reason
is
cloud
vendors,
providing
it
out
of
the
box
for
them.
So
maybe
that's
why
it's
being
used,
but
another
possible
reason
is
maybe
they're
intentionally
enabling
it
because
they
want
to
use
bytecode
instrumentation,
in
which
case
I
feel
like
there's.
Some
compatibility
work
that
we
need
to
do
to
to
make
that
possible.
B
B
See
effort
potential,
but
it's
only
in
my
mind.
I
never
saw
it
like
I
saw
it.
Similar
stuff
in,
for
example,
go
sdk
that
some
configuration
might
be
hard
to
set,
for
example,
using
environmental
variables.
B
As
an
example,
I
can
say
that
the
go
like
the
go
sdk,
for
example,
enables
you
to
set
the
tls
configuration
for
the
exporters
that
are
in
use
so
that
you
can.
You
can
set
very
complex
tls,
like
tl
tls
configuration
that
is
very
strict
more
than
the
defaults.
That,
for
example,
do
you
only
accept
ls
1.3?
E
There's
some
really
complex
configuration
that
can
be
done
there.
I
don't
think
that
net
necessarily
provides
all
those
same
hooks,
but
I
I
honestly
haven't
paid
close
enough
attention.
C
I
I
do
believe
like
dot
net
asset.
We
we
need
to
get
that
as
a
part
of
our
auto
instrumentation,
also
through
environment,
variable
the
views
and
all
so
like.
Coming
back
to
this,
I'm
in
agreement
with
that,
like
that,
we
may
need
to
load
our
auto
instrumentation.
C
Also
in
that
case,
for
example,
we
will
take
a
scenario
where
customer
has
an
app
with
sdk,
but
he
also
wants
the
bytecode
instrument
or
mongodb
or
like
a
graphql
in
that
case,
like
he's
going
to
have
a
two
trace
provider,
unless
he
handles
all
the
environment
variables
properly,
we
will
collect
data
from
these
two
places
and
send
it
to
the
exporter.
C
So
in
case
of
devops
scenario,
it
becomes
even
more
trickier
because
they
just
go
and
enable
the
devops
guy
will
be
different.
Then
there
will
be
a
entirely
different
guys,
so
they
just
go
and
turn
on
the
button.
They
don't
set
any
of
the
environment
variables
in
devops
case
all
the
customer
do
is
like
they
just
turn
on
a
button.
C
That's
how,
like
I
would
say,
nearly
1
million
of
apps
in
azure
apps,
like
in
azure
environments,
are
auto
instrumented
in
that
way
they
just
toggle
the
button
and
auto
instrumentation
gets
enabled
for
them
and
we
send
data
to
the
backend
service.
So
in
those
cases
they
might
have
an
sdk.
So
in
those
cases
we
will
have
a
two
tracer
provider.
Both
will
be
sending
data
to
them
and
that's
where
we
see
a
major
issue
because
they
will
be
charged
for
both
of
them.
The
injustice
ingested
data.
C
So
this
is
how
we
avoid
currently
like.
We
have
an
option
like
whenever
we
find
an
sdk.
C
The
auto
instrumentation
backs
off
in
our
logic,
whatever
the
microsoft
currently
has
it,
and
we
have
a
button
called
as
interrupt
the
moment.
They
enable
that
what
it
does
it,
it
disables
the
telemetry
collection
from
the
sdk,
and
it
enables
only
the
telemetry
collection
from
the
auto
instrumentation.
So
we
have
that
toggle
button
to
just
for
the
customers
to
select
whether
it
should
be
sdk
one
or
the
auto
instrumentation
one
that
needs
to
be
enabled.
C
I
had
a
conversation
with
like
noah
because
it
tracer
provider
is
on
the
builder
pattern,
so
we
can
combine
the
configuration
and
try
to
make
it
work,
so
the
dotnet
does
not
recommend
that
they
say
whenever
we
try
to
combine
any
of
the
builder
and
try
to
combine
the
configuration
we
always
run
into
issues
at
some
point
in
time,
so
their
recommendation
is
always
to
keep
one
of
them.
So
this
is
a
recent
conversation
I
had
with
noah
about
that.
C
That's
the
reason
why
I
proposed
like
we
should
be
reaching
out,
like
the
sdk
space,
to
provide
a
disable
switch
on
the
tracer
provider
bill,
so
that
we've,
if
need
be
auto
instrumentation,
can
take
control
over
that
and
that
switch
can
be
only
provided
for
auto
instrumentation
use
not
for
all
the
users.
They
don't
need
to
document
publicly
or
something.
So
that's
the
reason
why
I
bought
up
that
point.
The
other
day.
E
Yeah
yeah,
it's
you
brought
up
an
interesting
point:
how
in
that
case
in
azure,
there's
a
switch
that
they
can
control
as
to
whether
or
not
they
want
to
re-enable
the
sdk's
version
and
disable
the
the
auto
instrumentation.
C
E
C
So
in
normally
when
just
enabling
is
just
clicking
on
this
button
and
ensuring
this
is
enabled
for
auto
instrumentation
to
get
enabled,
but
if
there
is
an
sdk
presence,
we
just
back
off
if
customer
sees
no
telemetry
or
if
they
don't
see
something
expected,
they
just
come
here
during
the
troubleshooting
session.
We
just
say
that
just
go
ahead
and
enable
this
like
override
the
sdk
which
is
present
so
that's
it
like
so.
Finally,
the
even
our
auto
instrumentation,
like
whatever
the
whenever
we
take
it.
This
is
how
it's
going
to
go
to
the
customer.
C
E
Yeah
that
that
behavior
seems
to
to
make
sense
to
me
where
it
gives
the
sdk.
So
so
the
program
configuration
precedence
over
the
auto
instrumentation.
C
So
if
we
agree
like,
I
will
create
an
issue
in
like
the
open,
telemetry,
sdk
and
robert.
I
may
need
your
help
because
might
not
be
tracking
the
work
there.
I
might
need
your
help
to
see
if
that
moves
in
the
right
direction.
B
B
So
I'm
usually
I'm
usually
when
I
wanted
something
I
just
was
creating
issues
and
I'm
pinging
pinging
or
on
slack
or
like
before
I
joined
the
sick
meetings.
I
always
try
to
ping
on
slack
or
cg
or
really
or
or
even
on
slack
channel.
If
that
wasn't
helping-
or
I
saw
that
I
need
more
conversation,
then
I
was
like
at
last
resort.
I
was
joining
the
sig
meetings
because
they're
extremely
late
for
us
in
poland.
C
Okay,
I
got
it
so
I
had
a
the
discussion
with
cjo
on
this,
because
cjo
knows
this
implementation
from
our
more
so
he
he
says
this
is
not
only
going
to
help
only
us
it's
going
to
help
the
entire
auto
instrumentation
to
come
in
at
the
end.
This
is
a
like
valid
us.
That's
what
he
said.
Probably
I'll,
create
an
issue
and
follow
up
with
him
or
blanche
to.
B
C
So
I
just
want
to
like
we
all
of
us
sure
to
be
in
sync
and
in
agreement
to
get
this
done,
because
if
we
are
in
not
a
good
agreement,
it
makes
no
sense
to
engage
the
sdk.
That's
what
I
thought.
C
Okay,
let
me
move
on
to
the
next
one.
I
think
bootstrap
meter
provider,
now
eight,
I'm
still
working
on
the
few
document
update
and
the
the
example
that
we
have.
We
have
a
run
example
dot
sh.
I
want
to
modify
the
script
to
add
the
metrics,
also
to
be
a
part
of
it,
so
I'm
working
on
that
part.
I
know
like
and
again
robert
also
pointed
out
one
other
document
where
we
need
to
do
an
update.
I
will
get
that
done
and
then
I'll
move
this
towards
closure.
C
C
B
I'll
be
off
starting
friday
for
one
week,
but
then
afterwards,
maybe
I
will
try,
maybe
I'll
be
able
to
help
it,
because
I
think
the
biggest
challenge
here
is
just
to
create
some
mock
grpc
endpoint
to
catch
the
metrics.
I
assume
and
some
helpers
like
the
infrastructure
to
to
test
it
in
a
stable
way.
A
A
B
You
know
have
the
test
applications
having
the
the
test
logic.
A
C
B
The
problem,
if
the
test
application
will
like
test
itself,
would
there
be
any
do
we
expect
any
problems
like
side
effects
or
not?
Really,
because
I
imagine
that
we
could.
You
know,
for
example,
even
put
some
tests
there
and
just
you
know,
for
example,
put
an
exit
code
exit
with,
for
example,
one.
If
something
fails,
if
everything
goes
successfully,
could
return,
zero.
E
And
I
feel
like
we'll
we'll
lose
a
lot
of
the
niceties
of
the
that
the
test
runners
bring
as
far
as
yep
debug
ability
and
all
of
that.
A
B
C
Sure
so
the
next
one
is
the
matrix
instrumentation,
so
we
have
the
logic
for
it.
All
we
need
to
do
is
like
add
the
packages
we
already
have
a
packages.
Also,
I
remember
we
just
need
to
test
it
out,
updating
the
launch
settings.json.
B
B
C
C
C
B
B
B
Here-
and
there
is
already
a
comment
from
rayleigh
that
he's
basically
at
the
bottom-
that
he
he's
okay
with
the
proposal
and
he
had
even
added
some
tips.
How
we
can
how
we
can
go
forward.
C
E
B
E
E
C
E
Yeah,
I
don't
think
anybody's
been
working
on
it,
but
it
right
now.
I
think,
in
our
documentation,
where
we're
calling
out
version
library
versions
that
are
supported,
we
just
have
an
asterix
yep
and
we
just
want
a
way
to
try
to
communicate
what
are
the
supported
versions.
And
so,
in
a
previous
meeting
we
talked
about
linking
to
some
of
the
package
documentation
and
deferring
it
that
way,
but.
C
E
So
this
kind
of
like
this
implicit,
oh,
does
this
asterisk
mean
all
versions
or
is
it
just
a
subset.
E
E
I'm
not
arguing
against,
including
it
or
anything.
It's
just
something
I
just
wanted
to
call
out
so
that
we're
aware,
maybe
when
we
have.
A
B
I
think
that
in
future
it
might
be
useful
to
have
something
like
an
experimental
flag
which
someone
could
explicitly
enable
that
would
like
to
use
like
non
1.0
like
instrumentation
libraries,
because
in
a
lot
I
think
I
feel
that
a
lot
of
customers
do
not
like
wants
to
have
something,
and
it
will
not
matter
that
much
if
the
span
names
or
the
the
the
attributes
are
will
change
or
not.
That's
my
that's.
My
expectation.
C
Yeah,
oh,
I
think
better.
We
haven't
even
a
better
approach,
I
believe
the
plug-in
approach,
so
I
would
say
instead
of
redoing
something
if
someone
needs
we
should.
Our
recommendation
should
be
to
use
a
plug-in.
It's
a
lot
easier
than
any
other
thing
they
have.
The
customers
will
have
the
control
over
it.
C
So
do
we
have
any
other
topic.