►
From YouTube: 2020-09-15 .NET SIG
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
A
B
Oh
yeah,
I
guess
we
can
start
it's
three
minutes
past
four.
We
can
look
at
the
agenda.
I
don't
have
any
agenda
we'll
be
doing
an
intermediate
release
of
the
sdk
today.
This
was
originally
planned
for
end
of
this
month,
but
there
is
a
request
to
release
it
earlier
and
the
only
dependency
we
had
was
dotnet
rp1,
which
was
released
yesterday.
So
we
should
be
good
to
release
today.
I
will
be
taking
care
of
that
after
this
meeting.
B
I
didn't
get
a
chance
to
look
at
this.
Can
someone
like,
I
think
it
was
asked
for
aws
for?
Can
you
like
walk
us
through
this.
C
Okay,
so
this
is
the
issue:
we've
talked
about
before
of
being
able
to
generate
ids
in
a
different
format
for
x-ray,
because
the
ids
have
to
be
prefixed
with
the
time
stamp
of
the
trace,
and
so
we
came
up
with
this
approach
from
sergey
suggested.
We
look
at
using
the
sampling,
callback
and
override
the
ids
there,
and
it
mostly
works,
except
for
one
issue
we
had
was
the
only
way
to
override
the
trace
id
was
to
use
the
set
current
id
method.
A
C
E
Yeah,
it
worked
yeah
yeah
just
but
except
for
this
simple
checker.
B
Okay,
so
you
are
using
a
new
generating
a
new
id
in
some
format,
yeah
and
setting
the
parent
id
to
that
one
so
that
when
the
activity
gets
created,
it
will
have
the
same
trace
id
as
whatever
you
created
here
right
and
you're.
Only
doing
it
only
for
root
right,
okay
and
this
queue
is
like.
Is
it
sergey
who
suggested
yeah
surgery
is
here,
so
we
can
also
ask
forgive
whether
this
is
exactly
what
he
intended.
E
Yeah,
I
think
it
is
very
similar
to
what
we've
been
discussing
before
I
think.
Maybe
the
only
problem
here
is
that
there
will
be
parent
span
that
leads
to
nowhere,
because
this
pen
wouldn't
be
reported,
but
I
don't
think
I
don't
know
how
big
of
a
problem
with
this
for
x-ray.
A
E
B
But
sergei,
like
is
there
any
other
concern,
because
I
I
can
see
like
this
requires
a
change
to
do
like
when
we
do
check
whether
the
parent
is
null
or
empty.
We
now
need
to
check
whether
it
is
the
parents.
Panic
is
like
zero,
zero,
zero
one.
B
And
this
being
executed
in
like
hot
path
before
I
mean
for
every
span,
I
think
we
should
be
able
to
figure
out
some
optimizations
to
this.
That
is
my
only
thing
because
this
code
has
to
leave
in
the
like
this
repo,
not
anywhere
else,
so
this
would
affect
like
other
customers.
So
we
can.
I
mean
this
should
be
like
a
implementation.
We
can
properly
figure
it
out,
but
I
don't
see
on
quick
look
any
major
issues
with
this
approach.
B
E
B
Yeah
I
mean
these
things
are
like
purely
w
specific
right
like
how
we
are
generating
the
id
it's.
It
should
be
like.
E
B
Yeah,
so
anything
which
requires
to
be
public
like
specifically
like
anything
related
to
id
generation
or
propagation,
is
okay
to
be
in
the
main
repo,
even
if
they
are
vendor
specific
yeah.
I
think,
okay,
you
don't
need
to
do
it
anywhere
else
yeah.
It
should
be
fine.
B
C
B
Spend
some
time
like
reviewing
this
in
detail,
because
I
mean
from
glance
I
don't
see
anything
wrong,
but
yeah.
I
definitely
take
a
detailed
look.
B
And
I
mean
I
remember,
there
was
one
other
suggestion
which
sage
or
others
made
last
time
about
using
a
trace
date
to
deal
with
the
custom
trace
id
is
that
pursued
and
what
was
the
like
reason
why
this
approach
was
required,
as
opposed
to
using
the
trace
state
option.
C
B
Yeah
that
makes
sense
all
right
yeah,
so
I
mean
from
cube
glance.
It
looks
good
we'll
let
it
be
there
for
at
least
a
day,
so
we'll
have
more
comments
from
others
as
well.
I'll
also
take
a
look
after
the
meeting,
so
okay
yeah
and
you
already
had
created
an
issue
for
that
right.
Oh
yeah,
yeah.
Okay,
we
can
link
it
to
that.
Okay,
okay,
thanks
thanks.
B
Is
there
anything
else
we
want
to
do
today?
Yeah,
there
is
a
new
get
release.
Yes,
I
will
be
doing
that
a
little
later
today
I
mean
I
house
the
scripts
like
pop
some
partial
scripts,
to
generate
the
combined
change
log,
so
I
want
to
like
make
it
like
really
automated,
so
that
next
time
it's
like
really
easy.
I
was
doing
like
some
hand
constructed
changes
last
time,
but
I'll
be
making
sure
that
partial
scripts
are
like
ready
and
I'll
make
it
part
of
the
release
talk,
so
it
should
be.
B
It
should
get
much
more
easier
to
release
next
time
yeah,
so
this
release
would
be
like
very
lightweight.
I
don't
think
we
fixed
anything
major
yeah.
We
took
a
dependency
on
rc
one
of
diagnostic
source.
We
fixed
couple
of
bugs
we
fixed
a
sampling
bug
as
well,
but
that
I
said
there
is
no
major
change.
E
B
B
No,
it
should
not
have
been
like
we
made
sure
like
we
waited
till
the
package
which
fear
referees
in
nougat
and
after
that
we
removed
this
from
even
our
build
system.
So
we
know
for
sure
that
we
are
not
depending
on
anything
outside
of
nucleate,
and
then
we
release
so
we're
doing
the
same
today.
Also
so
it
should
not
have
happened.
If
it
has
happened,
then
yeah
we
can
investigate
why.
B
But
it
shouldn't
be,
because
I
personally,
like
do
a
sanity
check
just
to
make
sure
there
is
no
no,
no
no
get
dependencies.
B
Today
is
going
to
happen
like
we'll
be
using
this
version
20451.14,
and
this
is
exactly
the
one
which
is
published
to
nougat,
so
there
shouldn't
be
any
issue
once
we
like,
I
mean
once
we
just
push
this
to
nougat
like
packages
from
this
repo.
It
should
just
depend
on
other
packages
which
are
also
located.
A
D
Yeah,
I
I
think
the
there
are
basically
two
pin
points
that
I
want
to
kill
here.
First,
one
is
that
right
now
we
have
14
even
source
implementations
for
emitting
errors,
basically
for
our
self
diagnostics
or
internal
troubleshooting,
and
then
every
new
package
have
to
create
their
own.
D
But
it's
it's
basically
some
repeated
code
that
sounds
a
burden
for
every
new
package
to
do,
and
then
second,
is
that,
although
we
have
so
many
event
source
for
emitting
these
events,
but
it's
not
easy
to
to
track
all
those
events
they
have
to
either
use
some
third-party
tool
or
basic
to
to
get
those
events.
D
So
I'm
proposing
that
the
second
feature
is
to
have
a
have
a
module
that
can
log
all
those
messages
to
the
disk
when
and
you
can
enable
this
very
easily
by
adding
a
configuration
file
and
then
when,
when
they're
not
when
it's
not
enabled
it
does
nothing.
So
it's
it's,
it
can
be
always
there
and
then
easily
enabled.
Whenever
there
is
a
problem
say
say:
the
user
has
a
server,
that's
running,
but
they
see
a
problem
and
they
don't
want
to
restart
the
server.
B
Yeah,
okay,
so
this
is
like
self-diagnostic,
so
the
alternate
option.
Currently,
what
we
have
is
to
use
tools
like
perfume
and
start
perfume
and
get
the
traces
using
perfume,
but
this
is
basically
self-contained
without
installing
anything
else.
You
just
add
a
config
file
and
we
start
listening
to
all
the
even
sources
from
open,
telemetry
itself
and
put
that
into
a
file
right.
Yes,
okay,
yeah
yeah,
I
mean
I
have
some
comments,
but
it's
like
minor.
Okay,
I'm
very
curious.
How
do
you
load
this
like
without
restarting
process
etc?
B
But
I
think
we
can
discuss
that
offline
later,
but
in
general
like?
Are
there
any
questions
or
concerns.
D
I
have
one
concern
is
that,
since
this
is
only
for
internal
use,
we
want
to
keep
it
internal,
and
then
I
might
need
to
create
some
public
apis
for
everyone
in
the
open,
telemetry,
community
or
contributors
to
call,
but
it's
not
necessary
for
any
urban
telemetry
users
to
call
so
and
also
if
we
really
need
to
expose
those
apis.
D
B
Think
the
hardware
whether
we
want
to
expose
this
as
a
public
api
or
like
public,
only
for
like
other
packages
from
this
repo
that
let's
solve
that
like
second,
but
I
think
we
can
independent
independent
of
that
logging
api.
We
should
still
be
able
to
solve
the
self
diagnostic
module
right
like
we
already
have
14
even
sources
we
like
enabled
self
diagnostic,
then
it
should
immediately
start
capturing
logs
from
all
the
existing
open,
telemetry,
dot,
star
event,
sources
and
store
that
into
a
file.
B
So
we
should
be
able
to
do
this
without
like
digging
too
deep
into
how
the
api
should
look
like
right.
B
Yeah
this
sounds
good,
like
in
azure,
monitor
slash
application
sites.
We
had
something
similar
to
this.
There
was
a
self
diagnostic
module
which
listened
to
sdk's
on
stuff,
and
this
sounds
very
similar
yeah
and
it.
This
should
be
like
much
more
performant
by
using
this
one
yeah
are
there
anything
which,
like
anyone
else,
want
to
comment
down
this
feature?
I
think
you
have
a
basic
structure
open
in
apr,
right,
yeah,
this
one
yeah.
If
there
are
any
concerns,
please
do
raise
it
either
in
this
pr
or
right
now.
E
So
much
my
only
concern
with
any
new
login
kpi
is.
I
want
to
make
sure
that
something
that
will
be
maintained
and
supported
long
term.
I
know
that
events
are
working,
so
I
I
can
rely
on
existing
so
event
source
and
that
if
there
is
an
issue
it
will
be
solved.
If
there
is
a
new
login
kpi
like
it's
either
needs
to
live
here,
so
we
can
fix
issues
if
needed,
or
it
should
be.
E
I
mean
somehow
like
promised
to
be
maintained.
Otherwise
it's
it
may
be
a
little
bit
complicated.
B
The
api
can
still
remain
whatever
we
currently
have
like
every
project
will
create
their
own
even
source
and
the
self-diagnostic
module
can
still
subscribe
to
all
of
them.
I
love
that
you
have
a.
B
Yeah,
so
this
let's
get
like
shown,
you
can
get
started
on
this
part
where
you
provide
respect,
show
some
actual
use
case
of
this,
like
when
things
go
wrong.
You
just
go
and
turn
this
on,
and
you
may
at
least
see
logs
in
the
disk,
and
if
it's
not
turned
on,
there
is
no
performance
and
then
at
the
end
after
that
is
like
this
feature
is
like
ready
and
then
we
can
consolidate
all
the
14
or
15
even
sources
into
a
single
one.
So
at
that
time
it
would
become
a
apa.
B
We
need
to
figure
out
how
to
expose
it
only
for
internal
usage,
but
not
for
public,
but
let's
address
it
separately
after
the
the
self
diagnostic
part
of
this
is
complete.
B
I'm
very
interested
in
knowing
like
how
do
we
subscribe
it
on
the
fly
without
restarting
the
process,
because
usually
even
sources
are
like
created
when
the
process
starts.
So
if
you,
if
you
miss
the
opportunity
to
subscribe
to
something,
you
don't
usually
have
an
opportunity
to
do
that.
B
D
In
in
a
word
I,
it
will
be
basically
doing
no
up
when
there
is
no
configuration
file.
I
see
yeah.
B
Anyway,
let's
discuss
that
beneath
the
pr,
because
this
is
something
which
I've
been.
I
tried
little
earlier
for
some
other
reason
for
even
source.
My
understanding
was
that
you
get
the
callback
when
and
even
source
is
created,
and
it
is
always
created
at
the
application
startup.
If
you
miss
that
opportunity
to
subscribe
to
it,
you
may
see
you
don't
get
it
later.
This
is
like
completely
different
from
the
diagnostic
source
api,
where
you
don't
really
have
to
be
there
at
that
startup,
you
can
go
ahead
and
call
the
api
like
diagnostic
source
dot.
B
B
B
Okay,
then,
it
should
be
fine,
because
I
saw
that
you
mentioned.
We
want
to
enable
it
without
restarting
the
process
yeah.
That
would
be
awesome
like
if
something
goes
wrong,
just
change
a
file
and
that's
it
without
restarting
you
start
seeing
the
logs
for
you
yeah
okay,
so
yeah
go
ahead
and
do
the
second
part
yeah
I'll
keep
reviewing
the
like
smaller
sections.
B
Okay,
yeah.
Okay,
let
me
go
back
to
this.
If
we
don't
have
anything
in
the
agenda,
I
want
to
raise
everyone's
attention
to
look
at
one
thing
which,
like
alan,
has
opened
few
minutes
earlier,
like
we
were
discussing
about
this
so
alan,
do
you
want
to
just
walk
everyone
through
like
what
is
the
proposal
here.
F
Yeah
sure
so
yeah
the
thought
is
that
we'll
get
some
basic
metric
collection
going
on
specifically
for
web
frameworks,
asp.net
asp.net,
core
and
http
client
grpc,
and
while
the
metric
sdk
is
still
a
thing,
that's
in
flux,
at
least
this
will
establish
some
of
the
you
know.
Initial
patterns
for
us
to
collect
metrics
from
instrumentation.
F
I've
noted
a
couple
of
the
high
level
requirements
that
cjo-
and
I
talked
about
you
know,
namely
that
metrics
and
tracing
shouldn't
necessarily
be
dependent
upon
one
another.
That
is,
users
should
be
able
to
enable
metrics,
but
not
necessarily
have
to
enable
tracing
in
order
to
get
metrics
out
of
their
application.
F
And
likewise
you
know
if
tracing
is
enabled,
then
sampling
shouldn't
have
any
effect
because,
of
course,
metrics
aren't
supposed
to
be
sampled,
they're,
aggregated
numbers,
and
that's
that's
about
it
and,
and
I
think
in
the
in
the
longer
term,
it
will
be
cool
to
see
how
the
metric
sdk
evolves
so
that
you
know
exporters
can
start
consuming
these
metrics.
But
it
actually
sounds
like
there's
some
there's.
Some
people,
sergey
is
sergey.
F
You
you
mentioned
in
one
of
the
more
recent
sig
meetings
that
it
sounded
like
you
had
a
use
case
where
you
were
consuming
metrics,
where
you
found
that
bug.
F
E
Internal
applications,
that's
where
we
found
a
bug
and
mostly
because,
like
on
installation
of
this
bucket,
so
like
race
condition
so
yeah.
Hopefully
this
is
fixed
now.
B
Yeah
so
like,
when
we
do
this
thing
like
we'll,
be
building
it
on
top
of
the
existing
metric
apa.
Whatever
we
have,
I
mean
it
could
be
changing
in
the
future
because,
like
the
semantic
convention
says
to
use
value
recorder
for
like
this
matrix,
but
we
don't
have
that
yet,
but
we
can
just
use
whatever
we
currently
have,
and
it
should
be
possible
to
export
to
electrometers
and
it
has
some
other
bugs,
but
overall
it
should.
B
It
should
still
work,
and
once
we
replace
this
api
with
the
most
accurate
one,
as
per
the
spec
when
it
arrives,
we
shouldn't
have
to
change
any
like
top-level
things.
All
we
need
is
just
replace
the
underlying
apa
and
it
should
just
continue
to
work
so
we're
just
getting
a
head
start
on
matrix
collection
without
waiting
for
the
underlying
api
to
be
like
super,
steady,
yeah
and
yeah,
and
once
this
is
done,
we
can
probably
start.
B
I
mean
it
should
be
fairly
straightforward
once
you
figure
out
it
for
one
instrumentation
like
everything
else,
should
be
very
similar,
just
like
tracing
it's
just
one
and
everything
else
is
mostly
mirroring
the
other,
and
once
this
is
done,
we
can
consider
like
getting
even
counter
based
collections,
so
we
can
get
hold
of
the
existing
metrics
like
cpu,
gc,
stats,
memory,
usage
and
all
other
things
which
are
published
by
dot
net
into
even
counter.
B
So
that
would
be
like
a
potential
next
step
where
we
can
build
things
on
top
of
matrix,
apa,
fully
understanding
that
api
might
change
in
the
future
if
there
are
others
who
are
interested
in
this,
please
do
comment
here
like
if
there
is
any
other
requirement
which
we
have
missed,
or
there
are
like
specific
concerns
which,
with
this
approach,
then
we
would
like
to
know
as
soon
as
possible.
I
think
allen
is
trying
to
do
this
like
right
away,
yeah,
yeah,
okay,
yeah.
I
do
not
have
any
other
topics
to
discuss.
B
I
mean
I
am
still
working
on
some.
I
think
I
mentioned
this
a
couple
of
weeks
back
I'm
trying
to
get
logging
apa
into
open
telemetry
so
that,
like
we,
can
have
there's
a
basic
dock
which
is
already
part
of
the
repo
about
how
to
use
the
ilogger.net
cylinder
ap
and
have
it
correlated
with
stress
id
span
id
but
I'll
be
actually
working
on
getting
in
real,
open
telemetry
provider.
For
I
logger
in
the
next
couple
of
fees,
so
mostly
my
energy
will
be
spent
there.
B
So
you
don't
see
me
doing
anything
else.
Apart
from
that,
so
the
milestones
which
is
supposed
to
come
end
of
the
month,
he's
very
light
on
features.
I
haven't
added
it
from
turn
off
feature,
so
it
still
contains
like
very
small
number
of
items,
but
if
there
are
anything
which
requires
like
urgent
attention,
please
let
us
know
in
the
channel
and
we
can
take
a
look
and
prioritize
accordingly.
B
B
Okay,
yeah,
I
don't
see
any
questions
yeah.
I
think
we
can
like
end
early
so
we'll
like
continue
the
discussion
on
two
topics
next
week
as
well.
The
matrix
part
and
the
self
diagnostic
I'll
also
have
something
for
logging,
at
least
for
a
draft
version
in
the
next
week
as
well.
So
all
right
thanks.
F
G
Yeah
hi
everyone,
I'm
I
just
joined,
as
is
my
first
time
attending
one
of
these
meetings.
I'm
a
software
engineer
at
new
relic.
G
I
work
on
the
serverless
and
cloud
services
team
we're
actually
looking
into
an
azure
integration
that
is
going
to
hopefully,
leverage
open,
telemetry
and
so
so
yeah
alan
recommended
that
I
attend
these
meetings
so
that
I
can
be
more
aware
of
sort
of
the
inner
workings
of
the
net
open,
telemetry
project.
So.
A
B
Thank
you
yeah.
If
you
require
like
any
help
with
functions
like
actual
function,
since
you
said
you're
integrating
it,
it's
all
open
source.
So
you
can
it
yeah
this.
I
can
paste
the
link
here
like
actual
web
job.
Sdk
shows
how
azure
functions.
Monitoring
currently
works.
It's
built
on
top
of
azure
application
insights,
but
since
the
entire
code
is
public,
you
should
be
able
to
see
like
how
it
is
done
and
do
the
similar
thing
for
your
needs
as
well.
B
All
right,
so
we
can
end
early
today
and
see
you
next
week.