►
From YouTube: 2020-09-10 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).
B
I
want
to
say
tuesday,
which
of
course
knocked
out
the
knocked
out,
all
the
routers
and
internet
and
stuff
for
about
a
minute
for
everything
to
reboot.
B
A
A
Well,
the
problem
is
it's:
the
the
winds
are
blowing
from
the
east
right
now,
so
that
it's
blowing
all
the
the
wildfires
into
the.
A
D
A
I
was
just
noticing
the
the
haircut,
which
basically
nobody
around
here,
gets
anymore
or
does
it
themselves
and
it
comes
out
all.
A
No,
I
did
I
did
I
spent
I
spent
like
half
an
hour
working
on
this
this
weekend,
because
it
had.
I
hadn't,
touched
it
since
the
pandemic
started,
and
it
was
starting
to
look
a
little
a
little.
C
C
You
you've
got
a
opportunity
for
being
santa
claus
in
a
mall
this
year.
A
I've
got
yeah
that
that
could
be
my
future
career.
My
guest
got.
B
C
C
D
A
Hit
or
miss
it's
it's
hit
or
miss.
I
don't
remember
very
many
halloweens
that
it
were
really
like
really
rained
out.
I
mean
definitely
like.
A
A
Probably
need
to
take
a
nikita
at
some
point,
we'll
probably
take
another
hard
look
at
all
of
those.
D
A
Make
sense:
oh
yeah,
I
fixed
the
this.
If
you
go
to
this
link
yeah,
I'm
not
sure
I
fixed
this
link
to
also
add
the
label
required
for
ga
or.
D
A
To
make
some
sense
to
have
some
prioritization
of
things
after
ga
also,
although
potentially
potentially
it's
the
same
list,
though
of
things
that
we
didn't
get
to,
that
were
required
for
ga.
A
Okay,
sergey
kick
us
off.
F
C
So
I
have
opinions
about
this
and
my
main
opinion
is
by
default.
We
should
try
to
keep
our
logging
as
minimal
as
possible.
F
D
But
there
is
also
trace
yeah
trace
yeah,
so
I
I'm
totally
okay,
with
moving
some
of
the
debug
to
trace
and
and
having
like
option
to
say,
do
I
want
debug
or
trade
because
yeah
I
oftentimes
want
to
see
debug,
but
at
least
half
or
three
quarters
of
that
debug
is
true
they're
both
for
me.
I
don't
want
that.
F
Yeah
so,
for
example,
in
the
debug
I
see
so
much
stacked
races
looks
like
oh
exceptions,
it's
errors,
but
it
works.
Fine.
Yes,.
A
When
grpc
context
starts
up
it
logs
a
stack
trace
at
the
bug
level
that
it
didn't
find
that
storage
override
yeah
that's
one
time,
yeah
yeah,
that's
the
only
one
that
I've
seen.
D
A
Which
is
a
which
is
also
sergey?
Have
you
noticed
how
much
of
that
debug
is
coming
from
the
instrumentation
versus
coming
from
the
sdk,
because
that
that
level
controls
the
sdk
logging.
F
A
A
Yeah
moving,
it
certainly
makes
sense
to
move
stuff
to
trace.
That
seems
like
a
normal
way
to
go
about
the
info
logging
moving
it
up
to
info.
A
I
tend
to
think
of
info
as
like,
like
a
startup
kind
of
like
info
about
the
system,
but
I
could
also
be
I
mean
that's
that
sort
of
limits.
What
info
would
be
useful
for.
C
C
Like,
for
example,
general
policy,
maybe
along
the
lines
of
start,
only
startup
should
be
logged,
only
startup
stuff
should
be
logged
at
at
info
and.
C
You
should
be
very,
very
careful
about
that.
C
Yeah
is
support
for
the
trace
log
level
limited
at
all.
Are
there
any
any
implementations
that
don't
support
trace.
A
A
A
But
I
don't
think
we
have
to
worry
about
that,
because
we're
not
bridging
to
our
internal
logging
to
to
that.
G
Hey
hey,
how
are
you,
how
are
you
guys
doing?
Thank
you
yeah,
so
I
we
were
doing
some
triaging
at
the
specification
level.
There
there's
too
many
items,
and
we
were
wondering
andrew
and
me
yesterday
about
how
important
for
the
instrumentation
is
specifying
all
of
these
environment
variables
how
important
this
is
for
you
guys.
G
What
do
you
mean
important
like,
for
example,
let's
say
propagators,
auto
propagators,
there's
an
issue
for
that,
but
there's
there's
no
pr!
So
do
you
think
we
need
these
for
ga
or
let
me
rephrase
that
and
say:
do
you
think
it
could
be
fatal
in
some
way
that
ga
appears
without
this,
like
in
the
specification,
because.
D
D
A
I
mean,
if
should
we
do
the
famous
x
dash,
if
it's
not
part
of
the
spec,
to
make
just
in
case
the
spec
changes
the
what
that
means.
A
Right
what
if
the
spec
decides
that
this
to
do
this,
but
it
has
that
it
defines
a
different
like
instead
of
comma
delimited.
It
wants.
A
So
I
guess
I
mean
carlos.
It
would
be
nice
this
one
in
particular
the
log
level
we
don't
care
about
for
now,
or
it's
not
is
definitely
not
critical,
but
the
hotel
propagators
would
be
nice
if
possible,
just
so
that
you
know
we're
aligned,
we
don't
run
into
problems
later
of
it
being
defined
differently
than
how
we're
we've
defined.
It.
G
G
Perfect
yeah
yeah:
let's
do
that.
I
think
it's
relatively
straightforward,
so
at
least
initially.
A
Yeah
I
mean
we
could
basically
just
copy
paste
what
what
we
wrote
here
as
far
as
you
know
what
it,
the
definition.
G
G
D
G
A
We're
using
that,
but
does
that,
would
that
be
done
in
the
like?
I'm
assuming
the
the
propagator
would
be
something
that
would
be
done
in
the
sd
moved
essentially
to
the
sdk
right.
A
C
G
A
And
nikita,
do
you
remember
the
exporter?
There
was
some
discussion
about
exporter.
D
D
And
can
they
maybe
maybe
important
to
have
inspect.
G
G
A
Cool
yeah,
so
I'll
follow
up
with
you,
carlos
and
figure
out
how
to
get
that
rolling.
I
I
I
owe
the
spec
repo
a
pr
one
of
these
days,
so
nice.
B
Yeah
so
as
the
line
says,
I
thought
that
underag
had
put
in
backwards
compatibility
on
the
changes
to
the
exporter
sbi
packaging
because
you've,
all
of
you
all,
changed
it
to
be
dependent
on
packages
inside
the
agent
distribution
or
inside
the
the
agent
code
base
instrumentation
code
base.
But
it
is
not
working.
B
Yeah,
there's
also
there's
a
note
in
here
somewhere.
I
don't
remember
where
it
was
that
it
was
going
to
continue
to
work.
The
old
one
will
continue
to
work.
Where
do
we
see
that.
B
Here
all
right-
because
I
had
talked
about-
I
had
talked
about
this
on
last
week
and
you
all
agreed
that
it
was
gonna
stay
there,
because
this
makes
me
have
to
completely
rewrite
our
exporter,
which
sucks.
So
I
got
to
figure
that
out
how
to
do
this
now,
even
figuring
out.
I
have
to
figure
out
how
to
get
a
different
dependency,
that's
only
published
on
on
bin
tray.
B
So
anyway,
I
thought
this
was
going
to
be
backward
compatible
because
honorarong
told
me
it
was.
A
B
B
B
Okay,
so
anyway
that's
a
bummer,
and
especially
since
we
didn't
really
get
any
heads
up
until
honorable
pr
that
was
basically
deleting
it
and
saying
it
was
no
longer
the
work
gonna
work,
so
some
earlier
would
be
super
super
helpful
in
the
future.
A
B
Yeah,
just
some
heads
up
would
be
useful
because
it
was,
it
was
very
unexpected.
A
How
would
you
what
would
be
the
right
venue
I
mean
because
normally
we
would
you
know
dock
it
in
the
in
the
release.
Notes
or
you
know,
I
mean
if
you're
following
the
pr's,
but
that's
a
lot
of
effort
to
follow
the
prs.
B
Just
so
that
there
I
would
be
able
to
figure
out
a
plan
for
that.
So.
A
A
E
B
E
B
Say
you
have
to
that,
you
add
what
you
had.
Basically,
what
is
written
here.
D
A
Cool
yeah,
because
it
the
gradle,
has
that
known
j
center,
alias.
D
D
A
D
B
Well,
I
copied
it
out
of
the
the
I
copied.
The
bin
tray
coordinates
directly
out
of
bin
tray
like
out
of
what
it
says
to
use.
Okay,
it
wasn't
it's
still
not
working.
B
A
A
Yeah
so
in
this
one
I
do
see
the
exporter
config.class
and
then
that
the
span
exporter
factory,
that
you
need.
D
B
B
As
long
as
it's
documented
well
like
where
the
packaging
is
it's
all
fine
so
anyway
and
maven
central
is
a
huge
pain.
I'm
well
aware,
having
had
to
publish
many
things
there,
it's
not
fun
to
interact
with.
A
B
E
A
I
will
open
an
issue
for
that,
at
least
to
track
yeah,
and
we
do
yeah,
so
the
maven
central,
the
we
haven't
been
pushing.
We
actually
have,
I
think,
the
pipeline,
because
the
you
all
set
that
up
in
the
sdk.
A
A
Right
yeah
that
artifact
may
mean
oh.
D
D
I
actually
wanted
to
talk
about
that
to
tyler
who
just
left
okay,
but
what
I
wanted
to
talk
about
is
so.
I
have
submitted
a
pull
request,
which
saw
several
bugs
in
our
react
project
director,
instrumentation
and
the
main
change.
The
essence
of
the
change
is
that
our
instrumentation
captured
context
during
pipeline
assembly.
D
The
and
the
interesting
part
is
that
datadog.
It
claims
in
people
request
and
comments
that
they
took
that
instrumentation
from
sprint
sleuth,
but
spring
sleuth
captures
contacts
during
subscription
during
terminal
operation,
not
during
assembly
by
as
pipeline
assembly,
and
so
my
question
what
I
wanted
to
ask
tyler,
and
so
I
will
do
that
offline.
D
C
D
D
A
Yeah,
I'm
trying
to
think
if
I've
seen
anything.
I
definitely
agree
with
the
change.
I
mean
it.
It
definitely
makes
sense
to
capture
at
the
terminal
operation
because
you
could
have.
I
mean
built
up
that
flow
at
some
point
and
even
reused
that
flow
or
exactly.
A
A
About
vertex
and
other
things
are
I
mean
there's
several
I
mean
reactor
is
the
key
one
and
thank
you
for
the
work
on
that,
because
several
of
the
other
instrumentations
depend
on
that
lettuce,
webflux
others
yeah.
D
A
Yeah,
let's,
since
you
brought
that
up-
let's
just
see
if
anybody
has
thoughts
on
our
latest,
our
latest
revisited
for,
like
the
15th
time
now,
literally
there's
probably
15
issues
in
this
repo
about
artifact
naming
so
the
I
would
say
the
main
thing
that
the
main
kind
of
question
that
we're
having
is
right
now
at
least,
is
whether
to
call
these
artifacts,
auto
or
java
agent
and
same
with
the
like,
the
pack.
A
The
group
id
are
we
auto
or
java
agent,
and
so
I
think
we
all-
and
I
had
gotten
this
onorak
head
kind
of
started.
This
discussion
over
here
about
auto
versus
java
agent
and
auto,
is
sort
of
like
two
generic
other
things
like
spring
auto
spring.
Boot
starters,
for
example,
could
be
considered
auto
instrumentation
because
they
don't
require.
A
A
On
the
other
hand,
java
agent
is
we've
already
kind
of
talked
about
reusing
the
bytecode
instrumentation
in
as
like
compile
time
instrumentation
for
android.
We
were
talking
about
that
last
week.
A
We've
had
this
idea
of
using
it
in
in
the
main
startup
people
being
able
to
inject
basically
that
bytecode
instrumentation
at
startup
for
like
aws
lambdas,
where
they
don't
have
that
you
can't
have
a
java
agent,
but
this
would
allow
you
to
basically
hook
in
the
the
bytecode
instrumentation
at
startup
of
your
app.
So
in
that
case
neither
of
those
are
really
java
agents.
A
So
I
mean
maybe
something
different
all
together.
Like
I
mean
I
thought
I'd
like
bite
code,
but
bytecode
bytecode,
spi
bytecode,
it's
not
really.
It's
like
bytecode
instrumentation,
it's
not
like
like
bytecode.
The
the
thing
is,
is
everything's
byte
code,
so
one
thought
was
well.
The
our
primary
use
case
is
java
agent.
A
So
you
know
it
might
be.
You
know
it
would.
If
we
reuse
the
java
agent
artifacts
for
other
things
like
compile
time
instrumentation
of
android,
I
don't
think
it
would
be
confusing.
I
don't
think
it
would
be
that
weird,
because
it's
like
oh
well,
java
agent,
is
the
main
thing
in
this.
You
know
in
this
repost
the
main
use
case
and
now
we're
you
know
we're
reusing
parts
of
that
for
these
other
things.
A
A
I
looked
in
the
spec
repo
and
carlos.
Maybe
I
don't
know
if
you
have
any
recollection
of
like
I
know,
we've
had
terminology,
you
know,
there's
a
glossary
there
and
I
looked
at
some
old
otps
that
sort
of
defined
the
auto
instrumentation.
A
Objectives
but
couldn't
really
find
anything
that
helped
was
too
helpful.
Also
in
other
languages
I
mean
I
am
wondering
if
auto
and
auto
instrumentation,
you
know
like
there's.
No,
you
know
if
they're
does
anybody
know
without
like
python,
for
example,
what
they're,
using
the
term
auto
instrumentation
to
be.
A
But
is
that
like?
Is
there
auto
instrumentation,
similar
to
our
library
instrumentation,
where
it
still
requires
some
code
or.
D
D
D
And
it
says
if
an
instrumentation
library
should
be
named
to
follow
any
naming
convention
of
the
instrumented
library
if
there
is
no
established
name,
the
recommendation
is
to
prefix
packages
with
open
telemetry
instrumentation,
followed
by
the
instrumental
library
name
itself.
It's
not
in
the
glossary
in
the
overview.
D
A
Yeah,
that's
a
good
find
because
yeah
we
should
follow
this.
D
Can
you
open
again
your
your
ticket
with
those
names
you
suggested
yeah?
So
if,
if
we
try
to
replace
here
java
agent
with
instrumentation.
A
I
think
what
this
is
saying
over
here
is
that
open,
telemetry,
instrumentation
flask.
I
think
this
that's
what
this
is.
This
should
be
open,
telemetry,
instrumentation.
A
A
Yeah,
I
see
what
you're
saying
so
over
here,
for
example,
if
we
changed
everything
to
instrumentation
and
we
say:
hey,
that's
our
and
then
I
guess
and
not
even
do
it
under
like
do
we
need
this?
Do
we
need
this?
Do
we
want
this
distinction
between
auto
everything,
that's
auto
and
everything,
that's
library
based.
D
Well,
we
at
least
have
to
have
two
different
jar
names
for
like
chat
library,
yeah
for
cats.
We
have
to
have
two
different
journeys.
D
A
Well,
they
need
they
need
at
least
a
unique
group.
Id
artifact
id.
D
A
I
think
it's
nice
to
have
different
jar
names,
but
I'm
not
sure
why
that
would
be
required,
because
the
you're
not
you're,
not
bundling
the
jars
together
like
in
a
like
a
web
and
flip
directory
or
something
okay.
D
Probably
yeah,
I
have
to
think
that
through
just
in
case,
but
probably
all
right
so
and
so
you
you
were
suggesting
that
if
we
replace
java
agent
with
instrumentation
below
we
remain,
we
leave
open,
telemetry
cats
as
it
is,
then
we
may
need.
We
may
not
need
two
different
group
ideas.
That's
what's
what
you're.
A
A
A
D
G
There's
there
is,
there
is
a
small
package
that
actually
calls
this
script
for
you,
so
you
you
can
use
that
to
start
your
python
application.
If
not,
you
can
import
that
directly.
A
All
right
cool.
We
will
think
on
that
more.
If
anybody
has
thoughts
artifact,
they
mean
quickly
just
wanted
to
mention
some
of
the
stuff
that
happened
last
week,
a
lot
of
different
contributors,
so
that's
cool.
We've
got
logback
mdc
support.
A
Now
so
john,
I
saw
your
ping
this
morning
on
the
context
listener,
and
so
what
anurag
did
for
now,
and
maybe
maybe
for
good
on
the
log
back
mdc,
is
sort
of
wrapping
the
appender.
So
when
the
appender
is
called,
then
we
stuff
the
trace
id
the
mdc
properties
into
it
into
the
con
into
the
mdc.
At
that
point,
and
so
that's
actually
going
to
I
I
like
that
approach
in
that
that
will
alleviate.
I
know
we
had.
A
We
talked
about
the
performance
concern
of
around
trace
id
span,
id
converting
them
to
strings.
I
know
we
don't
have
that
problem
anymore,
but
in
reactive
apps,
where
this
constantly
changing
threads
and
we'd
have
to
be
constantly
converting
that
to
strings.
A
In
case
there
happened
to
be
logging
at
any
point.
The
nice
thing
about
the
approach
here
now
is
that
it
only
stuffs
them
into
the
mdc
properties,
if
that,
if
there's
actual
logging
happening
so
not
even
if
the
log
has
been
called,
but
if
it's
filtered
all
the
way
down
to
a
pen.
So
it's
already
it
meets
the
thresholds
and
whatnot.
B
So
I
wonder
whether
the
the
issue
that
that
pr
was
addressing,
whether
that
is
neat-
sorry,
my
cat,
just
bit
my
foot
whether
that
issue
is
sorry
to
laugh.
B
I
have
to
push
him
out
of
the
way,
whether
that,
whether
the
issue
that
that
that
draft
pr
is
addressing
is
actually
needs
to
be
open
still,
because
we
need
to
have
a
context
listener
in
the
sdk
or
in
the
api,
or
do
we
can
we?
I
mean
it's
already.
That
issue
is
already
marked
as
after
ga,
but
I
wonder
whether
they're.
D
B
A
Take
a
look
at
how,
with
the
log
back
because
and
look
at
the
so
I
had
in
before
I
removed
it
and
pre
pre
ga
I'd
removed
our
log
logging
instrumentation.
That
was
doing
that
hacky
span
creation,
but
those
those
instrumentation
points
that
that
instrumentation
was
using
were
all
on
the
append
like.
Basically
they
were
all
similar.
They
all
get
instrument
after
the
threshold
has
been
met
and
it's
actually
going
to
an
operator.
A
So
potentially
the
same
approach
could
work
for
all
of
those
and
they
do
have
a
very
broad
version.
Support
range.
A
Yeah,
my
understanding
of
the
the
async
is
that
the
do
append
on
the
async
appender
is
synchronous,
but
then
the
async
appender
right.
Okay,
I
have
to
check
that.
Okay,
thanks
for
the
hint
I
I
got
it
yeah
yeah,
just
because
I
I
think
that
would
potentially
be
cleaner
or
perform
better
or
also
it
would
be
the
same.
Instrumentation
points
that
we'll
use
to
capture
eventually
we'll
bring
back.
Basically
the
hacky
span
stuff,
but
instead
of
hacky
spans,
we'll
use
the
log
api
yeah.
Okay,
thanks!
A
Oh
no,
we're
two
minutes
over
time.
Sergey!
Thank
you
for
java,
11,
http,
client,
instrumentation.
That's
very
cool
and
john
blay
from
splunk
contributed
some
really
great
kotlin
co-routine
instrumentation.
So
our
support
is
so
much
better
for
that
now
I
know
we'll
get
questions.
I've
had
several
customers,
it
seems.
Kotlin
is
more
popular
than
I
imagined,
based
on
the
number
of
like
customers
that
I
see
using
it
yeah
and
just
yeah
a
bunch
of
yeah
anyway.