►
From YouTube: 2023-01-19 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
D
D
Yeah,
it
seems
like
John's
already
answered
it.
I
didn't
know
that
that
was
shattered
about,
but
is
there
any
risk
in
people
kind
of
being
misled
or
thinking
that
they're
using
the
right
thing
by
keeping
it
in
there
I
mean
it's.
C
A
D
Cool
then
there
is
a
plan.
That's
that's
enough
on
that
topic,
cool
the
next
one's
a
little
bit,
meteor
I,
suppose,
I,
don't
know
if
anyone
is
in
love
with
our
current
test
framework
for
http
I
think
it
is
rather
complicated
and
it
has
I,
don't
know
multiple
levels
of
inheritance
and
the
responsibilities
are
spread
throughout
them.
It
uses
overridden
methods
for
customizing,
test
runs
and
it's
it's
kind
of
hectic,
so
I.
D
D
So
that's
the
one
that
I
want
to
be
able
to
deprecate.
I
can't
actually
put
The
annotation
on
there
because
it
breaks
the
build
like
because
we
have
warnings
flagged
as
errors,
and
so
this
is
the
thing
that
I
would
like
to
ultimately
eventually
get
rid
of,
and
it
has
a
lot
of
classes
that
inherit
from
it.
Basically,
every
HTTP
client
framework
out
there
inherits
from
it.
E
D
Think
this
I
think
the
same
is
true
of
the
server
stuff,
but
I'm.
You
know
you
got
to
start
somewhere
so
client
stuff
first,
so
the
replacement
for
this
and
I've
factored
a
couple
of
things
out
to
try
and
shrink
the
responsibility
a
little
bit
up
front
but
yeah
exactly
so.
D
Traffic
has
already
found
it
HTTP
client
tests
that
could
be
renamed
to
like
test
Suite
or
something,
but
really
its
responsibility
is
to
provide
the
list
of
all
of
the
tests
that
we
want
to
generally
run
for
a
given
HTTP
client
and
it's
through
this
all
method
or
all
list
method
below
and
those
provide
a
list
of
dynamic
tests.
These
are
junit
Dynamic
tests.
D
Mean
what
I
think
what
most
of
us
really
want
is
for
Jaina
to
have
like
a
better
way
of
defining
like
a
template,
but
like
a
test.
Template
is
what
I
keep
thinking
of,
but
it's
not
really
there.
This
kind
of
gets
Us,
close
and
yeah.
That
big
looks
very
cool
I
mean
that's
basically
all
of
the
tests
that
we
want
to
run
for
all
HTTP
clients.
However,
it
is
also
gated
on
these
options
right
and
that
exists
today.
D
It's
just
it's
hard
to
read
and
I
think
it's
complicated,
but
there
are
these
test
options
that
say
for
for
a
given
client
like
what
things
are
out
of
scope
like
what
do
we
not
want
to
test,
and
those
are
done
currently
through.
These
junit
assumes
I,
don't
know
if
people
are
familiar
with
those,
but
these
June
assumes
will
abort
a
test
if
the
condition
is
not
true,
rather
than
doing
that
in
the
dynamic
test
case,
we
can
just
omit
those
tests
entirely
from
the
list
right.
So
it's
a
little
bit
cleaner.
F
How
did
how
does
IntelliJ
handle
these
Dynamic
tests
like?
Are
you
able
to
run
an
individual
Dynamic
test
if
it
fails
and
or
whatnot
or
do
you
have
to
do
all
of
them.
F
D
Love
it
yeah
and
those
could
be
composed
and
different
clients
could
Implement
I
mean
you
could
even
start
off
like
by
not
having
to
satisfy
all
the
tests
right,
yeah,
I,
love
it
and,
in
fact,
that
single
hdb
client
tests,
like
the
suite
class,
is
already
too
big
like
the
abstract
one
that
it's
coming
from
is
like
1200
lines,
long
or
something,
and
this
one's
also
long
but
yeah
I
think
there's
some
room
to
sort
of
categorize
or
group.
Those
into
something
helpful.
D
So
that's
something
I've
been
fiddling
with
and
I
have
two
implementations
that
I've,
like
I,
wanted
to
kick
the
tires
and
see
how
I
don't
know
how
it
would
feel
to
actually
do
these
and
yeah
so
there's
an
example
of
like
one
of
the
tests
right.
So
it's
gated
on
the
option
there,
those
nulls
are
all
filtered
out
and
then
that
test
on
line
496,
that's
a
you
know:
that's
a
convenience
method,
because
Dynamic
tests
don't
support
before
each.
D
We
need
to
reset
the
the
state
of
the
stored
Telemetry
between
tests
and
so
I
just
have
a
wrapper
method
there.
That
does.
C
B
E
D
B
D
What
was
I
gonna
say:
oh
yeah,
so
I
did
do.
If
you
want
to
look
at
like
one
of
the
implementations,
I
did
Google
and
I
did
http
to
no
h,
okay,
hcp2.
D
So
the
Google
The
Google
ones
I
left
the
Legacy
one
in
there
so
that
we
could
just
compare
and
contrast
kind
of
easily
I
I
move
them
into
a
legacy
package.
So
yeah
that
abstract
Google,
HTTP
client
serves
both
the
sync
synchronous
case
and
the
asynchronous
case.
So
there's
already
like
three
levels
of
inheritance
that
are
happening
here
and
that
abstract
one
basically
gets
replaced
by
that.
E
D
D
And
something
you
you
had
on
screen
to
ask
while
I
was
talking
earlier,
is
that
type
adapter?
That's
a
new
interface
that
I
introduced
just
to
that's
the
that's
the
type
SP
like
the
implementation,
specific
interface
of
like
how
to
create
a
request
and
how
to
send
a
request
and
how
to
send
a
request.
Asynchronously.
D
Well,
so
this
is
a
lot
for
people
to
just
like
you
know,
take
in
on
this
call,
but
I
wanted
to
make
sure
that
people
were
aware
of
it.
I'm
still
hacking
on
it,
Mateo
she's
awesome
and
has
already
like,
provided
some
feedback
that
I'm
I'm
looking
at
so
it
seems
it
seems
good,
but
definitely
harsh
on
it,
like
I'm,
also
looking
for
ways
of
improving
it,
but
also
like
ways
that
it
doesn't
work
for
us
if,
like
like
Tyler
mentioned,
if,
like
re-running
failed
tests,
a
lot
in
idea
is
problematic.
G
I
think
that
we're
running
the
individual
tests
doesn't
work
with
cool.
We
either.
E
D
G
It's
maybe
not
the
biggest
issue
yeah.
What
concerns
me
is
like.
Have
you
tried
to
figure
out
how
to
make
our
groovy
tests
also
use
your
new
code.
B
G
To
be
honest,
I
don't
feel
like
I'm,
not
against
having
abstract
classes
that
are
extended,
so
so
I.
In
my
opinion,
the
old
framework
is
probably
also
fine.
C
D
B
G
B
To
the
most
recent
version
of
spec,
not
a
single
one
of
them.
B
Yep,
although
I've
made
some
like
preliminary
investigations
and
I,
think
that
at
least
for
some
HTTP
clients,
it
should
be
possible
to
implement,
but
still
a
lot
of
work.
Though.
C
In
terms
of
like
things
that
bother
me
about
our
tests,
I
would
say
number
one
that
I
run
into
is
groovy
and
then
number
two
is
the
IntelliJ.
You
know
re-running
a
single
test
in
IntelliJ
which,
as
Lori
points
out,
is
tied
to
groovy
I,
don't
actually
know
I,
don't
actually
have
enough.
Java
tests,
I'm
not
familiar
with.
Can
we
rerun
a
single
Java
test?
Do
those
work
yeah.
G
C
G
I,
don't
know
like
like
if,
if
the
test
is
in
the
abstract,
Pace
class,
the
re-running
single
test
might
might
also
be
tricky.
D
G
D
But
like
even
the
okay,
like
the
okay,
HTTP
2
test
and
I,
think
the
Google
is
in
the
same
same
boat
like
on
my
machine.
It
runs
in
10
seconds,
so
it's
not
like
to
run
the
whole
I'm,
calling
it
a
suite,
but
the
client
test
Suite
for
a
given
implementation
is
like
10
seconds.
It's
not.
C
D
That's
a
good,
that's
a
good
point.
I
can
take
that
as
an
action
item
to
figure
out
like
what
the.
If
there's
any
IntelliJ
hints
improvements.
Plugins
that
assist
with
this.
C
Frame
framework
for
cross
language,
testing
of
HTTP
client,
an
HTTP
server,
instrumentation.
C
And
so
you
know
something
that
was
possibly
along
that
lines
where
I
mean
it
provided
more
I,
don't
know
better
control
like,
as
you
say,
right
now,
everything
is
a
little
meshed
together
in
the
the
hierarchy.
So
it
would
be
hard
to
sort
of
break
that
out
and
drive.
Maybe
tests
more
generically,
I
guess
I
guess
maybe
not
for
I.
Guess
that
doesn't
make
doesn't
make
sense
for
HTTP
clients,
or
this
is
more
for
test
I
guess
for
HTTP
server
testing.
Probably
you
could
do
cross
language
yeah.
F
I
mean,
is
there,
is
there?
Is
there
any
better
architecture
around
structuring
code
for
like
sharing
logic,
between
independent
to
separate
tests.
F
How
does
Jun
expect
you
to
do
something
like
that?
I
mean
the
the
method,
inheritance
kind
of
works.
It's
it's
obviously
clunky.
It's
got
its
own
problems
and
but
I
mean
do
they
intend,
for
this
Dynamic
test
is
that
is
that
the
intended
purpose
for
this.
D
Yeah
and
there's
there's
kind
of
two
approaches
that
I
from
what
I
can
tell
there's
kind
of
parameterized
tests
and
there's
Dynamic
tests
parameterized
test.
You
could
imagine
a
single
test
being
parameterized
with
like
every
framework,
but
it's
kind
of
like
inverting
the
responsibilities
there
right
like
right,
yeah.
D
F
I'd
be
scared
to
do
the
one
test
testing
a
dozen
different
Frameworks
because
of
the
class
path
conflicts
that
that
would
entail
yeah.
D
For
sure,
which
is
why
I
think
a
parameterized
test
kind
of
doesn't
work
that
well
for
this?
It
also
hints
at
like
what
I
was
saying
about
there
being
some
sort
of
like
a
like
people
want
I,
think
a
template
where
you
can
just
say:
hey.
There
exists
a
template
here
for
running
junit,
client
or
sorry
HTTP
client
tests,
I
just
want
to
like
bring
that
in,
like
I,
want
to
be
able
to
use
that
here
with
my
customizations
yeah
I,
don't
think
that
exists
in
junit.
D
G
F
I
mean
another
way
that
we
could
potentially
do.
This
would
be
to
do
composition
where
the
implementation
of
the
test
is
in
just
a
generic
class,
and
then
each
test
implementation
has
to
call
that
function
to
actually
do
the
test.
That's.
F
I
see
if
that
makes
sense,
got
it
so
I
guess
that's
how
you
kind
of
work
around
the
the
issue
of
what
I
was
proposing.
If
you
add
a
new
test
method,
you
then
have
to
go
through
each
of
those
test
classes
and
add
that
new
method,
yeah.
D
C
So
Jason,
it
seems
like
there's
kind
of
two
different
things
you're
doing
here
and
I'm
wondering
if
we
could
look
at
them
separately,
one
which
is
just
giving
better
structure
to
even
if
we
keep
the
general
inheritance
from
a
base
class
that
has
all
the
tests
in
it.
We
could
still
have
the
adapters
and
all
that
other
stuff
in
these
subclasses.
That
would
provide
better
structure
and
maybe
would
the
other
thing
is
the
dynamic
test
piece
which
is
about
basically
removing
that
changing
the
assumes
into
Dynamic
yeah.
D
Yeah,
you
know
I
think
that's
fair
and
that's
also
probably
why
we
see
changes
and
stuff
like
that
vertex
and
like
other
under,
like
it
probably
did
inflate
the
size
of
this
factoring
out.
A
couple
of
those
things
was
like
the
first
thing
I
did
before
trying
to
tackle
some
of
this
Dynamic
test
stuff.
So
I.
C
D
Yeah
I
mean
the
two
things
are
definitely
related.
I
I
mean
I
didn't
have
to
factor
out.
An
adapter
I
could
have
just
like
repeated
that
you
know.
I
could
have
repeated
that
same
pattern,
but
it
I
thought
it
made
sense
like
and
we
don't
even
have
that
adapter
interface,
it's
just
some
abstract
methods
on
the
on
the
base
class.
C
D
D
It
would
be,
but
then
they
wouldn't
show
up
as
tests
right
like
we
could
run
them
all
together.
I
think,
like
you,
can
still
have
a
single
entry
point
like
someone
could,
instead
of
gathering
up
a
list
of
dynamic
tests,
you
could
just
this
could
be
restructured
so
that
you
would
call
all
and
then
all
just
invokes
each
of
these
in
turn.
But
then
you
lose
all
of
the
sort
of.
Is
that
not
what
you
were
saying
to
ask?
No.
C
What
I
meant
is
have
each
one
of
these
have
the
test
annotation
on
it?
Okay,
so
it
each
one
of
these
is
a
separate
test
right
and
run
separately
right.
D
D
So,
there's
a
lot
of
similarity
between
the
synchronous
case
and
the
asynchronous
case
and
a
lot
of
these
Frameworks
so
in
the
existing
implementations.
There's
a
common
Base
Class
that
they
also
inherit
from
so
in
my
re-swizzle
of
this
I
tried
to
avoid
that.
So
this
is
like
all
of
the
tests
that
you
want
for
Google,
HTTP,
clients,
synchronous
or
asynchronous
and
there's
you
know
the
creation
setup
stuff,
but
the
main
the
main
method
there's
on
line
55.
It's
the
all
method
that
provides
you
the
list
of
tests.
D
In
this
particular
case,
we
augmented
with
an
additional
test.
So
there's
a
Google
specific
error.
Traces
when
exception
is
not
their
own
test.
D
But
if
then,
we
look
at
the
synchronous
case
right,
so
this
just
creates
one
of
those
and
then
calls
all
so
that
test
Factory
method
online,
test,
Factory
annotation.
This
is
what
drives
it
exactly
yeah.
So
if
we
like
this,
then
that
would
be
the
pattern
that
we'd
use
going
forward
for
this
stuff.
C
Well,
I
think
the
figuring
that
checking
on
the
IntelliJ
Behavior
with
running
a
single
test
is
important.
Cool.
C
And
then
kind
of
it
may
be
just
outlining
the
any
concerns
with
using
Dynamic
tests
from
like
the
before
annotations
before
each
not
working
from
the
perspective
of
like
somebody
coming
to
this
like
this
is
new,
like
this
is
new
magic.
Now
that's
happening
that
might
be
less
familiar
to
people.
E
D
C
You
as
I,
concur
with
mateus's
comment.
You
are
a
brave
soul,
tackling
trying
to
make
more
sense
of
the
HTTP
client,
abstract,
HTTP,
client.
F
I
do
think
that
having
common
tests
for
generic
things
like
HTTP
clients
is
very
valuable,
though
so,
like
it's
definitely
a
helpful
concept
to
have
absolutely.
E
C
Foreign,
oh
yeah,
that
was
one
of
the
things
that
I
when
I
was
first
looking
over
the
datadog
code
base
that
I
gave
a
big
thumbs
up
to
was
you
know
just
having
that
consistency
of
testing
across
all
the
HTTP
clients
and
all
the
HTTP
servers,
so
good
job
Tyler?
Thank
you.
E
H
Know
it's
so
weird
something
weird
was
happening
with
my
zoom
everybody's
there's.
No
there's
no
screen
share
everybody's
face
was
like
there's.
It
was
just
black
screen,
so
I
actually
had
to
restart
my
computer
and
and
I.
Think
I'd
accidentally
gone
into
the
zoom
settings
and
rotated
my
camera
trying
to
fix
it.
C
H
Up
Jack
all
right:
this
was
a
recommendation
or
someone
opened
an
issue
that
we
requesting
that
we
add
service
instance
ID
to
our
default
resource.
I
think
this
is
a
good
idea.
I
think
it's!
You
know,
I!
Think
of
the
the
couple
of
ways
that
you
would
run
a
the
the
Java
SDK.
One
of
the
main
ones
is
with
the
agent
and
the
only
way
or
the
the
most
convenient
way
to
set
a
service
instance
ideas
via
environment
variable.
H
So
you
could
use
the
the
hotel
resource
attributes
environment
variable,
but
it's
hard
to
generate
programmatically
I,
guess
like
like
in
an
environment,
variable
One,
That,
Is
Random,
and
that
will
be
different
for
each
run
of
the
application.
If
you're
running
in
a
kubernetes
environment,
you
can
use
the
downward
API
to
inject
the
the
Pod
uid
and
use
that
as
a
service
instance
ID.
H
But
it's
kind
of
awkward
it'd
be
nice
if
there
was
just
a
unique
ID
that
we
set
as
this
by
default
and
the
spec
here
there's
a
quote
from
the
spec
that
says
that
if
the
service
has
no
inherent
unique
ID
that
can
be
used,
it
is
recommended
to
generate
a
version
one
or
version
four
uuid
and
so
I
guess
what's
ambiguous
about
that
part
in
this
spec?
Is
it's
not
clear
in
exactly
who
should
generate
that
unique
ID?
Should
the
application
owner
generate
it
or
should
the
SDK
generate
it?
H
That's
a
bit
ambiguous
and
I!
Guess:
I
I
guess
I'm
wondering
what
people
think
about
this
I
think
it'd
be
great
to
add
it
to
the
default
resource.
But
if
not
the
default
resource,
maybe
a
a
resource
provider
implementation
with
a
low
priority.
A
F
A
A
Literally,
my
only
concern
is:
are
there
any
potential
metric
cardinality
issues
for
this?
If
people
aren't
currently
including
their
host
name
or
instance,
or
Docker
container
ID
or
whatever
in
their
resource.
C
I
H
It's
not
the
service,
so
it
should
in
it
should
identify
individual
instances
of
the
service,
there's
no
guarantee
that
it's
either
ephemeral
or
you
know,
potentially,
if
you're
using
a
Daemon
set
of
your
service
in
like
a
kubernetes
environment,
it
could
be
persistent
across
restarts.
I
think
that's!
You
know.
I
It
can
be
either
okay,
because
if
we
are
generating
once
every
time
we
restart
well,
that's
there.
The
cardinality
problem
will
explode.
Yes,.
J
Wouldn't
this
be
over
ridden
in
somebody's
case,
if
you're
running
kubernetes
and
you
in
the
collector,
for
example,
you
have
the
kubernetes
plug-in
and
it
might
pick
up
the
the
Pod
name
or
or
something
like
that
and
overwriting
with
it.
So
you
would
make
use
of
it
in
the
case
where
you're
not
adding
it
yourself
and
then
you
would
be
able
to
separate
things
that
wouldn't
be
separate
today,
but
in
in
kubernetes
or
other
deployment
environments
it
might
be
overridden
as
part
of
your
pipeline.
H
The
kubernetes
environment
question
is
actually
a
bit
interesting.
So
if
you're
going
to
use
the
kubernetes
processor
and
The
Collector,
you
actually
need
to
have
some
sort
of
identifier
so
that
the
kubernetes
processor
can
look
up
and
enrich
your
data
with
additional
attributes,
and
so
what
you
actually
have
to
do
to
get
that
to
work.
H
J
H
Yeah
effectively,
so
you
know
whenever
a
resource
is
built,
a
series
of
different
resources
and
sets
of
attributes
are
emerged
in
in
a
layered
approach,
and
so
I
would
effectively
recommend
that
at
one
of
the
like
low
priority
layers,
we
we
add
one
of
these
randomly
generated
service
instance
IDs
such
that,
if
anybody
has
an
opinion
on
what
their
actual
service
instance
ID
is
it's
it's.
It's
really
easy
to
overwrite
it.
The.
D
Okay,
that,
if
that's
all
that
that
means
then
cool,
my
concern
was
just
that,
like
it's
it's
available
sometime
after
we've
already
made
one
up.
E
H
Well,
I
agree
with
John
it's
worth
some
clarification
with
the
spec
I'll
open
an
issue,
call
out
the
ambiguity
and
we
can
go
from
there.
Foreign.
A
Why
I
think
I
think
that
there's
a
little
bit
of
confusion
about
who's
responsible
for
this
thing,
like
I,
think
the
the
semantic
convention
is
like?
This
is
a
thing
and
here's
how
you
can
use
it,
but
I,
don't
think
that
necessarily
says
that
sdks
are
supposed
to
provide
it
because
of
these
exact
reasons
like
some
people
might
want
to
use
something.
That's
the
same
for
every
restart
on
the
same
pod
and
like
inside
the
like
the
container
in
the
Pod
restarts.
You
want
to
reuse
it,
and
some
people
might
want
to
have
something.
A
C
A
A
I
I
think
that's
just
that
was
what
I
was
thinking
thinking.
Sorry
it's
because
if
we
generate
some
uid
that
identified
that
instance,
we
cannot
really
track
it
to
anything.
It's
just
some
instance,
and
we
cannot
correlate
it
with
a
specific
instance
and
go
to
the
actual
kubernetes
cluster
and
see
which
one
was
it.
So
it's
the
data
set
with
it,
it's
kind
of
isolated
and
useless.
So
I,
don't
probably
what
John
was
mentioning
it's
empty.
It's
probably
better.
H
I,
disagree
with
that
I
think
it's
useful
to
be
able
to
differentiate
between
runs
of
an
application,
even
if
those,
even
if
you
can't
tie
that
you
know
which
specific
run.
That
was
knowing
that
you
know
you
you
had
data
coming
from.
You
know,
process
the
first
run
of
the
process
and
then
a
second
run
of
that
process,
I'd,
say
is:
is
valuable
and
I
I
personally
I,
don't
worry
about
that
cardinality
issue!
H
A
Well,
I
think
the
fact
that
smart
people
on
this
call
disagree
about
what
they
want
is
the
default
means
that
we
need
to
take
it
to
the
spec
and
get
some
clarifications.
I'm.
E
B
I
mean
they're
the
detriment
from
having
additional
cardinalities.
Probably
much
more.
You
know
significant
than
any
kind
of
Improvement
you
get
from
that
information.
F
So
I
know
that
datadoc
they
have
something
similar
to
like
similar
to
this
I
think
they
call
it
a
runtime
ID
and
they
use
that
it's
a
randomly
generated,
ID
at
startup,
so
it's
Unique
per
run
and
it's
used
to
correlate
metrics
and
traces.
H
You
know
think
about
the
use
case
of
running
a
deployment
in
kubernetes
and
having
a
deployment
that
has
three
instances
of
your
service
running
and
you
haven't
used
the
environment
variables
to
specify
a
resource
attribute
that
specifies
the
service
instance
ID,
and
so
in
that
case,
all
your
apps
are
going
to
be
collecting
things
like
runtime
metrics,
and
you
won't
have
any
way
to
tell
the
difference
between
those
runtime,
metrics
and
they'll
get
aggregated
together
and
you'll.
Just
have
this
data
that's
effectively
useless
until.
J
Know
you
can
put
that
into
the
to
The
Collector
right
to
have
the
processor
layer
right
you
put
in
sort
of
okay,
I'm
running
in
kubernetes,
take
a
look
at
this
metric
logo
or
Trace
flowing
through
and
and
add
labels
to
it,
and
it
will
do
different
things
right,
I'm,
not
fully
aware
of
all
the
capabilities
are,
but
it
has
different
ways
of
looking
up
and
I.
Think
one
of
the
ways
is
I
think
we
include
like
the
IP
of
where
the
metric
is
coming
from
and
is
using
that.
So
you
can.
F
Oh
hi,
Tyler
I
was
just
gonna
say.
Is
that
the
default
Behavior
or
does
that
require
manual
configuration
or
something
so.
J
It
requires
a
manual
configuration
to
add
the
kubernetes
processor,
but
it's
not
that
much
configuration
to
put
in
there
for
it
to
look
out,
but
you
have
to
sort
of
add
that
process
render.
If
you
don't
do
anything,
it's
just
gonna
flow
through,
so
it
Deborah
I
think.
The
question
here
is
like:
if
I
have
two
services
that
I
run
at
the
same
time
and
I
export
them,
will
they
sort
of
start
colliding
because
we
don't
provide
enough
uniqueness
in
them
right?
It's
the
other
part
here.
H
I
just
want
to
reiterate
that
the
Kate's
attribute
processor
that's
doing
that
enrichment.
It
needs
some
identifier
to
look
up
to
you
know
figure
out
which
deployment
you
know,
which
node
all
the
context
about
where
that
pod,
where
that
container
is
running
I.
H
So
in
that
case
you
have
two
containers
running
in
one
pod
and
you
would
need
to
use
the
downward
API
to
inject
the
Pod
ID
into
the
collector,
that's
running
in
a
container,
and
you
could
use
I
guess
a
static
resource
processor
to
enrich
that
data
in
a
static
way
based
off
that
environment.
Variable.
A
A
J
Yeah,
so
this
was
something
I,
don't
think
about
the
last
week,
because
we
had
a
service.
We
generate
a
little
response
in
jdbc
and
sort
of
just
effective
as
a
sort
of
a
com,
complex,
request
right
and
then
we
we
went
ahead
and
added
a
sort
of
disabled
jdbs
instrumentation
for
the
agent
and
one
thing
I
would
think
of
like
okay
before
it
was
only
traces
by
sort
of
gender
by
generated
by
Aiden,
but
I.
J
Think
now
it's
starting
to
add
some
metrics
in
particularly
around
jdbc
and
a
question
there
that
came
up
and
I.
Think
Tyler
said
that
we
don't
separate
things
today
is
I
would
like
to
see
metrics,
but
maybe
not
spans,
for
example,
or
let's
say
we
had
events
at
some
point
that
you
might
want
to
sort
of
keep
those
flowing,
but
not
spans
and
still
continue,
metrics
or
or
whatnot
right
now.
J
It
feels
it
seems
like
it's,
it's
very
sort
of
or
all
in
one,
and
would
it
make
sense
to
look
at
adding
the
capability
to
be
more
sort
of
explicit
in
what
you
want
to
disable.
Maybe
keep
this
flag
and
say
like
okay:
I,
don't
want
anything
around
gdbc,
but
it's
one
because
it
breaks
something
like
let's
say,
but
maybe
you
could
have
Auto
instrumentation
databc
tracing
enable
false
and
it
will
keep
the
other
ones
sort
of
continue
to
to
be
Auto.
J
B
F
Use
for
metrics
I
I
thought
it
was
something
like
the
Tracer
Tracer
provider,
so
you
could
specify
a
tracer
provider
to
for
a
given
Tracer
name.
Just
return.
A
no
op
span
right.
H
If
that
was
discussed,
it
didn't
make
it
into
the
spec
so
well,
one
thing
that
Samplers
are
I,
guess
the
best
tool
available
to
selectively
record
or
not
record
spans,
but
one
of
their
deficiencies
is
that
you
don't
have
access
to
the
instrumentation
scope
right
now,
and
so
you
can't
author,
a
sampler
that
says:
hey,
you
know,
ignore
spans
or
don't
record
spans
based
on
the
scope.
C
D
J
So
so,
for
me,
in
this
case,
it
is
right.
I
would
like
to
have
the
database
metrics
because
they
are
super
useful,
but
the
number
of
like
individual,
like
I,
don't
really
care
to
see
every
individual
select
spam,
because
if
you
have
this
large
complex
request
like
I
like
in
this
case,
it
was
I.
Remember
how
many
spans
we
ended
up
with,
but
it's
a
long-running
request.
J
H
Well,
it's
it's
there's
kind
of
a
you
know
two
competing
problems
in
my
in
my
head,
so
there's
the
you
know
the
fact
that
the
metrics
SDK
gives
you
a
tool
to
turn
off
metrics
for
a
particular
scope.
Right
now,
that's
views.
That's
great
and
traces,
don't
give
you
an
equivalent
tool.
H
That
seems
like
a
deficiency
that
needs
to
be
solved,
but
then,
if
you
step
back
a
bit,
one
thing
that
I'm
kind
of
running
into
I'm
doing
some
work
in
JFR
right
now
is
that
you
know
I
want
to
turn
off
the
instrumentation
Upstream
of
the
SDK
because
of
the
performance
implications
of
the
instrumentation
itself,
and
so
you
know
do
you
want
to
like
you
know,
instrumenting,
something
is
not
free.
H
Having
the
ability
to
turn
off
instrumentation,
were
you
know
or
duplicating
a
responsibility
that
should
probably
live
in
the
SDK.
D
H
F
F
I
actually
wasn't
crazy
in
the
the
open
Telemetry
SDK,
there
is
a
tracer
provider
interface
and
it
takes
a
git
method
and
returns
a
tracer
and
I
I.
Don't
know
if
it's
the
SDK
supports
this
currently,
but
when,
when
I
believe
when
it,
this
API
was
originally
designed.
F
The
intention
was
specifically
this
case,
where
you
could,
as
a
user
potentially
provide
a
custom
Tracer
provider,
you
could
register
a
tracer
provider
such
that
for
a
given
instrumentation
name
or
a
tracer
name
that
you
could
just
have.
It
return
a
no
op
instead
and
use
that
as
a
way
to
disable
a
specific
span
from
being
generated.
F
H
You
could
bring.
You
could
provide
your
own
implementation
of
the
trace
API.
That
selectively,
you
know,
returned
either
the
the
open,
Telemetry
Trace
SDK
or
your
own
SDK
version
of
a
tracer
for
for
different
Scopes,
but
there's
nothing
built
in
that
will
do
that
automatically.
For
you
also.
C
Yeah
and
Jack
mentioned
earlier,
but
it's
worth
where
is
it
sampler
discrimination
name
is
probably
before
we
renamed
it.
A
Well,
that
was
a
that
thing
is
still
open.
I,
that's
like
two
years
old
now,
isn't
it
I.
C
Know
yeah
I'm
coming
up
on
it,
which
would
allow
you
to
essentially
do
Tyler
what
you're
saying,
but
at
the
sampler
level,
where
that
instrumentation
scope
name
is
the
same
thing
you
pass
into
the
Tracer
provider,
but
I
wanna
before
we
run
out
of
time,
I
want
to
Circle
back
to
Stefan.
J
So
this
would
be
so.
Okay
now
I
need
to
go
in
and
really
integrate
sort
of
the
application
even
more
with
open
diameter
I
did
it
sort
of
we
get
so
much
for
free
by
just
using
all
the
instrumentation
and
that's
I
think
that's
where
these
environment
variables
are
being
picked
up
right,
and
so
it's
more
of
like
okay
in
order
to
instrumentation,
would
it
make
sense
to
to
like
expand
the
configuration
options
for
that
one
right?
It's
and.
E
J
C
So,
very
briefly,
if
you're
using
the
Java
agent
check
out
this
issue
explains
because
generally
we
get
the
question
of
how
to
exclude
health
checks,
but
you're
kind
of
in
the
similar
situation
of
excluding
jdbc
calls,
and
you
can
see
it's
our
most
popular
issue
and
so
Jack
actually
put
together
a
nice
example
recently
of
how
to
do
this
using
rule-based
sampler
to
drop
things.
So
you
could
use
that
to
drop
jdbc
calls
spans
and
long-term.
C
Once
we
get
the
yaml
based
configuration
that
the
configuration
working
group
hotel's
configuration
working
group
is
working
on.
Currently
we
want
to
provide
a
yaml
based
way
to
configure
those
the
Samplers
in
the
Java
agent,
which
would
then
allow
you
to
say
hey.
If
my
DB
system
is
postgres,
then
drop
that
span
kind
of
a
thing.
H
Was
just
thinking
out
loud
I
should
probably
make
an
issue
about
this.
You
know
exponential
histograms
are
stable.
That's
great,
there's
a
number
of
changes
that
need
to
be
made
to
decode
so
that
they're,
they're,
really
usable,
and
so
this
this
just
lists
them
out.
It
would
be
good
if
these
are
kind
of
sequential
steps.
They
can't
be
really
done
in
parallel
for
the
most
part.
So
if
we
want
to
get
that
out
for
the
next
release,
you
know
we'd
it'd
be
good
to
get
reviews
and
start
merging.