►
From YouTube: 2020-10-14 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
Okay,
I
think
we
can
start
folks
on
the
call.
Please
try
to
write
your
name
to
the
list
of
attendees.
Once
again,
we
don't
have
a
lot
of
agenda
this
week.
We
will
be
just
going
over
like
one
item
which
timothy
has
put
here.
A
I
think
we
can
start
with
that,
and
then
I
can
give
a
quick
update
on
the
release
plan
for
point.
Eight.
B
Sure
can
you
hear
me
yeah,
okay,
cool
yeah,
so
I'm
from
working
on
the
azure
motor
monitor
exporter
and
we
have
our
first
beta
ready.
We
wanted
to
publish
it.
Last
week
we
were
blocked
because
I
guess
the
open
telemetry
community
has
that
namespace
reserved,
so
the
the
name
of
the
exporter
would
be
opentelemetry.org.
B
C
Yeah,
actually
new
relic
wasn't
given
access;
they
published
it
before
it
was
like
policy
was
changed,
the
namespace
was
acquired.
I
think
I
think
somebody
from
new
relic
on
the
call.
I
think
the
agreement
was
that
this
expertise
will
be
moved
away
to
the
new
relic
name
space
and
we've
been
hoping
to
have
vendors
to
have
vendor
specific
prefix
into
for
the
for
the
experts.
B
Okay,
is
there
a
recommended
name
for
the
package,
then
that
we
should
follow.
C
Yeah,
I
think
we
discussed
it
once
on
a
guitar.
I
can
try
to
dig
into
guitar
and
bring
it
up,
but
basically
yeah
as
a
reminder
that
x
opens
the
limit
dot.
Exporter
may
be
a
good
name,
so.
A
A
D
I
can
speak
a
little
bit
that
I'm
alan
west,
I'm
from
new
relic
yeah.
I
raised
that
conversation
and
get
her
a
number
of
months
back
and
we
can
absolutely
change
this
package.
Sorry,
it
actually
kind
of
slipped
my
mind,
but
I
do
agree
that
I
think
the
relic.open
relic.opentelemetry.exporter
is
a
sensible
name.
D
The
like
sergey
said
it's
not
so
much
that
we
had
access.
It
was
just
that
the
the
registration
process
for
getting
a
prefix
assigned
to
your
organization
through
nougat
is
something
you
have
to
go
through
and
I
don't
think
that
the
hotel
community
had
done
that.
Yet
so
that's
that's
how
we
ended
up
with
that
name,
but
we
can.
We
can
change
that
prior
to
our
ga.
A
B
That
makes
perfect
sense.
Is
there,
should
there
be
any
like
guidance
published
on
the
repo
somewhere?
So
I
imagine
that
every
third
party
vendor
may
run
into
this
exact
scenario
at
some
time.
Thinking
they're
like
conforming
to.
A
We
can
write
a
note
here
like
for
folks
who
are
extending
the
sdk
to
shoot
their
own
vendor
specific
thing.
Please
take
a
note
of
like
not
naming
it
with
this
way
so
that
you
won't
hit
this
issue
so
yeah.
Let
me
put
some
note
yeah.
Thank
you.
C
Very
much
one
important
thing
here
is:
if,
if
the
exporter
in
country
prepository,
then
it
will
have
a
name
open,
telemetry
dot
com
trip,
we've
been
discussing,
whether
we
want
to
leave
with
an
open,
telemetry
namespace,
or
we
want
to
do
like
open
cmt
country
with
one
name,
but
we
like,
I
think
the
decision
was
to
keep
it
in
opencemetery.com
trip
and
clearly
articulate
the
support
and
supportability
of
that.
So
again,
supportability
was
another
reason
to
put
it
into
vendor
specific
prefix.
A
Yeah-
and
I
mean
I
lost
track
of
this
thing,
so
we
haven't
ever
published
anything
from
this
report
to
new
gate
ever.
A
Okay,
so
it
is
it
using
the
contrib
name
space
or
is
it
using
like
just
open
elementary.
A
A
Okay,
I
don't
hear
questions
so
yeah,
so
quick
update.
We
will
be
doing
a
release,
probably
tomorrow
or
like
day
after
tomorrow,
which
we
already
have
the
dotnet
rc2
available
in
youtube,
and
we
just
updated
thanks,
ready,
so
I'll
be
reviewing
like.
Overall,
we
had
like
a
lot
of
changes
in
logging.
A
A
A
So
I
I
will
update
it
as
soon
as
I
know
more,
but
in
general
like
this
is
still
the
plan
like
we'll
have
a
another
beta
like
towards
the
end
of
the
month
and
we'll
probably
have
one
or
two
like
non
non.
Ga
versions
and
the
actual
ga
would
be
sometime
after
number
10,
I
put
number
30
to
be
on
the
safe
side,
but
we
should
be
able
to
release
any
time
after
number
10,
because
that's
the
heart
dependency.
A
We
have
that
20
days
buffer
is
to
make
sure
we
have
enough
time
to
like
make
sure
we
are
still
complying
with
respect
and
do
other
things.
So
this
is
still
the
plan
and
the
matrix
part
will
be
marked
as
non-ga
or
beta,
like
some
terminology,
which
will
borrow
from
overall
open
elementary,
but
we'll
still
have
tracing
and
logs.
A
So
if
there
are
no
questions,
I
can
give
q
update
on
like
where
we
are
with
the
logs.
So
I
mentioned
like
two
weeks
back
that
we
are
trying
to
deliver
a
logging
solution
and
it
should
be
already
there
like
so
yeah,
so
please
take
it
like
we
haven't
had
like
a
lot
of
like
actual
exporters
like
compared
to
traces.
We
don't
really
have
an
exporter
which
is
actually
useful
because
the
logs
are
currently
exported
only
to
in
memory.
A
So
in
the
next
week
we
will
be
actually
having
exporter
to
use,
otlv
and
eventually
the
jaeger
and
zipkin,
and
I'm
still
thinking
whether
we
should
have
an
elastic
search
exporter
but
we'll
at
least
do
otp
and
from
what
you'll
be
we
can
like,
send
it
to
jaeger
or
any
other
place
so
that
that
should
be
it
and
we
don't
really
need
any
new
ap.
A
It's
just
cylinder
api,
so
we
and
as
long
as
we
have
the
way
to
stamp
the
tracing
and
span
id
into
the
logs,
we
should
be
good
to
call
ourselves
ga.
But
please
take
a
look
and
see
if
there
is
any
thing
from
the
login
which
you
are
interested
in
and
we
are
not
covering
yeah.
It
looks
mostly
ready
and
it's
mirroring
whatever
we
have
for
our
tracers
it
like
the
same
way.
You
add
a
processor
or
exporter
or
assembler.
You
would
do
it
for
logs
as
well.
A
The
sampler
I
mean
few
things
are
still
not
ready,
but
overall
the
project
is
like
ready
to
use,
except
that
there
is
no
exporter
other
than
in-memory,
so
yeah
feel
free
to
sit.
Give
some
feedback.
I
am
mostly
working
on
logging
for
last
few
weeks
and
I
think
we,
when
I
close
the
task
done
when
we
have
a
otp
exporter,
we
may
or
may
not
end
up
having
a
direct,
a
guarantee
exporter
which,
if
there
is
enough
time
we'll
do
it
otherwise
we'll
just
keep
it.
A
It
doesn't
prevent
us
from
getting
anywhere
because
I
believe
most
vendors
would
be
writing
their
own
log
exporter,
so
we
should
still
be
covered
from
there.
So
any
questions
on
logging
in
general.
A
Okay,
that's
good.
I
assume
everyone
is
familiar
with
this
approach
or
not
interested,
because
many
folks
were
asking
they
are
not
interested
in
logs.
They
want
to
see
metrics
earlier,
but
unfortunately,
it's
going
to
be
the
other
way
around
logs
are
going
to
come
first,
primarily
because
we
don't
have
to
like
invent
a
new
api.
We
just
use
the
I
logger
for
matrix,
it's
still
waiting
for
like
the
specs
to
ga,
which
which
would
be
sometime
end
of
this
one.
A
That's
what
I
hear
even
in
the
overall
open
thing,
so
they
can
give
some
idea
if,
like
I
am
wrong,
so
the
overall
plan
open
elementary
spec
repo
is
also
to
how
trace
ga
first
and
matrix
later,
and
there
is
no
firm
deadline
for
when
the
matrix
is
going
to
be
ga.
Is
this
correct.
C
Yeah,
as
far
as
I
know,
there
is
no
firm
deadline.
We
we
actually
want
to
put
a
lot
of
effort
into
g
in
trace,
and
this
is
quite
important
now
for
for
the
logs.
I
have
a
question.
Actually,
how
do
you
is
there?
A
correlation
with
the
resource
api
at
all.
A
Just
like
you
get
an
activity,
that's
pretty
much
it
like
everything
else,
including
supporting
of
scopes,
because
logs
support,
my
logo
supports
something
called
scopes,
and
that
is
not
supported
and
like
everything
else,
like
sampling
and
resource
pro,
I
think
configuration
is
also
done
so
yeah.
We
need
to
find
a
way
to
associate
it
with
the
resource.
The
the
way
we
currently
associate
span
slash
activity
to
a
resource
is
also
being
reworked
because
it
currently
stores
the
resource
inside
every
activity,
which
is
probably
not
the
right
thing
to
do
from
a
perfect
standpoint.
A
So
yeah
we'll
be
revisiting
that
in
this
week
or
next
week,.
C
Cool
yeah,
the
reason
I'm
asking
is
I
I
just
did
the
talk
this
morning
about
open
telemetry
in
kubernetes
and
preparing
to
this
talk.
I've
been
thinking,
how.net
will
be
collecting
all
the
metadata
about
kubernetes
and
what
we
have
today
and
what
we'll
have
in
future.
C
A
Yeah,
that's
a
good
point
like
I
think,
like
we
already
have
a
way
to
use
resources,
it's
just
that
it's
not
performant
and
we
should
be
able
to
like
borrow
the
same
concept
and
put
it
into
logging
as
well
yeah.
Thank
you.
Yeah
I'll
have
more
answers
because
I
think
there
is
an
open
issue
about
resource
being
stored
in
a
custom
property
in
activity.
So
it's
like
every
activity
we
create
have
the
resource
stored,
which
is
not
really
required,
but
yeah.
A
That's
a
separate
issue
which
we'll
be
addressing
so
yeah
yeah
logs
are
overall,
like
even
in
like
dot
net
side.
A
We
are
working
with
them
to
make
sure
the
overall
eye
logger
documents
which,
like
some
people
who,
if
you,
if
you
are
ever
if
you
have
ever
read
the
I
logger
dogs,
it's
not
that
easy
to
read,
because
it's
like
very
lengthy
and
not
very
clear
on
how
to
do
it
outside
of
facebook.com,
but
we
have
been
working
with
the
dotnet
team
to
make
sure
this
talk
like
this
is
a
overall
logging
dock
which
talks
about.
A
I
logger
slash
microsoft,
extensions
login,
so
this
will
be
like
drop
down
into
or
broken
down
into
smaller
sections,
and
hopefully
that
should
be
ready
before
we
go
here,
so
we
don't
really
have
to
write
any
documentation
on
how
to
do
looking.
All
we
need
is
just
one
line
which
says,
add
open
elementary
exporter
and
whatever
is
the
name
of
the
exporter,
but
that
would
happen
like
parallelly
from
our
referred,
but
overall
like
once
these
two
are
done.
A
We
should
have
a
good
tracing
and
login
story
and
also
the
team
will
be
documenting
the
activity,
source
etc.
Somewhere.
Here
I
don't
know
where
there
is
an
issue
already
opening
the
dot
net
report
to
try
writing
the
documentation
for
that.
So
it
combined
with
the
doc
from
the
official.net
reports
for
tracing
and
logging
and
the
open
elementary
examples.
We
should
be
in
a
good
position
to
like
sell
to
customers
or
for
internal
purpose.
Whatever
yeah,
okay
yeah,
I
don't
really
have
any
other
update
yeah.
A
I
was
not
actively
working
on
anything
in
this
repo.
I
was
mostly
investigating
logging
and
other
things,
but
I
would
be
actively
working
this
week
and
exo
expect
to
close
all
the
open
issues.
We
have
quite
a
number
of
open
issues,
so
I'll
be
getting
to
them
in
the
next
few
days.
A
D
Yeah
sure
by
all
means
yeah,
so
this
is
this.
Is
I
opened
it
up
as
a
draft
pr
to
begin
with,
because
I
have
a
number
of
to
do's
throughout
the
code
that
I
hope
to
have
some
conversation
with
folks
about,
but.
D
Is
that
we're
making
an
initial
push
just
to
get
some
metrics
from?
You
know
some
of
the
main
libraries
or
asp.net
core
http
client,
and
so
on
this
pr
that
I've
just
opened
up
only
addresses
asp.net
core
and
it
captures
a
duration
metric.
So
an
http.server.duration
is
a
metric,
that's
defined
within
the
metric
specification
or
within
the
http
semantic
conventions.
E
D
If
you
look
through
this
pr,
it's
basically
it
follows
a
very
similar
patterns
as
with
traces,
that
is,
it
sets
up
a
diagnostic
source
listener
which
in
turn,
you
know
receives
on
on
start
on.
Stop
events
this
this
basically
only
listens
to
the
on
stop
event
of
the
activity,
that's
created
by
asp.net,
core
and
yeah.
Thank
you
cg.
D
You
got
this
up
on
the
screen,
so
basically,
we
really
pull
a
lot
of
the
same
information
that
we
do
for
traces
and
we
add
those
as
labels
which
ultimately
get
recorded
on
the
metric.
All
of
this
is
based
on
a
older
version
of
the
metric
spec.
You
know
the
thought
being
that
when
the
spec
actually
does
take
some
shape,
and
it's
a
little
more
solid
that
you
know
we're
gonna
have
to
come
in
here
and
we're
gonna
have
to
change.
A
D
Yeah
yeah,
I
believe
so
yeah
really
it's
about
the.
I
think
the
spec,
the
big
big
part
of
the
spec
change
is
that
the
the
metric
instruments
there's
more
than
there
were
before
and
so
it'll
just
be
mapping
those
to
the
new
thing
when
okay.
A
D
D
A
Okay,
so
you're,
basically
using
these
metrics
and
these
labels
are
recommended.
Okay,
perfect,
exactly.
D
Yep
yep
yep
yeah,
most
of
it
in
there
there's
there's
a
couple
of
metric
or
there's
a
couple
of
attributes
in
there
that
I
haven't
worked
out
yet,
but
I'll
be
I'll,
be
working
that
out
before
making
the
draft
pr
a
real.
A
Pr
yeah,
so
one
overall
thinking
is
this
is
something
which
we
were
thinking
like
earlier.
Also,
they
also
shared
some
ideas
like
few
months
back
when
I
try
to
tackle
this
so
essentially,
this
is
a
separate
subscription
to
the
same
diagnostic
source
like
a
separate
from
traces,
so
tracers
are
setting
up
one
listener
and
in
matrix
also
we
are
setting
up.
Another
listener
like
both
are
like
independent
of
each
other.
One
can
exist
without
other
and
cannot
affect
each
other
yeah.
A
A
Okay,
let's
see
yeah,
there
was
a
like
open
question
like
long
back
and
like
sergey
was
suggesting.
We
should
try
to
reuse
the
subscription,
but
then
I
wasn't
sure
like
whether
it
was
a
strong
suggestion
or
just
a
thought,
because
that
probably
has
some
implication
on
the
performance.
A
But
I
think
we
can
do
some
measurements
and
figure
out
whether
we
should
do
the
brand
new
subscription
or
we
should
try
to
like
dig
back
on
to
the
tracing
one
and
somehow
get
a
callback
respectively
of
the
sampling
decision,
so
yeah.
But
this
is
a
good
start.
Yeah
we
can
discuss
those
in
in
the
pr
and
based
on
the
format.
Yeah.
D
I've
put
a
little
bit
of
thought
into
what
it
would
take
to
share
the
same
subscriber.
I
went
this
route
just
because
it
was
a
little
bit
quicker
though
I
can.
I
can
circle
back
and
think
about
what
that
would
take.
It's
just
the
the
trick
is
that
right
now,
the
listeners
that
we
set
up-
you
know,
if
you
say,
set
up
metric
recording,
but
you
don't
set
up
traces.
A
The
same
thing
I
mean
I
did
yeah,
they
did
actually
use
the
same
one
right,
yeah,
yeah
yeah.
I
mean
I
don't
think
as
long
as
our
these
two
requirements
are
matched.
I
don't
think
there
is
any.
I
mean
the
only
thing
which
would
influence
the
decision
would
be.
What
is
best
for
the
performance
I
mean
if
we
have
a
way
to
collect
metrics,
irrespective
of
tracing
is
enabled
or
not
and
respectively
of
assembling
decision,
then
I
believe
we
should
be
good,
except
the
puff
part.
A
A
Yeah
so
so
alan
and
I
was
just
discussing
like
what
is
the
current
approach-
is
to
get
metrics.
We
are
re
subscribing
to
the
diagnostic
source.
This
is
a
fresh
subscription,
independent
of
the
tracing,
so
we
are
wondering,
like
you,
had
any
strong
opinion
for
or
against
this
approach
or
reusing
the
same
instrumentation
for
traces
and
metrics.
A
C
Yeah,
I
remember
there
was
an
issue
with
the
original
diagnostic
source
when
you
have
multiple
subscribers,
so
performance
will
start
degrading.
For
this
reason,
we
I
mean
in
application
insights.
I
remember:
we've
been
having
like
diagnostic
adapters
that
you
subscribe
once
and
then
proxy.
Those
calls
into.
C
Into
listeners
so
kind
of
another
layer
of
subscription
and
the
reason
for
that
was
that
performances
showed
that
just
creating
this
event
and
sending
it
was
overwhelming,
I
see
but
okay.
I
think
it
was
mostly
because
we
needed
to
filter
this
event
multiple
times
so
in
every
subscriber.
C
You
need
to
have
an
if
statement
in
the
beginning,
saying
like
whether
I'm
interested
in
this
event
or
not,
because
if
you
subscribe
to
this
thing
like
if
you
end
all
events
you'll
be
reaching
your
listeners
like
no
matter
who
subscribe
to
that
so
may
not.
It
may
not
be
an
issue
for
this
specific
case
when
the
same
set
of
events
is
interesting
for
us
but
yeah.
It
may
be
a
performance
issue.
A
Okay,
okay
got
it,
so
there
is
nothing
which
dot
net
team
has
done
in
your
like
recollection
that
they
fix
the
underlying
issue
that
if
multiple
people
are
subscribing
to
the
portfolio,
no
okay,
so.
A
Benchmarking
and
see
like
subscribe
once
and
broadcast
it
to
two
listeners
or
like
subscribe
twice
and
then
see
which
one
is
performing
better,
and
then
we
can
pick
the
approach,
but
irrespective
we
can
still
review
this
pr
like
because
this
will
only
change
the
way
we
subscribe
like
everything
else
would
still
be
the
same,
like
all
this
logic
would
still
be
the
same.
It's
except
the
fact
that
we
will
be
either
subscribing
directly
or
we'll
be
sharing
it.
Somehow.
C
Yeah
and
the
again,
the
performance
issue
wasn't
in
subscribing
once
I've
climbed
in
twice.
On
the
same
event,
the
issue
was
that
filtering
of,
if
undesired
events
was
too
expensive,
when
you
have
multiple
subscribers.
A
C
C
A
C
A
So
maybe
we
are
fine,
but
let's
do
the
actual
measurement
and
see
if
we
can
do
some
tweaks.
D
D
I
can
definitely
do
the
benchmarking
to
see
what
impact
this
has
at
the
end
of
the
day
I
mean
if
we
need
to.
If
we
need
to
take
on
the
work
to
merge
this
into
one
subscriber,
I
I
think
it's
totally
doable.
I
think
that
it
would
require.
Maybe
some
rethinking,
because
you
know,
there's,
there's
a
different
provider
builder
for
traces
versus
metric.
E
D
A
Yeah
right
now,
it's
like
completely
independent
right,
because
the
meter
provider,
sdk
and
tracer
provider
are
completely
independent,
so
yeah.
The
only
thing
which
is
connecting
is
the
sdk
dot
cs
class.
That's
the
only
thing
which
is
common
yeah.
Let's
discuss
this
offline
again
or
in
pr
to
see
what
is
the
best
way
to
handle
this,
but
yeah
we'll
do
the
pr
review
respective
this
approach
like
the
subscription
approach,
yeah
sounds.
D
A
E
I
do
have
a
quick,
quick
question.
I'm
just
wondering
like
I
know
alan.
You
were
trying
to
keep
a
relatively
narrow
scope
on
this,
but
I'm
wondering
about
where
other
stuff,
like
kind
of
you
know,
runtime
metrics
and
like
garbage
collection
memory,
utilization
cpu
like
that
sort
of
stuff,
is
going
to
come
in.
A
I
think
that
would
be
that
can
be
covered
very
easily.
Once
we
write
a
generic
even
counter
listener,
we
did
try
it
like
few
months
back
so,
like
all
the
I
mean,
there
are
two
ways
like
one
is
performance
counter
collector
and
second
is
event
counter.
So
starting
with
dotnet
core,
the
recommendation
is
to
use
event
counter
and
dotnet
runtime
publishes,
like
all
the
system
counters,
like
gc
allocations,
cpu
everything
using
even
counter.
A
So
once
we
write
a
like
generic
even
counter,
we
can
just
like
leverage
that
and
build
like
any
like
system
metrics
on
top
of
that,
and
this
is
something
which
we
can
do
independent
of
what
island
was
doing
right
now,
because
the
one
which
allen
is
doing
is
about
like
something
about
http,
which
is
leveraging
the
diagnostic
source
callbacks,
but
for
metrics
we
can
do
purely
based
on
even
counters
because
it
can
be
like
completely
independent,
like
we
should
be
like
if
someone
has
like
some
bandwidth
to
like
explore
that
I
can
help,
because
we
have
some
code
already
working
for
that.
A
It's
just
that
we
need
to
migrate
it
to
open
telemetry.
I
can
share
that,
but
if
not
yeah
I'll
wait
for
a
link
to
finish
this
and
then
come
back
to
even
counters
as
a
whole
and
then
system
metrics
on
top
of
even
even
counters.
D
Yeah
and
then,
of
course,
the
same
thing
is
going
to
apply
there.
I
mean
it
yeah,
it's
a
totally
separate
effort.
I
mean
the
the
old,
the
old
spec
had
the
concept
of
an
observer,
and
so
that's
probably
what
we
used
to
get
the
the
runtime
metrics.
I
think
the
new
spec
has
something
called
here:
they,
they
refer
to
things
called
like
synchronous
instruments
versus
asynchronous
instruments
for
capturing
those
kind
of
like
background.
A
Okay,
I
I
was
actually
referring
to
the
collection
mechanism,
which
is
the
event
counter
thing
like
dotnet
has
something
called
even
counter,
and
starting
with
dotnet
3.0
or
like
a
bunch
of
counters,
are
being
published
using
even
counter
there's
a
list
of
counters
which
are
being
published
somewhere
documented,
based
on
my
understanding
when
I
looked
at
it
like
a
month
and
a
half
back.
The
system
matrix
semantic
conventions
is
something
which
we
can
build
on
top
of
that.net
thing.
A
D
Yeah
and
myself,
and
chris
ventura,
who
is
also
on
the
call,
actually
have
some
experience
with
that
event.
Source
based
stuff.
A
D
Well,
I
was
just
saying
that
you
know
chris
ventura
who's
also
on
the
call
and
myself
I'll
have
some
experience
with
those
event.
Counters.
A
Yeah,
absolutely,
I
think,
let
me
go
ahead
and
create
an
issue
and
tag
it
with
help
wandered
and
linked
to
the
existing
documentation
and
see
if
we
can
get
someone
to
do
that.
Otherwise,
yeah
you
can
come
back
to
it
once
we
are
done
with
the
instrumentation
based
one,
because
this
seems
little
bit
more
challenging
than
encounters.
A
Okay,
that's
it
no
other
questions,
I
I
will
be
updating
this
note,
so
you
can
take
a
look
at
it
afterwards.
If
you
want
okay
yeah,
we
can
end
early
one
more
time,
thinking
that
starting
next
will
be
more
topics
to
discuss.
We
take
the
full
five
or
four
one
hour
all
right
thanks.
Everyone,
bye,
bye.