►
From YouTube: 2021-12-16 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
All
right:
well,
we've
got
quorum,
let's
dive
in
just
in
case.
Nobody
has
seen
this.
We
did
publish
this.
Luckily,
we
were
not
vulnerable.
A
E
A
A
E
F
A
G
Well,
all
the
legend
doesn't
have
one,
but
the
splunk
agent
used
to
have
turned
out
that,
because
of
some
jagger
thrift
dependency,
we
actually
bundled
tomcat
inside
our
agent.
A
Yeah
I
had
in
a
early
version
of
our
agent
we
had
pulled
in
log
for
j
transitively.
I
don't
know
how
or
why
yeah
so
lots
of
fun
to
be
had.
A
C
A
C
C
The
only
the
only
information
I
got
is
that
otep
actually
hints
that
yeah
one
of
the
future
possibilities
to
have
parent
schema
future
idea
in
hotep.
It's
not
it's
not
anyhow
implemented
in
spec.
Yet.
A
Yeah-
and
we
still
have
even
with
that-
we
still
have
the
issue
of
whether
we
declare
the
entire
artifact,
whether
we
have
to
declare
the
entire
artifact
as
unstable.
If
we
have
some.
A
So
clearly
marked
so
this
was
sort
of
the
kind
of
sticking
point
to
me
of
what
does
clearly
marked
mean
because
normally
clearly
marked
as
unstable
would
mean,
as
the
version
would
be
dash
alpha.
A
A
Yeah
yeah,
I
it
looked
like
tigran's,
while
that
may
be
his
preference
to
declare
the
entire
artifact
as
unstable.
A
A
D
I
I
have
it
so
that
I
could
create
this
draft
just
before
this
meeting,
so
I
just
very
recently
started
working
on
upstreaming
our
meter
bridge
instrumentation.
We
use
micrometer
internally
in
splunk
agent
to
send
some
metrics
and
we
had
a
micrometer
instrumentation
that
breached
the
micrometer
from
the
application
to
the
micrometer
in
our
agent,
which
is
really
similar
to
how
open
telemetry
api
bridge
instrumentation
works
in
in
the
upstream
agent,
and
now
that
matrix
api
is
stable.
D
We
want
to
upstream
that
and
slowly
start
moving
our
stuff
to
the
upstream
we
go.
So
this
is
like
the
first
step.
Maybe
half
of
the
first
step
and
well
translating
micrometer
to
micrometer
was
pretty
simple.
I
mean
these
were
the
same
objects
just
in
different
packages,
because
one
was
shaded,
but
hotel.
D
No
micrometer
to
auto
is
is
a
bit
more
complicated.
So
I
added
this
pr.
It
contains
like
three
different
instruments
I
used
counter
gauge
and
timer
counter
engage
are
pretty
straightforward.
They
have
like
pretty
much
one-to-one
equivalence
with
open
telemetry,
which
is
not
the
case
for
it
for
timer,
because
timer
in
micrometer
exports,
oh
yeah,
that
that
was
it's
blank.
D
To
write
to
auto
got
it.
A
How
what
does
it
detect?
How
does
it
plug
in?
Does
it
plug
in
just
to
the
global
micrometer
registry.
D
Yeah,
just
the
global
one,
which
I
think
is
used
by
libraries
like
spring.
So
if
you're
using
spring
boot
and
have
micrometer
metrics.
A
That's
worth
double
checking
because
I
had
in.
I
had
done
something
similar
in
our
agent
early
on
and
I
had
to
do
separate
spring
boot,
actuator
instrumentation,
because
the
it
wasn't
using
the
global
micrometer
registry,
but.
D
D
D
Yeah
and
well,
it's
still
pretty
much
unfinished
anyway,
going
back
counter
engage,
are
pretty
straightforward.
They're
like
one
to
one
translations
counter,
is
double
counter.
I
think
engages
caged
upgrades.
D
Let
me
check
that
but
yeah,
something
like
that.
The
timer
is
a
bit
more
complex
because
in
micrometer
timer
exports
free
signals.
It
exports
the
total
time
the
max
time
in
the
count,
and
aside
from
that,
it
also
supports
micrometer
histograms,
where
you
can
define
like
slos
or
instagram
number
percentiles
that
you
want
to
capture
in
in
buckets
and
micrometer,
then
creates
gauges
for
each
packet.
D
So
this
is
probably
the
instrument.
That's
that
needs
to
be
reviewed.
The
most
I
used
a
similar
strategy
to
the
drop
with
altimeter
registry
micrometer.
D
I
think
either
bundles
or
has
a
separate
jar
that
basically
forwards
micrometer
metrics
to
drop
wizard
matrix
registries
and
they
use
the
they
basically
implemented
timer
in
a
way
that
just
uses
an
existing
histogram
with
instruments.
And
if
you
define
micrometer,
if
you
pass
any
histogram
distribution
settings
to
micrometer,
then
it
also
creates
those
additional
gauges.
D
So
it
I
use
the
same
behavior
here
so
that,
possibly,
if
you,
if
your
application,
defines
a
timer
that,
for
example,
defines
several
service
level
objectives
and
you're
also
using
like
custom
views,
then
you
will
have
like
duplicated
histograms.
But
I
I
guess
this
is
probably
fine,
because
it's
it's
not
possible
to.
I
I'm
sorry
can
I
can
I
ask
about
that
you're,
so
timer
is
actually
creating
multiple
instruments
in
the
sdk
or
is
it
creating
just
the
histogram
instrument
and
then
you're
using
views
to
do
those
other
signals.
D
I
Right
now
in
the
agent,
but
absolutely
should
it
be
yes
yeah.
So,
like
though
this
is,
this
is
a.
We
should
I'd
love
to
talk
more
about
that.
This
is
amazing.
By
the
way
I'm
super
excited.
Thank
you.
Views
are
meant
to
solve
that
problem
of
I
I
need
to
export.
You
know
max
as
its
own
gauge
or
count
as
its
own
gauge
or
like
a
percentile.
I
We
we
only
specified
like
four
kinds
of
aggregation,
so
the
like
percentile
aggregation
that
is
computed
client-side
is
not
there.
So
it's
just
not
a
feature.
Hotel
has
the
idea,
so
you
know
you
could
take
two
approaches
here
of
one
is:
if
micrometer
someone
says
that
they
want
a
percentile
gauge
exported
and
they're
using
hotel
hotel
exports,
a
histogram.
Sorry
like
that's,
that's
just
an
unsupported
feature,
initially
option
number
two
is:
we
can
actually
look
into
starting
to
specify
sdk
hooks
where
you
can
provide
the
views.
I
I
If
we
had
a
way
to
basically
get
those
percentiles
back
out
for
users
who
want
to
preserve,
you
know
old,
behavior
and
slow
migrate,
you
know
that'd
be
amazing,
but
we're
just
missing
it
right
now
in
the
sdk,
but
I'd
love
to
get
it
added
and
make
sure
we
support
that
use
case
yeah.
That
would
be
awesome.
B
D
B
Yeah,
like
I
thought
I
thought
like
with
the
way
I
was
reading,
what
you
were
saying
is
you
know
you
take
this.
This
histogram
from
from
micrometer,
which
has
more
information
than
our
histograms
and
open
telemetry
have,
and
you
translate
that
to
an
open,
telemetry,
histogram,
plus
some
additional
instruments
to
capture
the
information.
D
It's
slightly
different,
so
I'm
using
auto
histogram
as
a
timer
like
the
real
timer
right,
and
if
you
have
a,
if
you
have
configured
a
micrometer
histogram,
then
I'm
just
allowing
micrometer
to
create
those
additional
instruments
which
are
two
sets
of
gauges.
Basically,.
D
I
Right
yeah,
so
our
view
api
right
now
is
hidden
behind
the
sdk
on
purpose
and
it's
meant
to
be
kind
of
something
you
do
after
the
fact
where
the
instrumentation
so
from
an
open,
telemetry
standpoint
right
if
I
define
a
timer
instrument
that
timer
never
changes,
but
if
I
export
a
gauge
of
the
maximum
value
and
the
average
or
and
and
like
the
99th
percentile,
that's
supposed
to
be
like
a
view,
config.
I
What
we
cut
from
our
api
was
this
thing
called
hint
because
it
was
kind
of
we
weren't
clear
in
use
cases
and
we
weren't
clear
whether
or
not
it
would
actually
do
what
we
needed
it
to.
But
this
would
be
in
micrometer.
I
For
for
the
timer,
you
actually
can
specify
a
timer,
and
you
specify
the
timer
with
your
kind
of
aggregation
that
you
want
right.
That's
that's!
That's
what
we
would
call
it
so
like.
That's
all
your
histograms.
We
had
this
thing
called
a
hint
api
that
was
meant
to
allow
you,
when
you
instrument
to
say
here's
the
views.
I'd
like
you
to
use
if
possible,
right
and
then
the
you
would
do
this
all
in
the
api.
So
you
could
say
like
hey,
this
is
a
histogram,
but
you
should
export.
I
You
know
these
five
metrics
or
this
this
set
of
aggregation.
That
was
the
idea
behind
the
hint
api
where
the
user
provides
some
default
aggregation
as
part
of
the
api
that
we
use
so
right
now,
histogram
always
does
open
telemetry
histograms.
I
But
what
if
we
allowed
some
configuration
as
an
optional
thing,
when
you
create
the
instrument
that
got
cut
so
we
don't
have
it,
but
that's
what
I'm
suggesting
is.
If
we
understand
what
you
need
here,
the
one
of
the
goals.
I
think
that
riley
had
was
to
get
him
api
back
in
starting
next
year
into
the
api
once
the
sdk
is
stabilized.
I
I
think
what
was
proposed
would
not
have
allowed
you
to
solve
this
problem,
but
it
really
should
have
right
and
so
like.
I
have
the
same
issue
with
open
census,
actually
so
open
census.
There
is
no
instrument,
there's
just
measurements
and
everything's
a
view,
and
I
have
no
way
to
bridge
the
two
at
all.
So
we
went
with
a
completely
different
approach
so
anyway,
sorry,
I'm
talking
too
much.
D
Yeah,
and
just
just
by
the
way,
my
computer
also
has
measurements,
which
I
just
completely
ignored,
because
they
don't
really
need
to
be
read
by
by
our
metrics
registry
and
well,
we
can.
We
have
no
way
of
reading
them,
retrieving
the
data
from
the
api
so
and
yeah,
so
the
hint
api.
I
think
it
if
it
would
be
possible
to
translate
all
those
histogram
aggregation
settings
then.
I
I
I
do
want
to
get
percentile
calculation
in
client
added
back
in
at
some
point.
If
it's
a
mandatory
thing
for
users,
I
think
it's
better
to
do
it
in
the
server.
But
if,
if
people
want
it
client-side
we
can
totally
do
it.
Can
you
open
an
issue
that
describes
something
for
people
who
don't
have
context
on
micrometer
or
java
in
the
spec
around?
Like
hey,
I
tried
to
do
bridging
here's.
The
issues
I
ran
into,
I
feel
like.
We
need
a
solution
to
this.
B
And
just
to
confirm
so
these
the
percentiles
that
are
being
emitted
from
these
micrometer
histograms.
It's
something
like
you
know.
You
tell
micrometer.
I
want
you
to
also
emit
the
75th
percentile
of
this
timer
and
then
it
it
says:
okay,
yes,
and
it
like
when
you
export
it,
it
emits
okay,
the
70th
percentile
for
this
window
was,
you
know,
88
milliseconds
or
something
yeah.
That
okay
and
you
know
pretty.
B
B
Yeah,
so
I
guess
what
we
should
probably
look
to
understand.
Josh
is
like
we
should
probably
study
what
a
micrometer
histogram
consists
of
and
just
like
see
if
all
of
the
settings
can
translate
to
things
that
you
could
do
with
a
vue
in
open
telemetry,
because
if
there's
not
a
one-to-one,
then
you
know
it
doesn't
really
matter
what
the
hint
api
provides.
We
can't
do
it.
I
Yeah
yeah,
I
think
I
think
that's
why,
having
the
issue
discuss
all
the
problems,
then
we
can
open
sub-issues
but
like.
I
If
you
look
at
the
aggregations
we
have
available
in
our
api,
it
is
optimized
around
only
exporting
otlp
and
doing
everything
else
in
like
a
collector,
but
in
practice
I
think
we
might
need
to
offer
more
client-side
telemetry,
especially
for
java.
If
you
look
at
drop
wizard,
if
you
look
at
micrometer
like
there's
an
expectation
there,
but
we
only
have
the
minimum
right
now.
A
I
had
one
quick
question
in
the
your
prior
implementation:
would
did
you
use
a
like
a
splunk
meter,
red
registry
and
still
do
the
aggregation
was
happening
in
micrometer
inside
the
agent
class
loader
and
then
on
export?
You
were
translating
it
to
otlp.
D
We
weren't
actually
using
otp.
We
were
using
the
signalfx
metrics
format,
which
has
a
standard
implementation
standard
metric.
A
Yeah,
no,
this
is
awesome
to
have
it
go
into
the
actual
ot
hotel,
metrics
sdk.
A
A
All
right,
so
I
sent
this.
F
Just
I
want
to
maybe
preempt
a
thing
in
the
agenda
here
I
have
to
take
off
in
five
minutes.
Oh
josh,
you
do.
We
need
to
talk
about
the
of
double
stuff,
while
I'm
here.
I
Okay,
I
wrote,
I
wrote
my
thoughts
in
the
bug
it.
I
know
that
john
you
and
anurag
both
thumbs
it
up.
So
I
I'm
just
curious.
If
anyone
has
anything
they
want
to
talk
about
here,
we
did.
If
I
recall
correctly,
we
had
almost
exactly
the
same
discussion
with
the
same
proposal
in
the
sake
but
effectively.
I
The
question
here
is:
there's
a
concern
around
the
fact
that
our
counter
returns
a
int
counter
and
has
an
of
doubles
in
the
builder
to
switch,
and
then
our
histogram
and
gauge
return,
double
recording
things
and
have
of
longs
or
events.
I
forget
which
one
it
is
to
switch
and
that
that's
inconsistent
and
hidden
and
confusing
to
users.
I
A
I
mean
lack
of
the
user
input
well.
I
Yeah,
how
how
hard
was
it
for
the
the
micrometer
use
case
is
a
pretty
significant
one
like
was
that
something
that
three
for
a
loop
with
count,
because
I
know
micrometer
counters
are
doubles
right,
yeah,
no,.
I
I
I
would
say
you
are
the
closest
to
a
real
user.
We
have
here.
Okay,
that's
true,
I
guess
yeah,
the
the
only
user
feedback.
I
remember
that
we
had
was
around
the
bind
api
and
somebody
wanted
the
ability
to
like
pre-allocate
attributes
as
a
convenience
and
then
also
add
more
attributes
later.
D
B
Another
data
point
so
ben
used
metrics
in
the
jfr
implementation
ben.
Do
you
have
any
comments
about
how
it
was
to
use
that
api.
J
It
was
okay,
once
I
got
my
head
around
it,
I
I
used
bind
in
a
couple
of
places,
but
it
wasn't.
It
wasn't
super
essential.
My
my
my
feeling
is,
you
know,
providing
me
document
this
stuff
properly
and
actually
get
a
good
introductory
user
guide
to
it.
Then
I
think
it
will
be
fine
it.
It
was
a
little
counter-intuitive
at
the
start,
but
once
I
I
bashed
my
head
against
it
for
the
for
the
requisite
period
of
time.
I
I
thought
it
was
a
pretty
decent
api.
I
Did
you
get
hung
up
by
of
double
and
oblong,
like
was
that
you
said
you
had
to
bash
your
head
against
it?
Was
it
more?
One
of
our
assumptions
is
that
picking
instruments
is
the
confusing
part.
We
want
users
to
think
through
what
that
is
picking,
whether
you're,
recording
a
double
or
long
is
not
really
that
important
to
most
people,
and
we
wanted
a
good
default.
So
I'm
kind
of
curious
how
true
that
is.
J
Yeah,
I
think
that's
pretty
true,
I'm
you
know
I
I
certainly
you
know
I
I
didn't
have
any
particular
problems.
Anything
which
was
was
of
of
obviously
integral
type
was
of
long
and
everything
else
was
of
double.
J
A
A
I
mean
that's
the
one
thing
I
like
about
it
is
that
it
does
help.
You
choose
the
right
default
most
of
the
time,
and
I
was
wondering
if
over
here
does
that
match
all
the
specked
out
instruments
like
up
down
counters
are
always
in
64
and
gauges
are
always
double
in
this
pack.
I
I
I
Right
and
like,
for
example,
the
the
int
double
distinction
in
like
prometheus,
almost
doesn't
matter,
because
everything
kind
of
becomes
a
double
when
you
export,
so
the
there
are
systems
where
instant
double
is
called
out
all
the
way
down
to
the
storage
level.
I
Google
cloud
monitoring
is
one
of
those
systems
where
we
can
actually
store
integers
and
doubles
separately.
You
get
the
precision
of
an
int
when
you
store
an
int,
you
get
the
precision
of
double
when
you
store
a
double
in
practice,
though,
like
there
are
times
where
it
matters,
and
it's
not
significant
enough
that
I
even
care
for
the
most
part
for
instrumentation.
If
we
went
with
a
all
double
solution,
it
wouldn't
be
the
end
of
the
world
for
open,
telemetry
and
it'd,
be
in
line
with
other
things.
I
I
think
there's
reasons
for
us
to
optimize
that
are
entirely
related
to
runtime
performance.
I
So
I
think
defaulting
to
int
is
actually
a
pretty
good
thing
for
us
right
now.
You
know
adding
to
an
integer
versus
adding
to
a
double,
especially
if
it's
in
a
hot
path
is
just
enough
that
it
matters
when
it's
at
scale.
I
A
And
makes
it
micrometer
we'll
make
all.
I
A
A
A
Yeah
yeah-
let's
we'll
punt
this
till
this
evening
and
with
honorary
or
will
you
be
there
this
evening.
I
I
don't
think
it's
a
we
have
we
have
our
championship,
volleyball
game,
so
I
don't
know
if
I'm,
if
I'll
make
it
or
not
depends
yeah
thanks,
yeah
man,
recreational
volleyball,
it's
totally
a
thing,
so
if,
if
I
do
make
it
cool
my
my
current
thinking,
though,
is
that
we
had
already
discussed
this.
I
think
most
of
us
are
on
board.
That
of
doubles
and
of
longs
is
not
the
problematic
part
of
our
api.
I
yeah
the
I'm
more
worried
about
up
down
counter
honestly,
but.
A
Close
to
the
right
too
many
tabs,
okay
onto
logging,
there's
been
some
good
progress
in
the
in
the
sdk
repo,
also
with
logging.
I
think
we're
kind
of
all
chipping
away
at
it.
If
you
have
a
chance.
This
is
the
kind
of
appender
api
that
we've
discussed,
which
we
need
in
the
instrumentation
repo,
because
we
don't
want
instrumentation
to
depend
on
the
sdk
directly
on
the
sdk.
A
So
this
is
just
a
really
basic
shim
on
top
of
the
log
sdk,
with
these
types
delegating-
and
it's
got
a
no
op
in
implementation
and
a
global
because,
like
the
log
for
j
appender
is
needs,
is
configured
via
the
xml
configuration,
so
you
can't
inject
stuff
into
it.
A
Well,
you
could
at
later
on
at
run
time,
so
that
that's
certainly
an
option,
and
then
this
will
allow
us
to
bridge
in
the
agent
is
also
why
we
need
a
api
to
be
able
to
bridge
into
the
agent
very
similar
to
helmet.
Ish
was
describing
the
micrometer
bridge
bridging
into
the
agent
so
yeah.
If
you
have
a
chance
to
take
a
peek
at
this,
I'm
sure
this
will
evolve
over
time
as
we
get.
It
looks
like
we're
getting
possibly
a
global
in
the
sdk.
A
B
A
Yeah,
so
I
think
once
we
have
these
two
things,
we
may
have
a
shot
at
getting
that
all
hooked
into
the
agent
and
emitting
log
telemetry,
that's
awesome!
A
A
Cool
meeting
just
quick,
update
meeting
schedule,
I'm
going
to
cancel
all
the
java
meetings
for
the
next
two
weeks.
A
Anything
any
other
topics
anybody
wanted
to
chat
about
today.
Before
I
just
give
the
quick
week
in
review.
H
Yeah
really
really
quick.
I
opened
an
issue
on
the
other
configuration
size
and
I
wanted
to
to
know
your
opinion
about.
It
is
because,
in
the
open
telemetry
for
the
tracer
configuration,
we
are
registering
a
shutdown
hook
for
jvm
to
call
dot
close
on
the
tracer
or
actually,
then
it
calls
the
the
dot
close
on
the
on
the
worker
thread
that
exports
all
the
spans
right.
H
Now.
The
issue
is,
if
you
use
auto
configuration,
let's
just
say
on
on
an
application
and
then
you
deploy
in
that
application
on
on
a
multi-app
environment
right
then,
your
life
cycle
to
call.close
is
not
on
jvm
shutdown,
but
also,
I
was
actually
on
the
app
shutdown
right.
H
So
it
means
that
on
the
auto
configuration
side
of
things,
you
cannot
call,
or
you
cannot
register
the
shutdown
hook
for
a
dot,
close
method
on
on
the
tracer,
meaning
that,
on
the
auto
configuration
side,
you
have
to
have
a
way
to
exclude
the
registration
of
the
shutdown
hook,
but
the
tricky
part
is
then
you're
able.
Then
you
require
to
have
an
instance
of
the
tracer
or
actually
is
the
sdk
tracer
provider,
because
that's
the
one
that
implements
closable
to
be
able
to
call
dot
close.
H
H
So
I
was
wondering
if
any
of
you
already
encounter
such
issue
or
if
you
have
any
thoughts
on
any
thoughts
on
this,
especially
because
I
think
that
right
now
there
is
no
way
if
you're,
using
auto
configuration
to
access
the
sdk
dresser
provider.
H
A
I
So
I
I
had
this
issue
as
well,
but
I
believe
auto
configure
actually
does
register
a
shutdown
hook
itself.
It.
B
So
you
you
call
whatever
the
method
is
auto
configured
open,
telemetry,
sdk,
initialize
at
application
start.
I
Yeah
yeah,
but
the
issue
is
like
flush
and
close
are
only
available
in
the
sdk
and
we
never
exposed
the
sdk
ever.
That
was
like
considered
a
thing
java
doesn't
do
so
like
anyone
who's
doing
anything
manual
just
cannot
close
or
flush
any
sdk.
It's
not
just
tracers,
it's
metrics
and
I
I
don't
know
what
logs
looks
like,
but
probably
logs.
If
that
has
a
flush
or
a
close,
so
I
think
it's
just
like
it.
I
I
ran
into
this
as
well.
I
B
I'm
not
sure
I
follow
josh.
If
you're
using
auto
configured
open,
telemetry
sdk,
you
can
get
your
hands
on
an
instance
of
the
open,
telemetry
sdk,
not
just
the
more
generic
open,
telemetry
interface.
H
B
I
wait.
I
must
be
missing
something
because
if
you
call
like,
I
thought
you
were
calling
auto
configured
open,
telemetry
sdk
initialize
at
the
beginning
of
your
application,
yeah,
and
if
you
call
that,
then
you
can
call
after
that.
You
have
an
instance
of
auto
configured,
open,
telemetry
sdk,
and
from
that
you
can
get
an
open
telemetry,
sdk
instance,
and
from
an
open
telemetry
sdk
instance,
you
can
get
like
sdk
tracer
provider
without
any
obfuscation
or
reflection.
A
Yeah
check
out
how
the
the
java
agent
is
doing
this
actually
because
we
have,
for,
I
believe
the
lambda
instrumentation
is
doing
a
force
flash
after
every
request.
A
We
grabbed
the
open,
telemetry
sdk
set
that
aside
and
then
when
we
want
to
call
force
flush,
we
have
kind
of
a
a
redirect
api
internally.
That
will
then
call
force
flush
on
that
sdk
tracer
provider.
B
Yeah,
so
if
you
have
a
auto
configured
open
telemetry
sdk
instance,
you
can
set
that
globally,
wherever
you
want
or
statically
wherever
you
want
and
then
access
it
and
it's
and
therefore
you
have
like
a
static
accessor
for
the
sdk
tracer
provider
or
whatever
you
want
now
we
still
don't
solve
your
problem
of
you
know.
We
still
have
that
shutdown
hook.
That's
added
and
there's
no
way
to
not
add
that
or
is
it
would
you
want
to
remove
that
shutdown
hook,
or
would
you
just
want
to
when.
H
It
when
I
believe
with
that,
so
I
think
I
so
to
answer
the
first
thing
I
yeah.
I
was
not
aware
of
this
open
telemetry
sdk
access,
because
that
basically
gives
you
the
the
the
way
to
force
the
flush
which
you're
not
able
to
do.
H
If
you
only
have
the
object
directly
now
on
the
on
the
other
configuration
side,
I
think
there
needs
to
be
a
way
for
you
to
optionally,
not
register
the
shutdown
hook
right,
so
it
can
still
be
as
a
default,
but
then
even
either
on
the
api.
I
have
a
way
to
say:
do
not
register
the
shutdown
hook
or
just
have
a
configuration
to
skip
the
registration.
H
Well,
you'll:
you
need
to
keep
an
instance
on
your
hand
of
the
thread
that
registers
the
shutdown
hook,
yeah.
A
H
H
A
A
Yeah,
this
makes
sense.
This
makes
sense
to
me
because
in
your
case
exactly
you
on
this,
like
undeploying
a
war
file,
you
we
would
want
to
remove
that
shutdown
hook.
Otherwise
we're
going
to
leak
class,
loaders.
A
Cool
anything
else.
A
So,
just
quickly
the
week
bunch
of
stuff,
as
always,
went
in
the
last
week,
exposing
the
the
more
the
auto
configured
open,
telemetry
sdk
in
the
agent
extension
spi,
so
that
oops.
Why
am
I
clicking
the
wrong
button?
A
No,
I
meant
to
ignore
that
meeting
not
to
join
that
meeting.
Sorry,
I
forget
what
this
use
case
was.
B
So
so
the
the
agent
listeners
can
have
access
to
the
resource
so
auto
configured
open,
telemetry
sdk
gives
you
access
to
the
resource,
along
with
just
the
open,
telemetry
sdk.
So
therefore
sdk
tracer
provider,
sdk
meter
provider
and
and
so
now
we
can
safely
and
that's
a
that's
a
use
case
in
in
the
splunk
distribution.
B
They
need
access
to
the
resource,
and
so
now
we
can
remove
a
couple
of
deprecated
static
accessors
for
getting
the
auto-configured
resource
from
the
auto-configure
module.
That's
very
confusing.
E
A
E
D
So
I
I
right
now
I
prefer
using
config
in
the
agent
because
it
has
config
properties
is
not
safe.
If
you
call
a
method
on
it,
and
you
know
somebody
configures
an
integer
which
is
not
actually
integer,
you
get
the
config
files
exception
or
whatever,
while
the
java
agent
config
doesn't
throw
ever,
it
will
return
the
default
value
that
you
that's.
The
user
of
this
api
have
provided
so
it's
very
safe
to
use
in
sites
instrumentations
like
if
you're
injected
into
some
third
party
class.
B
Not
I
can't
address
the
global
piece,
but
I
suppose
the
the
exception
free
accessors
and
the
optional
aspect
that
you
mentioned.
Those
are
those
are
definitely
nice
usability
things.
You
could
probably
get
away
with
some
utility
functions
that
accepted
config
properties
and
applied
those
you
know
it
wouldn't
be
as
user
friendly,
but.
D
Yeah,
I
I
also
thought
about
maybe
just
slightly
refactoring
config
so
that
it
doesn't
have
like
its
own
copy
of
the
whole
configuration,
but
it's
just
a
like
a
safe
wrapper
over
complete
properties,
but
we
would
have
to
pretty
significantly
remodel
the
whole
edge
agent
initialization
procedure.
But
I
think
that
that
would
be
possible
too.
E
E
A
Cool
in
our
final
minute,
plus
the
we
have
rpc
metrics
now
following
the
metric
semantic
conventions
for
rpc
mateusz,
has
been
doing
some
background
work
in
preparation
for
capturing
http
route,
which
is
especially
important
for
metrics
for
http
metrics.
A
A
Awesome,
thank
you.
That's
our
very
final
instrument
or
api
conversion,
more
work
towards
stabilizing
the
instrumentation
api
so
trying
to
make
as
much
stuff,
private
and
internal
as
possible
limit
our
public
api.
This
is
more
stuff
about
limiting
our
public
api
quarkus.
A
More
bug,
fixes
bug,
fixes,
bug
fixes
and
we
decided
to
take
advantage
of
look
on
the
bright
side
of
the
log4j
problem
and
we
previously
had
this
weird
base
version
that
our
our
library
instrumentation
only
supported
213-2,
because
that's
when
oddly
log4j
introduced
a
new
feature
in
a
patch
release
that
allowed
us
to
do
the
context
integration.
A
But
then
there
was
also
a
bug
in
this
version
that
was
fixed
in
this
version
so
that
the
library
instrumentation
really
only
worked
in
this
version,
but
in
auto
instrumentation
we
injected
the
library
over
here.
So
that
was
just
a
mess.
So
we
decided
to
take
advantage
of
the
fact
that
nobody
should
be
using
library
instrumentation
on
anything
less
than
216.
Now
so
library
instrumentation
now
targets
auto
instrumentation,
still
targets
2,
7
and
above
but
starting
at
216.
A
A
A
All
right,
two
minutes
over
like
to
give
you
time
to
walk
to
your
next
meeting.
Have
a
great
holidays
won't
see
you
all
for
well
other
than
those
who
I
see
tonight,
but
I
won't
see
you
for
a
long
time.