►
From YouTube: 2020-08-27 .NET Auto-Instrumetation 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
I
can
name
things
that
we
are
planning
to
work
on
and
we
will
contribute
as
soon
as
they
are
in
the
right
shape
and
some
things
where
I
would
like
others
to
specifically
that
I
would
suggest
for
others
to
consider
contributing
and
see
whether
it
makes
sense
for
them
does
it
work.
A
So
we
are
working
on
target
method
level,
sorry,
target
method,
instrumentation
right
now.
The
person
who
is
working
in
it
is
actually
on
vacation.
So
he's
away
for
about
two
weeks
or
three
seconds
remember
he
has
some
very
early
prototypes
and
I
think
he
would
benefit
from
a
review,
especially
by
by
folks
from
microsoft
and
folks
from
from
new
relic.
Who
already
did
this
kind
of
thing
one?
However,
I
think
the
strategy
is
very
similar
and
in
in
detail
would
be
good
to
get
some
feedback.
A
So
that's
something
we
are.
We
are
already
working
on
it
and
it's
up
to
tony
to
see
how
much
code
level
collaboration
makes
sense
and
how
much
she
would
benefit
from
more.
Like
reviews,
that's
that's
up
to
him.
I
think
when
he's
back
from
vacation,
she
can
join
one
of
these
meetings,
so
you
can
she's
in
europe.
Maybe
we
can
set
up
a
smaller
meeting
with
just
interested
parties.
C
And
then
you
have
an
issue
for
this
you
mentioned,
but
it
will
be
an
official
review
in
it.
I
would
love
to
yeah.
C
I
dealt
a
lot
with
diagnostic
strokes
with
different
viewers
and
support,
and
so
on.
So
I
would
love
to
learn
how
you're
gonna.
A
A
Yeah,
so
for
that
one,
I
think
I
would
leave.
I
can
create
an
issue
for
sure
and
about
all
the
details
about
how
to
handle
this
right
now,
tony
is
not
here,
so
I
don't
want
to
create
extra
work
for
him
for
for
tracking
things
more
than
he
already
has.
I
think
the
next
step
on
that
specific
thing
would
be
understand.
A
Who
of
us
would
like
to
help
him
and
have
a
meeting
with
him
when
he's
returned,
then
the
second
thing
is
probably
what
you
talked
about
is
the
activity
source
so
that
I
actually
will
be
working
on
myself
so
there
I
would
be
happy
to
create
an
issue
and
to
copy
paste
a
or
create
a
lego
share
in
whatever
way
makes
sense
share
a
design
doc
with
all
of
you,
so
that
you
can
provide
provide
feedback.
There
is
actually
already
a
working
prototype,
so.
A
High
level
is,
we
will
remove
all
locks
that
are
in
the
pipeline
and
we
will
make
some
things
faster
and
we'll
follow
the
general
look
and
feel
of
the
sdk,
but
not
exactly
in
the
exact
way.
The
sdk
works,
because
we're
not
targeting
the
customer
to
configure
anything
through
code.
We
just
want
us
to
configure
something
as
we
deploy
things
and
that
front,
I
definitely
would
benefit
from
a
review
of
the
design
dock
and
one
of
the
things
where
I
would
really
like
some
help
from
microsoft.
A
This
is
probably
more
a
question
for
david
and
nora,
but
anybody
would
do
is
we
will
need
to
solve
the
versioning
problem,
so
it
is
quite
likely
that
an
application
already
references
diagnostic
source
develop
and
we
need
to
deploy
diagnostic
source
dll
with
the
tracer,
and
we
need
to
make
sure
that
there
is
no
versioning
conflict,
that
the
application
always
loads.
C
That's
very
correct
concern,
in
fact
we
dealt
with
in
our
network
implementation
and
it
is
like
not
that
straightforward
to
deal
with.
So,
let's
make
sure
we
have
a
perfect
conversation
and
dotnet.net
core
in
this
regard
should
be
considered
separately.
C
C
Is
a
part
of
bcl,
so
it
is
there
also
rules
how
this
year
will
get
auto.
C
It's
not
part
of
bcl,
it
has
to
be
used
for
the
nougat.
That's
the
only
way
how
you
can
get
diagnostic
source,
but
again
a
lot
of
applications
might
be
potentially
be
using
diagnostic
stores,
especially
those
applications
which
use
microsoft,
sdks
like
event
hub
or
sql
or
whatever
right
they
all
of
them
reference
some
diagnostic
source.
So
it's
quite
possible
that
diagnostics
also
going
to
be
already
present
in
the
application.
C
A
So
exactly,
and
that
will
be
a
key
point
and
you
know
whether
I
implement
it
or
you
contribute.
Some
code
is
sort
of
secondary
to
me,
but
where
I
really
want
to
have
a
long
conversation
either
in
the
context
of
this
meeting
or
a
separate
one
with
people
who
are
interested,
I
don't
mind,
but
I
really
would
like
to
get
some
support
from
you
guys
about
the
strategy
for
implementing
that
part
of
of
activity,
source
transition
on.
A
Actual
listening
to
activity
sources
and
grouping
them
and
sending
them
to
an
interface
that
represents
the
downstream
channel,
which
would
be
different
for
every
company.
That
is
a
part
that
I
think
we
have
pretty
much
nailed.
It's
just
a
question
of
going
through
the
motions
we
have
a
working
prototype,
but
we
have
some
other
unrelated
work
related
to
to
customer
escalations
that
we
need
to
balance
with
this.
So
that's.
C
Cool
cool
cool-
well,
it's
good
here,
just
notice
I'll
be
on
vacation
for
the
next
couple
of
weeks.
So
if
there
are
any
questions
about
diagnostic
source
and
I'm
not
available
english
wish
I'll
give
you
his
email
as
well,
he
is
my
player
contrapod
who
helped
me
with
all
of
this.
So
he
knows
all
the
details
as
well,
just
as
a
backup
contact.
A
Away
from
which
time
period
are
you
aware
just.
A
Starting
like
on
my.
C
C
B
Greg,
I
I
have
a
question
about
just
to
be
sure
the
call
target.
Does
it
a
change
that
you
have
discussed
it
so
far?
Does
it
affect
any
way
the
instrumentation
or
is
transparent
for
that.
A
It
is
not
transparent.
We
will
have
to
move
instrumentations
to
the
new
to
the
new
world.
Let
me
get
back
to
you
when
tony
is
back
on.
You
know.
We
need
to
have
a
plan
so
that
we
don't
have
to
move
all
of
them
at
the
same
time
right
so
that
we
can
move
them
one
by
one,
but
it
will
need
to
be
different.
A
It
will
be
a
little
similar
to
how
we
saw
it
in
pretty
much
all
of
the
examples,
both
in
java
and
dot
net,
where
you
have
a
method
that
is
called
before
method
that
is
called
after
the
the
original
method
and
where
we
are
currently
doing
investigations
and
design,
and
some
work
that
is
not
yet
completely
fixed,
is
around
robustness
for
for
for
these
instrumentation.
A
So,
for
example,
when
you
call
when
you
get
parameters,
how
do
you
ensure
that
you
have
all
the
right
types
and
and
whatnot
so
right
now,
tony
is
working
on
some
prototypes
yeah.
B
Yeah,
I
I
I
think
that,
as
as
mikhail
said,
if
also
as
you
said,
for
the
active
source-
perhaps
just
even
if
you
are
waiting
the
person
to
get
back
from
vacation,
perhaps
just
open
the
issue
so
put
kind
of
whatever
little
information
you
have
before
that.
So
people
can
start
discussing
participating
on
the
issue.
A
Sure
I'll
open
an
issue.
I
don't
want
to
micromanage
his
his
approach
to
the
architecture.
So,
let's
in
terms
of
making
us
aware
that
we're
working
on
it,
yes,
but
in
terms
of
the
specifics,
I
would
really
prefer
for
him
to
return
from
his
vacation
and
participate
in
in.
B
You
you
could
open
the
issue
and
just
say
that
when
he
is.
D
B
What
I'm
thinking
another
question
that
I
have
about
the
active
source
is
the
following:
is
there
any
convention,
because,
typically,
when
we
work
with
the
instrumentations
we
make
then
align
with
open
tracing
and
now
also
open
telemetry?
You
know
for
symmetric
tags,
especially
you
know
and
types
of
spends.
B
A
So
this
was
created
relatively
quickly
and
I
would
say
that
things
are
90
percent
consistent
across
integrations.
There
will
be
I
I
wouldn't
be
largely
consistent,
but
I
wouldn't
be
surprised
if
there
are
outliers,
we
have
never
gone
through
a
formal
effort
of
ensuring
that
everything
is
exactly
consistent.
We
actually
planning
to
do
something
like
that
now,
but
it's
working
progress
as
far
as
we
are
concerned.
A
As
far
as
we're
concerned
here,
I
would
say
that
this
is
an
example
for
what,
like
you
said,
initially
like
when
we
come
close
to
shipping,
we
need
to
standardize
it
and
the
open
telemetry
semantic
conventions
are
probably
the
right
ones
to
standardize
on,
but
I
would
first
focus
on
the
actual
functionality
like
the
activity,
source
and
and
target
method,
level
instrumentation
and
just
copy
the
actual
business
logic,
as
is
choose
that
to
that
new
feature
set
and
then
as
a
subsequent
step,
change
the
tag,
names
and
everything
that
needs
to
be
changed
to
actually
standardized
on
semantic
conventions.
A
That
would
allow
us
to
to
move
on
on
the
first
part
quicker.
And
that
being
said,
the
thing
is
that
all
the
vendors
like,
if
you're
using
data,
docker
right
now,
you're,
probably
using
whatever
tag
names
we
use
so.
A
We
in
the
exporters,
we
always
have
a
a
wait
because
you
serialize
this
the
activity
to
whatever
is
your
data
contract?
You
can
map
tags
as
you
please.
So,
whatever
convention
we
choose
for
the
actual
tracer,
your
backhand
convention
may
or
may
not
be
the
same,
and
so
you
will
likely
do
some
mapping
of
tag
names
as
you
serialize
anyway,
unless
you
want
to
redo
your
back
end
to
exactly
follow
open
telemetry,
and
I
I
bet
that
that's
probably
not
going
to
happen
so
yeah.
B
Okay,
so
you
you
mentioned
two
two
things
we
have
discussed,
you
think
about
the
active
source
and
the
call
target
the
call
target.
It
seems
because
of
what
we
talked
about
comes
later.
It
seems
that
we
can
start
perhaps
with
the
active
source
migration,
and
we
have
to
start
to
discuss
about
plugging
the
opentelemetry.net
sdk.
B
You
know
we
have
to
start
that
discussion.
I
I
think
perhaps
I
can
start
that
discussion.
Are
you
open?
I
usually
open
telemetry.net
sdk
forward,
because
basically
we
have.
What
is
used
internally
is
the
api.
That
is
the
agent
from
datadog,
and
I
think
our
goal
is
to
use
the
the
open
telemetry
in
the
end.
You
know.
B
So
the
the
open,
the
limit
becomes
the
tracer
itself,
because
then
we
have
the
exporters
and
everything
that
we
have
from
the
open,
telemetry
sdk.
A
B
This
needs
to
to
happen
at
first,
but
it's
something
that
we
need
to
do
before
we
get
to
availability.
You
know
right.
B
What
I,
what
I
see
is
that
we
want
to
be
able
to
use
the
exporters,
processors
and
whatever
we
have
in
orbit
elementary
sdk,
so
we
should
be
able
to
plug
them
at
first.
What
crossed
my
mind
is
to
try
to
use
the
open,
telemetry,
sdk
the.net.
A
So
something
that
I
really
would
like
to
avoid
is
taking
a
compile
time
dependency
on
anything.
A
I
really
don't
want
to
be
in
a
station
where
we
have
to
solve
a
versioning
problem
of
a
application
already
referencing
the
operation
sdk
and
we're
referencing
another
version,
and
suddenly
there
is
a
version
in
conflict.
A
What
we
can
do,
however,
is
wherever
it
makes
sense
to
do
duck
typing,
essentially
to
create
the
same
the
same.
If
so,
as
an
example
right,
if
we
want
to
have
an
exporter,
we
could
create
an
exporter
interface.
That
is
actually
looks
the
same
as
open
telemetry
sdk,
but
we
wouldn't
be
actually
referencing
the
open,
telemetry
sdk
instead,
instead
of
that,
we
would
create
a
the
same
interface
as
a
part
of
of
the
open,
telemetry
tracer.
C
I
think
we
could
also
reuse
existing
code.
We
don't
have
to
copy
stuff
and
so
on
right.
So
if
we
I
mean
either
send
right
paulo,
correct
me
phantom,
but
your
goal
and
your
scenario
is
to
be
able
to
use
the
dd.net
trace
based
agent,
open
telemetry
agent
to
submit
data
to
a
local,
open,
telemetry
agent
right
so
basically
you'll
need
a
protocol
implementation
and
the
easy
way
how
to
turn
it
on,
so
that
all
the
traces
will
flow
to
the
local
opentlang
agent.
C
If
it
is
a
goal,
then
we
will
actually
need
to
take
the
implementation,
not
only
interface
to
break
the
dependency,
but
for
implementation
itself
greg
we
could
potentially
use
the
shading
or
shadowing
or
ile
park
or
I'll
merge.
Whatever
name
you
use
to
avoid
a
dll
conflict
right.
So
what
yeah?
We
will
just
completely
hide
the
details.
What
kind
of
implementation
we
used
in
order
to
submit
this
data,
and
that
way
we
will
just
use
a
potential
sdk
to
transmit
data,
as
this.
A
Yep
that
works
true,
yeah,
the
the
all
of
these
options
work.
For
me,
the
only
thing
that
I
want
to
avoid
is
having
a
actual
dependency
on
another
library,
so
in
any
any
tools
that
we
can
use
either
we
can
copy
the
code
or
we
can
reference
the
code
from
another
report
at
build
time
or
we
can
do
il
merge
any
any
of
that
works.
Whatever
yeah.
C
Whatever,
and
is
this
a
goal
for
you
to
submit
data
to
local,
open
telemetry
agent,
that's
what
you're
trying
to
achieve.
B
B
So
that's
why
I
was
thinking
that
the
natural
path
is
kind
of
to
have
the
tracer
in
the
in,
in
being
the
thing
that
we
use
to
make
all
of
those.
But
that
said
that
this
is
just
my
initial
idea:
I'm
not
thinking
that
that
is
a
must
in
the
sense
that,
as
long
as
we
have
that
functionality
that
we
can
make
this
work
with
those
exporters
that
are
required
by
open,
telemetry
and
supporting
the
features
from
open
telemetry,
then
that's
fine.
For
me,
you
know
yeah.
C
So
I
think
greg
mentioned
that
his
plan
is
to
leverage
activity
pair
for
exporting
of
the
data.
So
you
mentioned
that
you
are
planning
to
use
activity
and
diagnostic
source
right
library
to
have
a
plugable
model
where
different
exposures
could
be
used
and
open
tlm.
There
could
be
just
one
over
export
to
reach
subscribers
so.
A
Essentially,
so
I
I'm
following
a
slightly
different
implementation
than
the
than
the
sdk
for
set
for
collecting
and
sending
data
based
on
the
on
years
of
experience
that
we
had
running
application
insights
as
well
as
for
on
some
experience
that
we
have
in
in
data
docs.
So
but
it's
it's
very
similar
but
different
than
nuances.
So
we
use
way
less
async
than
the
open
telemetry
sdk.
Instead,
we
will
be
using
a
dedicated
background
thread.
A
We
with
with.
Basically
you
have
to
find,
find
a
good
compromise
between
the
tracer,
impacting
your
response
time
as
little
as
possible,
but
also
not
doing
too
much
throughput
impact.
So
we
will
have
a
dedicated
background
thread
for
sending
things.
Essentially,
when
you
have
a
activity
that
is
completing,
we
will
add
it
to
a
log
free
data
structure
like
a
queue
and
then
at
at
certain
intervals
that
are
on
the
order
of
one
second,
but
that's
something
that
should
be
able
to
con
should
be
configurable.
A
But
I'm
just
saying
one
second,
because
we're
not
even
trying
to
target
something
is
like
millisecond
resolution
so
on
the
order
of
one
second,
we
will
take
this
data
structure
where
we
have
previously
added
all
completed
activities,
and
we
will
a
background
thread
that
is
dedicated
to
that
job.
That
is
not
an
async
threat
to
invocation,
but
a
background
thread
that
has
been
created
explicitly
just
for
that
and
that's
based
on
issues
we
this
is.
A
I
can
talk
a
long
time
why?
But
it's
it's
based
on
experience
during
application
insights
that
otherwise
you
get
into
deadlocks.
B
So,
but
but
just
to
capture
the
the
high
level
spirit,
you
are
saying
that
you
want
a
a
different
model
for
capturing
the
the
activities
and
batching
processing
exporting.
Then
what
we
have
on
the
open,
telemetry
sdk
slightly
different.
A
Yes,
so
there
is
one
background
thread
that
essentially
so
first
see
in
a
synchronous
way
when
an
activity
completes,
and
we
know
that
as
a
completed
activity,
we
put
it
in
a
log-free
data
structure
that
is
like
a
growing
q,
but
we
know
because
it
never
shrinks.
A
We
can
make
it
completely
lock-free,
it's
very
fast,
then,
when
the
period
expired,
which
is
approximately
one
second
give
or
take,
we
can
take
this
data
structure
using
a
single
interlocked
operation
and
you
know
swap
it
against
a
new
one
that
will
be
filled
in
the
future.
Then
we
have
this
data
structure
that
is
not
no
longer
contended
and
we
can
take
this
whole
thing
on
the
background
thread
that
is
dedicated
for
it,
serialize
it
and
send
it
off.
And
then
after
the
sending
has
been
completed,
we
look.
A
Okay,
our
target
is
approximately
once
per
second
out
of
the
second
say:
100
milliseconds
already
passed
for
for
doing
what
I
just
described
so
our
now.
We
have
about
0.9
seconds
to
sleep
on
the
thread,
so
we
send
it
to
sleep
and
then,
when
it
wakes
up,
it
checks
the
times.
Make
sure
that
the
timing
is
correct
and
if
the
time
has
come,
then
it
picks
up
the
data
structure
again
and
repeats
the
whole
thing
and
the
things
to
avoid.
There
is
one
thread:
starvation.
Sorry
set
pull
starvation.
A
So
if
this
was
a
normal
async
operation
and
the
application
just
happened
to
to
create
a
lot
of
async
tasks,
then
we
would
be
competing
with
those
tasks
sending
telemetry.
We
don't
want
to.
We
don't
want
that
to
happen.
A
Another
reason
for
this
approach
is
this
is
an
explicitly
created
thread,
not
a
threadball
thread,
because
it
can
happen
and
has
happened
also
in
the
past-
that
if
you
asked
for
the
threat
from
the
threadpool
very
early
on,
this
thread
might
have
been
used
for
an
async
operation
and
someone
might
have
used
a
synchronization
context
that
requires
that
previous
async
operation
should
be
continued
on
this
thread
on
this
actual
thread,
but
we
just
grabbed
the
thread
forever
for
our
purposes
and
we
never
plan
to
return
it
so
that
operation
gets
into
the
deadlock.
A
B
On
this
approach,
what
you
are
talking
about,
keeping
memory
until
the
point
of
I
don't
know
when
that
happens,
but
you
are
talking
about
keeping
the
activities
and
then
then
I
don't
know
when
the
conversion
happens,
if
it's
before
getting
to
this
thread
or
at
this
thread
that
does
the
conversion
to
whatever
is
the
exposure.
A
So
this
this
thread
yes
webkeeping
activities
as
as
in
memory
when
this,
when
this
time
period
expires.
The
thread
takes
this
data
structure
in
a
log-free
way,
and
then
it
passes
it
to
an
interface
that
we
named
together,
but
for
the
purpose
of
of
today,
let
it
code
exporter,
and
this
interface
has
some
apis
that
are
very
similar
to
what
the
sdk
has
with
maybe
one
addition.
A
I
have
to
dig
and
look
at
my
at
my
docs
and
I'll
I'll
post
it
to
the
to
the
issue,
and
then
this
interface
will
be
provided
by
every
vendor
by
splunk
by
datadock.
A
They'll
have
different
implementations,
and
then
you
will
have
the
choice
between
putting
things
on
the
wire
using
async
operations
or
doing
it
synchronously.
In
respect
to
this
background
thread
that
I
just
described,
my
recommendation
is
to
do
this
synchronously
in
respect
to
the
thread,
because
again
you
don't
you're
already
on
the
background
thread.
You
know
that
for
sure-
and
there
is
no
reason
for
you
to
further
impact
the
application
with
more
async
at
that
point,
you're
already
out
of
the
hot
part
for
the
user
code.
A
So
so
that's
that's.
The
plan,
and
then
there
is
a
nuance
that
is
different
from
from
the
sdk,
as
I
see
it
right
now,
and
that
is
something
that
is
specific
to
the
data
dock
agent,
but
I
think
it
can
be.
A
A
Let's
be
a
second
is
too
much,
so
I
am
looking
for
the
agent
sorry
for
this
interface
implementation
to
give
feedback
to
this
main
loop
to
not
only
fire
after
a
certain
time
period,
but
also
after
we
have
collected
the
some
number
of
activities.
Whichever
is
sooner
so
that's
an
addition
to
to
choose
something.
That
is
the
key
does
so,
but
that's
that's
the
plan.
E
Can
I
enter
jack,
so
I
I
feel
like
we're
getting
into
a
a
lot
of
technical
details
about
different
approaches
for
getting
stuff
sent
sent
elsewhere.
E
E
A
For
creating
exactly
that,
that's
exactly
what
I'd
like
to
do.
The
part
of
this
activity,
source
work
so
for
generating
activities.
I
plan
to
use
activity
source
without
taking
a
dependency
on
and
so
diagnostic
source
dll
is
the
dependency
we
need
to
take
and
then
for
sending
one
thing
that
I'm
really
passionate
about
that
is
different
from
the
sdk.
I
don't
want.
The
customer
to
programmatically
configure
is
lots
of
stuff.
A
A
B
So
so
the
profiler
is
injecting
you'll
be
injecting
a
listener
for
active
sources.
Right,
yes,
exactly
yeah.
So
in
that
sense
that
that
that
was
my,
my
first
thought
that
that,
basically,
that
lisa
was
going
to
be
the
opentelemetry.net
sdk
and
trying
to
avoid
this
dependency,
we're
going
to.
Let's
see
we
work
with
something
on
our
rip
or
via
sub
modules.
B
This
is
a
technical,
a
technical
decision
that
we
make,
but
my
kind
of
worry
kind
of
concern
is
if
we
have
to
implement
a
lot
of
stuff
that
already
exists
on
the
open,
telemetry.net
sdk.
You
know
I
wanna.
At
the
same
time,
I
understand
the
the
the
the
desire
to
not
take
the
dependency.
I
I
also
think
that
if
you
have
to
rewrite
out
that
stuff,
then
we
are
gonna
duplicate
a
lot
of
work.
E
A
Yeah,
so
in
terms
of
the
threading
issue,
I
completely
agree,
but
in
terms
of
the
second
point
I
think-
and
you
guys
please
correct
me
if
you
feel
different-
this
is
just
my
kind
of
initial
thinking.
A
Right
is
that
the
sdk
and
the
agent
tracer
have
very
different
goals
in
terms
of
the
extent
to
to
which
user
configuration
is
desirable,
because
sdk
is
essentially
saying
you
guys
own
the
application
and
you
you
the
case
part
of
your
application
now
and
you
have
to
write
some
code
to
and
you
can
configure
whatever
you
want
in
terms
of
how
you
export
data
and
then
that's
it
you,
you
took
an
sdk,
you
configure
it.
If
it
doesn't
work,
then
whoever
wrote
that
code
needs
to.
A
You
know
fix
it.
We
as
open
telemetry,
can't
help
you.
If
we
just
give
you
an
sdk,
go
nuts,
whereas
with
a
tracer
we'll
be
going
to
the
customers
and
say:
well,
you
don't
need
to
modify
your
application.
A
You
just
install
the
splunk
tracer,
the
new
relic
traces,
the
microsoft
tracer,
which
is
all
essentially
the
open,
telemetry
tracer
shipped
from
a
different
repo
from
a
branded
repo.
You
just
put
it
on
your
infrastructure
and
things
just
work,
it's
magic
and
all
you
configure
is
like
what
is
the
name
of
your
environment.
What
is
the
name
of
your
service
that
you
would
like
to
see
on
the
back
end?
You
know
how
strong
you
would
like
to
sample
versus
pay
more
money
for
more
data.
You
know
stuff
like
that.
A
So
some
values
that
are,
you
know,
limited
configuration,
but
if
something
doesn't
work,
you're
our
customer-
and
we
help
you
so
that's
very
different,
because
if
we
allow
the
customer
to
write
code
to
configure
some
all
sorts
of
unusual
possibilities,
then
they
will
say:
oh
stuff
doesn't
work
help
me
we
pay,
we
pay
you
money
and
we
every
one
of
us
is,
will
be
now
on
point
to
figu
debugging
customer
applications,
and
I'm
not
sure
we
want
that.
A
B
But
but
I
think
the
the
I
think
we
agree
with
zero
touch
to
the
customer
code.
We
we
are
not
talking
about
that,
but
we
have
to
have
a
way
to
set
up
things
like,
for
instance,
because
that
is
a
open,
telemetry
tracer
itself.
Let's
say
on
this
project:
we,
it
is
not
only
about
installing
from
the
vendors
I
think
most
vendors
perhaps
have
their
own
build,
but
there
will
be
people
that
will
be
installing
directly
from
open
telemetry.
B
You
know
there
will
be
people
that
are
using
zip,
king
and
jager
and
managing
promoters,
so
we
need
to
have
our
offer
for
those
we
need
to
have
a
open,
telemetry
build.
That
should
include
this.
This
basic
functionality,
you
know
agree.
B
So
so
that's
the
part
that
I
think
that's
is
the
part
that
I
think
it
should
have
a
cooperation
with
the
folks
working
on
the
api
and
sdk4.net,
because,
as
chris
mentioned,
perhaps
this
feedback
about
the
thread
and
avoid
they
are
think
is
something
that
is
worth
to
reach
the
sdk
team.
You
know
so
in
that
case
the
change
of
the
code
perhaps
is
done
there,
but
we
benefit
here.
I
I'm
not
saying
that
we
we
are
going
to
use
that.
B
What
I'm
saying
is
that
we
should
work
in
close
collaboration
between
the
two,
even
if
you
are
not
taking
the
dependency,
if
you
are
using
the
technical
solution,
doesn't
matter
if
it's
git
sub
modules
or
something,
but
I
from
my
perspective,
my
goal
is
try
to
avoid
to
have
this
to
rewrite
a
bunch
of
the
stuff
that
exists
on
the
sdk,
while
in
being
a
offer
from
open
telemetry
that
satisfies
the
criteria
to
people
that
want
to
use
with
not
of
the
vendors.
You
know
we
have
to
cover
both
cases.
A
That
make
sense.
Okay,
let's
do
this
as
an
actionable
thing,
so
I'll
need
to
write
a
design
doc
anyway
and
as
a
part
of
it
I'll
outline
outline
this,
and
I
will
look
at
in
more
detail
at
what
open
telemetry
sdk
has,
and
I
will
suggest
you
either.
This
is
how
we
just
copy
the
how
we
physically
copy,
whether
it's
for
now,
I
will
assume
we
copy
source
code,
but
you
can
always
replace
it
by
automatic
copying
of
il
whatever.
A
This
is
something
I
don't
want
to
go
into
I'll
either
say:
okay,
this
is
we
take
these
classes
and
call
them
in
the
same
or
different
way
or
if
I
feel
that
it's
not
the
right
thing
to
do,
then
I'll
call
it
out
and
we
can
discuss
it
and
I'll
say
this
is
why
I
think
we
shouldn't
do
it
and
then
I
might
be
wrong
and
then
we
can
talk
about
it.
D
Hey
greg,
this
is
just
starting
to
that.
I
believe
this
should
be
like
two-way,
like
whatever
issues
sdk
has
in
terms
of
performance
or
log,
free,
algorithms
or
like
using
dedicated
thread.
It
should
benefit
like
sdk
customers.
If
you
implement
it
at
the
same
time,
it
should
also
benefit
the
codeless
or
asian
customers,
or,
if
you
let's
say
you,
find
a
better
algorithm
to
implement
log
free,
it
should
not
be
just
restricted
to
the
auto
instrument.
It
should
come
back
to
the
sdk
as
well.
D
So
I
I
mean
I
don't
know:
how
is
it
possible
to
physically
do
it
like
whether
asparagus
was
mentioning
about
the
rigid
sub
module
or
some
partial
script,
which
just
literally
clones
the
repo
some
mechanism?
I
don't
know
what
that
like
logistics,
but
I
have
a
strong
feeling
that
if
we
try
to
duplicate
efforts
in
both
repos,
it's
probably
it's
not
just
trivia
like
most
of
the
code,
as
you
mentioned,
like
it's
not
trivial,
like
doing,
we
recently
had
implemented
log
free
batching
dedicated
current
here
as
well.
D
So
if
you
don't
like
rely
on
each
other
to
like
reuse
the
code,
then
it's
it's
just
like
we'll
be
spending
a
lot
of
time,
just
solving
the
exact
same
problem,
which
one
of
us
has
probably
solved
in
a
sister
report.
D
I
think
it
has
something
to
do
with
the
instrumentation
also,
but
I
don't
really
know
whether
it's
relevant,
for
example,
the
main
repo
the
sdk
repo
has
instrumentation
library
for
like
asp.net,
hp.net,
core
http,
client
etc,
unless
like,
if
you
are
not
planning
to
reuse
it
like.
If
you
are
like
writing
something
on
your
own,
then
you'll
be
like
spending
tons
of
effort
just
to
duplicate
whatever
things
which
we
have
already
quoted.
So.
A
I
so
that
I
completely
agree
I
just
that
part.
I
didn't
look
at
yet
so
you're,
probably
right.
It's.
I
just
want
to
split
the
considerations
related
to
that
part
from
the
considerations
related
to
collecting
activities,
but
generally,
I
agree.
D
And
like
who,
who
can
actually
do
the
investigation
of
like
whether
it
is
feasible
to
share
the
same
code
without
having
an
explicit
new
gate
or
tlr
dependency
apollo
mentioned
like
submodule?
Is
it
something
which
we
have
done,
or
it's
just
a
thought.
A
So
what
you
will
notice
something
that
we
do
a
lot
in
the
tracer
already
is
we
simply
we
check
the
license
if
it
permits
for
it.
We
just
we
just
copy
code.
We
can
always
improve
on
it.
It's
absolutely
true.
Okay,
it's
always
a
fallback
that
we
can
use
and
the
tracer
has
we
have
newtonsoft
rendered.
We
call
it
rendering
we
have
new
full
copy
of
newtonsoft.
We
have
a
full
copy
of
of
all
sorts
of
logging
libraries
we
have.
D
C
I
think
one
thing
to
add
to
this
is
what
conversations
about
using
open
telemetry
is
eq
for
exporter.
We
should
be
based
on
real
scenario.
So
if
you
have
a
real
scenario
and
real
customers
already
painting,
then
we
should
initiate
more
deeply
in
how
to
reuse
the
code,
but
so
far
my
understanding
is
that,
like
at
least
lung
and
daughter
dog
are
not
do
not
have
a
scenario.
Microsoft
does
not
have
this
scenario
yet
as
well.
C
So
maybe
I
should
answer
a
question
who
will
be
investigating
is
going
to
be
answering
the
question
who
what's
naga,
trying
to
enable
and
who
is
going
to
be
piloting
this
scenario
and
but
will
actually
tell
you
like
who
will
be
working
on
this.
B
Yeah,
so
I
I,
I
think
we
should
kind
of
discuss
various
things,
so
I
think
we
we
should
kind
of
just
use
the
last
10
minutes
of
the
meeting
to
kind
of
agree
on
this
follow-up
smasher.
So
since.
A
There's
one
sorry
apollo
you're
right,
but
there
is
one
other
thing
about
activities
that
I
wanted
to
bring
up
where
I
also
would
really
want
some
help
from
you
guys
from
other
vendors,
so
once
related
to
activities.
So
one
thing
that
I
already
mentioned
is
the
versioning
problem
for
diagnostic
source.
A
I
really
would
like
some
people
from
microsoft
to
help
us
there.
The
second
version
is
the
second
area.
Is
this
we'll
go
through
the
design
reviews
together,
we'll
ship
that
prototype,
and
we
will
be
now
in
a
situation
where
we
collect
activities
instead
of
the
spans
that
are
currently
part
of
the
tracer?
A
That
means
every
single
integration.
Now
that
already
exists
needs
to
be
converted
to
the
new
world.
So
the
plan,
the
plan
for
this
that
and
please
feel
free
to
suggest
a
better
plan-
is
I'll,
go
and
modify
the
existing
datadog
trace
library
to
create
activities,
and
then
I
will
rip
out
from
that
library.
B
So
I
I
think
this
is
a
good
thing
that
we
can
start
work
very
soon.
Basically,
because
this
is,
I
think,
his
agreement,
every
every
instrumentation
is
moving
to
activity
right.
So
there
is
a
path
to
do
that
without
breaking
what
works,
and
that,
I
think,
is
the
part
that
you
already
had
some
vision
for
that.
But
I
I
think
this
is
something
that
I
I'm
willing
to
work
and
start
to
work
and
move
in
those
two
activities
as
soon
as
possible.
B
You
know
because
this
is
something
at
least
from
my
perspective,
that
this
is
a
thing
that
we
are
sure
that
we
are
going
to
do,
and
it
kind
of
gives
us
time
to
discuss
the
other
things
about
the
tracer
and
how
we
are
going
to
be
able
to
interact
with
the.net
sdk.
A
The
thing
is
until
we
have
this
engine
working
to
at
least
some
degree,
there
is
nothing
to
if
you
do.
If
you
do
that
before
we
do
the
other
thing,
then
we
can
never
test
it.
You
see
that's
the
problem,
so
we
need
to
do
the
engine
first.
We
need
to
do
this
modification
that
I
mentioned
first
before
we
can
do
it
in
parallel,
but
then
you
can
never
test
your
work
until
until
you
actually
did
it.
A
So
I
would
actually
suggest
that,
in
order
to
have
a
product
that
is
testable
at
any
time
so
that
we
can
always
be
testable
means
we
can
take
more
frequent
integrations
into
vendors
reports,
because
then
we
can
go
and
run
it
and
give
it
to
customers
and
all
of
the
stuff.
Because
of
that
I
would
actually
prefer
doing
the
engine
of
this
first.
What
do
you
think.
B
I
I
I
think
that
to
some
degree,
because
the
integration
tests,
the
integration
tests
kind
of
really
require
the
injection
and
the
trace
it's
really
hard,
but
I
think
we
can
do
some
of
that
stuff
in
parallel.
If
you
have
unit
tests,
you
know
okay,
so
I
think
I
I
think
that
that's
something
that
can
happen
kind
of
in
parallel,
okay,
I
I
do
agree
that
for
the
integration
test,
then
you
need
a
tracer
to
be
in
place
to
listen
to
the
activities
you
know.
B
Otherwise
the
integration
test
is
not
going
to
work,
but
my
my
impression
is
that
we
can
start
that
work
and
it
seems
to
me
that
is
also
something
that
is
more
kind
of
closer
to
being
agreed
by
every
member
in
the
community
than
about
the
tracer
itself.
You
know,
okay,
sure.
E
B
B
B
So
going
back
to
what
we
are
talking
before
kind
of
to
to
kind
of
get
out
with
the
actual
items
and
follow-ups
for
for
us.
After
that,
I
think
we
we
mentioned
various
things.
I
think,
if
I'm
reading
this
right-wing
agreement,
that
this
part
of
moving
the
activity
source
it's
kind
of
a
common
goal
and
agreed.
B
So
perhaps
if
you
can
greg,
if
you
can
point
to
us,
as
you
mentioned
in
the
beginning
kind
of
or
either
the
branch
or
the
work
that
we
can
start
to
do
on
the
community
to
work
on
this
side,
it
will
be
great.
A
So
so
I'll
create
an
issue
and
I'm
off
for
the
rest
of
the
week
so
I'll
create
it
on
monday,
I
I
like
essentially
today
is
my
last
day:
okay,.
A
And-
and
I
create
an
issue-
a
branch
I
mean-
I
can
point
you
to
like.
I
think
the
first
step
for
me
would
be
a
design
document
code,
so
yeah
yeah.
B
A
Can
you
can
for
for
for
doing
integrations,
you
can
create
your
own
branch
or
fork
or
whatever
is
appropriate.
A
I
think
something
we
should
finish.
First,
though,
is
the
whole
ci
thing
that
you're
already
working
on
what
did
it
make
sense.
A
And
and
yeah
no,
I
mean
branch,
I
think
it's
I.
I
can
post
a
guitar
link
to
everything
that
we
have
so
far,
but
I
think
creating
a
design
dock
is
the
first
step
and
I'll
see
I
created
as
an
issue,
always
a
google
doc
that
they
link
from
the
issue.
I
think
it
doesn't
matter.
B
It
yeah
yeah
so
that
for
the
achieved
source
for
the
migration
for
the
active
source,
the
call
target
we
are
going
to
be
waiting.
I
I
forgot,
who
is
the
name
of.
B
So
when
he
is
back,
he
is
gonna
bring
something
about
the
design
to
convert,
to
call
target
to.
E
B
Yes
and
the
other
thing
about
the
tracer-
I
don't
know
what
will
be
the
I'm
not
sure
about
the
best
path
there,
but
we
have
somebody
bring
up.
I
could
do
that,
bring
up
kind
of
high
level.
B
What
is
is
there
and
kind
of
what
was
my
initial
thought
and
then
from
that
we
kind
of
something
short,
nothing
very
complicated,
not
a
real
design,
doc,
but
kind
of
exploring
the
options,
and
we
we
try
to
have
a
discussion
from
there
about
how
we
are
going
to
integrate
with
the
sdk
via
source,
and
I
I'm
just
to
get
these
three
things
going
on.
You
know.
A
So
I
have
a
question
for
which
version
michael?
Would
it
make
sense
for
you
guys
then,
to
work
on
this
versioning
challenge?
A
C
So
we
investigated
it
and
we
actually
chatted
a
lot
with
noah
and
jeff
give
in
general
and
the
recommended
way
is
not
to
force
the
newer
version
of
diagnostic
source,
but
rather
than
adapt
your
code
to
the
existing
version
of
diagnostic
cell-
and
this
is
something
we
will
need
your
help.
We
just
need
a
separate.
C
Maybe
this
meeting
can
be
used
for
technical
discussion,
but
we
need
a
technical
discussion
in
what,
if
you're
going
to
use
older
version
of
diagnostic
source,
what
does
it
imply
and
what's
the
minimum
dynamic
surface
version,
we
need
to
support
so
functionality.
C
B
So
but
but
you
are
going
on
vacation
monday
right
so
can
you
share
some
dogs
or
some
information
that
you
collect
in
this
process
that
people
perhaps
can
start
to
have
information
kind
of
form,
some
opinion
about
it.
C
A
B
Okay,
so
I
o,
I
o,
update
the
the
the
discussion
of
the
the
meeting
afterwards
and
I'll
post
on
the
gita,
so
people
can
review
if
I
didn't
capture
some
of
our
discussion,
but
I
think
I
think
we
we
kind
of
have
some
stuff
concrete
to
work
on
right
now
and
I
think
we
can
move.
I
don't
know
if
anybody
else
has
anything
that
they
want
to
discuss
on
the
meeting.