►
From YouTube: 2022-06-28 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
A
C
Thank
you.
I
don't
think
I
can
share
my
screen
because
I
have
some
issues
with
my
laptops.
I
am
from
my
phone,
so
can
one
of
you
utkash,
if
you
can
like
share
your
screen,
sure
thank
you.
C
A
I'm
not
sure
if
yeah
erasmus
do
you
think
it
will
be
worth
if
you
first
present
your
pr
or
you
think
I
should
start.
I
think
you
can
start
actually.
Okay.
So
sorry
for
my
background
noise,
because
it's
late
even
here
and
my
daughters
are
around
missing.
If
you
fear
to
ask
me
for
a
petition
because
I
don't
know
when
some
when
you
cannot
hear
me
or
not
so
I
mean
I'll
share
my
screen
and
try
to.
A
A
So
this
is
the
issue
which,
which
I
created
like
a
few
minutes
ago.
It's
not
on
the
sdk
repository
because,
like
I'm,
the
maintainer
of
the
auto
instrumentation
repository,
but
I
create
it
first
here
for
first,
first
of
all
for
tracking
and
secondly,
because
before
getting
creating
anything,
we
want
also
to
discuss
it
ourselves.
A
So
the
quality
of
whatever
we
will
create
will
be
better
and
simply
to
not
involve
you
more
than
needed,
but
before
doing
anything
even
starting,
I
wanted
to
just
give
a
teaser
on
what
we
want
to
do
just
to
get
initial
feedback
if
it's
even
a
good
way
or
not.
So
basically,
as
for
our
outer
instrumentation,
what
we
are
doing
we
try
to.
A
We
are
working
on
enabling
or
trying
to
enable
all
of
the
instrumentation
libraries
like
or
by
default
or
basic,
even
enabling
to
add
it
without
changing
the
the
code.
A
So
we
have
several
approaches
how
we
try
to
apply
it,
but
one
of
the
problems
that
we
see
is
if
we
can
enable
the
auto
instrument
issue
for
certain
library
is
dependent
on
the
instrumentation
library
code.
That
is
there.
So
I
will
give
a
few
examples
of
a
library
that
is
easy
for
us
to
auto
instrument
and
some
which
is
very
hard
to
auto
instrument,
and
so
the
example
like
the
first
example
is
npgsql.
A
Basically,
the
activity
is
as
simple
as
it.
As
far
as
I
quickly
looked
into
the
source
code,
the
activity
sources
are
created
in
the
code
base.
There
is
nothing
needed
like
and
like
needed,
there's
nothing
needed
them
more
than
that.
There's
no
need
to
create
a
special,
for
example,
npg,
sql
connection
or
adding
any
more
libraries
etc.
Cj
do
you
want
to
say
something,
and
I
was
just
acknowledging
what
you
said.
A
So
this
is
the
first
example,
which
is
ideal.
If
you
have
instrumentation
library,
a
library
which
works
like
that,
then
it's
super
easy
and
I
think,
is
the
way
that
microsoft
basically
designed
the
activity
api.
That
is
how
how
I
think
microsoft
expected
libraries
to
be
instrumented,
but
this
is
my
assumption.
A
Second,
one
is
something
like
we
call.
A
social
library
is
the
mongodb
it's
so
so
because
it
requires
to
where
was
it
yeah
to
make
some
little
changes
in
the
mango
clay?
In
the
like,
in
the
in
when
creating
the
the
mongol
client.
A
It
is
so
so
because
I
imagine
that,
if
someone
has
like
is
right
in
an
application,
then
it
will
not
be
a
very
big
deal
to
enable
it
because
it
can
be
like
understood
as
part
of
the
of
the
mongodb
setup,
but
it
requires
additional
changes
and
from
our
perspective,
we
are
just
registering
rewriting
the
code
when
it
is
registered
and
we
try
to
simply
add
such
code
when
we
see
that
a
mongodb
is
created
it
right
now,
it
requires
to
use
a.net
profiler
and
in
theory
I
think
there
can
be
some
edge
cases
which
could
cause
the
application
to
crash
the
other
one
and
the
last
one
which,
like
the
hardest
one
from
our
perspective,
and
I
think
it's
also
the
hardest
one
for
the
application,
like
using
manual
instrumentation
as
well.
A
Maybe
I'm
wrong,
because
I
was
not
using
it,
but
these
are
just
my
guesses,
so
basically
we
were
just
I'm
not
sure
if
our
our
this,
my
nose
is
correct,
like
regarding
this
apis
for
instrumentation
libraries,
but
we
are
thinking
of
proposing
something
or
creating
some
guidelines
that
would
help
first
of
all
for
like
because,
first
of
all
for
us
for
auto
instrumentation,
but
hopefully
also
like
this.
That
will
help
also
the
manual
instrumentation
users
as
well
to
make
it
more
easier
to
consume.
C
So
I
can
give
a
quick
update
like
there
is
already
a
section
on
how
to
write
instrumentation
library.
So
if
you
go
to
the
main
repo
go
to
docs,
let's
just
open
that,
but
while
you're
at
it
like
it's,
sometimes
not
feasible
for
us
to
do
anything
about
like
reddish
climb
because
register
does
not
simply
do
any
any
events
which
we
can.
Who
can
do
so.
The
only
way
is
to
like
accept
the
actual
connection
and
then
modify
things
inside
that
so
yeah,
okay,
yeah.
You
can
open
the
extending
the
sdk.
C
Search
for
building
your
own
instrumentation
library-
and
it
has
like
some
guidance
it-
it
suggests
people
to
do
the
right
thing,
but
since
it
is
not
feasible
in
some
cases
like
this
is
a
good
example
that
is
just
not
allowed
like
any
nice
way
to
like
who
can
do
it?
That's
why
we
need
the
connection.
C
I
haven't
looked
at
the
mongodb
thing
yet,
but
I
believe
it
also
is
like
somewhat
not
like
very
friendly
to
write.
Instrumentation
sequel
is
very
good.
They
just
fire
eventually
can
attach
to
it.
We
just
call
like
ad
sql
and
you
just
create
sql
by
defaulting.
You
don't
need
to
pass
the
actual
instance
to
us.
C
Http,
client
and
sp
network
are
like
in
between
because
they
do
create
the
activity
but
somewhat
incorrectly,
but
that's
just
just
a
like
temporary
limitation,
because
starting
with
dotnet
7,
that's
like
majority
of
them
are
being
addressed,
and
eventually
it
will
be
like
a
trust
even
further.
So
so,
whatever
guidance
we
have,
I
expect
we
should
do
it
in
the
write.
Your
own
instrumentation
library,
section
of
the
door
which
we
just
opened.
Thank.
A
C
D
Yeah,
I'm
just
going
to
mention
that
so
some
of
it
is
like
the
case
with
that
redis
instrumentation
is
we
don't
have
much
of
a
choice
because
the
api
that
redis
exposes
is
this
profiling
api,
that's
built
on
the
connection
multiplexer,
so
you
have
to
hook
into
that
in
order
to
turn
on
your
profiling
session,
get
all
the
data
and
then
we
emit
activities
from
it.
So
the
better
solution
in
that
case
is
we
have
to
work
with
stack
exchange
redis
to
ideally
have
their
own
activity
source
and
just
emit
activities.
D
D
D
As
open
telemetry
grows
as.net
you
know
adopts
it
before
it
was
maybe
a
little
bit.
You
know
the
gray
area,
they
didn't
really
want
to
do.
You
know
our
span
api,
but
then
we
got
it
in.net.
Then
there
was
some
confusion
about
you
know
semantic
convention,
so
it
might
be
a
little
bit
of
a
journey
to
get
there,
but
I
don't
even
know
if
it's
time
yet
to
approach
the
authors
semantic.
C
C
So
it's
probably
like
the
right
time
to
like
start
poking
asking
them,
because
I
expect
70
conventions
to
get
stable
over
the
next
few
months.
So
at
that
time
like
they
should
be
able
to
like
just
follow
it,
as
is
yeah,
and
I
think
for
the
stack
exchange.
A
Maybe
I
just
want
to
mention
here.
I
just
mentioned
one
thing:
I
think
that,
even
if
the
library
is
like
not
like
instrumented
inside,
there
can
be
still
some
little
like
api
changes,
which
will
make
it
more
like
first
of
all,
easier
for
consume
to
us,
but
I
think
that,
secondly
also
better
design
in
general.
Right
now,
if
you
have
a
redis
connection,
each
address
instrumentation
creates
a
separate
thread.
As
far
as
I
looked
quickly.
A
What
if
there
are
three
or
four
or
ten
redis
connections,
we
need
to
spa
ten
threads.
I
think
that
it
should
be
separated
the
coach
which,
as
the
ins
like
the
redis
instrumentation
and
which
drops
the
connection
which,
where
we
want
to
add
basically
the
which
is
responsible
just
to
wrapping
for
wrapping
creating
the
activities.
A
C
No,
I
got
the
point
like,
but
what
I
was
saying
is
we
don't
have
any
control
over
the
library
itself,
the
stack
exchange
itself.
They
don't
provide
us
with
any
hooks
except
the
one
which
they
currently
have
the
profiler-based
thing
which
we
wrap
on.
So
ideally
they
would
just
use
the
activity
source
fund.
So
we
don't
really
need
this
hack,
we'll
just
publish
it.
C
So
we
get
the
activity,
but
it
would
definitely
take
a
long
time
for
them
to
move
to
that
because,
as
we
were
saying,
the
semantic
conventions
part
is
not
stable,
yeah,
but.
A
A
E
B
E
C
F
We
can
hear
you
okay,
perfect.
I
have
to
change
to
another
mic,
something
about
this
career
anyway.
I'm
not
sure
how
many
are
familiar
with
the
pr.
C
I
have
looked
at
the
issue
which
you
have
linked.
The
issue
which
robert
also
tried
to
allude
to
earlier
about
adding
sources
after
the
provider
is
built,
see
vr
is
doing
because
I
didn't
look
at
this
pr,
but
it
says
it's
linked
to
the
issue
about
subscribing
to
activity
source
after
the
provider
is
built.
F
Exactly
so,
basically,
I
had
to
back
off
like
a
lot
and
I
I
undid
the
changes
in
the
asp.net
core.
So
basically,
we
can
move
most
of
the
code
to
the
auto
instrumentation
site,
using
some
reflection
and
mostly
just
a
few
reflection
lines
and
add
the
sources
manually
there.
So
this
is
basically
doing
the
trick.
A
But
what
you're
understanding.
F
A
F
C
F
So,
first,
basically
the
review,
but
the
general
program
comes
out.
The
instrumentation
libraries
are
built.
Basically,
we
see
a
lot
of
different
patterns.
Currently
you
can
have
like
adopters
connecting
to
existing
telemetry
making
activities
then
just
subscribe
to
the
activities,
and
so
basically
this
makes
us
very
hard
to
make
a
common
scenario
out
of
it,
and
that's
why
the
robert
also
created
the
issue
that
is
trying
to
frame
the
how
the
instrumentation
libraries
are
created.
C
C
We
should
like
track
it
in
the
issue,
because
it's
not
really
in
our
control,
how
we
can
ask
people
to
write
instrumentation
libraries
if
they
already
do
like
create
activity
as
http,
client
and
sp
net
code,
then
we
have
to
do
like
some
extra
thing
like
we
have
to
do
some
reflection,
hack
ourselves.
Then
there
are
cases
where
they
do
publish
diagnostic
source
events,
which
is
very
easy
to
subscribe
to,
and
then
we
create
activity
on
their
behalf.
C
And
then
there
is
a
completely
different
thing,
like
sequel,
client,
for
old
dotnet
framework,
which
just
publishes
even
source,
which
is
again
easy
to
subscribe,
and
then
we
create
activity
on
like
ourselves
so
like
we
need
all
these
things,
because
there
are
like
different
ways
to
like
basically
attach
or
hook
into
a
library.
C
C
Source.Startactivity
as
opposed
to
the
activity
source,
because
it
did
not
so
all
these
are
like
results
of
like
historical
thing,
and
some
of
them
would
be
like
to
solve
by
dot
net
seven,
which
is
releasing
end
of
this
year.
Like
http
client
sp
network
would
move
away,
but
we'd
still
have
this
hacks
in
the
sdk,
because
we
still
want
to
support
older
versions
of
asp.net
core
and
http
client,
so
that
would
partially
explain
like
why
we
have
like
different
patterns
of
different
types
of
instrumentation
libraries.
Some
is
easy.
Some
is
moderate.
C
Some
is
very
hard
is
that
the
problem
which
you
are
after
or
your
only
sole
issue
which
you
are
after,
is
the
ability
to
add
activity
source
after
the
provider
is
being
built
because
in
this
pr
it
looks
like
you
are
like
doing.
I
don't
see
this
pr,
adding
the
ability
to
add
an
activity
source
after
provider
is
being
built.
Is
that
something
which
you
intend
to
do
as
a
separate
one
or
like
this?
Pr
is
solving
it
in
a
different
way.
F
Yeah
I
actually
had
to
build
a
little
bit
because
I
also
opened
the
issue
and
taught
at
runtime
about
the
activity
listener
and
got
a
good
response
there
that
actually
we
don't
need
to
add
sources
later,
because
we
can
do
the
sources
and
the
poster
big
time.
F
F
So
that's
why
I
had
a
little
idea
that
if
you
have
like
a
interface
that
or
after
class
that
you
need
to
implement
for
your
instrumentation
library,
you
can
like
separate
sources
instrumentation.
F
C
A
C
Yeah,
because
ad
instrumentation
is
added
just
to
tie
the
life
cycle
to
the
provider.
So
if
you
just
do
like
add
instrumentation,
all
we
are
doing
is
just
keep
it
in
the
trace
provider.
So
when
the
provider
itself
is
being
disposed,
we'll
check,
if
any
of
the
instrumentation
passed
to
us
will
also
get
disposed
if
they
implement
ids
possible.
So
that's
the
only
thing
which
we
do
with
ad
instrumentation.
We
don't
do
anything
with
that
in
creating
the
activity
listener
side.
C
A
C
C
So
when
an
activity
source
is
being
created,
that's
the
only
time
we
look
at
the
source
name
and
check
whether
we
should
be.
A
C
A
C
So
is
that
described
in
this
pr
also
because
I
haven't
had
the
chance
to
actually
look
at
it,
because
you
describe
that
certain
things
are
like
must-haves.
Certain
are
like
nice
to
have
so
is
that
described
in
the
that
issue?
Does
not
talk
anything
about
instrumentation,
it
simply
says
we
need
the
ability
to
resource
I'm
talking
about
issue
3253,
but
this
pr
is
like
attempting
something
else
which
is
to
touch
the
ad
instrumentation
site.
B
It
was
a
mistake,
yeah
cjo
kind
of
hit
on
some
of
it.
D
The
main
thing
I
wanted
to
ask
is
like
cj:
I
don't
totally
understand
what
problem
we're
solving
if
we
just
want
to
track
the
lifetime,
so
we
can
dispose
things.
Couldn't
auto
instrumentation,
just
keep
a
list
of
the
instrumentation
objects
and
dispose
them
when
it
either
shuts
down
or
it
detects
the
tracers
being
shut
down.
F
A
C
A
F
C
So
maybe
I
can
clarify
one
thing:
it's
in
the
same
dock,
which
I
mentioned
about
earlier,
the
talk
about
writing.
Instrumentation
libraries
ad
instrumentation
is
really
optional.
You
don't
need
to
do
it.
You
only
do
it.
If
you
expect
the
sdk
to
manage
your
lifecycle,
that's
only
time
you
would
do
the
ad
instrumentation
code.
There
is
no
need,
so
it's
really
optional.
C
F
Yeah,
the
one
thing
that
was
confusing
is
basically
you
can
use
the
instrumentation
object
to
actually
post
a
adapter
to,
for
example,.
F
F
F
This
is
the
main
issue,
as
of
with
the
asp.net
core.
C
E
F
So
currently
we
didn't
have
much
problems
with
the
solution
that
and
described
in
the
pr
just
the
future
about
how
to
do
it
for
every
instrumentation
library
like
commonly,
because
if
the
everything
is
using
different
bootstrapping
options,
they
don't
have
like
framed
interfaces
or
something
like
that.
That's
gliding
strongly.
A
Yeah,
but
I
think
it
should
be
like
addressed
in
the
issue
that
I
described,
that
I
I
need
to
check
how
the
guidelines-
and
I
think
that
we
will
not
say
like
solve
the
problems
of
the
whole
world
and
the
whole
ecosystem
yeah.
Exactly
some
instrumentation
will
be
hard.
You'll
need
to
use
reflection,
the
sum
will
be
easier
and
it
will
be
just
like
just
adding
subscribing
like
adding
source
for
some.
A
C
In
the
sdk,
so
can
you
like
summarize
like
what
is
the
expected
expected
action
from
the
sdk
team?
Is
it
just
wait
for
this
draft
to
be
like
stable
before
we
offer
review,
or
do
you
want
to
like
know
whether
the
approach
as
a
whole
is
in
the
right
way
or
like?
Is
there
like
something
more.
F
Yeah,
I
think,
currently
it's
just
review
the
draft
and
let's
see
how
we
can
like
add
this
functionality.
C
So
like
I
would
suggest
you
like
make
the
description
clearer,
because
it
needs
to
explain
like
why
you
are
touching
the
ad
instrumentation
and
not
the
add
activity
source
api,
because
the
linked
issue
is
all
about
activity
source.
So
it
will
be
like
helpful
if
you
update
the
description
to
explain
the
intent
and
we
should
be
like
able
to
review
it.
I
mean
just
because
like
if
there
is
no
response,
then
we
can
decide
like
who
is
the
best
person
to
reveal
like
I
can
help.
A
F
A
C
A
C
So
do
you
want
to
have
like
any
other
questions
discussed
on
the
same
topic,
or
I
mean
we
don't
have
any
other
topics,
I'm
happy
to
keep
this
one.
If
not,
we
can
move
to
the
next
topic
which
is
non-existent.
So
that
means
we
can
it.
C
Any
other
topics,
for
I
mean
I'm
in
a
room
without
my
laptop,
so
I
don't
really
have
access
to
the
like
notebook.
So
if
anyone
can
see
if
there
is
anything
added
to
the
agenda,
that
would
be
great.
Otherwise
we
can
end.
C
Okay,
it
looks
like
no
other
thing
so
robot
like
please.
Let
us
know
if
you
need
anything
in
the
slack
channel
and
we
can
try
to
be
as
helpful
as
possible
and
if
needed,
you
can
bring
it
in
the
next
thing.
But
I
I
I'll
try
to
see
if
you
can
address
it
in
the
slack
itself,
because
I
know
it's
like
very
odd
time
for
you
to
join
the.
C
Not
possible,
but
maybe
interviews
yeah,
we
will
see
like
if
you
like,
really
need
to
like
talk
to
one
of
the
maintainers.
We
can
always
schedule
something
at
hog
because
we
don't
really
want
to
like
force
you
to
join
at
late
night
if
it's
something
which
we
can
solve
offline
in
a
separate,
dedicated
call
if
needed.