►
From YouTube: 2023-03-15 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
Hey
Alan,
I
I
think
we
can
start
I
I'm,
not
sure
if
CJ
would
be
joining
I
think
he's
been
busy
with
some
other
stuff
at
work.
B
So
the
very
first
thing
on
the
agenda
I
have
put
this
here:
I
added
it
so
on
contract
repo
someone
opened
a
PR
where
they
wanted
to
modify
where,
when
we
run
public
API
analyzers,
so
this
isn't
the
contract
repo.
This
is
I
think
the
same
as
main
repo,
that's
where
it
was
a
copy.
We
currently
only
run
it
if
it's
on
Windows
and
in
on
this
PR
I
think
the
change
is
to
just
run
it
from
Windows
and
Mac,
but
then
I
think
somewhere
in
the
pr.
B
Then
Peter
had
also
mentioned
that
we
could
just
get
rid
of
the
condition
completely
because
then
people
are
developing
on
Linux
wouldn't
be
able
to
see
public
API
analyzer
errors,
if
on
their
Dev
machine,
so
I
wanted
to
ask,
like
is,
does
anyone
know
like
is?
Was
there
any
particular
reason
for
having
it
run
only
on
Windows?
E
I
think
this
would
only
matter
if
there's
any
NET
Framework
compilations,
because
that
would
be
skipped
on
a
non-windows
environment
and
it
might
affect
the
public
API
but
I
think
most
of
our
projects,
Target
net
standard.
So
maybe
it's
not
an
issue
at
all.
A
D
Prevents
things
from
building
because
there's
like
a
Net,
Framework,
Target
or
something
then
I,
guess
that
would
be
kind
of
a
deal
breaker
but
looks
good
to
me.
B
Yeah
so
Alan
you
usually
like
develop
on
a
Mac
right.
Like
do
you
have
you
ever
run
into
issues
where.
D
Yeah
I
could
absolutely
test
this
out.
You
know
if
we
do
this
because,
yes,
I
do
I
mean
I.
I
I've
got
a
Windows
VM,
because
Visual
Studio
is
just
better,
but
I
do
use
Visual
Studio
code
a
lot
of
the
time,
so
I
would
absolutely
try
this
out.
I
didn't
even
know.
This
is
the
reason
it
wasn't
working
I
just
figured.
It
was
like
Visual
Studio
code
is
wasn't
capable
of
of
running
this
analyzer
or
something
I
never
actually
like,
dug
into
the
the.
Why
behind
any
of
this?
D
So
if
this
works,
I
I
would
love
it.
That
would
be
cool.
B
Okay,
yeah
I
took
then
maybe
we
should
like
have
it
run
for
every
platform
and
then
make
sure
that
for
non-windows
it's
only
running
on
non
non-net
framework,
core
I
yeah
I
mean
that
should
be
doable.
B
Cool
then
I
think
I'll
respond
to
that
PR
yep.
Moving
on
to
the
next
items.
C
Okay,
so
this
came
in
yesterday
and
I
see
sigil
started.
E
C
But
I
have
seen
something
similar
in
the
past
and
I
always
wondered
if
this
is
something
that
we
support,
so
what
they
are
doing
is
they
are
targeting
net
four
six,
two
in
the
application.
However,
then
the
user
is
just
using
the
package,
references
to
asp.net,
core
MVC
and
asp.net
core,
and
they
are
expecting
the
ASP
net
core
instrumentation
to
work
correctly,
so
I
just
wanted
to
like
see
what
everyone
thinks
about.
This
scenario
is
just
like
considered
like
a
supported
scenario,
even
like
outside
of
open
Telemetry.
C
Is
this
supported
scenario
in
the
in.net
I
still
just
wanted
to
get
some
ID
on
this
and
I
I
have
seen
something
similar
as
well
somewhere
else
too.
So
it
just
wasn't
just
curious
about
this
thing.
C
A
C
Yeah,
so
the
thing
is
like
they
don't
Target
asp.net
core
2.1
correctly,
so
like
the
their
app
like.
If
you
open
the
branch
like
there's
a
link
to
that
Branch
just
go
to
examples
open
that
asp.net
Code
test.
B
Actually,
I'm
projecting
this
on
a
on
another
bigger
screen,
so
my
mouse
is
doing
like
I'm,
okay,
never
mind
but
yeah,
so
they
have
ASP
Network
package
reference
here.
So.
C
Plans
this
this
is
like
targeting
net
460,
which
is
a
supported
framework.
Microsoft.Exp
net
core
is
a
nuget,
but
it
doesn't
say
it's
deprecated,
so
is.
Is
that
one
also
not
supported.
D
E
A
D
Definitely
had
customers
that
were
running
it,
on.net
framework
there's
even
like
this,
like
IIs
module
that
is
used
in
order
to
to
run
asp.net
core
apps
within
IIs.
C
D
An
interesting
case
because
we
say
we
support.net
framework,
462
and
above
and
we
don't
really
have
like
a
stated
support
policy
in
terms
of
like
versions
of
the
instrumentation
or
the
things
that
we
instrument.
C
Yeah,
so
they
are
complaining
about
like
something
with
Dandridge
I
believe,
but
then
they
will
have
some
other
issues
too.
I
think
they're
they're.
The
correlation
will
not
work
the
w3c
because
we
like
we
are
not
extracting.
C
C
So
this
could
potentially
have
other
issues
as
well
like.
If,
if
we
think
that
this
is
supported,
then
we
have
to
go
back
and
see
what
all
things
were
removed
because
of
removing
the
Network
apps
2.1
support.
C
Yeah
so
I
think
before
3.1,
like
it
was
I've
removed
that
the
reflection
way
of
extracting
context,
but
that
just
fails
because
now
they're
targeting
net
standard
like
the
next
standard,
one
will
be
used
in.
Apparently
this
doesn't
work
with
the
net
standard,
one.
That's
what
Dimension
and
the
issue.
C
So
we'll
have
to
bring
all
of
these
things
back
and
also
I
believe
something
with
the
the
context
extraction
as
well.
It
is
2.1
was
not
w3c
compatible
I'm,
not
wrong,
but
yeah,
so
we
removed
that
those
checks
as
well.
So
we
have
to
do
like
a
whole
bunch
of
different
things.
Now
to
support
this,
we
are
looking
to
do
that.
D
Actually,
I
wonder
if
this
would
be
that
bad
I
mean
can
I
wonder
if
you
can
use
like
dot
Net
7
with
asp.net
core
2.1.
If
that's
not
the
case,
then
what
we
might
be
able
to
do
is
just
add
a
net
462
Target
for
the
instrumentation
and
just
add
those
lines
just
for
that
compilation
of
it
does
that
make
sense.
D
C
Probably
not
right
because
it's
the
packages,
dot,
Net
7-
will
bring
higher
version
of
those
packages
automatically
if
I'm
not
wrong.
The
microsoft.asp
net
core
and
Dot
ldc1
I
could
be
wrong.
I
haven't
tried
that
but
I'm
I'm
guessing
that
it
will
be
out
of
created
for
them,
or
they
will
see
a
compiled
time.
Error
saying
that
that
is
downgrade
error
or
something
like
that.
B
C
Yeah
so
for
this
one
I
just
wanted
to
get
some
review
on
this
and
had
a
question
on
the
the
behavior
about
the
observable
instruments.
C
C
What
I
noticed
is
in
case
of
observable
instrument.
Only
one
of
them
is
taken
and
it
depends
on
which
one
is
coming
in
last.
C
So
just
wanted
to
understand
like
if
this
is
like
in,
like
some
expected
Behavior,
or
this
whole
scenario
is
like
undefined
in
terms
of
the
specification,
because
if
the
instrument
is
non-observable
like
like
a
counter
or
something
we,
we
just
kind
of
combine
the
the
the
metrics
from
both
the
instruments
into
one.
So,
if
I
have
like
two
counters
with
same
instrument
name
each
reporting,
some
Metric,
both
of
them
will
be
combined
into
one.
But
that's
not
the
case
with
observable.
Only
one
of
them
wins.
C
In
this
scenario,
I
tried
looking
up
the
spec.
Also,
there
is
some
data,
like
some
text,
about
the
duplicate
instruments,
but
it
doesn't
really
differentiate
between
like
observable
and
non-observable.
B
A
bit
about
it,
just
like
very
briefly
I,
had
a
discussion
about
this.
So
he
said,
even
if
you
have
like
multiple
observable
instruments
with
the
same
name,
it
should
be
calling
each
of
those
like
or
each
of
those
callbacks
should
be
called.
And
since
we
do
last
value
aggregation
for
observable,
like
gauge
or
I,
think
even
for
counter.
B
We
just
pick
the
the
Callback
that
reported
the
value
last,
the
last
callback
that
reported
the
value,
essentially
so
I
think
if
you
in
your,
you
had
some
sample
app
where
you
had
like
a
simple
two
observable
counters,
one
to
turn
like,
let's
say,
number
20,
another
returning
number
25
and
the
one
which
is
called
the
last
is
what
what
gets
returned
right.
So
maybe,
if
you
and.
A
B
We
don't
have
any
unit
tests
for
it,
but
which
I
think
would
it
would
be
good
to
add
to
the
repo
to
verify
this.
Video
I
haven't
checked
it,
but
as
far
as
this,
like
from
what
I
learned
from
sijo,
if
you
have
multiple
observable
counters,
with
the
same
name,
each
of
their
callbacks
is
called
and
within
our
aggregation
logic,
we
do
last
value
aggregation.
That's
why
it
gets
that
picks
up
the
last
one.
C
That
that
basically
means
like
the
last
like
the
the
Callback,
which
was
called
first,
is
just
like
ignored
right.
Ultimately,
it's.
B
B
Theoretically,
that's
where
the
behavior
should
be.
We
don't
have
any
unit
tests
to
like
test
this
Behavior.
B
You
and
since
for
counter
the
like
for
some
types,
the
aggregation
type
is
usually
the
count
as
its
sum
right.
The
aggregation
type.
It's
not
last
value
aggregation.
So
if
you
have
multiple
counters
of
the
same
name,
you
just
add
them
up,
because
that's
the
aggregation
expected
for
her
or
that
type
of
metric.
C
Got
it
okay,
thanks
I'll
I'll,
go
ahead
and
add
that
unit
test,
then
for
the
metric
SDK
file,
so
yeah,
leaving
that
I
yeah
whenever
everyone
has
chance.
Please
take
a
look
at
this.
We
are
if
like
right
now,
there
are
still
some
issues
that
I
need
to.
C
Figure
out
along
the
same
lines
having
the
duplicate
instrument,
but
with
an
observable
callback,
so
yeah
trying
to
figure
it
out
right
now.
So.
B
Yeah
and
I
think
a
few
other
things
we
probably
it's
going
to
have
like
one
instrument
for
per
signal
like
instead
of
creating
a
counter
for
each
batch
export
processor,
Maybe,
just
one
observable
counter
for
all
Trace
related
batch
export
processors
and
one
for
all
log
related
batch
export
processors
and
have
the
if
there
are
multiple
instances
report
them
via
dimensions,
because
all
of
this
does
take
up
a
lot
of
memory.
Each
instrument
we
create
takes
up
a
good
amount
of
like
decent
considerable
amount
of
memory.
So
we
don't.
D
Sorry
I
have
not
spent
much
time
looking
at
spr
at
all,
so
this
might
not
make
sense
at
all,
but
I'm
just
wondering
if,
instead
of
creating
instrument
inside
of
the
batch
export
processor
itself
like
what.
If
we
had
like
some
Central
place,
where
we
defined
all
of
the
metrics.
Where
are
all
of
the
instruments
for
measuring.
A
D
Health
in
like
a
separate
class
in
and
of
itself,
that
maybe
components
like
the
export
processor
could
access,
or
maybe
it's
instantiated
with
like
a
handle
to
it
or
something
so
that
we
don't
run
it.
We
wouldn't
even
run
into
the
situation
where
we're
creating
multiple
instruments.
C
B
So
what
I
was
saying
was,
let's
say,
for
a
single
SDK
registration
if
you
have
like
two
Trace
match
export
processors.
B
D
One
one
thing
that
like:
if,
if
we
want
to
count
like
I,
don't
know
I'm
getting
a
little
abstraction
because
I
don't
know
exactly
what
this
this
PR
looks
like
it's.
It's
measuring
like
batch
export
processor,
how
many
it
it
dropped!
What
if
the?
What?
If
the
actual
instance
of
the
processor,
was
a
dimension
on
the
metric
rather
than
part
of
its
name.
B
Yes,
I
was
kind
of
suggesting
that,
like
have
oh
okay,
one
observable
counter
just
for
traces
which
will
show
you
any
Trace
related
batch
exporters
and
what
they
dropped
and
a
separate
one
for
logs
I.
Don't
know
if
there's
value
in
like
merging
than
both,
but
so
like.
Let's
say
you
have
two
otlp
Trace
exporters
registered
to
your
SDK.
B
C
I'm
going
sorry,
no
okay,
it's
okay,
yeah,
so
like
I
actually
started
with
that,
but
since
we
were
already
calculating
the
dropped
count
like
so
I
changed
it
up
with
the
observable
one
so
that
we
don't
have
to
redo
the
same
thing
twice
together.
F
I
know
Riley
has
that
guide.
That
tells
you,
when
you
should
use
the
different
types
and
one
of
them
doesn't
allow
you
to
merge.
Like
he's
got
the
example
of
temperatures
like
you
can't
add
temperatures
together,
it
doesn't
make
any
sense.
I
feel
like
that's
the
observable
case,
but
I
could
be
misremembering
so.
B
That's
I
think
the
one
you're
talking
about
is
about
additive
Dimensions
rate,
so
I
think
that's
to
determine
which
one
to
between,
when
choosing
between
observable
gauge
versus
observable
counter,
you
kind
of
look
at
like
are
the
metric
values
yeah
that.
D
F
D
The
guidance
here
speaking
to
Mike
is
a
gauge
versus
an
up
down
counter
less
so
about
you
know,
observable
versus
not
observable.
D
Both
a
gauge
and
an
up
down
counter
are
values,
of
course,
that
basically
can
go
up
and
down.
You
can
take
negative
measurements,
but
yeah
here,
yeah
yeah
non.
D
So
like
things
like,
temperature
that
aren't
meaningful,
like
semantically
to
be
added
together,
should
be
measured
with
a
gauge,
but
like
memory,
consumption
which
you
know
can
go
up
and
down
so
like
memory
utilization
of
a
process,
it
is
Meaningful
over
time
to
be
able
to
sum
that
together,
because
if
you
sum
it
together,
you
know
you
can.
You
can
effectively
drive
like
a
rate
of
of
memory,
consumption
or
utilization
over
time.
D
So
that's
why
memory
utilization
is
usually
measured
with
an
up
down
counter
rather
than
a
gauge
foreign.
B
So
it's
between
gauge
versus
some
kind
of
counter,
but
both
within
asynchronous
both
within
Observer
and
then
so.
If
the
values
are
additive,
then
you
have
to
choose
what
kind
of
counter
you
want
and
then
monotonically
increasing
or
then
you
have
to
go
between
other
values,
monotonically
increasing
or
monotonic,
not
monotonically,
increasing
and
I.
Think
our
drop
count
will
is
monotonically
increasing.
We
are
not
gonna
reduce
that
value.
C
We
are
once
this
emerges
and
we
can
discuss
on
that
one
how
to
if
we
have
to
make
any
changes
on
that
so
I'll
take
in
the
suggestions
of
creating
the
single
observable
counter
for
one
for
log
and
one
for
trees,
or
probably
just
a
single
one,
with
the
dimension
as
a
type,
and
we
could
do
that
as
well
and
I'll
follow
up
on
a
different.
A
B
Has
another
comment
by
Riley
about
the
life
cycle,
management
story
and
I?
Think
Blanche
would
remember.
We
had
something
similar
for
instrumentation
process
where
we
had
like
a
static
meter,
and
we,
if
you
have
two
instances
of
the
SDK,
then
disposing
the
meter
would
essentially
lead
to
the
other,
instant,
the
if
you
have
one
instance
getting
disposed,
but
the
other
SDK
instance
is
still
active,
then
the
other,
the
active,
SDK
instances
instruments
would
not
work
if
you
just
dispose
the
shared
meter.
So
yeah
like
we
need
to
know
like
what
you
wanna.
C
F
F
So
when
you,
when
you
create
that
counter
you're
doing
it
on
the
meter
right,
you're
saying,
like
meter,
dot,
create
observable
so
you're,
basically
giving
that
meter
a
delegate,
that's
tied
to
some
closure
that
includes
the
instance
of
that
batch
processor,
so
that
meter
itself
has
like
a
dictionary
or
a
list
of
all
those
callbacks.
It
needs
to
invoke
anytime.
It
needs
to
collect
that
counter.
F
So
if
somebody
discloses
their
provider,
it
will
dispose.
You
know
the
processors
and
the
batch
and
exporter
and
everything
normally
the
garbage
collector
would
come
around
and
reclaim
all
that
memory.
But
because
of
this
observable
delegate,
closure
thing
being
maintained
by
our
static
meter,
it's
going
to
prevent
the
garbage
collector
from
cleaning
any
of
that
up
may
or
may
not
be
an
issue.
B
B
Or
you
could
like
create
an
extension
method
for
this
I.
Don't
know:
what's
the
like,
what
have
you
thought
about
like
how
the
user
would
use
it,
like,
maybe
add,
SDK,
internal
troubleshooting
or
something,
and
that
that
method
can
just
know
that
that
can
correctly
pick
up
the
meter
for
that
SDK
instance
and
added
again.
D
E
A
D
Lifetime
management
problem
goes
away
too,
in
that
you
know,
as
as
say,
A
bash
processor
where
it
was
disposed
it
didn't
it
didn't,
create
any.
B
B
C
Yeah
I
had
another
PR,
which
I
kind
of
close,
but
there
is
an
open
question
and
plan
had
a
comment
on
that
where
I
was
trying
to
dispose
the
meter
and
like
on
the
process
exit,
though
so
I
think
yeah,
so
Bland
suggested
that
the
meter,
which
is
not
disposed
should
be.
Okay.
However,
like
this
still
I
believe
yeah,
we
attacked
Noah
on
that
to
see
if
he
has
any
inputs
on
that
so
yeah.
C
So
if
no
one
comes
back
and
says
that
we
have
to
do
that,
then
probably
can
go
with
this
approach.
I
guess
where
I'm
great.
So
this
is
not
a
static
class,
but
it's
like
a
an
instance
with
the
single
instance
with
a
Singleton.
F
D
I
mean
if
it
had
to
be
an
observable
and
I'm
I.
Think
I'm
with
you
like
I'm,
not
quite
understanding
why
it
needs
to
be
observable.
But
if
it
had
to
be
observable
for
some
reason,
you
could
probably
still
like
design
it
in
such
a
way
that
the
the
instance
is
not
coupled
to
the
to
the
delegate
like
if
the
if
the
observable
was
created
elsewhere
and
then
somehow
batch
processors
exposed
some
count
for
a
dropped
count
for
it
to
be
observed
on
a
period.
B
B
I,
don't
understand
like
why
would
going
from
observable
to
a
regular
instrument
fix
this
problem,
because
I
think
the
problem
is
with
the
like
two
instances
or
like
yeah,
two
SDK
instances
sharing
the
meter
and
we
are
not
disposing
the
meter
right
now,
so
that
should
be
fine
but
like
just
to
type
it
out.
There's
sdk1.
B
Problem
I
see
is
like
sdk1
has
some
instrument
like
whatever
observable
counter
or
something
and
sdk2
has
another
instrument,
and
they
are
both
created
from
the
same
meter
same
instances.
So
now,
if
you
dispose
sdk1
instance
as
long
as
we
don't
dispose
the
shared
meter
when
we
are
disposing
this
SDK,
these
instruments
will
continue
to
work,
regardless
of
whether
they
are
observable
or
not.
B
But
if
you
dispose
sdk1
instance
just
because
you
are
done
with
it
and
along
with
it,
if
you
dispose
the
shared
meter,
these
instruments
are
going
to
stop
working
so.
B
F
B
D
So
when
you
say
when
you
say
like
so,
you
have
an
instrument
for
for
counting
dropped
count.
You
know,
you
would
say
like
record
drop
count
and
you
would
pass
in
like
I,
don't
know
some
some
batch
exporter,
like
identifier
as
so
that'll,
get
added
as
an
attribute
and
the
dropped
count,
and
you,
the
the
two,
the
two
sdks
would
just
record,
maybe
different
dimensions
and
you'd
be
able
to
facet
that
sing
stuff
generated
by
that
single
instrument
any
any
way
you
want
to.
C
So
yeah
I
think
I.
Guess
it's
a
very
simple
start.
We
could
just
add
the
instrument
on
the
SDK
itself,
the
way
I'm,
adding
the
meeting
and
just
use
those
instruments
in
the
export
processor.
C
If,
if
that
works
and
yeah,
the
observable
one
is
something
will
have
to
get
rid
of
in
that
case,
because
those
will
be
initialized
independent
of
the
batch
export
processor.
F
What
you
would
have
to
do
is
when
you
create
that
observable,
give
it
some
method
that
then
calls
like
a
delegate
that
each
batch
exporter
could
register
itself
with
and
then
unregister
itself
when
it
disposes.
That
would
kind
of
fix
the
life
cycle
problem,
but
it
could
also
just
be
non-observable
either
way
would
be
fine,
but
we
can
make
that
work.
I
can
kind
of
give
you
some
code.
If
you
want.
C
Yeah
yeah
sure
yep.
Let
me
try
it
out
and
I'll
chat
with
you
once
I
have
something
looking
or
some
some
code
they
can
know
sounds
good.
C
F
D
From
the
like,
like
from
the
user
perspective,
that's
like
a
common
thing.
I
get
asked
too
so
I
I
feel
like
that
would
be
useful
for
a
lot
of
people.
D
That
is
part
of
the
spec.
You
should
be
able
to
unregister
delegates.
A
D
Where,
where
does
the
show
the
code
where
the
the
actual
drop
count
is
computed
on
on
export.
D
D
A
A
C
C
F
B
B
B
Yeah
I
mean
a
good
good
point.
I
think
we
can
consider
that
one
as
well
anyway,
you're
gonna
send
something
out
so
I'll
just
take
a
look.
There.
C
Yeah
yeah
I'll,
just
like
I,
think
I
I
need
multiple
PSA
I.
Think
I
started
it
with
just
as
an
example
to
show
like
how
it
will
work,
but
it
just
turned
out
to
be
a
little
bit
more
involved
than
just
simply
adding
in
any
example,
so
probably
need
to
break
it
down.
Yeah.
B
Cool
any
others,
topics.
B
A
B
He
was
an
approver
for
like
quite
a
few
months
now.
Just
today
morning
we
must
appear
yeah,
that's
that's!
It.