►
From YouTube: 2022-01-27 meeting
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
A
A
So
1101
finally
went
out.
There
were
a
few.
I
think
three,
three
regressions
or
three
bug
fixes
two
regressions,
I'm
not
sure
if
the
aws
one
was
an
actual
regression
or
not
we're
continuing
to
work
through
our
patch
release
process
and
make
it
smoother.
A
A
To
metrics
semantic
conventions
run
time,
yeah
look
at
that.
We
have
jvm
metrics,
and
so
the
next
thing
that
the
metrics
the
jvm
metrics
group
is
working
on
is
we've
got
jonathan's
pr
for
cpu
metrics,
so
it'll
be
great
to
get
some
reviews
on
that.
Oh
yeah,
I
did
ask
around
about
approvers
on
like
splitting
out
approvals
on
in
the
spec
repo,
and
it
sounds
like
that's
not
something
they've
done,
so
they
still
have
just
these
three
breakouts
for
the
three
signals.
A
Honorable
was
mentioning
that
the
getting
and
actually
the
good
thing
is
we
do
have
so
in
the
this
is
under,
oh,
which
people
set
of
people.
I
think
it's
everybody
all
three
groups,
let's
see
spec
approvers,
ometrix
approvers
yeah,
so
this
the
good
thing
is:
we've
got.
A
We
can
we've
got
john
here
and
we've
got
honorable
here
so
we'll
we
can
ping
them
for
trying
to
get
green
check
marks
on
there
and
then
honorable
mention
the
hardest
part
is
often
getting
somebody
from
the
technical
committee
who's,
the
only
group
that
can
actually
click
the
merge
button,
but
we
had
good
success
with
armin
on
the
last
pr,
so
I'll,
we'll
ping
him
next
time
we
get
blocked.
There.
Also.
A
Fantastic,
so
we
wanted
to
chat
micrometer
bridge
today.
Do
you
want
to
kind
of
phrase
your
the
question
for
the
group.
C
I
will
try.
I
will
warn
you
ahead
of
time.
My
puppy
has
decided
that
something
outside
is
really
interesting,
so
we
may
get
some
weird
noises
because
squirrels
or
birds
are,
I
don't
know
what
he's
decided
he
sees.
So
just
you
hear
that
it's
where
it's
not
me,
so
we
have
different
interests
across
different
groups,
which
is
normal,
like
we
have
within
the
open,
telemetry
specification
cncf
project
space.
C
We
have
the
micrometer
bridge
that
was
just
created
within
the
instrumentation
agent
project,
which
of
course
is
bridging
to
older
versions
of
micrometer.
Because
of
the
needs
of
a
certain
segment
of
our
group
regarding
supporting
older
programs
right
and
whatever
not
enough
nouns,
and
then
we
have
like
what
joni
and
I
are
trying
to
work
on
in
terms
of
getting,
I
guess,
more,
recent
versions
of
micrometer
to
be
compatible
with
open
telemetry,
and
so
I'm
thinking
in
the
from
the
perspective
of
several
different
consumers.
C
C
So
how
am
I
going
to
support
open
telemetry
in
that
environment
and
then
there's
like
just
straight
up
library
maintainer
like
micrometer,
and
it's
like
it's
like
even
just
from
consuming.
I
have
three
different
perspectives
where
what's
happening
in
the
relationship
between
what's
happening
at
the
instrumentation
agent
level,
with
what
I
might
do
at
any
of
these
other
levels
is
unclear
so
and
it's
like,
I
I'm
not
saying,
there's
not
a
valid
purpose
for
each.
So
don't
misunderstand
me:
I
get
what
all
these
levels
are
for.
It's
just.
I
don't
know
that.
C
Here's
what
you
should
be
considering
consuming
here's,
how
these
pieces
fit
together
or
how
we
expect
or
want
them
to
fit
together,
and
I
just
think
it
causes
some
tension,
because
we
don't
really
know
what
we
want
to
do.
C
It
sounds
weird,
I
think,
there's
a
whole
segment
of
us
that
are
like
yeah.
You
just
use
open
telemetry
for
all
the
things
and
that's
the
answer.
That's
of
course
what
you
do,
but
I
don't
know
how
realistic
that
answer
actually
is
within
a
space
as
robust
as
java
is
I
don't
know
that
we're
ever
gonna
have
like
a
single
answer.
So
that's
basically
the
nature
of
my
ask
is:
how
do
we
get
to
the
bridge?
C
That's
in
the
telemetry
project
is
at
the
agent
level,
and
so
then,
how
does
that
relate
to
whatever
we
might
do
with
micrometer
at
the
library
level?
Did
we
get
into
a
place
where
they
conflict
is
one
superseding
the
other?
I
think
we've
talked
about
that
a
little
bit
before
and
have
decided
that
if
the
library
does
something,
then
the
agent
wouldn't
have
to
do
it,
but
like
it's
not
super
clear
that
this
is
what
we
want.
This
is
the
target.
This
is
how
we
want
these
things
to
be
related.
A
Yeah,
let
me
just
give
just
for
to
put
some
terminology
out
there
to
try
to
help
the
discussion,
what
we're
calling
those
different
levels
of
instrumentation.
We
call
we're
kind
of
referring
internally.
At
least
we've
been
referring
to
when
libraries
instrument
themselves
as
native
instrumentation
and
when
we
have
an
instrumentation
in
the
java
agent,
an
automatic,
auto
instrumentation,
that's
agent
instrumentation,
but
the
instrumentation
group
also
produces
library
instrumentation
that
can
be
used
outside
of
the
agent
and
that
we
call
library
instrumentation.
A
A
The
reality
is,
we
have
a
lot
more
agent
instrumentation
at
this
point,
and
so
but
new
stuff
we've
been
trying
to
build
out
both
together
and
ideally
use.
The
agent's,
auto
instrumentation
is
based
on
the
library
instrumentation,
so
the
agent
instrumentation.
A
A
C
It
does
I
the
reason
I
raised
that
one
in
particular
is
because
we
have
had
a
few
discussions,
and
I
had
that
poc
a
long
time
ago
that
granted
has
sat
there,
so
you
guys
should
all
be
firing
guns
at
me
and
cannons
and
whatever
water
balloons
marshmallow
cannons
anyway.
I
think
like
ben
is
thinking
about.
C
I've
got
jfr
micrometer
we've
got
at
least
two
flavors
of
potential
integration
at
the
micrometer
layer
that
we've
been
trying
to
think
about
between
micrometer
and
open
telemetry
and
that's
up
at
the
micrometer
layer.
And
so
then
we
have
this
agent
one
underneath
and
it's
like.
C
How
do
we
want
open,
telemetry
and
micrometer
to
work
the
most
efficiently
together?
Do
you
see
what
I'm
saying?
That's
what
I
don't
understand
when
I'm
looking
at
this,
like
at
the
purpose
of
the
bridge.
I
understand
this
is
the
wrong
way
to
say
it.
There
are
not
enough
words.
I
understand
its
purpose
like
I
understand
why
it
exists.
A
So
I
think
I
mean
at
this
point
I
mean
the
advantage
is
at
this
point:
it's
yeah
our.
I
would
say
it's
currently,
the
the
only
way
to
do
it
great.
A
I
think
it
is
generally
consistent
with
what
we
recommend
in
terms
of
if
you
want
to
use
library
instrumentation,
if
you
don't
want
to
use
a
java
agent.
Here's
your
solution.
C
Yeah
cause
john
watson,
you
and
I
talked
a
long
time
ago
about
what
I
think
is
the
inevitable
case,
which
is
there
will
be
both
you
won't
have
one
or
the
other.
You
will
have
both
for
whatever
reason
and
then
you're
kind
of
in
a
mess.
Because
then
I
don't
know
how
those
two
things
know
about
each
other
or
stay
out
of
each
other's
way.
A
C
Like
as
someone
who
hasn't
like,
I
have
in
my
head
ideas
and
we've
got
a
couple
different
ones
about
how
to
have
micrometer
and
open
telemetry
integrate,
but
understanding
then,
where
the
right
place
to
put
this
capability
is
given
that
the
agent
that
we
do
have
is
in
some
senses
constrained
to
you,
know
old,
buggy
levels
of
micrometer,
because
you
guys
have
to
support
that
right.
We
got
like
layers
of
concerns
for
who
has
to
support
what,
and
that
complicates
things
too.
D
C
It
hasn't
changed,
that's
correct,
but
we've
fixed
bugs
there's
like
behavior
things
that
have
improved.
I
know
that
you're
hooking
in
in
a
way
that
kind
of
bypasses
some
of
what
micrometer
is
doing.
I
don't
know
that
joanie.
I
am
totally
talking
for
you
and
I
should
not
be
you
should
talk.
I
don't
know
where
he
went.
My
camera
was
called
off
of
it,
but
like
from
from
how
micrometer
is
going
to
involve
going
forward.
C
I
don't
necessarily
know
that
having
the
automatic
hooks
in
to
bypass
micrometer
behavior
is
the
right
way.
It's
not
necessarily
my
call
to
make.
I
understand
why
it
has
to
happen,
especially
for
older
versions.
I
just
don't
know
that
that's
the
best
way,
it
is
a
way
it's
a
way
that
definitely
works
for
the
old
stuff
right.
But
it's
like
that's
the
part.
I
don't
understand.
Okay,.
A
So
that's!
Okay!
If
micrometer
wants
to
make
changes,
so
we
have
a
lot
of
infrastructure
in
the
java
agent
to
handle
applying
different
instrumentation
to
different
versions
of
a
library.
E
C
C
Like
I
just
it's,
I
I
get.
I
have
a
hard
time.
This
is
just
me.
I
I
expect
any
of
the
other
people
who
operate
at
my
level
to
chirp
in
at
any
time.
I
feel
like
I'm
talking
too
much
and
roberto
I
know,
is
on,
and
he
and
I
have
been
looking
at
telemetry,
both
metrics
and
tracing
for
corgus,
and
I
find
it
a
little
challenging
too,
because
you
have
like
the
instrumentation
apis.
C
So
it's
like,
should
we
in
quarkus
be
using
the
instrumentation
apis
or
are
those
still
for
agents
using
an
instrumentation
api
and
then
quarkus
has
a
whole
other
problem
with
how
the
hell
agents
are
even
going
to
find
anything
since
we
go
and
mess
with
the
byte
code
every
place.
So
I
guess
I'm
trying
to
it's
like
this
is
good.
I
guess
I
I
would
like
it
to
to
be.
This
is
what
we
this
is
how
we
would
like
all
of
these
things
in
the
ecosystem
to
play
together.
C
C
A
Really
solved
yet
we've
solved
it
in
certain
cases
and
in
general.
Our
thought
is
that
this
is
a
java
agent
problem
that
the
java
agent
should
back
off.
I
right
so
we
don't
really
want
to
burden
library.
Authors
with
that
concern.
We
kind
of
want
library,
authors
just
go
and
build
the
best
instrumentation
for
your.
You
know
your
ecosystem
and
we
may
provide.
We
may
build
java
agent
instrumentation
that
pulls
in
that
your
the
bridge
that
yeah.
A
And
we
have
a
couple
examples.
I
think
it
was
couch
base,
we're
doing
that
already.
They
have
like
an
open,
telemetry
instrumentation,
and
we
auto
inject
that
and
azure
sdk
has
something
similar
and
that's
a
nice.
We
love,
we,
we
love
native
instrumentation
right,
like
that's
the
only
way
this
is
going
to
scale
beyond
our
small
group.
A
That's
why
I
wanted
to
set
yeah
and-
and
we
do
I
like
what
you
said
about
how
to
play
in
the
ecos,
how
ecosystem.
B
B
To
be
brutally
honest,
we
have
this.
We
have
this
issue
within
open,
telemetry
itself,
like
the
agent
like
people,
we
every
day
we
see
people
trying
to
configure
their
own
sdk
and
use
it
along
with
the
agent,
and
it
just
doesn't
work
exactly
and
there's
no
indication
to
the
user
about
the
fact
that
things
are
just
not
like.
This
is
not
the
way
things
should
work,
so
we
internally
already
have
this
problem
in
it
like
a
slightly
different
flavor
that
we
need
to
figure
out
how
to
solve
as
well.
I.
C
A
A
F
What
happens
if
the
user
is
not
using
the
global
registry,
because
I
personally,
I
don't
recommend
to
use
it
usually
because
it's
harder
to
it's
like
basically
a
question
of
like
dependency,
injection
versus
like
static
things
and
usually
excluding
the
very
simple
cases.
The
former
one
is
usually
better
for
the
users.
A
We
also
inject
it
for
a
spring
boot
actuator
so
have
a
auto
instrumentation
to
so
that
if
you're
not
using
the
global,
but
you
are
using
spring
boot
actuator,
I
have
a
feeling
we
may
do
something
similar
in
open,
telemetry,
we're
sort
of
starting
with
the
simple
case
of
global
registry
and
seeing
what
what
people
say
but
yeah.
If
you're
not
using
a
pattern
that
we
know
about
like
say
you
weren't
even
using
spring
boot,
actuator
just
your
own
pattern,
then
I
don't
know.
A
I
do
know
how
we
would
thoughts.
I
mean
like
on
how
we
would
do
that.
F
So
yeah,
so
basically,
my
question
is
like
more
like
general.
If,
if
I
have
like
a
application
using
like
x,
let's
say
it's
in-house,
be
it
proprietary
framework
which
you
will
never
know
about,
and
I
am
using
dependency
injections
and
let's
say
that
is
an
inherent
speed
solution
which
you
will
never
know
about
either.
F
In
that
case,
I
would
still
provide
a
way
to
the
users
to
hook
up
into
this,
and
basically
just
saying
that
hey
this
is
my
composite
registry.
I
am
going
to
inject
this
everywhere.
Could
you
please
configure
and
add
the
autometer
registry
to
this,
and
once
you
are
done
with
that,
I
know
that
it's
there.
I
can
continue
and
using
it.
So,
basically,
when
I
configure
my
own
stuff,
I
am
putting
my
registries
into
the
composite.
F
A
And
so
would
that
be
different
than
what
users
can
do
today,
which
is
add
the
hotel
meter
registry
as
a
dependency
and
register
it
themselves.
F
D
The
the
library
instrumentation
setup
is
pretty
straightforward.
You
just
call
quantum
mechanical
registry.create
and
that's
it.
The
java
agent,
though
yeah
it's
a
bit
more
complicated
there
due
to
the
fact
that
we,
we
only
know
the
metrics
that
we
have
a
registry
one
and
yeah.
I
I
will
add
the
spring
with
actuator
support
later,
because
it's
a
very
good
idea
but
other
than
these
two
well.
A
Yeah-
and
so
I
would
I
know
that
was
raised,
the
question
of
supporting
old
versions
is
the
is
the
is
that
question
around
as
the
context
of
that
that
there's
stuff
in
newer
versions
of
micrometer
that
we
could
do
better
at
this
point
or
is
the
context
for
that
question.
Just
sort
of
the
future
micrometer
direction
of
planning
out
the
future.
F
So
right
now,
as
far
as
I
remember,
the
instrumentation
depends
on
micrometer
1.5.
That
is
a
really
really
old
version.
C
C
C
A
So,
just
to
clarify
the
dependency
is,
compile
only
so
we're
not
pulling
in
we're,
not
transitively
pulling
in
an
old
version,
so
users
in
basically
in
no
way
should
this
affect
what
users
are
already
using.
C
G
F
That's
a
good
question
and
it
is
under
discussion,
but
right
now,
as
things
are
today-
and
I
believe
this
will
stay
with
your
support-
eight
for
the
to
the
text
line,
which
is
no.
G
G
Yeah,
because
you
can
probably
see
what
I'm
trying
to
go
for
here,
is
that
because
we
only
support
version
8,
you
know
inflammatory.
If
there
was
a
version
of
of
micrometer
that
supported
seven,
we
could
definitely
cut
off
the
version
at
that
point.
But
if
it
was
born
all
night
that
doesn't
help
us,
it
was.
A
This
is
a
good
worth
reading.
If
folks
haven't.
This
is
sort
of
summarizes
our
thoughts
on
so
library
instrumentation
we're
more
than
willing
to
drop
old
versions
for
for
a
good
cause.
We
just
kind
of
need
to
know
what
that
you
know
good
cause
is
like.
Can
we
produce
better
telemetry
for
that
instrumentation
for
that
library,
on
a
newer
version?
A
Can
we
have
cleaner
tests,
something
like
that,
whereas
the
java
agent,
as
aaron,
was
saying
you
know
from
a
observability
vendor
perspective,
and
you
know
people
running
old
apps
that
they
haven't
touched
in
a
decade,
it's
a
different
situation,
but
we
are-
and
so
you
know,
if
we
can,
for
the
same
for
the
the
same
price,
we
can
get
both
the
library
and
java
agent
instrumentation.
A
You
know
we
can
reuse
the
library
instrumentation
in
the
java
agent,
that's
great,
but
if
there
is
a
compelling
reason
to
you
know,
bump
library,
instrumentation
we're
fine
with
you
know
we
can
just
consume
this
vendor
this
into
the
java
agent,
for
example,
and
drop
that
library,
older
library,
instrumentation.
So.
C
A
A
Yeah
and
so
if
you
built
that
out,
if
you
had
an
open
telemetry
registry
in
the
micrometer
community,
then
we
would
drop
our
library
instrumentation.
C
Cool
that's
good
to
know,
and
so
then
I
think
joni
one
of
the
things
I
think
we
should
look
at.
We
meaning
you
because
I
have
zero
real
control
over.
This
is
how
to
put
it
in
a
repo
that
allows
more
collaboration,
because
there's
just
there's
constraints
around
contribution
to
the
core,
for
lots
of
good
reasons.
C
F
Also,
by
the
way,
in
connection
with
that
we
are,
we
are
planning
to
like
implement
the
aodlb
registry
for
four
micrometer
right
that
that
means
that,
like
we
haven't
like
talked
about
it
for
that,
we
don't
necessarily
need
to
use
the
open,
telemetry,
api
or
sdk,
because
it
is
basically
just
a
micrometer
history
with
that
output.
So
tlp.
A
F
C
F
There
there
was
a
pr
a
couple
of
days.
C
B
E
C
C
A
In
case
you
have
any
sway
in
micrometer
tracing,
that's
a
whole
another
gonna
be
a
whole
nother
mess
of
bridges.
That
seems
maybe
less
necessary.
Given
it's
a
new
project
versus
you
know,
micrometer
and
hotel.
The
bridges
are
very
necessary.
H
F
Also
that
one
is
for
likely
to
the
text
line
for
four
micrometer,
so
with
with
the
this
this
one,
five
instrumentation
you
you
can
ignore
that
that
that
will
not
be
supported
for
for
the
wonder
text
line.
A
C
C
G
Some
ways
it's
like
it's
like
programming,
language
design,
that
you
know
you
start
off
with
an
initial
budget
of
words
and
you
use
them
up
by
assigning
them
to
con
concepts
and
eventually
adding
more.
It
becomes
increasingly
difficult
because
all
of
the
generic
nouns
are
gone.
You
know,
class
and
module
and
layer
and
all
of
those
things
bar.
A
Cool
any
last
thoughts
on
micrometer
before
we
move
on.
A
All
right,
the
yeah
we
had
oops,
we
had
a
good
discussion
on
tuesday
about
the
test,
so
our
tests
run
automatically
against
the
latest
dependencies
that
we
download
from
maven
central,
and
we
haven't
been
really
tracking
where
we,
where
we
have
those
failures,
sometimes
we
fix
them
and
sometimes
we
cap,
we
have
a
way
to
cap.
The
latest
version
that
we
run
on,
which
is
particularly
useful
for
when
there's
a
like
an
alpha
like
log
back
1.3
alpha
our
tests
fail
on
that.
But
that's
fine.
A
We
don't
care
so
hopefully
there's
a
couple
of
things.
We
can
do
to
improve
that
situation.
A
There
was
a
question
in
slack.
I
know
we've
discussed
this
before.
I
was
just
kind
of
curious.
If
anybody
had
new
thoughts
on
we
in
our
download,
we
don't
have
the
dash
like
1.10.1.
A
In
the
jar
name,
of
course,
it
is
there
if
somebody
downloads
it
from
maven
central.
I
think
the
reason
we
originally
didn't
put
the
version
here
was
to
make
it
easy
to
curl
and
replace
your
existing
one.
D
D
A
H
A
Yeah
yeah
but
like
mateusz
was
saying
you
can
run
java
dash
jar
and
so
after
downloading
with
no,
if,
if
you're
downloaded
the
latest-
and
you
don't
know
what
the
version
is
and
you
want
to
get
it,
you
can
run
java
jar
capture
the
output
and
then
rename
it
okay.
So
it
sounds
like
we
haven't,
really
changed
our
minds
on
that
I'll.
Just
reply
kind
of
that.
There's
this
option
always
to
download
it
from
maven
central
or
to
jack's
solution
of
renaming
it
on
the
during
download.
A
Static
instrumentation,
so
I
I
threw
this
in
here
just
as
as
an
fyi,
so
that
people
know
that
this
exists.
But
it
was
something
that
one
of
our
colleagues
worked
on
as
a
university
project.
A
So
and
it
has
demonstrated
a
fast
reduction
in
startup
time,
as
you
might
imagine,
to
instrument
at
build
time,
and
it
was
also
more
within
the
the
sort
of
guidance
or
or
target
of
like
lambdas
and
functions
rather
than
like
growl,
but
maybe
there's
some
overlap
or
interest
in
reuse.
I
don't
know
just
want
to.
D
Make
sure
people
were
aware
of
it,
it's
pretty
cool
and
this
project
will
be
sooner
or
later
migrated
to
the
country
there's
already
an
empty
directory
there,
that
that
is
supposed
to
host
that.
A
Jason,
do
you
wanna,
I
mean
for
folks
who
may
not
know
do
you
want
to
summarize
a
little
bit
more?
What
this
does?
I
can.
I
didn't
work
on
it,
so
I
don't
know
it
that
well,
but
I
saw
it
demoed
so
I
can
I
can
I
can
fake
it
so
there
I
think
there
was
originally
a
maven.
This
is
a
maven
plug-in
right
so
at,
and
I
think,
there's
also
some
amount
of
work
on
a
gradle
plug-in,
not
sure,
but
essentially
at
build
time.
There
is.
A
This,
provides
tooling,
build
tooling
that
will
leverage
the
existing
open,
telemetry
instrumentation
and
do
class
file
transformation
at
build
time
rather
than
the
bite,
buddy
dynamic
class
loading
time.
So
the
same
instrumentation
is
applied
to
the
same
class
files,
but
it
happens
statically
at
build
time
rather
than
dynamically,
a
class
load
runtime,
and
so
the
output,
then,
is
a
fully
instrumented
app,
which
doesn't
incur
nearly
as
much
overhead,
because
the
the
wiring
of
instrumentation
by
code
instrumentation
takes
some
time.
There's
reflection
right,
so
there's
a
significant
amount
of
startup
overhead
to
applying
the
instrumentation.
A
A
But
like
jdbc
is
kind
of
a
bummer.
Maybe
although
we
have
custom
instrumentation.
D
D
F
Drivers,
oh
go
ahead!
So
how
badly
will
this
like
affect
the
stack
trace.
F
I
mean
like
adding
new
friends:
yes
in
production,
the
code.
What
is
running
is
not
the
source
code
that
you
can
see
in
the
sectors
anymore,
right
totally
yeah.
So
when
you.
A
A
A
Yeah,
the
one
thing
I
on
the
jvm
internals
that
I
was
thinking,
because
this
faster
startup
time
is
an
amazing
benefit.
We
definitely
have
more
customers
than
fit
on
one
hand
that
complain
about
the
startup
time
of
the
agent,
especially
on
these,
like
cpu
constrained
like
containers,
the
startup
time
is
magnified
and
it's
it's
not
great,
and
so
I
was
thinking
with
that.
You
know
we
could
have
a
very
lightweight
like
a
much
more
targeted
java
agent
that
just
targets
like
thread
pools
or
certain
internal
internals.
A
C
A
Because
we
have
to
to
make
it
fast,
we
have
to
not
walk
the.
We
have
to
not
care
about
the
super
classes
of
the
classes
that
we're
instrumenting,
because
that's
where
the
bytecode
instrumentation
gets
slow
is
we
have
to
start
doing
introspection
of
every
class
that
we
load.
How
do
you
know
that
trask
I
mean
other
than
just
being
super
smart?
How
do
you
know
that
know
that
that's
where
the
slowness
is.
E
A
From
lots
of
profiling
and
tuning
java
agents-
okay,
yeah,
whereas
if
you
just
have
a
static
like
I
want
to
match
this
exact
class
name
like
this
exact
java
internal
thread,
pool
and
apply
this
instrumentation,
that's
actually
quite
fast.
I
I
guess
we
could
try
improving
our
asian
performance,
like
we
probably
could
abuse
like
the
the
loaded
super
class
like
if
you
can
find
the
little
super
class
and
get
the
type
information
from
there.
It
would
be
significantly
faster
than
parsing
the
white
coats
to
figure
out
like
what's
the
super
class
and
traversing
the
hierarchy.
That
way.
A
So
like
cache
it
at
cache,
it
like
create
a
cache
during
one
startup
and
reuse,
that
on
subsequence.
I
I
was
meaning
that
like
currently,
if,
if
there
is
a
matchup
that
says
like
instrument
all
the
classes
that
implement
runable
interface,
you
would
need
to
look
up
like.
What's.
The
superclass
from
the
bytecode
then
find
the
bytes
for
the
superclass
and
see
if
it
implements
run
number.
I
No
not
exactly
like,
instead
of
parsing
the
bytecode,
if
you
could
say
that,
like
the
super
class
is
already
loaded,
we
could
ask
from
the
class
file
like
from
the
class
object
like.
Do
you
actually
implement
runnable.
A
But
on
the
on
the
loading
of
the
class,
we
still
have
to
inspect
the
byte
code
to
see
what
its
super
class
is
in
the
first
place
right.
I
A
Oh,
I
see,
and
so
we're
not
on
those
were.
I
thought
the
bite
buddy
would
return
us
the
it
has
a
resource,
resource-backed
view
of
the
class
file
and
a
class
backed,
but
maybe
not
yeah.
If
that
could
I'm
all
for
anything
that
makes
startup
faster.
I
But
of
course
like,
there
are
still
some
like
instruments
where
it
won't
work
like
I
think
somewhere
in
chuck's
rest.
We
have
like
method
if
it
extends
like
some
type
that
has
this
method
with
the
chaksa
rest
annotation.
C
A
So
actually,
there's
one
thing
I
forgot
about
for
that:
the
duplication
is
a
lot
better.
Now
has
been
solved
in
actually
a
lot
of
cases
if
you
use
the
instrumenter
api.
A
Yes,
in
that
case,
the
instrumentor
api
will
automatically
suppress
like
nested
server
spans.
So.
C
That's
for
tracing
so
if
we
get
to
metrics,
which
I'm
going
through
micrometers
api
at
the
metrics
layer
for
counting
our
http
server
requests
and
our
http
client
requests,
but
I'm
doing
that
for
rest
requests
out
of
the
vertex
layer,
because
quarkus,
of
course,
does
several
flavors
of
http.
So
I'm
doing
it
at
the
at
the
vertex
layer
outside
of
jaxres,
but
it
still
is
counts
right.
C
Does
that
mean
that,
in
order
to
have
this,
what
I'm
doing
within
quarkus,
which
at
the
moment
is
using
micrometer
in
order
to
avoid
duplication
with
an
agent
at
a
lower
level?
I
need
to
be
aware
of
and
use
the
micro
the
the
instrumentation
api
instead
or
is
that
where
micrometer
would
have
to
have
the
hotel
registry
involved?
That
would
use
the
instrumentation
api?
A
A
From
an
from
an
open,
telemetry
perspective,
at
least,
I
think
we
would
want
to
use
the
instrumenter
api
everywhere
and
the
instrument
or
api
knows
how
to
produce
request
metrics.
A
So
that's
all
built
in
to
the
instrumentor
api,
and
so
as
long
as
you're
using
the
instrument
or
api,
you
would
not
produce
request
metrics
on
your
own.
You
would
okay.
C
Because
that's
very
strange
and
unexpected
because,
from
the
rest
perspective,
knowing
what
the
template
of
the
uri
is
and
other
things
that
we're
aware
of
like
granted,
I
mean
we
are
using
it
for
tracing,
but
this
is
where
spring
has
a
long
history
of
how
it
produces
its
instrumentation
with
reason,
codes
and
exceptions
and
some
other
tags
that
open
telemetry
might
not.
A
In
both
met
tracing
and
metrics,
so
the
metric
stuff
is
some
recent
work
that
mateosh
has
been
doing
to
capture.
E
C
C
C
A
A
C
E
C
I
E
Instrumental
api
has
this
notion
of
of
an
extractor
right
where
you
can
just
basically
were,
is
going
to
extract
data
and
that's
what
the
thing
is
going
to
generate
the
tags,
all
right.
So,
for
instance,
you
remember
when
we're
talking
about
how
to
read
the
route
right
and
and
that
in
that
particular
case,
we
actually
put
the
route
yeah.
C
E
A
C
I'm
not
sure
that
it's
feasible
for
instrumentation
to
safely
handle
all
of
the
cases,
because
so
many
runtimes
are
doing
unique
things,
and
I
don't
know
this
is
where
we
have
this
tension
of
who's
supposed
to.
Who
knows
what
and
how
we
get
to
the
right
place
in
a
way,
that's
maintained
over
time
when
we
have
different
runtimes,
you
are
now
starting
to
optimize
and
do
things
in
very
different
ways.
That's
what
I'm
trying
to
say,
I'm
not
saying
that
we
can't
make
it
work,
I'm
trying
to
say
how
much.
E
We're
trying
to
do
there's
always
going
to
be
an
integration
point
that
you're
going
to
have
to
fit
in
right.
The
instrument
api
comes
with
some
reasonable
defaults
for
where
it
tries
to
to
retrieve
data
right.
If
you
have,
if
you
have,
for
instance,
an
http
request,
then
most
likely
you
can
go
to
http
request
and
retrieve
some
information
from
there.
But
things
like
specific
things
like
route
they're
not
really
easy
to
retrieve,
especially
because
they're
not
even
exposed
at
the
api
levels
at
the
framework
level
right.
A
C
I
I
feel
like
I'm
not
able
to
use
the
right
words
to
say
what's
in
my
head,
so
I'm
getting
them
frustrated,
but
it's
because
I
can't
words
aren't
right
so
like
here
you
have
stuff
to
instrument,
vertex
and
you're
gonna
say
well.
We
can
just
do
that
and
if
you
scroll
up
you're
gonna
say
well,
we
could
we
can
instrument
rest
easy
and
we
can
instrument
all
the
things.
C
A
So
I
think
what
we,
what
we
want
is
so
with
the
next
release,
there's
going
to
be
much
better
http
route
support
and
if
you
can
take
that
and
try
applying
that
to
your
to
quarkus
and
come
back
and
show
us
show
us
what
works
and
what
doesn't
work,
because
we
really
want
the
instrument
or
api
to
be
what
people
use,
because
there's
huge
benefits
to
not
just
to
a
more
opinionated
api
than
just
the
you
know:
open
telemetry,
api
free
for
all.
E
Right
yeah,
I
think
I
think
that
in
our
case
for
quercus,
you
always
going
to
have
some
sort
of
extension
where
you
have
to
extend
some
aspects
of
the
instrument
api.
So
you
can
feed
in
exactly
what
you
want
in
particular
aspects
to
retrieve
certain
tags.
So
route
is
one
of
them,
and
maybe
there
are
a
few
others
that
I
can't
remember
which
I
have
to
to
implement
manually.
But
I
don't
see
that
as
a
as
a
problem
right.
It's.
E
That
you're
always
going
to
be
always
because,
for
instance,
open
telemetry,
you
have
your
sure
you
have
vertex
integration.
You
have
rescues
integration,
which
we
use
in
quercus,
but
there
are
other
application
servers
that
both
use
vertex
and
rest
easy
and
they
might
be
using
it
in
a
different
way.
So
it's
going
to
be
impossible
for
open
telemetry
to
cover
all
of
these
cases,
so
they
have
to
go
with
the
minimum.
The
denominator
and
try
to
I.
J
Think
I
think
I
just
speak
for
open
liberty.
We
don't
use
the
vertex,
we
don't
use
the
like
that.
The
other
things
we
kind
of
we
have
our
own
framework.
So
I
think
you
build
kind
of
say,
okay.
This
is
how,
if
you
use
vertex,
this
is
the
way
you
should
use.
That's
a
pretty
much
fail
a
lot
towards
the
runtime.
C
Yeah,
they
already
have
a
lot
of
that
stuff
in
the
in
the
in
the
instrumentation
api.
Like
I
said,
we
that's
what
we
were
able
to
do
it
with
quarkus.
It
was
more
to
make
sure
there's
a
awareness
with
like
across
this
whole
organization
that
some
of
the
runtimes
do
very
esoteric.
Things
that
do
share
existing
libraries,
but
use
them
in
different
ways
is
that's.
I
guess.
A
A
Yeah
sorry
in
I'm
supposed
to
time,
moderate
yeah.
A
I'm
sorry,
I
do
real
things
yeah!
No!
No!
If
I
could
ask
your
roberto
to
bring
next
week
sort
of
show
us
how
it's
working
in
corcus
and
that
might
help
us
to
be
more
concrete
in
you
know,
next
steps
that
we
should
be
pursuing
here.