►
From YouTube: 2022-04-08 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
Yes,
so
dan
who's
been
very
active
in
other
areas
of
open
telemetry
I'm
joined
to
talk
about
the
jmx
metrics
gatherer.
You
probably
saw
he
opened
a
contrib
issue
on
a
rug.
A
Basically,
what
they're,
trying
to
figure
out
from
the
collector
perspective
is
whether
it
should
manage
the
jmx,
metrics,
gatherer
or
not,
and
dan
is
in
favor
of
it.
A
You
know
managing
that
from
a
user
experience,
kind
of
embedded
simplistic,
and
so
he
was
just
kind
of
curious
if
people
were
using
it
outside
of
the
collector
or
if
the
collector
was
sort
of
the
main
use
case,
with
the
idea
that
if
it
was
primarily
being
used
in
the
collector
that
that
maybe
it
could
be
more
tightly
integrated
and
that
could
help
help
them.
A
We
asked
that,
and
he
didn't
really
didn't
seem
to
think
that
I
think
more
spawning
the
sub
process,
but
just
that
the
contract
between
spawning
the
sub
process,
the
jvm,
wouldn't
need
to
be
defined
like
they
could
change
implementation
details.
Then.
A
He
didn't,
he
never
really
mentioned
the
security
angle.
Did
he.
D
C
C
Mentioning
something
about
an
implicitly
created,
otlp
receiver-
I
don't
know
what
that
means,
but
maybe
that's
the
interface
they're
talking
about,
but
on
the
flip
side,
maybe
less
coupling
is
even
better
because
I
think
a
job
that
just
pushes
otlp,
that's
a
pretty
normal
thing,
and
so,
if
the
jmx
gathers
just
treated
like
that,
I
I
mean
the
collectors,
the
side
cards
very
similar
to
start
at
the
gmx.
I
get
pushing
that
to
users
rather
than
doing
this
sub
process
stuff,
I
don't
find
that
to
be
a
significant
regression
in
user
experience.
C
A
A
Can
the
collector
scrape
prometheus
metrics
from
endpoints?
It
can.
D
D
So
it
doesn't
actually
manage
anything
other
than
like
starting
up
the
process
and
shutting
it
down.
It
doesn't
even
download
it
for
you.
You
have
to
like
download
it
yourself
and
include
it
and
reference
the
path.
A
C
Yeah,
if
the
idea
is
also
not
even
needed
in
downloading
and
stuff,
but
then
that
seems
to
make
sense,
but
still
just
if
someone
isn't
running
the
collector
and
they
just
want
jmx,
it's
also
pretty
easy
for
them
to
run
the
gm
expert
together.
I
guess
so.
Instead
they'd
probably
learn
the
collector
in
that
case.
Yes,
it's
okay,.
A
Yeah-
and
that
was
kind
of
I
think,
dan's
question
yeah
was
what
are
people
is
that
a
common
use
case.
C
A
A
And
I
was
thinking
for
like
the
java
agent
itself,
I
mean,
I
think
at
some
point
we
would
have
configurable
gmx
metrics
that
we
would
push
out
like
our
distro.
Has
that
where
you
can
configure
additional
like
jmx
your
custom,
jmx
metrics
and
we'll
push
those
out
which
could
cover
people
who
want
sort
of
custom,
gmx
metrics,
but
don't
want
to
use
the
java
agent
or
can
use
the
java
agent.
C
C
A
C
D
Yeah
they're
kind
of
trying
to
figure
out
what
role
they
play
with
the
collector.
C
B
A
C
D
The
the
use
case
for
that
will
be
limited
once
the
the
agent
offers
jmx
capabilities,
like
supposing
there's
a
library
and
auto
instrumentation
for
jmx
offered
through
open
telemetry
java
instrumentation.
D
What's
left
for
something
like
this,
it's
folks
that
want
to
kind
of
read
jmx
metrics
out
of
a
process,
but
don't
want
to
be
bothered
to
like
modify
its
code
to
add
that
instrumentation.
A
C
A
Good
point:
we've
been
run,
I've
run
the
java
agent
with
cassandra
and
kafka.
B
A
I
joined,
and
there
had
been
a
question
over
here
from
the
micro
profile
folks
about
timers,
and
so
it
sounds
like
they're
they're
moving
forward
with
their
abstraction,
but
with
looks
like
hotel
will
be
a
kind
of
a
you
know,
one
of
the
first
class
citizens
of
implementations
of
it.
A
And
so
yeah,
I
replied
after
to
this
with
this.
Basically
based
on
our
conversation
this
morning,
where
it
seems
like
for
their
use
case,
they
don't.
They
may
not
actually
need
a
timer
instrument
since
they're
already
providing
their
timer
instrument
and
then
they
could
map
it
to
histogram
already
in
a
hotel
which
would
be
nice.
I
don't
want
them
to
be
blocked
on
something
like
that,
because
I
think
that's
an
important
feels
like
that's
an
important
ecosystem
for
us
to
kind
of
if
we
can
get
hotel,
micrometer
and
micro
profile
all
sort
of
cooperating.
A
Yeah,
that's
also
one
of
the
arguments
I'm
trying
to
use
in
the
spec
repo
for
why
we
should
be
able
to
capture
additional
like
like
cpu,
because
still
getting
pushed
back
on
us
capturing
cpu
metrics
from
the
jvm.
A
C
Yeah,
so
I
mean
if
this
doesn't
go
anywhere,
we
can
just
add
a
spec
folder
to
our
open
genre
java
repo
and
put
our
javascripts
there.
Instead
of
dealing
with
this,
because
there
doesn't
seem
to
be
much
advantage
to
the
world
to
go
through
the
actual
spec
repo
on
this.
If
it's
just
going
to
be
a
lot
of
people
that
don't
understand
the
java
world
fighting
back
every
single
time,.
A
Yeah
that
that's
a
good
I'm
gonna
put
that
card
in
my
back
pocket.
A
D
A
Yeah
and
I'm
okay
with
I
mean
I
get
that
back
and
it
takes
time,
but
what's
frustrating
is
when,
when
it
just
like
gets
they
don't
allow
sort
of
momentum
to
carry
through
and
there's
like
a
block?
And
then
you
know,
there's
no
update
for
two
weeks
right.
A
D
D
A
That
is
the
problem.
Yeah,
that's
essentially
what
happened
on
jonathan's,
cpu,
avm
cpu
pr
right.
A
So
we
also
would
tell
a
little
bit
about
the
the
faster
matchers
and
the
jax
rs
and
jax
ws,
and
so
these
lori
was
explaining
because
I
asked
if
we,
if
we
disable
these,
if
we
lose
the
nice,
if
we
lose
http
route
right,
because
that's
that's
the
critical
one
and
he
said
no,
we
don't
because
we're
getting
that
from.
He
said
he
actually
and
I
forgot
this.
A
He
had
actually
moved
that
over
to
the
framework
specific
instrumentation,
the
jack
like
jersey,
rest
easy,
because
the
annotation
based
ones,
you
can't
really
know
for
sure,
like
you,
can
see
that
it
called
a
method
with
a
a
jax,
rs
annotation.
And
so
you
can
infer
that
that
was
part
of
the
route.
But
you
don't
actually
know
that
you
didn't
just
happen
to
call
that
method
as
a
delegate
from
another.
B
A
So
that's
good:
we
would
lose
the
controller
span.
That's
the
internal
span
for
that
annotated
method.
A
Lori
thought
that
we
might
be
able
to
get
that
via
the
framework
specific
instrumentation,
but
that's
all
for
jax
rs,
2
and
jax
rs2
jax
rs1.
We
only
have
the
annotation
based
instrumentation
and
jax
ws.
I
don't
know.
I
haven't
looked
at
that
so
anyway,
I
was
messing
around
a
little
bit
today
with
disabling
this
one,
because
I'm
especially
since
in
our
distro
we
don't
produce
the
we
disable
those
internal
spans.
Anyway,
I'm
excited
about
potentially
getting
that
performance
boost.
A
So
we'll
see
we'll
have
I'm
sure
here.
I
will
have
some
more
follow-up
on
this,
but
yeah
some
really
good
numbers
coming
out
of
that,
and
and
also
good
numbers
on
the
motivating
to
try
to
at
least
make
these
optional,
even
if
we
have
to
leave
them
on
by
default.
At
least
we
would
know
if
people
are
saying
hey,
I
want
better
startup
performance.
We
could
tell
them
what
to
switch
and
what
they
would
lose
by.
Switching
that.
A
A
C
Do
you
know
if
some
like,
for
example,
does
a
normal
spring
boot
app
have
those
on
the
clasp,
or
is
it
more
just
like
these
jboss
some
integrated
container
type
of
thing,
because
the
problem
is
that
these
annotations
tend
to
exist
even
without
being
used?
I
guess
so.
I'm
just
wondering
sort
of
there's
any
famous
libraries
that
do
that.
A
A
C
C
A
B
So
I
was,
I
was
looking
into
that
metric
descriptor
thing.
I
don't
think
we
need
to
make
metrics
descriptor
public
until
we
have
a
public
aggregator
api,
which
we
don't
have
as
a
part
of
this
release.
At
the
moment,.
D
D
Oh,
the
so
so
metric
descriptor
is
an
internal
class
yeah
and-
and
we
want
to
it,
actually
is
a
different
concept
than
what's
being
talked
about
in
that
in
that
issue.
So
like
metric
descriptor
is
kind
of
each
unique
metric.
Descriptor
is
like
a
stream
that
we
have
like
it
corresponds
to
so
like
one
to
one
with
like
unique
metric
streams,
but
like
what
what
what
this
issue
is
talking
about
is
just
some
collector
for
the
identifying
pieces
of
a
metric
so
that
you
can
more
easily
group
them
on
export.
D
It
would
be
weird
if
we
added
it
later,
because
you
would
want
it
like
right
now.
Metric
data
has
a
description
field,
a
unit
field
and
a
name
field,
and
you
would
want
to
get
rid
of
those
and
instead
have
a
get
descriptor
which
collects
those
fields.
So
you
wouldn't
want
both.
C
And
I
think
one
hard
thing
like
I
would
expect
the
metric
descriptor
to
have
the
attributes
on
it
as
well.
I'm
not
sure
exactly
how
that
would
happen
and
because
that
is
also
part
of
the
identity
of
a
metric,
I
guess,
but
that
seems
like
a
much
harder
refactoring.
So
it's
probably
just
too
much
work
to
do
right
now.
C
B
Between,
let
me
think,
if
I
can
so
actually
jack,
I
think
actually
honorary
is
right,
like
the
metric
stream
is
related
to
the
attributes
which
is
not
currently
exposed
on
metric
data.
Like
you
said.
D
But
there's
all
right
yeah,
so
I
each
this
is
where
it
gets
tricky.
So
a
metric
stream.
I
said,
like
you
know
you,
you
take
all
your
instruments,
multiply
them
by
the
views
that
so
you
know
they
they
match
to
and
that
that
produces
all
your
metric
streams,
but
each
metric
stream.
D
You
know,
which
is
basically
a
name,
a
description,
a
unit
and
an
aggregation
and
like
that's
its
own
thing,
but
within
each
one
of
those
there's
like
many
individual
points
representing
each
unique
set
of
attributes,
so
metrics
a
descriptor
right
now,
the
actual
metric
descriptor
class
collects
many
unique
sets
of
attributes
that
all
share
those
same
characteristics.
C
D
That's
what
I
was
thinking
you
know
it
seemed
like
it
was
inspired
by
your
your
marshaling
efforts,
and
you
know
there's
other
ways
to
do
efficient
grouping
that
don't
require
the
metric
data
to
have
an
extra
method.
D
All
right
and
then
the
other
pull
request.
4340..
It
looks
like
that's
approved.
Thanks
for
taking
a
look
at
that
yeah,
I
don't.
I
don't
have
anything
else
to
add.
I'm
I'm
happy
with
where
we're
at.
D
A
So
it'll
automatically
generate
the
release,
notes
from
the
changelog.
Oh
okay,
and
let's
see
today,
no
I'm,
I
think
I
just
yeah
when
I'm
doing
the
change
log
and
I
notice
you
all-
have
kind
of
a
different
format
for
the
changelog
in
this
repo.
A
I
think
I
ran
the.
I
think
I
tested
that
generating
the
release,
notes
yeah.
So,
ideally
it
will
create
the
release,
generate
the
release,
notes
over
there
from
the
changelog
and
publish
that
release.
Okay,.
D
I
was
just
asking
from
the
perspective
of
like
you
know.
If
we
still
need
to
manually
write
the
change
log
I
can.
I
can
do
that
update
tomorrow.
A
Oh
yeah,
so
that's
a
good
point.
Then
the
so
are
you
you're?
Okay,
with
releasing
with
not
having
the
release,
notes
populated
in
the
beginning.
A
So
it
creates
the
release,
notes
and
copies.
B
A
Log
from
the
last
version
to
the
current
version,
so
everything
in
between
these
and
then
it
it
actually
releases
like
so
it
it
attaches
and
clicks
the
publish.
A
D
C
C
To
do
so.
A
A
B
So
what
we
could
do
is
we
could
have
the
change
log,
be
version,
1.13.0,
dash,
unreleased
and
then
have
the
script.
Have
the
release
script
go
and
actually
look
for
unreleased
and
create
the
release
based
on
that
version?
Div
does
that
with
that
makes
sense,
and
then
we
would
be
able
to
get
the
release
notes
in
place
as
unreleased,
but
then
have
the
release
generate
the
actual
release
notes
and
then
we
can
do
a
change.
Log
change.
Log
update
is
a
separate
thing.
A
B
A
A
Yeah
I
can
make
that
change
today.
If
we
want
to,
I
would
love
to
go
through
to
make
it
before
the
release.
I
can
test
out
test
it
out.
A
Yeah,
do
you
want
to
jack
your
work
on
the
changelog
in
honor
of
tomorrow?
Well,
tomorrow's
your
saturday!
But
if
you,
if.
D
A
Coordinate
here
to
make
sure
that
that's
true,
because
it
is
yeah
I
gave
honorag.
My
estimate
was
like
about
90
sure
that
the
release
was
gonna
fail.
A
A
And
on
slack,
just
at
trask
is
like
that
busts
through
the
the
whatever
notifications.
B
C
A
C
C
A
Another
team
reach
out
to
me
and
ask
me
because
they're
doing
some
projects
and
doing
they
want
to
you
know,
do
some
fancy,
async
stuff
and
so
they're.
Looking
at
rx
java
and
reactor
and
they're
like
oh,
this
is
so
much
better
than
completable
future.
B
A
D
I
had
to
write
something
that
it
was.
D
It
was
like
a
web
service,
but
it
wasn't
just
necessarily
bounded
to
payloads
of
a
predictable
size,
like
people
could
ask
for
gigabytes
worth
of
data,
and
it
would
it
would
process
these
requests
and
continuously
gather
data
from
a
database
process
it
and
stream
it
to
the
client
and
yeah.
I
was
looking
at
reactor
a
bit,
but
I
I
was
able
to
do
it
without
that
with
just
like
completable
futures
and
streams.
A
A
B
A
C
I
find
it's
split
of
like
publishers
and
subscribers
and
then
the
ability
to
compose
those
to
get
very
out
of
hand
pretty
easily
because
completely
for
the
future.
It's
always
just
like
one
thing.
Well
with
the
reactive.
You
can
have
streams
composed
into
each
other,
and
it
gets
very
confusing
to
me
especially
then,
like
I
still
can
never
know
what
thread
any
particular
callback
is
being
called
on,
because
it's
either
the
producer
third
or
the
subscriber
did,
but
I
can
never
figure
out
which
one
it
is.
B
C
The
instrumentation
was
the
hardest
is
getting
that
context
propagated
to
all
of
those
steps
and
if
you
do
it
wrong,
which
we
might
be
doing,
I'm
not
too
sure
but
like
if
you're
mounting
and
I'm
mounting
a
thread
local
across
20
operations,
every
single
time
that
also
gets
quite
slow.
So
it's
very
easy
to
have
your
instrumented
reactor
app
just
tink
and
performance
that
red
locust
and
getting
managed
very
well.
A
And
even
if
that
is
the
the
performance,
is
okay,
the
the
stat
we're
tripling
the
size
of
these
back
traces,
which
are
already
really
huge
and
makes
it
look
like
makes
it
look
like
we're
doing
a
ton
of
stuff
whether
we
are
or
not.
C
My
go-to
is
still
dagger.
They
have
this
framework
for
stitching
together
features.
It
has
its
own
flaws,
of
course,
but
I
find
it
to
be
still
way
more
manageable
than
reactor
because
and
then
everyone's
using
like
unary
stuff.
So
why
use
the
stream
based
thing
for
you
know
like
it's
just
it
feels
of
respect
for
the
east
case
that
most
people
use
reactor
for
while
dagger
is
still
just
features,
so
it
just
feels
a
lot
more
manageable.
I
thought.
C
C
C
D
Yeah,
what
would
it
take
for
libraries
to
just
kind
of
step
up
it?
I
mean
spring's,
making
some
movement
right.
Didn't
they
say:
java
11,
17,
17,
they're,
skipping
11.
C
Well,
at
least
that's
what
they
first
announced.
I
wouldn't
be
surprised
if
they
attracted
that
decision,
but
yeah
they're,
saying
java
17,
which
is
oh,
wait
yeah.
It's
these
big
come
like.
I
think
I
don't
know
if
you
call
it
company
or
big
organization
or
something
like
if
google's
internal
uses
are
all
java,
11
and
they'll
migrate
to
libraries,
grp,
not
to
java
11.