►
From YouTube: 2020-07-16 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
B
C
D
G
C
I
was
just
thinking
of
you
know,
maybe
a
short
like
a
short
term
before,
like
dropping
it
completely
and
like
no
backsies
I
know
that
the
main
our
main
motivation
is.
We
want
to
want
to
be
able
to
use
test
containers
clean
up
a
bunch
of
our
tests
using
docker
containers
that
meets
Java
8.
So
I
wonder
enough
short-term.
If
we
could
go
ahead
on
those
instrumentations
that
are
not
going.
D
C
C
He
was
mentioning
that
the
so
some
people
who
develop
Android
apps,
who
want
to
target
like
a
very
broad
range
of
phones,
including
older
phones.
They
may
still
be
releasing
new
apps
that
are
targeting
old
phones
and
they
are
using.
You
know:
okay,
she
TPG
our
PC
or
super
common,
so
it
would
be
nice
for
the
manual
instrumentation
to
still
support
those
I
did
ping.
I
can
follow.
F
A
C
A
C
A
Also
I
reached
out
to
our
internal
Android
folks
here
to
find
out
if
they
knew
kind
of
the
same
way.
You
have
all
the
data
around
versions
of
Java.
They
say
they
don't
have
that,
but
I
talked
to
the
PM
and
she
is
gonna.
Try
to
prioritize,
make
finding
figuring
out
a
way
to
either
gather
or
publish
a
data
if
they
actually
have
it
and
just
haven't
shared
it
with
anyone.
H
A
F
That
we
can
drop
support
for
Java
7,
going
all
in
with
generate
both
in
all
our
code
base
and
when
we
hear
from
Google
people
that
from
Android
people
that
these
libraries
yeah
need
some
lower-level,
we
Canwell
will
downgrade
them.
I,
don't
think
we
will
change
that
so
much
that
that
downgrade
will
be
painful,
so
I
wouldn't
want
to
like
postpone
yeah.
We
have
dropped
support,
but
still
we
can't
use
anything
from
Joey
because
we
wanting
for
those
probably
two
libraries.
H
So
I
would
suggest
from
the
get-go,
starting
with
at
least
the
ok
HTTP,
because
we
know
that
that's
very
commonly
used
in
Java
in
Android
right
so
I
would
say
at
a
minimum
start
with
that,
so
that
we
have
an
example
of
okay.
If
you
do
need
Java
7
support.
This
is
the
proper
like.
This
is
what
it
looks
like
in
the
codebase.
H
F
H
H
F
H
Ok,
do
we
know
of
any
other
libraries
besides,
like
ok,
HTTP,
that
we
like
definitely
want
from
the
get-go
to
support
nice?
Your
PC
is
me
alone.
Ok,
the
other
question
would
be,
for
example,
how
important
would
it
be
to
support
like
the
executor,
instrumentation
I?
Guess,
that's
more
like
automatic,
instrumentation
and
likely
to
be
usable
there.
So,
ok,
maybe
not
right.
C
All
right
next
Ida,
so
this
Nikki
I
pulled
out
from
get
er
because
had
never
replied
to
it,
and
so
the
spec
is
using
the
required
for
GA
tag,
and
so
we
want
to
track
somehow
what's
required
for
GA
for
us
versus.
What's
not
so
I
was
asking
them
so
the
things
that
we
are
currently
tagging
with
the
specification
tag.
C
So
certainly
things
that
are
spec
related
are
most
likely.
It
seemed
required
for
GA
and
I
was
wondering
if
there
were
anything
like
there's
lots
of
nice
to
have
things.
But
if
we're
really
trying
to
say
what's
absolutely
required
for
GA
I
was
wondering
if
the
spec
label
is
the
only
thing
and
Makeda.
You
had
some
comment
about.
Yeah.
F
C
F
Think
I
think
two
things
that
are
not
specification
but
still
may
be
required.
The
first
is
Boggs
to
eat,
half
a
bach
instrumentation,
it's
not
specification
just
Bob,
and
we
want
to
figure
out
before
J
ed,
because
we
think
that's
important
stuff
and
second
I
still
think
that
we
have
to
have
support
for
vendor
specific
distribution
before
GA.
If
we
can
manage
that
it,
it
is
a
very
good
thing
that
that
that
may
mean
either
we
have
rapid
adoption
or
we
not.
C
F
I
Just
gonna
say
yeah:
this
is
I'm
starting
to
call
this
open,
telemetry
distros.
This
is
a
term
I'm
trying
to
float.
The
people
are
I
think
starting
to
adopt.
So
it
would
be
good
to
have
this
open,
telemetry
distro
concept
work
with
the
Java
agent,
the
basic
idea
being
not
that
you're
modding
open
telemetry
under
the
hood,
but
you
have
a
suite
of
plugins.
You
need
installed
and
you
don't
want
the
end-user
to
accidentally
forget
to
install
your
sampler
or
something
like
that.
F
C
There
I
know
there's
been
discussions
of
some
things
that
are
required
for
GA,
like
documentation
example
code
for
the
SDKs
and
I.
Think
you
and
some
other
folks
were
working
on
putting
that
list
together.
Yeah
will
that
come
through
as
a
spec
that
that
everybody
needs
to
follow,
or
is
that
sort
of
a
separate
channel
that
we
should?
Why
track
yeah.
I
It's
a
separate
track
from
the
spec
we're
trying
to
organize
this
see
the
maintainer
z'
group,
because
there's
a
number
of
things
I
suppose
we
could
put
it
all
in
the
spec.
Maybe
that's
fine,
but
around
tracking
these
additional
issues
like
testing
harnesses
integration
tests,
documentation
that,
if
almost
a
stem
performance
testing,
so
there
is
a
spreadsheet
of.
I
C
F
F
Think
we
just
have
to
like
go
over
our
whole
backlog
and
put
three
and
put
that
required
for
GA
label
to
think
that
we
currently
think
only
four
before
GA
and
then
probably
have
some
trade
priority
rule
that
well
specification
goes
first
and
then
and
then
from
time
to
time
we
see
and
now
that's
gone.
That's
not
gonna
happen.
Let's
drop
the
prior.
That
requirement
tag
of
like
that.
C
C
C
So
you
know
it's
just
fine
to
just
post
a
question
there
and
we
can
discuss
it
and
then,
if
a
decision
comes
out
of
that,
then
it
probably
makes
I
was
thinking.
It
makes
sense
to
to
then
create
a
new
issue
with
that
action
item.
Instead
of
just
you
know,
having
these
really
really
long
issues
that
then
it's
hard
to
parse
back
everything.
C
G
C
A
F
C
F
C
So
what
honor
I'd
was
proposing
was
instead
of
supplying
oti
exporter.
I
want
to
use
the
AYGO
exporter
or
a
Zipkin
exporter
to
just
motto
on
if
somebody
supplies
the
Jaeger
endpoint
or
the
Zipkin
endpoint
or
the
OT
LP
end
point
that
we
Auto
enable
those
exporters
and
that
would
also
support
multiple
exporters,
potentially
with
multiple
like
you
could
have
Prometheus
then
and
Zipkin.
C
The
this
would
only
work
for,
like
our
built-in
exporters
that
we
know
about,
so
it
wouldn't
necessarily
solve
the
external
exporter,
multiple
external
exporters,
but
does
that
seem
like
a
somewhere?
That
makes
sense
from
like
people
who
expect
folks
on
the
call
I
was
wondering
if
that's
something
we
should
document
in
this
back
like
how
Auto
people
automatically
pick
up
the
right
exporter.
C
A
D
A
Interesting
yeah
I
would
vote
for
being
explicit
with
the
system,
property
say,
or
the
environment
variable,
x1,
second
or
a
comma
delimited
list,
or
something,
but
that's
feel
just
from
I
like
having
to
support
people
in
the
field
doing
this
stuff.
If
we
are
picking
things
up
and
configuring
things
from
environment
variables,
that's
great,
but
if
they're
they
could
be
very
surprising
they're,
not
in
control
of
their
environment.
F
I
F
I
Part
of
the
question
is
it
just?
Do
we
want
to
provide
mapping
like?
Do
you
want
to
explicit?
This
is
the
Zipkin
stuff?
This
is
the
eager
stuff
versus
like
these
are
open,
telemetry
concepts
and
somewhere
else.
There's
a
mapping
from
those
Otel
concepts
to
these
different
exporters.
That's
the
other
way.
I
would
see
people
doing
it.
I,
don't
know
if
that's
helpful
or
not
I,
afraid
I,
don't
follow
you.
I
So
if,
if
there
are
some
concepts
like
service
name
right,
where
you
can
say
open
the
open,
telemetry
concept
of
a
service,
name,
I'm
setting
that
and
then,
if
you're
running
Zipkin,
that
maps
to
something
and
if
you're
running
Jaeger
that
maps
to
something
and
then
okay.
Likewise
with
like
some
of
these
other
configuration
variables
like,
maybe
they
don't
map
that
well,
I,
guess
I'm
thinking
about
things
like
collector,
endpoints
and
there's
a
lot
of
stuff,
that's
pretty
standard,
but
the.
C
Collector
endpoints
are
in
that
environment,
variable
environment,
variable
spec
and
the
service
name
concept,
I.
Think
in
that
particular
PR
in
the
spec.
The
proposal
was
to
use
the
standard
resources
environment
variable
for
all
of
them
under
I
can
post
and
I
think
Nikita
and
I
both
liked
that
proposal
of
having
a
separate
service
named
environment
variable
just
because
that's
like
the
main
thing
that
people
need
to
set
up
and
having
to
explain
that
resources,
equal
service,
dot,
name
equal.
Something
else
is
you
know
a
recipe
for
people
messing
up,
yeah.
I
I
guess
maybe
I
would
say
if
we
come
up
with
standard
environment
variables
like
that,
then
having
like
you,
know
a
separate
one
like
to
the
degree
to
which
we
can
standardize
things.
Can
we
remove
Zipkin
or
Jaeger
specific
stuff
and
map
it
to
something
standard?
The
only
reason
I
bring
that
up
is
that
would
be
a
little
more
equitable
or
easy
for
people
to
potentially
adopt.
You
know.
Other
exporters
but
I
agree
all
these
systems
work
kind
of
different.
So
you
know
like
I,
don't
actually
know
how
standard
you
can
get
without
becoming
confusing.
F
F
F
F
A
I
C
F
F
C
F
F
A
If
there's
interest
I
have
so,
there
was
a
there's,
a
PR
into
the
specs
repo
to
specified
semantic
conventions
for
timed
operations
in
metric
business.
Metric,
metrics
and
I
prototype
that
just
to
see
how
it
would
look
to
actually
write
instrumentation
that
generated
spans
and
then
timings
for
them.
For
those
fans
and
I'd
be
happy
to
show
what
I
did
if
anyone's
interested.
It's
kind
of
just
a
packing.
That
I
did
definitely.
C
Recommend
them,
if
you're,
not
if
you're
interested
in
following
there's
like
I,
said,
we've
been
doing
getting
a
lot
of
discussion
going
in
the
issues
on
the
repo.
If
you
want
to
watch
the
repo
and
follow
along
I
know
watching
these
open
telemetry
repos
is
kind
of
a
flood
of
a
lot
of
stuff,
but
I've
been
happy
with
the
level
of
discussion
we've
been
able
to
have
in
the
issues
and
giving
things
resolved
there.
A
E
A
A
So
if
we
look
just
really
briefly,
it's
a
very
simple
specification
change
and
it
basically
what
it
says
is
that
if
you're
going
to
do
metrics
on
time
decorations
on
spans,
you
can
use
a
value
recorder
and
you
should
name
your
instrument,
your
value
recorder,
with
some
pattern
that
looks
approximately
like
this,
so
like
HTTP,
server,
duration,
HD,
client,
duration,
so
kind
of
the
category,
the
kind
of
thing.
So
it's
almost
like
a
subcategory
and
then
the
word
duration.
So
this
is
kind
of
the
semantics
convention
that
justin
is
proposing
it.
A
A
It
also
has
things
like
you
should
include
some
status,
a
status
code
and
some
labels,
which
are
still
to
be
determined
exactly
what
they
would
be,
but
to
keep
the
to
keep
the
cardinality
low.
So
it's
not
including
things
like
content
length.
So
again,
it's
very
high
level,
so
I
decided
to
see
whether
this
is
something
that
could
work
and
the
main
goal
for
me
was
to
see
whether
we
could
use
this
particular
convention
to
generate
what
New
Relic
calls
the
golden
metrics.
A
That's
error
rate,
throughput
and
latency
and
be
able
to
you
know,
see
what
that
looked
like
for
a
given
service
and
I
saw
I
decided
to
try
it
with
an
HTTP
service,
and
we
have
this
little
internal
app
that
the
Java
team
here
wrote
a
little
app
for
you
know,
searching
for
Oscars,
so
you
can
look
and
see
who
won,
actor
and
supporting
role
in
2012.
In
this
case
it
was
Christopher
Wallace
for
Django
Unchained
anyway.
So
it's
just
a
little
super
simple
app.
A
It
has
an
embedded
little
file
that
it
reads
oscar
date
out
of
and
return
stuff,
and
we
use
this
internally
kind
of
as
a
playground
for
playing
around
with
open,
telemetry
and
doing
writing
manual
instrumentation
for
things
so
anyway
to
the
code.
So
this
is
a
the
app
is
this
little
spring
app,
so
very
kind
of
standard,
straightforward
stuff
uses
the
spring
get
mapping,
and
you
know
normal
controller
and
service
on
the
service
to
get
the
data
that
sort
of
thing.
A
So
what
I
did
is
I
both
abstraction
call,
the
timer,
which
is
implemented
with
this
class,
called
HTTP
server
timer.
So
it's
very
specific
right
now.
That's
not
like
a
super
general
solution
to
anything,
and
this
is
how
you
end
up
using
it.
So
you
would
you
have
it
you've?
Had
this
timer
object
when
you
construct
this
timer
object,
you
basically
give
it
a
tracer,
you
give
it
a
meter,
and
then
you
give
it
a
route
that
you're
actually
wanting
to
instrument
so
fairly
straightforward,
and
then
you
call
the
time
method
on
it.
A
You
give
it
a
parent's
fan
at
the
moment.
It's
just
you
all!
You
get
a
parents
fan,
and
this
trace
utils
extract
incoming
span
is
just
using
w3c
trace
context
to
get
a
span
off
the
wire,
and
then
you
give
it
this
little
callback
lambda
where
you
are
given
a
span
and
this
timing
Ender,
which
is
basically
saying
I'm
done
with
my
operation,
stop
the
timing
and
what
you
do
is
you.
You
know
you
use
this
fan.
This
is
just
a
regular
open
flow.
Mitrice
fan,
you
said
attributes
on
it.
A
You
could
add
whatever
you
wanted
to
do
with
it.
You
make
your
call
and
then
you
call
on
end
for
the
timing
under
which
actually
will
you
know,
say:
I'm
done
with
the
operation
I'm
currently
working
on,
and
that's
essentially
how
you
end
up
using
this
little
old
thing,
and
so
it's
really
good
for
manual.
Instrumentation
I,
don't
know
how
usable
it
would
be
an
auto
instrumentation
world,
but
for
manual
instrumentation.
It
works
pretty
well
and
so
the
implementation
of
this
it
looks
kind
of
like
what
you
would
expect.
A
So
the
time
method
you
know
creates
a
span
with
the
or
the
remote
parent
that
comes
in
it
starts
the
timing.
Does
the
usual
dance
with
the
tracer
and
the
scope?
It
runs
whatever
the
worker
says,
and
then
implementation
when
you
get
says
and
labels,
so
the
yeah,
the
callback
you
give
it
a
status
and
a
set
of
labels
that
you
want
to
apply
to
the
timing
in
this
particular
case.
A
A
A
C
C
So,
where
you
start
you're
getting
the,
can
you
go
back
to
your
rest,
controller
yeah,
so
you're
extract
incoming
span.
This.
A
C
A
H
A
A
I,
don't
know
how
long
this
time
case,
there's
no
way
to
find
out
how
long
and
same
thing
I
can't
ever
find
out
what
attributes
were
put
on
by
the
user
or
by
anyone
from
the
span,
because
there
it's
alright
only
if
got
so,
it
doesn't
actually
make
doing
at
the
API
level.
It
makes
building
this
kind
of
instrumentation
find
it
tricky
and
annoying.
So.
H
A
Don't
know
the
right
solution
to
this
actually
because
I
think
this
is
the
kind
of
the
first
time,
at
least
in
any
of
I
mean
open
tracing,
obviously,
in
that
metrics
right,
so
it
didn't
run
into
this
problem.
I,
don't
know
what
open
census
does
around
this,
whether
it
even
tries
to
solve
this
problem,
but
I
think
this
kind
of
unified,
like
we
don't,
have
a
unified
API
right
now
for
spans
and
metrics.
We
have
two
separate,
api's
and
I.
A
Think
a
lot
of
the
idea
was,
though
well
the
SDK
can
do
the
work
of
cooking
those
things
together,
but
there's
actually
some
I
mean
there's
some
benefit
to
actually
letting
the
instrumentation
do
that,
rather
than
relying
on
the
SDK,
so
I
think
it's
actually
to
me
exposes
a
few
gaps
in
the
way
our
API
is
constructed
right
now
and
I.
Don't
have
any
great
answers
for
them,
but
I
think
it
was
super
super
useful
to
go
through
this
exercise
and
actually
see
what
it
would
take
all
items
API
right
this
instrumentation
anyway,
there's.
A
Yeah
I
can
give
it
as
best
I
can
give
the
start.
Time
stand
yes
and
I
could
manually
give
at
the
end
time
stand
right.
It's
a
little
bit
like
you
know.
The
span
already
does
its
own
timing,
like
Tyler
was
saying
like.
Why
do
we
need
it?
Why
didn't
that
work
also
like
yeah?
Certainly
the
instrumentation
again
can
work
around
it.
It's
just
a
little
bit
painful
I.
H
Mean
so
I
think
that
we
don't
necessarily
so
we
can
probably
make
some
progress
on
this
by
adding
some
methods
on
the
API
where
either
the
the
metrics
knows
about
this
bands,
or
this
bands
knows
about
the
metrics
or
some
sort
of
linkage
or
maybe
you'd
even
want
both.
But
yeah
I
do
think
that,
like
having
to
pass
in
the
time
or
track
the
time
separately
is
like
very
prone
to
to
bugs
oh
yeah.
A
It's
even
worse
than
that,
because
I've
hidden
a
bunch
of
mess
right
here
by
collapsing
it,
which
is
what
happens
if
your
the
callback
throws
an
exception
right
because
of
the
callback
there
was
an
exception.
I
don't
have
labels
anymore,
like
I,
don't
I
hope
the
instrumentation
couldn't
even
give
me
labels
so
I
have
to
so.
What
I
have
to
do
is
kind
of
make
a
loop
I
can
use
the
route.
H
F
A
C
A
Anyway,
so
this
is
what
we
have
it
work
yeah
in
rate.
We
can
use
the
error
to
generate
error
rates
based
on
the
count
me
right
now,
we're
generating
a
min/max
sum
count
aggregation
for
these
things,
and
so
we
can
get
the
count
to
get
the
rates,
and
we
can.
We
have
the
actual
timer
min
max
that
we
can
use
and
the
average
based
on
count
and
some,
so
we
can
get
kind
of
roughly
our
golden
metrics
can
be
acquired
from
this
one,
the
one
timer
plus
a
bunch
of
hockey
instrumentation.