►
From YouTube: 2020-09-17 Java Auto-Instrumentation 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
It
got
worse
again
yesterday
it
was
I
celebrated
too
early.
I
like
yesterday,
I
think.
Yesterday
morning
I
went
outside
and
I
could
actually
like.
The
the
fresh
air
like
getting
fresh
air
almost
outweighed
the
the
tinge
of
smoke
in
the
air,
but
then
it
got
worse.
B
C
A
C
B
A
Yeah
sorry
jason
to
hear
that
john
abandoned
you.
A
A
A
A
C
D
A
A
Let's
see
we
are,
I
think
this
one
this
one
just
kept
on.
Why
is
this
p1.
D
Though,
because
it
it
like
constantly
keeps
failing,
if
I'm
not
me
and
well,
it's
currently,
I
believe
one
of
our
top
failures.
It
actually
fails
our
build
not
just
making.
A
Was
it
revisited,
oh
yeah,
so
I
think
we
got
all.
Oh
did
that
oh
yeah!
No,
we
closed
that
related
one,
but
nikita
this
this
one.
We
should
probably
close
two
right
in
favor
of
yeah.
A
A
A
Well,
I
guess
that
the
only
sort
of
new
module
breakout
is
relatively
new
is
so
we
have
an
instrumentation
api
module,
which
is
things
that
this
these
are
like,
our
reusable
tracers
base
class
tracers
that
are
used
both
by
library,
instrumentation
and
java
agent,
instrumentation,
and
then,
additionally,
we
have
an
api
for
java
agent
instrumentation.
That
includes
stuff
like
bite,
body
matching
and
some
utilities
that
are
only
needed
by
auto
instrumentation
and
then
unrock
broke
this
out
already.
A
Yeah
yeah
that
was
merged
already,
which
is
a
separate
module
to
contain
sort
of
customization
points
for
people
building
their
own
java
agent
distributions.
A
So
if
you
want
to
plug
in
your
own
sampler
your
own
exporter,
things
like
that,
and
then
these
are
the
exporters
that
we've
shaded
and
have
the
configuration
sort
of
adapter
for
the
java
agent.
A
D
A
A
Right
right,
okay,
cool!
I
will
update
that
and
then
we've
got
a
couple
internal
components
of
the
java
agent.
These
this
is
things
which
need
to
live
in
the
bootstrap
class
loader,
which.
A
And
also
the
the
pre-main
class
also
lives
here,
even
though
it
lives
in
the
system.
Class,
loader
and
tooling
is
everything
that
we
load
inside
of
that
agent
class
loader,
where
everything
really
is
hidden,
except
things
that
are
needed
in
the
bootstrap
class
loader
for
instrumentation
to
be
able
to
communicate
over
to
the
bridge
over
to
the
agent
class
loader.
A
Let's
see
what
else
we
got
metric
exports
fails:
okay,
so
okay
cool,
so
it
sounds
like
we
don't
have.
Maybe
a
we
need
a
smoke
test
for
metric
exporting.
A
Bridging
correlation
context
so
correlation
context.
This
is
the
baggage
stuff,
john.
B
A
Yeah,
so
when
we,
when
we
implemented
our
bridge
from
the
our
interop
story,
instrumentation
instrumenting
the
open,
telemetry
api
itself.
A
On
duplicate
telemetry,
oh
yeah,
so
now
that
we
have
some
library
modules
and
we
just
have
a
few
but,
for
example
like
aws,
if
somebody
is
using
the
our
aws
library
instrumentation,
and
then
they
also
use
the
java
agent,
we
want
to
prevent
duplicate
capture
currently
we'll
capture
it
everything
twice
both
from
the
library
instrumentation
and
from
the
auto
instrumentation.
A
You
could
suppress
the
auto
instrumentation,
but
better
part
of
a
very
early
discussion
with
the
in
open
telemetry
when
we
were
kicking
off
the
auto
instrumentation.
Was
this
idea
of
by
doing
the
auto
instrumentation
as
part
of
open
telemetry,
that
we
could
have
a
nice
story
of
interop
and
and
not
capture
duplicates
in
this
case.
A
Licensing,
I
just
need
to
I've
been
kind
of
tracking
a
few
cases,
and
I
just
I
want
to
reach
out
probably
to
the
cncf
to
review
just
because
it's
a
little
bit
different
than
libraries,
where,
because
we're
actually
embedding
that
code
inside
of
our
agent
distribution
versus
having
a
transitive
dependency
to
it.
A
So
we
don't
pull
in
the
class
the
code
that
we
instrument
the
libraries
that
we
instrument.
We
don't
pull
those
in
the
that
those
classes.
C
There's
a
list
of
licenses
in
that
issue,
john.
A
So
these
are
the
dependencies
I
had
pulled
out
so
like
guava
grpc
context,
which
will
go
away,
bite,
buddy,
slf
for
jay
and
then
in
the
all.
We
have
some
additional
things
because
of
the
exporters,
a
lot
of
grpc,
okay,
http
protobuf,
zipkin.
A
So
nothing
viral
in
these,
so
I'm
not
too
worried
like
that.
It's
I
think
we
just
need
to
it's
more
a
matter
of
making
sure
our
we're
at
trip
attributing
attributing
those
correctly
got
it
yep.
B
D
D
A
D
A
But
why
yeah?
Maybe
this
was
when
we
thought
that
we
were.
We
were
more
ambitious
about
library,
instrumentation,.
A
A
Okay,
github
is
not
that's
fine.
D
Okay:
okay,
that's
interesting,
because
we
have
the
problem
in
in
one
of
our
clients
with
vertex
as
well,
but
anyway.
First
I
don't
think
that
p1
is
probably
p
p2.
We
can't
live
with
that,
I
think,
but
in
general
I
would
very
like
I
would
very
much
like
to
talk
a
little
bit
about
all
our
reactive
native
vertexes
and
whatnot
story,
because
there
are
a
lot
of
problems
there
yeah.
I
will
probably
write
a
little
something
if
you
want
okay.
A
Cool,
we
will
come
back
to
that,
but
I
agree
this
because
we
did
some
work
to
at
least
sort
of
around
what
our
current
leaking
scope
leaking
story
is,
and
I
feel
like,
even
if
we
do
leak
scope,
we
have
a
good
sort
of
backup
plan
of
we
reset
the
scope
at
the
beginning
of
each
request.
A
Naming
conventions
has
there
been
any
specification
discussion
around
sort
of
naming
conventions
for
custom
attributes.
A
Okay,
now
do
we
once
we
go
ga,
do
we
feel
comfortable
that
we
can
still
basically
muck
around
with
the
semantic
like
improve
the
semantic
attribute
capture,
or
do
we
feel
like
we
need
to
have
those
locked
down.
D
B
Yeah,
this
is
a
good
question
and
I
it
so
just
to
also
put
up
a
little
twist
on
this
there's
been
a
a
there
is
a
proposal
pending,
I
think,
not
written
up
yet
to
move
all
the
semantic
attributes
to
a
separate
module
so
that
it
was
an
independent,
the
semantic.
The
definition
of
all
the
semantic
conventions
was
independent
of
the
api
itself.
A
Well,
I
agree
with
nikita
about
the
the
cement,
so
I
think
these
ones-
I
think
this
is
this
issue-
is
more
about
things
that
are
not
in
the
semantic
conventions.
D
B
A
D
D
So
I
want
to
say
they
should
not
be
the
part
of
public
api
that
we
like
guarantee,
but
end
users
and
back
end
can
start
depend
upon
them,
starting
from
g8.
B
D
B
I
wonder
if
the
other
auto
instrumentation,
like
javascript
or
python,
are
running
into
this
as
well
might
be
worth
reaching
out
and
seeing,
if,
like
in
maintainer,
the
maintainers
meeting
on
monday.
D
A
Benchmark,
oh
this
one's
assigned
to
me.
Look
at
that.
A
So
onorag
I
mean,
has
a
vendor
distribution
out
in
the
wild
I
do
but
mine
is
mine
is
I
I
had
to
fork.
I
I
I
haven't
yeah.
D
And
so
we
still
have
a
lot
of
open
query
questions
like
overwrite
existing
existing
instrumentation.
That's
totally
unsupported.
A
Yeah,
even
adding
new
instrumentation
is
not
until
we
start
publishing
the
the
new
instrumentation
apis
and
trying
that
out,
yeah
yeah,
okay,
cool
leaving
that.
D
A
A
A
We
don't,
oh,
we
don't
have
a
fight,
we
don't
really.
Maybe
we
support
the
file
and
I
haven't
even.
A
We
dock
this.
We
don't
talk.
D
This,
I'm
not
sure
I
want
to
dock
some
of
these.
Maybe
not
I'm,
I'm
not
saying
that
we
have
to
document
everything,
but
I
re
I
do
want
to
review
and
to
say
yes,
we
have
documented
everything
that
we
want
to
be
documented.
D
A
Okay,
is
that
a
p1,
though
I
mean,
because
if
somebody
comes
along
and
asks
for
a
feature
later,
we
can
always
document.
A
A
All
right,
let's
see,
if
github
it's
still
pulling
in
my
p3
here,
hey
we're
down
so
then
we're
down
to
nine.
Then.
E
A
That
so
three
dropped
to
p1
during
this
meeting.
C
A
Yeah
and
then
I
think,
once
once
we
do
this,
then
I
would
be
comfortable
starting
to
push
to
maven
central
we've.
Just
we've
changed
our
group
id
artifact
ids
like
a
hundred
times
so
far,
and
I
didn't
want
to
create
a
massive
mess
over
in
maven
central.
F
Yeah,
I
was
just
wondering
we're
here,
I'd
like
to
step
discussing
whether
it
should
could
be
possible
to
support
this
scenario
where
sometimes
customers,
users
want
to
use
only
metrics
or
only
tracing.
For
example.
The
case
came
because,
with
the
latest
version,
the
otlp
metric
exporter
is
enabled
by
default,
so
probably
like,
for
example,
we
won't
use
it
for
for
some
time
at
least
yeah.
So
I
don't
know
if
there's
any
kind
of
support
going
through
the
readme.
There
was
nothing,
but
you
guys
know
better
either.
F
Right
so
in
that
case,
probably
we
can
put
sergey
to
spend
some
cycles
and
consider
what
options
we
could
do.
Probably
disable
provide
no
op
implementation
or
I
don't
know.
A
So
I
think
this
would
be.
We
can
follow
the
new
spec
now
hotel
exporter.
A
Could
so
hotel
exporter?
So
we
we're
not
following
this
yet,
but
if
we
followed
this
then
the
default
is
otlp.
But
if
you
specified
otlp
span,
then
that
would
give
you
only
the
span.
Exporter.
F
A
So
yeah
that
would
be
great
to
to
you
know,
to
follow
that
update
to
use
this.
F
Okay,
great
good
to
know
okay,
so
yeah,
so
maybe
a
ticket
needs
to
be
created
for
updating
this
and
depending
on
your
time,
as
I
said,
probably
sergey
can
help
with
that.
A
Okay,
cool
yeah:
I
can
create
an
issue
and
ping
sergey.
A
All
right,
let's,
let's
reprioritize
nikita
john.
B
D
B
I
believe
the
upshot
of
it
is
that
dynatrace
is
no
longer
going
to
stand
in
the
way
of
moving
to
java
8..
They
do
not
want,
since
they
are
the
only
group
that
is
interested
in
java
7.
They
do
not
want
to
maintain
a
public
fork
for
everybody,
so
if
they
do
support
java
7,
they
will
do
it
in
private,
secretly,
okay,
but
I
think
it's
very
very
hard
to
get
a
straight
answer
out
of
anybody,
but
I
believe
at
this
point,
they're
not
going
to
stand
in
the
way
if
we
move
to
job
8.
A
B
Which
means
that
my
putting
in
that
very
inflammatory
issue
on
purpose
yesterday
has
served
its
purpose.
B
A
Yeah
yeah,
so
that's
what
I
got
from
this
also
that
that
yeah
they'll
cool
yeah.
I
think
I
think,
because
the
problem
is,
if
we
don't
do
it
before
ga,
then
we're
we
can't
do
it
until
2-0
and.
B
A
Anyway,
we
can't
we're
kind
of
locked
into
the
api
and
can't
take
advantage
of
any
java
8
default
method,
static
methods
met
static
methods
on
interfaces
java
classes
java
time.
All
of
that.
B
All
of
that
good
stuff,
exactly
so,
I
think
it
sounds
like
we're
good
to
go,
which
is
exciting.
What
is
the
date?
I
may
try
to
get
this
done
by
09,
but
does.
B
Both
api
and
sdk
yay-
I
know
it's
glorious.
I
think,
there's
still
outstanding
questions
about
android,
although
since
we
still
have
no
android
interest
at
all
from
anyone
any
vendor
or
anyone
in
the
community,
it's
hard
to
justify
doing
a
whole
lot
of
extra
work
to
bend
over
backward
for
android
at
this
point.
G
I
mean
until
we
actually
adopt
the
java
8
features.
My
suggestion
is,
you
know
we
just
changed
the
the
build
the
compiled
version
see
if
anyone
complains-
and
you
know
it's
not
a
breaking
change-
to
go
backwards
as
long
as
we're
not
using
those
on
public
using
those
specific
classes
right.
B
A
B
Methods
on
them
I
agree,
but
you're
right.
The
first
step
is
to
just
change
the
build
and
then
maybe
so,
maybe
for
nine,
we'll
just
change
the
build
and
then
for
ten
we'll
start
thinking
about
using
actually
using
java
8
features.
D
A
Yep
go
for
it,
especially
I
mean
yeah,
especially
now,
but
already
we
had.
We
had
made
that
decision
already,
but
we
were
kind
of
I
was
kind
of
dragging
my
feet
on
it,
hoping
that
we
could
get
it
also
in
the
api,
sdk
and
then
yeah
that
further
justifies
our
our
dropping.
It.
E
A
D
D
And-
and
I
I'm
still
struggling
with
that
bug
which,
when
you
use,
react
when
you
use
sprint
web
flux,
reactor
sprint,
web
flux,
reactive
web
client,
which
uses
reactor
m80,
which
breaks
our
net
instrumentation
under
the
hood,
and
I
spent
like
two
or
three
days
trying
to
understand
how
reactor
native
works
and
how
to
pass
context
here
and
there
and
I
couldn't
it's
such
cluster.
Mess
of,
I
think
I
assumed
mono
mono,
create
monofilament
callback.
A
This
much
mono.
D
D
D
D
C
Sorry
to
jump
in,
I
think
that
we
also
have
that
same
that
same
challenge
in
our
agent
and
we
get
reports
on
stuff
all
the
time,
and
I
think
your
suggestion
is
very
smart.
D
I
I
talked
to
I
I
talked
to
when
I
talked
to
martian
about
web
client
box
march.
What
was
his
name.
D
D
C
That
makes
me
that
makes
me
happy.
I
mean
I
I
like
to
hear
this,
if,
if
I'm
optimistic
and
there's
some,
I'm
optimistic
that
there's
some
traction
and
that
we
can
help
move
this
forward
to
being
in
the
original
implementation,
like
at
least
some
sort
of
help
from
them
would
yeah
that's
good.
Thank.
A
A
B
A
You
have
a
do.
You
have.
B
A
C
A
Can
you
add,
is
that
something
you
could
add
to
our
yes
project?
Okay,
awesome
yeah,
I'd
like
to
just
take
a
look
to
also
kind
of
understand
the
the
corner
cases.
D
D
E
D
G
D
D
A
B
B
B
D
D
We
still
need
support
from
framework
authors
to
at
least
give
us
those
that
that
point
because
project
reactor,
for
example,
they
do
have
their
own
context,
so
we
could
just
use
okay.
If
we
working
with
project
reactor,
then
our
context
as
a
storage
will
use
that
the
problem
is
that
project
reactor
context
is
is
very
inconsistent,
which
api
methods
do
have
that
and
which
method
doesn't
have
that.
A
And
if
it
did,
if
it
did,
because
I
wonder
if
we
need
like
if
for
frameworks
that
do
have
good
context,
propagation
support,
we
tend
to
be
able
to
plug
into
those
instrument.
Those
yeah,
so
that's
kind
of
similar
to
like
kotlin
co
routines
has
a
nice
context,
propagation
mechanism
yeah,
whereas
some
some
don't,
and
so
I'm
not
sure,
if
kind
of
plugging
into
reusing
that
versus
just
instrumenting
those
using
those
instrumentation
points.
I
think
we
could
do
it
automatically
if
they
existed
and
were
used.
D
Yes,
so
what
I
think,
what
is
my
main
point
of
this
whole
discussion
is
that,
at
least
in
case
of
those
I
think
framework,
we
certainly
have
I,
in
my
opinion,
to
move
battle
to
them.
Ask
them
for
make
make
that
integration,
because
your
framework
is
too
bloody
complicated.
Nobody
understands
that
you
just
doesn't
make
it
easy
for
us.
You
don't
propagate
context.
D
B
I've
got
a
so
here's
a
q,
here's
just
this
purely
hypothetical
question.
What,
if
marching
in
this-
and
you
know
the
reactor
folks
and
whoever
is
like?
Oh
well,
we
know
we're
not
going
to
change
all
of
our
apis.
Make
that
easy,
but
we'll
start
embedding
instrumentation
in
our
code
and
do
it
ourselves.
B
B
A
B
A
Yeah,
it's
a
pretty
tough
battle
to
get
a
get
those
frameworks
to
adopt
something
like
that,
even
internally
in
azure,
all
the
azure
sdks.
A
Our
our
path
forward
is
open
telemetry,
but
they
have
implemented
basically
a
tracing
shim.
That
then
has
a
has
a
service
spi
and
it
loads,
something
that
then
delegates
to
open
telemetry
because
the
they
don't
want
any
kind
of
hard
dependency
on
on
anything.
D
A
That
I
think
it's
great
to
that-
I
really
you
know,
chat
talking
to
them
and
and
because
this
does
seem
a
very
particular
problem
problem,
particularly
problematic
for
us,
the
reactive
stuff.
A
We
will
keep
checking
in
with
you
on
that
thanks
three
three
minutes
for
weekly
digest
rest
easy
4.0.
We
have
a.
I
think
it
was
just
tests
to
prove
that
it
works,
but
that
was
significant
work.
A
We
have
support
now
for
injecting
resources
into
class
loaders,
which
is
cool,
so
we
had
originally,
I
mean
we
we've
always
injected
classes
into
class,
loaders
sort
of
helper
classes
that
the
instrumentation
needs
to
use,
but
now
we
can
also
inject
resources,
which
means
we
can
hook
into
existing
libraries
spi
hooks
and
provide
our
own
spi
implementations,
which
is
opens
up
new
doors
to
instrumentation,
as
opposed
to
bytecode
instrumentation
jack's
rs,
a
couple
of
just
supporting
some
new
features
into
one:
the
project
reactor
instrumentation
that
nikita
so
bravely
tackled
redacting
lettuce.
A
This
was
a
rashmi
contributed.
We
were
capturing
the
auth
password
in
lettuce
connections,
onrag.
I
contributed
the
initial
aws
lambda
instrumentation,
which
is
going
to
be
really
interesting
to
see
how
that
all
plays
out
because
of
the
two
two
factors
there.
One
is
the
overhead
in
basically
the
on-demand
plans,
like
so
in
the
plans
where
there's
dedicated
instances.
This
is
not
an
issue
because
those
just
keep
running
and
you
can
instrument
them.
You
know
we
instrument
the
startup.
A
We
we
take
that
startup
hit
and
then
it
keeps
running,
but
for
the
on-demand,
where
you
know
just
a
single
request
comes
in
and
it's
got
to
spin
up
a
vm
and
it's
gotta
make
that
request
and
we've
gotta
do
the
bytecode
instrumentation
we've
got
startup
overhead
and
the
other
issue.
There
is
at
the
end
of
the
request:
they
freeze
the
vm
and
so
the
the
telemetry
never
gets
sent
out
from
the
box,
and
so
he
added
in
a
in
a
follow-up
pr.
A
He
added
something
that
on
lambda
will
force
flesh
at
the
end
of
the
request,
which
you
know
again
adds
overhead.
So
still
a
lot
to
be
figured
out
here,
but
they
wanted
to
move
forward
just
to
get
something
that
at
least
worked
and
then
they
can
mess
around
with
performance
internally
updated
to
the
latest
sdk
snapshot.
So
this
brought
in
the
big
changes
john's
big
big
changes
around
converting
trace
id
span
id
to
strings
and
the
trace
flags
to
just
that
sampled,
boolean
and
so
in
our
world.
A
What
that
means
is
we
don't
have
to
bi-directional
sync,
these
little
objects
back
and
forth
if
somebody
is
using
open,
telemetry
api
manually,
so
that's
awesome,
anurag
brought
in
nolaway,
so
I
I
also
have
this
preference
over.
We
were
discussing
optional
versus
nullable
annotations
and
at
least
in
non-public
apis.
A
I,
like
I,
like
nullable.
I've
used
the
null
checkers
for
a
long
time,
honorable
likes
no
away,
which
does
seem
easier
than
the
one
that
I'm
familiar
with
that
I've
used,
which
is
checker
framework.
So
that's
there.
We
can
start
using
that.
Reviewing
oh
yeah
nikita
went
through
the
all
the
http
server
semantics
bands
and
made
sure
that
we
were
following
those
correctly
and
removed
some
extra
things
that
weren't
that
we
were
capturing
that
weren't
part
of
that
these
semantic
conventions.
A
And
then
we
had
some
broken
log
back
instrumentation
because
of
shading
problems,
because
log
back
instrumentation
was
using
sl
logback
uses
slf4j
and
we
shade
slf
for
jay
and
our
java
agent.
So
we
were
ending
up
shading
the
instrumentation
itself,
so
it
wouldn't
get
applied
to
the
users
to
the
user's
library,
and
so
that's
one
area,
any
kind
of
shading
problems.
We
currently
don't
catch.
A
Our
tests,
don't
catch
those,
but
our
smoke
tests
would
so
we
have
an
issue
to
to
create
a
log
back
smoke
test
since
that's
going
to
be
a
particularly
sensitive
area
to
shading.
Since
we
shade
slf
for
j
internally.