►
From YouTube: 2022-01-11 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
Well,
we
can
start
with
one
that
probably
is
more
less
nikita
and
more
youtube.
I
don't
know
if
you
had
a
chance
to
look
at
this.
A
It's
with
a,
I
don't
know
if
I
will
call
it
significant
or
not
significant,
but
it's
a
big
change
across
all
the
attribute
extractors
so
definitely
want
to
get
your
thoughts
on
it.
It
did
remind
me
of
sort
of
a
related
discussion
we
had
over
here.
Essentially
the
the
pr
does,
what
you
were
saying
here,
honorable
just
like
the
two
types,
the
the
getter
and
the
the
attributes
extractor,
and
so
it
made
sense
like
not,
I
tend
to
agree
with.
Well,
I
don't
know
I
to
me:
I'm
not.
A
The
two
types
also
carries
some
weight
so,
but
you
had
some
thought
on
at
least
sort
of
it
doesn't
really
hide
the
two
types
but
allows
you
to
at
least
simplifies
the
interaction
in
the
instrument
or
adding
them.
C
C
A
We
started
on
one
that
I
well,
you
may
very
well
may
have
an
opinion
about
this.
I
know
it's
a
it's
a
it's.
The
attribute
extractor
design,
oh
yeah,
jason's,
pr
to
split
out
sort
of
the
the.
A
I
don't
know,
I'm
not
thinking
of
the
right
words
to
explain
the
the
design
pattern.
C
B
Anyway,
with
jason's
idea,
I
think
it
like
having
http
attributes
extractor.create.
It
would
look
pretty
similar
to
how
we
handle
spam
name
extractors
or
spam
status
extractors.
So
I
guess
there
would
be
similarity
to
what
we
already
have.
B
B
A
Basically,
splitting
like
something
like
this
up
into
two
pieces:
there's
the
part
that
has
the
implement
the
part
that
does
the
work
like
the
and
then
extracting
these
into
pure
interface,
a
pure
interface
that
honorable
was
kind
of
calling
the
getter
interface
and
then
passing
this
getter
interface
into
the
extractor.
That
way,
you
don't
need
to
you.
Don't
need
inheritance
here,
yeah,
okay,.
B
And
they
might
get
unwieldy
at
some
point
in
time
and
I
think
it's
more
kind
of
like
a
style
question
here
that
usually
people
prefer
not
using
very
complicated
inheritance
hierarchies.
C
D
D
D
A
Okay,
I
think
that's
good
enough.
We
can
discuss
on
thursday
with
jason.
I
just
wanted
to
get
sort
of
feedback
before
we
discuss
with
him,
but
it
sounds
like
people
are
sort
of
okay
with
it.
If,
but
maybe
we
can
ask
him
to
kind
of
put
together
well
with
the
getter,
I
guess
showing
how
that
getter
piece
works,
which
is
slightly
different,
a
little
change
to
his
existing
pr.
D
That
pretty
significant
change
in
the
api-
and
we
are
like
on
the
verge
of
making
the
api
stable,
doesn't
somehow
push
our
stability
deadline
further,
because
we
have
like
new
api
and
we
somehow
want
to
make
sure
it
works.
So
again
we
have
to
migrate
all
our
existing,
but
assuming
he
already
does
that
in
this
pull
request,
so
yeah,
okay,
so
another!
So
do
we
want
to
do
that?
Migration.
B
D
B
A
D
B
B
A
And
a
couple
of
those
items
are
very
big
like
reviewing
every
single
method,
class
and
public
class
and
method.
We'll
probably
think
of
that
will
probably
spawn
new
ideas.
C
C
B
D
A
All
right
for
110
this
week,
I
think
there's
just
three
things
that
I
know
about
that.
We
need
this
is
probably
the
well
it's
not
actually
that
big
I
had
so
does
this
seem
good.
I'm
just
gonna
do
a
really
straightforward,
rename
instrumentation
appender
api,
internal
instrumentation,
api,
sdk,
internal.
D
B
You
would
have
to
make
sure
that
shading
and
medication
works
properly
in
that
case,
because
we
usually
treat
everything
under
io
asymmetry
instrumentation
as
instrumentations,
except
the
api
package.
B
A
And
I
was
kind
of
this:
is
the
convention
in
the
sdk
repo,
partly
because
things
are
split
across
different
modules,
and
so
it's
weird
to
have
internal
at
a
higher
level.
That
would
then
be
shared
across
different
modules.
Yeah,
okay
and
jpms
will
not
be.
C
C
A
Yeah,
I
guess
the
more
important
thing
that,
because
we
have
to
live
with
it,
for
you
know
longer
or
it's
is
the
module
name,
artifact
id.
A
All
right:
well,
if
you
think
of
anything
today,
post
it
nikita,
otherwise
we're
rolling
on
I'll,
probably
do
it
tomorrow
and
we
don't
there's
no
reason
we
need
to
wait
for
the
end
of
the
week
depending
on.
If
there's
anything
else,
is
there
anything
besides
these
three
that
anybody
knows
matthias?
Did
you
want
to
get
the
micrometer.
B
Done
yeah:
we
we
don't
really
need
it.
I
mean
splunk
doesn't
really
need
it
to.
We
don't
have
to
get
it
into
that
release,
but
I'm
wondering
whether
we
shouldn't
wait
for
it
anyway,
because
it
it
would
be
a
pretty
good
timing.
You,
with
the.
A
D
C
C
Like,
for
example,
adding
support
for
shutdown,
I
guess
we
implemented
in
our
own
registry
or
something
like
that.
Okay,
is
that
correct.
B
B
C
A
Yeah,
I
have
it
on
the
milestone.
D
Yeah,
so
let
us
take
a
little
step
back
here.
So,
first
of
all,
currently
our
jpi
compare
targets,
in
my
opinion,
are
totally
useless
because
we
don't
have
stable
api
yet
so
what
are
we
doing?.
D
That's
like
first
step,
then
we,
which
I
don't
understand,
is
how
exactly
somebody
a
person
can
review
public
api
changes
before
release.
I
don't
understand
how
this
specifically
like
workflow,
should
happen.
D
No,
I
mean,
I
assume
that
all
pull
request
was
successful.
Now
we
are,
we
are
ready
to
make
a
new
relief,
but
we
want
to
make
sure
that
we
that
all
changes
to
public
api
I
expected
and
okay,
how
that
happens.
C
C
D
A
C
C
D
D
A
C
C
A
C
A
C
D
But
if
you
want
to
che,
if
you
want
to
check
new
api
changes
in
pr
in
pull
request,
that
means
that
pr
author
should.
A
A
I
don't,
I
don't
think,
that's
any.
I
think
we
have
bigger
complicated
complexities
in
the
instrumentation
repo
for
new
contributors.
D
D
D
Okay,
that's
that's!
That
may
be
a
little
a
little
elevated,
okay,
but
okay,
then
the
last
question
for
me
is
so
currently
in
our
repo
in
instrumentation
repo
that
api
comparison
task
is
useless
because
we
don't
add
anything,
we
don't
fail
anything
we
don't
so
we
either
should
make
it
useful
or
we
should
remove
it
until
we
are
stable
and
then
we
have
to
make
it.
D
Approach,
so
we
yes,
when
we
add
that
when
we
have
that
back,
I
will
have
to
deal
I
we
have
to
do
it
in
some
way,
which
god
will
happy,
or
we
have
to
accept
that
one
step
is
a
little
bit
weird
greatly,
but
I
will
deal
with
that.
Okay,
at
least
now.
I
understand
what
we
want
and
that's
not
such
a
big
deal,
but
we
can't
say
gradle,
step.
A
Let's
back
that
good
to
hear
so,
does
everybody
prefer
to
to
use
java
util
logging
exclusively
and
just
via
shading
and
via
our
patch
logger
or
in
the
agent
continuing
to
use
slf4j
in
library
instrumentation
using
ju
j
javita
lagging.
D
C
D
A
So
we
shade
we
can
use
java
to
login,
because
in
the
agent
we
shade
that
to
the
patch
log
to
that
patch
logger,
which
then
internally
in
the
agent
then
uses
slf
for
j.
A
A
I
guess
we,
I
guess
we
could.
We
can't
use
javito
lagging
because
of
the
jboss
stuff,
or
at
least
not
without
you
know.
We
could
think
about
that.
But
that's
painful
and
you
know
we
don't
really
want
to
lose
startup
logs.
A
D
Yes,
but
that
so
my
thoughts
are
exactly
like
having
hope
we
already
have
a
lot
of
requests
in
this
repo
that
can
we
direct
logs
to
somewhere
else
files.
Can
we
have
the
same
login
configuration
as
with
application?
What
not
so
using
jool
would
like
to
solve
that
customers
just
have
their
existing
dual
configuration.
B
D
B
D
D
The
only
problem
is
indeed
that
jbl
is
logging.
So
if
we
can
solve
jboss
login
problem,
I
would
prefer
to
use
the
full.
B
D
A
So
to
regardless
of
whether
we
can
do
get
to
the
full
pipeline
director
logging
pipeline,
can
we
make
a
decision
just
on
this
one
I
mean:
are
we
good
to
just
go
at
least
forward
with
javi
to
logging
for
all
our
api,
all
our
actual
usage,
and
because
that
would
be
a
change
we
could
make
and
then
we
can,
you
know.
Definitely,
you
know
explore
this
separately.
D
What
was
the
game?
The
initial
reason
to
create
that
issue.
A
This
was
just
me
realizing
that
we're
using
ultimately
in
library,
in
particular
library,
instrumentation,
and
I
know
that
that's
not
consistent
with
the
sdk
and
okay,
so
it
is
consistent.
Yeah.
D
D
But
I
wonder
so
if,
if
we
so,
if
everybody
uses
all,
if,
if
we
use
jool
or
java
platform
login-
and
there
is
zero
data
exploit
in
there,
how
fast
fixed
to
that
will
be
propagated
to
all
production
systems,
that
would
be
a
bummer.
A
A
Let's
see
the
I
think,
we're
doing
pretty
good
on
contribute
owners
we're
all
set
for
jmx
metrics.
I
want
to
wait
to
ping
bogdan
until
we
all
fill
out
our
last
fill
these
out.
So
I
can
say
everybody
everything
has
two
owners:
disruptor
processor
has
zero,
can
we
can
it?
Can
we
delete
it.
A
So
any
particular
affinity
to
contrib
samplers
from
anybody.
Besides
nikita.
A
Thank
you,
okay.
Nikita
this.
This
was
your
inspired
by
your
slack
messages
yesterday,
but
in
particular
I
was
thinking
about
you
know
the
the
difference
between
a
metrics
bridge
and
a
tracing
bridge
from
the
micrometer
tracing
perspective
and
like
metrics
bridges
to
me,
feel
much
more
straightforward
and
performant.
A
I
don't
know
the
tracing
bridges,
at
least
with
the
experience
that
we've
had
with
open
tracing
and
the
feedback
that
I've
heard
from
john
about
the
sleuth
bridge.
That
seems
much
hairier
as
well.
As
I
mean,
there's
gonna
be
a
performance
more
of
a
performance
impact.
A
So
I
was
kind
of
trying
to
think
about
the
response
to
marchain
had
mentioned,
potentially
contributing
the
bridge
to
open
telemetry,
and
I
don't
think
that
we
had
ever
discussed
that
before
we
were
all
sort
of
hoping
things
would
go
in
the
other
direction
that
they
would
own
like
spring
instrumentation,
along
with
the
sleuth
bridge,.
C
Martin
has
been
dm'ing
me
about
this
for
like
from
many
months
ago,
I
guess
sometimes
about
wanting
to
give
the
photometry
bridge
to
open
tomorrow
or
something-
and
I
said
I
mean
it-
has
to
be
somewhere,
whether
it's
in
spring
or
open
geometry.
I
don't
know
if
it's
that
big
of
a
difference,
but
yeah
I
mean
I
didn't.
We
don't
talk
any
details
or
anything,
but
the
thought
has
come
up
just
in
private
conversation.
D
In
my
eyes,
all
those
tracing
bridges
we
imagine
like-
why
do
we
need
open
trade
racing
bridge,
for
example,
because
we
have
some
application
which
uses
open
tracing
kpi
for
like
manual
instrumentation,
and
then
they
don't
want
to
migrate
all
that
application
to
open
telemetry
api.
They
just
want
to
attach
to
our
agent
and
be
done
with
that,
for
that
we
need
open
tracing
shim
and
that
I
assume
one
of
the
reasons
why
open
tracing
shim
is
required
by
our
specification
more
or
less.
D
So
I
I
think
the
very
similar
situation
is
with
the
sprinkler
system.
If
we
have
a
huge
sprinkler,
if
you
have
a
spring
application
which
uses
some
springy
tracing
api,
that
was
slows
now
that
micrometer
three
tracing,
because
every
spring
application
will
now
use
that
micrometer
trade
race.
If
you
want
for
more
shape-
and
then
we
want
users
will
want
to
attach
our
agent
and
see
everything,
including
whatever
they
did
in
that
using
the
tracing
api
in
their
sprint
application.
D
D
I
think
there
there
must
be
a
way
to
consume
all
those
manual
instrumentation
using
micrometer
tracing
kpi
with
java
agent
will
that
breach
be
supported
by
spring
or
by
open
telemetry
that
separate
question,
but
I
I
think
that
bridge
if
spring
doesn't
want
to
support
us
as
it
seems
they
want
to
like
open
telemetry.
We
don't
donate
that
to
you
and
please
take
care
of
that
then
well.
B
A
Do
you
have
customers,
do
we
know
if
people
are
using
like
or
I
guess
first
do
you
have
customers
who
are
asking
for
sleuth
to
hotel.
A
A
User
or
users
same
I
mean
I'm
just
I'm
kind
of
wondering
like
I
know
in
theory,
like
I
totally
agree,
you
know
spring
is
a
big
deal
and
we
want
to
have
you
know
first
class
support
for
the
spring
ecosystem.
A
I'm
just
wondering
like
from
you
know:
is
there
really
the
demand
there
or
our
users
just
going
to
go
to
open
telemetry?
You
know
switch
tracing,
switch
gears.
D
So
you
you
car,
you
currently
essentially
asking
if,
if
anybody
is
using
spring
tracing
apis.
D
D
B
A
Do
you
think
there's
the
micrometer
tracing
folks
would
would
reshape
the
would
change
the
shape
of
that
to
match
otel
more
than
it
matches
brave,
because
I
mean
that's
part
of
the
problem.
Is
that.
D
A
A
A
Any
thought
so
if
they
donated
it
within
the
marching,
has
he
said
that
they
would
contribute
to
maintaining
it
or
they
just
want
to
dump
it
and
have
open
telemetry
maintain
it
don't
know.
Yeah.
A
A
B
B
A
And
a
lot
of
spring
users
use
it
and
expect
open
telemetry
to
work
seamlessly,
and
I
kind
of
feel
that
that's
unfair
to
the
open
telemetry
project.
When
you
know
we
can
just
tell
users
just
use
open,
telemetry
and
everything's
going
to
work
smoothly
for
you,
you
can
continue
using
micrometer.
We,
you
know,
I
mean
micrometer,
there's
so
many
users
out
there
right,
so
it
makes
sense
we're
coming
to
them
sleuth
tracing,
not
that
many
people
use
it,
and
so
I'm
I
mean
this
is
did
not.
This
is
different
than
people
using
brave
directly.
C
Think
that,
like
I,
have
a
feeling
this
won't
get
that
popular
for
manual
tracing.
Who
knows,
but
the
more
important
thing
is.
I
could
spring
instrumentation
like
if
the
user
wants
to
use
this
spring's
official
instrumentation
for
spring
boot,
which
would
be
using
this
api
but
then
use
our
instrumentation
for
other
libraries.
We
would
still
want
the
bridge
to
be
able
to
connect
those
two
right.
D
C
Yeah
I
mean,
I
think
this
is
actually
a
good
idea
because
even
like
vmware
is
part
of
cncf
in
some
capacity.
So
if
they
do
things
that
are
bad
for
the
cncf
ecosystem,
that's
probably
actually
pretty
bad
for
them.
So
taking
the
cnc
driven
approach
might
result
in
something
yeah
like
I
don't
think
it's
going
to
be
ted
like
it'll,
be
our
governance,
then
talking
to
cncf
governance
and
trying
to
figure
out
an
approach
to
talk
to
them
rather
than
us
directly.
But
I
think
that
actually
has
some
promise.
D
A
Do
you
have
do
you
have
folks
on
the
governance
committee?
It's
one
guy.
C
A
My
one
governance
committee
friend
so
do
who
would
be
good
to
sort
of
guide
on,
although
you
know
I
can
still
reach
out
to
sarah
she's
she's
involved
in
a
lot
of
other
of
the
cncf
stuff.
That
could
be
a
good.
A
D
B
A
Just
kidding
that
goes
back
to
nikita's,
like
redoing
everything,
that's
gonna
push
our
date.
Nikita.
D
Do
you
know
you
probably.
D
A
A
Like
a
little,
I'm
a
little
over
like
overflowing,
still
reeling
from
luck
for
j2.
A
Yeah
so
yeah,
I
saw
your
reply
here.
So
the
only
thing
that
I
was
but
yeah,
I
agree
just
if
there's
some
way
that
we
can
publish
it
and
still
kind
of
make
it
clear
that
it's
just
like
for
our
internal
repo
usage,
as
opposed
to
like
the
muzzle
plug-in
which
we're
putting
out
into
the
world
more
broadly.
D
And
first
I
think
that
at
least
license
file.
We
can
externalize
as
a
configuration
if
needed
yeah.
It
should
not
be
like
packaged
inside.
I.
C
D
C
A
Yeah,
if
at
least,
I
would
want
it
to
default
to
our
normal
license,
because
otherwise,
like.
A
D
D
C
D
A
Awesome
I
was
just
kidding.
C
A
A
So
the
excel
is
pretty
nice.
Now
it's
got
the
jfr
micrometer
splunk
new,
relic
prometheus,
and
then
I
just
added
this
today.
This
is
our
our
runtime
metrics
package
in
the
instrumentation
repo,
but
as
benzer
pointed
out
really
there's
just
sort
of
I
mean
there's
just
sort
of
two
implementations:
there's
the
all
of
these
there's
jfr
and
then
all
these
other
ones
are
just
you
know,
scraping
jmx
metric,
scraping
jmx
and
the
jfr
being
event
driven
is
very
different,
but
still
should
be
so.
A
The
while
the
jfr
metrics
could
be
like
gauges,
I
mean,
could
be
histograms
because
it's
capturing
at
each
gc
event.
It
would
we're
sort
of
probably
spec
it
as
just
a
gauge
or
up
down
counter
so
that
since
the
jmx
metrics
is
going
to
be
limited
to
that.
A
And
then
we
decided
just
to
we
were
just
kind
of
talking
through
this
one
memory
used,
oh
ben,
wasn't
sure
about
the
non-heap.
A
And
I
sent
just
a
very
tiny
little
placeholder
pr.
A
And
jack
is
going
to
then
for
next
time
he's
going
to
try
to
fill
this
in,
for
just
the
jvm
memory
used
and
jonathan.
We
just
kind
of
barely
started
talking
about
cpu
utilization,
but
jonathan
might
next
week
might
give
a
dot.
I
tried
to
add
that
also.
A
The
because
it's
getting
its
event
driven
so
on
every
garbage
collection.
You
get
a
number,
and
so
you
put
it
in
so
you
get
a
histogram
out
of
that.
That
value
set
over
time.
D
A
A
Have
that
yeah?
It's
it's
and
correct
me
if
I'm
not
getting
this
right,
but
I
think
the
difference
is
async
versus
sync
metrics,
where
there's
no
async
histogram.
A
A
Well,
it
doesn't
have
to
be
so.
The
idea
is
today.
It
is
because
that's
how
ben
wrote
the
prototype,
but
he
thought
that
you
know
he
agreed
that
we
would
change
that
to
be
up
down
counter
for
jfr
as
well,
because
we
have
to
we
have
to
spec
it,
and
so,
in
order
to
spec
it,
we
have
to
decide
what
the
instrument
type
is.
Okay
and
well
so
jfr
could
do
either
one
really
okay.
A
A
All
right
well
go
micrometer
and
go
1.10.