►
From YouTube: 2022-06-22 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
D
F
G
G
Oh,
I
did
the
the
open
telemetry.net
one
last
night
at
midnight,
my
time
so
yeah.
B
Okay,
I
think
we
can
start-
maybe
I'll-
maybe
I'll-
share
that
I
will
maybe
moderate
today.
So
maybe
maybe
first,
if
we
have
some
someone
new,
maybe
you
will
introduce
yourself.
I
don't
yeah,
you
can
start.
G
Yeah
so
martin
thwaites,
I
go
by
martin.net
on
the
twitters.
I
have
been
using
open
telemetry
for
a
while,
since
it
was
open,
tracing
way
way
way
back
just
started
on
honeycomb
as
devrel
for
emea
and
their.net
person,
so
they're
willing
to
sink
a
lot
of
my
time
into
making
open
telemetry
better
because
it
is
our
sdk.
Basically,
we
don't
have
one
so
we
use
open
telemetry,
so
the
the
better
opentelemetryfor.net
is
the
better
it
is
for
us.
G
So
I
will
be
in
and
around
these
meetings
and
trying
to
help
out
wherever
I
can.
B
G
I
was
speaking
to
somebody
last
night
and
I'm
planning
on
trying
to
go
through
the
repo
and
get
some
small
issues
that
I
can
pick
up
with
just
to
get
the
the
ball
rolling
and
then
potentially
pick
up
some
bigger
things,
because
I'm
here
for
a
longer
haul,
rather
than
a
fly
by
the
night
contributor.
So.
F
All
right,
I
guess
I'll
start
so,
I'm
zach
I
work
at
datadog
and
so
working
on
the
tracer
spent
a
lot
of
time
with
the
automatic
part
and
the
the
profiler
and
yeah
I'm
sort
of
our
our
man
for
datadog,
for
working
with
the
open,
telemetry
and
trying
to
you
know,
make
sure
the
we
can
help.
However,
we
can,
with
the
auto
instrumentation
project.
D
D
All
right
so
I'm
you
can
see
splunk
I've
been
with
open
sensors
and
then,
when
it
joined
with
opentlm,
to
work
at
a
bunch
of
the
collector,
but
about
two
years
ago
I
kind
of
wrap
it
down.
My
work
on
the
collector
then
start
working
on
the
dot
net
instrumentation.
D
It
has
been
a
long
journey,
but
now
I
think
we
are
getting
to
the
point
that
we
ship
the
first
beta
and
we
are
kind
of
getting
to
really
get
to
have
this
thing
out
and
auto
instrumentation.
I
think
it's
a
lot
of
a
lot
of
net
users
are
actually
looking
for
that.
B
I
see
you
have
another
person
here,
hello,
doc.
We
are
just
introducing
ourselves
as
martin
has
joined.
You
have
also
joined
so
right
now
we
are
just
telling
a
few
words
about
ourselves.
So
maybe
I'll
go
next
and
then
we'll
go
that
would
martin
started
the
duck.
You'll
be
the
last
one.
It
will
be.
I
think
the
easiest
way
so
I'm
working
with
paulo
at
splunk
and
I'm
like
maintainer
here,
I'm
also
an
approver
in
the
net
sdk
and
I'm
also
an
approver
in
the
go
in
the
hotel
go
sdk.
C
I'll
I'll
go
next,
hey
I'm
raj!
So
I'm
from
microsoft.
So
I'm
driving
the
like
open,
telemetry,
auto
instrumentation
efforts
from
the
microsoft
earlier.
I
was
doing
some
small
work
in
the
opentelemetry.net
sdk
space
and
I
felt
this
is
the
place
where
really
the
more
work
is
needed
and
I
switched
here
and
started
working
like
along
bringing.net
team
and
closely
working
with
the
community
here.
H
My
name's
chris
I
work
for
new
relic
prior
to
working
on
this
project.
I
worked
on
new
relics.net
agent
and
yeah.
Now
my
focus
is
on
supporting
this
community.
I
Sir
nice,
to
meet
you
guys,
doug
odergaard
from
q2
we're
we're
actually
a
user
of
open
telemetry.
We
are
a
splunk
customer
and
I've.
I've
been
using
the
splunk.net
tracer
for
a
while
and
heard
at
the
conference.
You
know
of
this
this
movement
and
I'm
super
excited
to
participate
with
you
guys
not
only
as
a
beta
tester,
but
also
to
help
with
any
documentation
or
areas
where
I
can
chip
in
and
help
out.
So
just
consider
me
a
lackey
on
the
team
and
and
happy
to
help.
H
Yeah
and
if
you
have
some
writing
skills,
I
know
that
I
definitely
could
use
some
help
with
making
more
attractive
announcements.
I
Yeah
I'll
be
very
happy
to
help
with
that.
I
know
I
implemented
the
dotnet
tracer
and
found
certain
things
I
was
like
gosh.
If
I
could
share
with
share
this
with
other
users,
it
would
probably
help
and
again
you
know
in
this
realm,
because
we
we've
been
implementing
it
strongly
and
there
there
are
certainly
gotchas,
as
you
guys
know
so,
yeah
happy
to
help
there.
B
Okay,
martin,
do
you
have
also
something
that
you
want
to
share?
So
maybe
I'll
just
share
my
screen
and
if
you
want
sure
that
we
do
not
forget.
So
here
are
google
meeting
the
like
google
docs.
B
B
B
Okay.
So
let's
go
through
our
agenda
quickly.
So
first
we'll
go
through
the
like
open
prs.
Then
you
create
tissues
to
discuss
them,
and
then
you
review
the
project
board.
What's
going
on
to
review
the
status
issues
so
first
stretch
your
your
pr
in
draft
say:
do
you
want
to
start.
C
Yes,
like
I
created
interesting
just
to
take
the
feedback,
even
I
am
in
like
agreement
with
whatever
the
discussions
that's
going
on
in
there,
so
like
mainstream
should
be
the
collector-based
test,
so
probably
whatever
that
remaining
like
runtime,
metrics
and
other
things
we
can
get
it
added
through
that.
I
was
trying
to
cover
two
things
in
this
pr.
One
is
the
ace
classic
asp.net
integration
test
and
the
prometheus.
C
I
think
we
can
I'm
in
agreement
that
we
can
split
this
into
two
and
like
test
out
the
asp.net
only
with
the
the
previous
model.
What
is
the
otlp
and
the
other
one?
We
will
create
a
exporter
based
prometheus
export
based
test.
We
can
have
a
small
console
application
created
to
emit
a
matrix,
and
that
can
be
added
so
I'll
separate
this
into
two
different
peers.
B
B
So
I
have
tried
to
extract
some
bullets
here,
so
I
think
that
by
default
we
should
use
the
otlp
exporter
in
our
tests
right
and
those
two
has
been
already
implemented
by
by
by
chris,
and
I
have
created
a
few
other
bullets.
We
don't
have
desperate
metrics,
and
this
is
what
you
try
to
do
it
together
with
this
promise
exporter-
and
I
don't
know
if
you
want
to
work
on,
I
think
we
can
even
do
something
like
that
that,
if
you're
trying
to
do
something,
we
can
write
something
like
that.
For
example,.
B
It's
faster
okay,
so
so
I
I
will
try
to
work
on
this
one.
If,
if
there
will
be
something
we
can
do,
you
know
just
pick
up
whatever
you
want,
and
I
can
also.
I
will
also
saw
that
we
do
not
have
any
tests
for
plugins
and
I
think
that
it
may
be
good
to
have
like,
and
you
know,
test
that
test
manual,
metrics
and
plug
in
at
the
same
time,
probably-
and
I'm
also
considering
to
do
the
same
test
for
traces.
C
As
we
are
speaking
about
the
integration
test,
I
have
one
more
feedback,
so
I
don't
know
whether
we
need
a
chipkin
exporter
that
mark
15
exporter
for
tracer.
At
this
time
I
would
recommend
moving
that
to
also
to
the
collector
base,
so
we
will
have
a
one
implementation
which
supports
everything.
C
Want
you
can
take
it,
I'm
saying
let's
create
an
issue
and
put
it
at
a
later
time
in
the
board
so
that
we
will
have
addressed
at
a
later.
I
might
oh,
I
would
check.
B
Still
good
for
mark
anything
more
to
discuss
here,
or
I
think
you
think,
you're
good.
We
are
good.
I.
B
Have
only
also
one
question
because
I
wanted
to
start
with
refactoring
and
I
prefer
to
have
to
have
some
questions
before
I
do
it
is
there
any
reason
we
have
a
project
for
each
test,
because
it
looks
like
a
madness
for
me
at
first
glance
like
an
over
engineering,
is
there
any
technical
reason
why
we
have
it
like
that.
F
Me,
I
think
maybe
the
only
motivation
was
so
that
you
can
test
each
integration
separately
in
case
you
want
to
try
different,
like
package
versions,
and
you
want
to
do
that.
Maybe
it's
not
really
necessary.
B
D
F
D
Do
you
have
some
do
we
pass
the
filter
on
the
nuke
task.
D
So
if
we
put
everything
together
at
the
filter,
to
look
so
could
be
separate,
doesn't
need
to
be
the
same
pr,
but
then
we
need
to
have
a
task
to
add
the
filter.
If
you
don't
have.
B
B
H
E
I
I
I
think
if,
if
the
test
is
really
really
big,
it
does
make
sense,
but
I
I
think
you
think
these
tests
are
very.
D
They
are
very
shallow
kind
of
because
you
have
the
test
app,
that
where
we
have
the
code
so
in
peaceful,
it
sounds
that
we
can
bundle
them
all
together.
You
know,
maybe
in
the
future
we
get
to
the
conclusion
of
different,
but
they
they
are
very
similar
and
very
start
the
app
check
for
something
start,
the
app
check
for
something
so.
B
Okay,
let
me
go
to
the
next
next
pr,
so
here's
the
next
pr.
B
The
thing
is
that
when
I'm
developing
I'm
trying
to
first
run
off
stuff
on
my
machine,
and
I
tried
running
the
the
tests
with
linux
containers
on
my
machine
and
it
failed
and
right
now,
I'm
not
I
there
is
a
issuance
containers,
but
I'm
not
really
sure
if
the
current
issue
is
my
like
environmental
problem,
because
I
updated
the
docker
docker
desktop
for
windows
today
and
it's
connected
with
with
some
changes
in
the
docker
for
desktop.
Or
is
it
also
some
flaw
in
test
containers
or
our
code?
B
B
G
I
ask
a
quick
question:
yep
is
our
test
strategy
for
for
this
documented
somewhere,
as
in
what
we're
doing
for
in-memory
testing
versus
docker-based
testing?
What
integration
testing
means,
what
where
our
expectations
are
for
each
instrumentation?
Is
that
documented
anywhere
about
in
the
contributing
guides,
not
at
all.
D
Okay,
that
that
will
be
a
very
welcome
contribution.
I
think
one
thing,
because
this
is
auto
instrumentation.
I
think
perhaps
people
don't
expect
that
at
first,
but
a
lot
of
things.
What
we
do
is
to
have
a
test
application
and
from
the
test
we
run
that
test
application
and
then
compare
if
we
got
the
data
that
we
expected
so
really
integration
test.
Is
this
kind
of
the
proof
that
the
monkey
patch
and
everything
is
working?
You
know.
G
Oh
yeah,
I
mean
it's,
I'm
sorry.
I
come
from
a
world
where
in
memory
testing
is,
is
the
thing
and
you
you
do
a
very
minute
amount
of
the
stuff
that
I'm
seeing
at
the
moment
around
the
docker
stuff.
That's
basically
just
checking
your
line
protocol
is
working,
whereas
checking
that
the
it
makes
it
to
the
exporter,
for
instance,
is
something
you
can
do
with
a
web
application
factory
as
opposed
to
running
up
a
container,
which
means
you
can
run
them
all
quicker
locally
and
all
of
that
kind
of
stuff.
B
G
What
I
can
do,
I
I
will
take
an
action.
I
will
write
it
down
now
to
have
a
look
at
what
we've
got
and
see
if
I
can
come
up
with
a
what
I
think
is
based
on
what
I
can
see
in
the
instrumentations
and
I'll
write
that
up
and
then
see
where
we're
at.
H
Yeah,
I
think
you'll
find
that
the
usage
of
containers
has
been
mostly
limited
to
external
dependencies,
like
databases
and
the
exception
to
that
is
for
dealing
with
our
one
test.
That
relies
on
an
iis
setup
and
in
able
to
allow
things
to
run
in
parallel.
We're
using
a
container,
as
opposed
to
relying
on
iis
express.
G
Okay,
I
I
will
I'll
take
it
away
and
have
a
look
see
what
I
can
see
and
then
I
think
it'd
be
useful
specifically
for
me,
as
a
new
person
coming
in,
to
try
and
contribute
to
know
what
there
is
an
expectation
of
in
terms
of
testing.
I
mean,
like
you
say
if
we're
saying
that
you
don't
use
containers
unless
you
absolutely
have
to,
and
everything
else
has
done,
that
it's
a
great
strategy,
let's
put
that
in
a
document,
so
that
it's
useful
to
people
who
come
on
and
want
to
add
their
own
instrumentations.
B
D
During
the
time
between
the
meetings
feel
free
to
reach
out
slack
and
we
can
have
things
moving
in
between
the
meetings
you
know
no
problem.
I
shall
absolutely
do
that.
B
So
let
me
go
forward
so
now,
I'm
I'm
opening
the
issues
that
have
been
created
during
this
week.
So
the
first
one
is
about
updating
opel
telemetry
protocols
created
by
chris.
So
so
I
think
it
will
be
better
just
to
do
it
right.
H
B
H
H
B
H
I
don't
know
that
it's
worth
yeah
using
automation
at
this
point,
the
sdk
sig,
isn't
using
any
automation
for
their
updates
either,
and
it
could
also
be
a
question
of
since
we're
just
using
it
for
tests.
Maybe
we
only
need
to
do
updates
when
we
need
to
start
seeing
a
breaking.
J
G
H
H
B
I
have
also
opinionated
opinion
that
it's
better
to
work
on
like
something
static
like
to
have
like
reproduce
reproducing
rep
help
from
here.
Reproducibility.
B
Yeah,
thank
you.
I
would
rather
create
some
new
target
that
updates
the
version
and
just
create
a
github
action
that
if
something
changes,
then
it
creates
a
pull
request.
For
example,
I
think
data
talk
right
now
is
very
good
at
create
in
such
automation,
day
repo,
correct
zach.
I
think
you're
doing
a
lot
of
stuff
like
that.
Right
now,.
D
Yeah
I
I
would
just
say
that
it
seems
low
priority,
because
it's
for
the
test
and
yeah
we
probably
have
some
more.
B
Okay
and
next
one
is
update,
this
one
is
great
chris,
and
the
thing
is
that
today
I
experienced
that
I
have
forgotten
to
er
to
run
it
with
admin
and
there's
no
feedback
right.
D
H
B
C
B
B
B
B
B
C
No
this
week,
I'm
planning
to
do
something
there.
You
want
to
discuss
something
now
yeah
in
the
open
element.
Not
in
this,
I
need
to
like
the
action
plan
is
to
follow
up
with
the
open,
telemetry
sdk.
B
B
H
Yeah,
I
took
a
a
brief
look
at
it
and,
at
least
from
from
what
I
understood
of
what
was
being
mentioned,
is
today
we're
currently
using
these
extension
methods
to
subscribe
to
both
the
activity
source
and
enable
an
instrumentation
library
and
what
we
need
to
do
in
order
to
make
things.
Work
more
smoothly
is
to
separate
those
two
concepts
such
that
we
can
subscribe
to
all
sources
up
front,
but
then
conditionally
enable
instrumentation
libraries
once
we
detect
that
a
supported
library
is
loaded
in
the
application,
and
that's.
J
D
So
sorry,
because
I
I
didn't
catch
up
with
all
of
these
since
last
week,
so
what
you're
saying
makes
sense
to
me.
My
question
is:
do
we
need
chains
in
the
sdk
or
the
sdk
or
red
support?
That's
past
that
you
described.
B
It's
not
a
bulletproof
implementation,
it
has
race
conditions,
but
it
shows
what,
from
the
you
know,
api
perspective
could
be
a
handful
to
discuss.
You
know
the
api
layer.
D
D
My
question
is,
for
instance,
I'm
putting
a
very
high
level
and
sorry
I
I
was
out
last
week
for
from
the
hotel.
I
didn't
follow
the
issue
closely,
but
my
question
is:
do
you
have
that
extension
point
in
the
sdk?
It
sounds
that
not
that's
why
you
have
this
api
change
proposed
by
rasmus
right.
H
E
H
So
the
unknown
part
to
me,
which
I
did
not
look
closely
at,
is,
if
there's
a
requirement
in
the
tracer
provider
for
all
of
those
instrumentation
library
pieces
or
if
it
is
sufficient
to
just
have
a
a
list
of
activity
sources
that
you
subscribe
to.
Upfront.
D
I
see
so
I
think
I
think
there
is
still
some
digging.
I
don't
know
when
rasmus
is
back,
but
I
think
I
I
I'll
try
to
take
a
look
too.
So
we
have
more
eyes
because
this
is
a
kind
of
critical
piece
for
us
to
add
the
experimentation
so
yeah.
So
whoever
has
a
chance.
Also,
please
dive
into
that.
B
So
this
is
all
here,
but
I'm
pretty
sure
I
have
forgotten
about
one
issue
yeah.
I
have
also
created
the
release
zero
to
zero
issue
to
for
tracking
the
release,
because
we
are
pretty
close
and
I
will
just
assign
to
the
project
and
milestone.
B
C
H
B
Yeah,
I
think
it
increases
the
probability
that
we
get
more
users
more
attention.
I
have
also
forgotten.
We
should
probably
also
ping
noah
again
to
have
some
announcement
on
the
dot
net
block,
because
I
think
that
that
he
has
because
I
have
just
said
that
he
has
the
contents
in
the
open
telemetry,
but
I
don't
know
if
he
expected
us
to
create
the
blog
post
like
there
was
miscommunication
here.
I
think.
D
There
as
well,
I
kind
of
I
kind
of
think
that
we
should
save
that
one
when
we
are
a
bit
closer
because
first,
the
bar
to
to
get
there,
it
needs
to
be
it's
a
bit
higher.
You
know,
and
also
when
we
get
that
visibility.
I
think
we
should
be
supporting
much
more
many
more
instrumentations.
D
So
I
I
I
I'm
crazy
for
the
feedback,
but
I
think
that
that
one
we
should
say
for
later.
C
I
gotta
see
their
feedback
from
noah
when
I
had
a
talk
with
him
say
he's
saying
he
knows
that
like
when
I
had
to
talk
with
him.
The
tracer
is
stable,
but
he
would
like
to
see
like
everything
else,
like
all
three
pillars
going
there,
so
that
would
be
the
right
time
where
we
could
engage
and
publish
it
in
one
shot.
So
it
invites
a
lot
of
people
to
use
it
like
all
three
sectors.
D
D
B
Like
dogs,
if
we
oh
give
me
a
second,
a
milk
appropriate
like
if
everything
in
conflict
is
like
described,
etc,
just
to
double
check
it
before
the
release,
because
I
remember
some
things
were
renamed,
etc
or
that
have
you
already
covered
everything.
B
B
Yeah
like,
for
instance,
there
is
like
these
not
traces,
matrix
disables.
We
need
to
check
both.
B
Okay,
okay,
I
will
stop
sharing
and
now
I
think
it's
the
time
for
martin
and
doc.
I
don't
know
who
want
to
start
doc.
I
think
you're.
I
see
you're
smiling.
I
Okay,
I
don't
mind
remind
me
again
what
you
wanted
me
to
speak
to
directly
just
experience.
B
I
Yeah
absolutely
so,
and
I'll
keep
this
brief,
so
I've
actually
I'm
a.net
developer
for
many
many
years
I
got
into
observability
here
at
q2.
We
we
create
observability
tools,
but
then
we
also
I've
been
pushing
open
telemetry
throughout
our
operation.
We're
not
just.net
we're
golang
or
python.
Where
node.js
I
mean
so
many
different
flavors.
I
We
have
a
large
code
base,
so
auto
instrumentation
was
an
unnecessary
thing
for
us
because
we
could
not
go
in
and
manually
instrument,
so
many
things.
So
I
did-
and
I
am
still
implementing
with
the
splunk.net
tracer
and
learned
a
lot
through
that
process
and
have
came
into.
I
think
I
spoke
to
a
couple
of
you
actually
on
a
phone
call
about
a
support
phone
call.
Once
from
that,
I
I
wanted
to
contribute
some
some
that's
either
best
practices
or
troubleshooting
type
of
information
to
to
that.
I
At
that
time,
and
then
I
saw
this
project
was
coming
open
and
it
was
like.
Okay,
great,
you
know,
I
would
really
like
to
help
other
people
with
that
as
and
part
of
it
is,
is
because
of
the
different
types
of
applications.
I
I
Mainly,
we
were
getting
a
lot
of
traces
just
with
single
sequel
statements
and
learned
a
lot
about
that
because
we
pay
per
trace,
and
so
when
it
comes
to
auto
instrumentation,
I
oftentimes
heard
well
it'll
run
out
of
gas
on
you
fairly
quickly
and
I'm
like.
I
can't
really
accept
that
answer.
I
I
I
would
I
I'm
not
a
c
plus
plus
expert
by
any
means
like
more
on
the
c
sharp
side,
but
again
I
I
would
love
to
help
out
with
the
documentation,
side
and
beta
testing
and
providing
that
because
we're
we
have
a
big
test
bed
of
different
types
of
applications.net
ones,
and
so
I
just
feel
like,
since
we're
in
the
mud
doing
this
anyway.
I'd
like
to
at
least
provide
some
of
that
energy
back
to
to
the
to
the
team
and
the
effort
so
yep.
I
And
so
far,
we've
we've
just
really
appreciated
the
auto
instrumentation
because,
like
I
said,
we
have
trying
to
get
into
our
developers
sprints
to
do
the
manual.
Instrumentation
is
really
hard,
we'll
get
there
at
some
point,
but
it
takes
a
while
to
get
into
their
priority
lists,
and
so
therefore,
therefore
you
know
these,
this
is
really
really
helpful
for
us.
So
yeah
thanks.
H
One
follow-up
question
that
I
have
was
you
talked
about
traces
and
having
to
pay
per
trace
and
does
the
amount
of
spans
in
a
trace,
make
a
difference
to
you.
So.
I
Yeah,
that's
that's
the
fun
part
of
it
is
as
long
as
they're
correlated.
We
can
have
many
many
spans,
but
we're
actually
paying
per
trace,
so
it
can
have
30
spans
in
it
or
it
can
have
one
span
in
it,
but
we
pay
per
trace.
So
that's
why
correlation
is
so
incredibly
important
for
us
and
in
the
very
beginning
of
this,
one
of
the
big
struggles
was
just
getting
getting
into
my
head:
b3
versus
w3c,
trace,
parent
and
things
like
that.
I
As
far
as
multiple
languages
and
multiple
sdks
and
auto
instrumentation,
you
know
things
like
that:
helping
brand
new
users
to
very
quickly
understand.
Oh,
I
have
to
pay
attention
to
that
and
yes,
that
is
correct
once
once
we
got
that,
then
suddenly
I
have
three
different
three
different
types
of
services:
blending
into
a
single
trace,
so
I
don't
have
to
pay
for
three
traces.
I
pay
for
one
trace,
and
so
that's
that's
that's
very
important
for
us
and
knowing
the
strategies
to
get
to
that
very
quickly.
I
D
Yeah,
I
I
will
add,
on
top
dog,
that
independent
of
the
pricing
model,
actually
the
usefulness
of
distributed,
trace,
really
shines
when
you
can
have
this
multiple
language,
multiple
service,
showing
the
whole
picture-
and
I
think
one
thing
that
somebody
called
my
attention
regarding
auto
instrumentation
that
actually
to
be
fair.
I
didn't
think
from
that
aspect.
D
But
recently
somebody
mentioned
to
me
is
about
the
consistency,
so
one
of
the
struggles
of
manual
instrumentation
and
nothing
against
manual
instrumentation
they
enrich
they
can
make
the
things
really
make
more
sense
for
the
people
that
own
the
service,
but
it's
very
hard
to
keep
consistent
when
you
do
these
menu
instrumentations,
so
the
auto
instrumentation
one
good
thing
is
the
consistent
that
you
get
so.
Okay,
both
serves
services.
Different
services
use
some,
let's
suppose,
database
with
the
user
of
auto
instrumentation.
D
I
And-
and
one
challenge
for
us
has
been
some
of
the
some
of
our
more
legacy
windows
services.
So
they
are,
you
know,
written
as
an
exe,
and
we
had
we
had
one
where
I
I
cut
loose
the
auto
instrumentation
on
and,
unfortunately,
what
it
did
was
it
spit
out
a
trace
and
per
sql
call.
I
So
that's
where
that
concept
of
somehow
being
able
to
if,
if
in
auto,
instrumentation,
there's
some
way
to
understand
that
it's
within
a
particular
main
or
something
there
that
they
is
able
to
actually
put
some
tor,
and
I
call
it
a
wrapper,
but
it's
just
basically,
you
know
getting
it.
I
So
that
those
sql
calls
that
are
all
called
in
that
in
that
iteration
of
the
the
running
code
can
all
be
correlated
and
that's
and
again
that
speaks
to
if
I
had
unlimited
tap
them
traces
per
minute,
I'd
be
okay,
but
at
the
same
time
those
traces
aren't
very
helpful
because
they're
only
single
sql
statements,
and
so
that
is
a
I'll
just
say
that
is
a
challenge
and
I
don't
know
specifically
how
to
handle
it
code,
wise
other
than
doing
it
via
manual.
I
So
I
just
wanted
to
throw
that
out
there
that
that
has
been
one
of
our
one
of
our
things
is
trying
to
tame
the
monster
on
that
one.
H
Yeah,
I
almost
wonder
if,
in
some
of
those
use
cases,
it's
almost
like
it's
a
case
of
missing
instrumentation
such
that
you've
got
requests
coming
into
this
service
somehow
and
so
there's
either
some
sort
of
restful
call,
or
perhaps
it's
subscribing
to
some
sort
of
message
queue
and
in
in
theory
there
could
be
instrumentation
to
generate
spans
for
those
incoming
triggers.
H
That
would
then
eventually
result
in
some
of
these
database
calls,
but,
as
we
support
more
instrumentation
libraries,
some
of
those
gaps
will
just
go
away
and
prevent
the
need
for
manual
instrumentation.
I
And
I'll
I'll
bring
more
as
I
attend
more
of
these
meetings
or
I'll
put
issues
in
as
as
we
get
there
because
again,
I'm
planning
on
taking
the
beta
for
this
and
using
it
on
some
of
our
services,
ones
that
are
non-critical
and
just
to
be
able
to
kind
of
compare
to
our
other
running
instrument
in
implementation
and
then
I'll
help
out
with
that.
As
far
as
as
addressing
it,
I.
I
It's
a
great
question:
I
actually
most
of
our
stuff
is
dot
net
core,
3.1
and
higher,
but
again
we're
facing
that
december
end
of
life
in
the
library,
and
so
I
am
having
to
press
a
lot
of
our
internal
teams
toward
you
know
getting
it
up
to
dot
net
six,
so
we
have
a
smattering
of
different
ones.
I
I
believe
the
phone
call
I
had
with
you
guys
originally
was
an
application
where
I
spent
two
weeks
and
I'm
like.
I
Why
am
I
not
getting
traces
out
of
this
and
it
ended
up
being?
It
was
net
core
2.2
and
then
and
then
it
was
like.
Oh
that's,
the
reason,
okay,
so
but
yes,
most
of
ours
are
3-1
or
higher,
with
also
understanding.
That
december
is
our.
You
know
when
that
when
that
goes
end
of
life.
I
D
Well,
I
think.
D
Microsoft,
I
don't
know
for
dot
net
core
sorry,
but
for
the
framework
they
have
that
layer
of
support
that
you
could
pay
to
get
the
fixes
for
after
kind
of
day
and
the
end
of
life.
But
I
don't
know
if
they
are
going
to
do
that.
For
that
score,
no
idea.
D
All
right
on
that
silence,
that's
somebody
else.
Once
you
bring
anything
up,
we
already
use
almost
the
full
hour.