►
From YouTube: 2022-01-05 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
Hi
good
morning,
hello,
hi
is,
is
it
me
or
is
your
audio
level
a
bit
low.
B
A
B
B
B
A
That's
absolutely
fine,
we'll
just
we'll
just
see
where
we
get
to
yeah
I
mean
I.
This
is
actually
the
first
one
of
these
we've
actually
managed
to
run
in
in
this
time
spot.
So
I
don't
know
how
many
people
will
get,
but
you
know
in
the
best
tradition
of
open
spaces
we
get
who
we
get
yeah
yeah,
it's
just
basically
it's
because
we
have
a
couple
of
folks
like
anarag
and
a
couple
other
people
who
who
want
to
come,
who
are
in
the
the
far
east
time
zone.
A
A
B
B
A
Think
will
will
take
the
whole
hour,
at
least
until
we
get
at
least
until
we
get
underway.
C
B
A
Essentially,
what
we,
what
we
want
to
do
is
we
want
to
have
something
which
which
moves
across
all
of
the
you
know
the
different
possible
implementations
so
that
any
instrumentation
library,
if
it
chose
to,
could
emit
metrics
which
were
compatible
with
the
open,
inflammatory
standard
so
for.
A
A
Sends
or
can
export
data
out
to
prometheus?
We
also
wanted
them
to
have
the
ability
to
to
have
them
send
stuff
out.
You
know
inflammatory
formats.
C
A
C
A
Oh
yes,
so,
yes,
I
saw
you
added
the
the
tags
for
the
prometheus
of
the
prometheus
library.
Thank
you.
That's
super
helpful.
Some
of
this,
of
course,
is
all
of
this.
You
know
I
I
I've
looked
at
it,
but
I
don't
know
the
details.
Is
everything
that's
in
the
prometheus
library,
basically
scraped
out,
jmx.
B
B
I
don't
know
why.
So
when
I
became
maintainer
of
that
library,
that
was
already
there.
So
I
assume
that
you
wouldn't
get
that
data
out
of
the
jvm
itself,
and
then
we
have
just
this
one
thing
at
the
the
bottom,
the
jvm
info,
which
is
basically
system
properties,
just
so
that
you
can
say
what's
my
java
version
and
so
on,
but
all
the
rest,
this
jam
experience
here.
A
C
A
Say
dc
time
or
memory
utilization
or
something
like
that
and
a
time
series
that
sourced
from
from
let's
say:
jfr
yeah
and
I,
but
but
I've
never
actually
had
had
the
time
or
or
the
spare
bandwidth
to
actually
investigate
exactly
how
big
those
differences
in
time
series
are
likely
to
be.
C
A
B
A
A
B
Now
you
can
count
jfr
events
and
then
have
prometheus
counters
out
of
that.
But,
okay,
if
there's
anything,
that's
of
interest
that
you
want
to
count,
I
mean
that's,
definitely
something
you
could
do,
but
I
don't
know
yeah.
I
didn't
really
look
into
what
what
like,
if
there
are
any
good
examples
of
what
what
could
yield
to
interesting
counters
that
you
don't
get
through
classical
jmx
beans.
I.
A
C
A
B
A
A
B
A
Thanks
for
joining,
I
know
it's,
I
know
it's
a
bit
it's
it's
evening
time.
A
Yeah,
that's
that
sounds
good
to
see
if
he
wants
to
come
and
join
us.
I
mean
we
were
just
just
talking
about
some
of
the
sort
of
this,
the
initial
just
just
what
the
scope
and
what
we
want
to
do
with
this
and
and
kind.
C
A
And
I
guess
you,
you
probably
know
that,
but
just
just
for
the
the
circus
completeness,
you
know
it's
things
like
erin
has
been
working
on
a
patch
to
make
micrometer
have
a
registry
which
emits
open
telemetry
directly,
and
so
at
that
point,
then
it
it's
like
okay.
Well,
what
other
implementations
are
there
of
monitoring
tools
and
and
libraries
that
might
want
to
to
do
the
same
thing
and
if
there
are
more
than
one,
then
that
kind
of
means
that
we
need
to
define
a
common
subset
or
a
minimal.
A
You
must
support
these
things
in
order
to
be
a
conformant
implementation,
primarily
so
that
when
when
this
is
actually
deployed
in
the
field,
if
you're
a
devops
person
that
spins
this
up
for
the
first
time,
what
we
don't
want
to
do
is
to
give
people
empty
graphs.
A
C
A
We
were
just
getting
started
and
just
you
know,
doing
kind
of
introductions
and
things
and
just
just
kind
of
going
around
the
point
of
what
we
were.
Why
we're
doing
this,
which
essentially
is
just
this
idea
of
a
common
subset
for
any
any
compatible
implementation
that
wants
to
wants
to
talk
hotel
directly,
so
I
mean
from
from
from
the
micrometer
standpoint.
You
know
this.
This
goes
to
things
like
errands
patch
to
get
a
registry
going
for
hotel,
which
I'm
you
know
I
was
actually
playing
with
over
the
christmas
break.
A
So
I
might
actually
try
to
get
that
up
and
running
and
get
it
to
a
point
where,
where
somebody
else
can
kick
the
tires
of
it
soon,
so
feedback
would
be
very,
very
welcome.
So
there
we
go.
C
Registry,
so
it
looks
like
matthias:
splunk
has
been
working
on
that
in
the
java
instrumentation
repo,
so
there
might
be
some
overlap
there.
So.
C
C
A
A
Which
would
be
cool
because
then
you
know
as
just
talking
to
fabian
about
then.
The
idea
is
is
that
you
can
then
compare
different
sources
of
data
like
say,
prometheus
being
sourced
from
mx
on
the
one
hand
and
my
prototype,
which
talks
to
jfr
to
generate
metrics,
and
you
know
kind
of
try
to
get
a
bit
more
rigorous
about
the
idea
of
how
much
the
metrics
can
still
diverge
from
each
other.
A
In
terms
of
how
the
time
series
is
look
when
they're
both
displaying,
obviously
the
same
underlying
behavior
of
the
same
jvm-
and
I
think
that's
probably
an
interesting,
interesting
conversation
to
have
so
yeah,
so
that
those
those
were
really
my
goals
of
getting
this.
This
thing
going,
obviously
anything
anybody
else
wanted
to
to
to
add
in
or
or
any
any
viewpoint
which
is
isn't
covered
by
those.
You
know
what
I'd
like
to
hear
it.
A
Yeah
I'll
take
a
look
at
that
that
piece
from
splunk
as
well
from
the
tabs.
Okay.
So
then
the
next
question
becomes
okay.
So
if
we,
if
we
feel
like
a
common
subset,
is
a
is
a
useful
thing
to
have,
then
what
should
it
look
like
and
so
I've
I've
started
talking
to
just
to
a
few
people?
We've
got
input
so
far
from
from
spelunk
and
new
relic
and
prometheus.
A
A
Is
there
any
other
implementation
that
we
think
we
want
to
to
take,
or
do
we
think
that
five
different
views
on
on
what
the
common
subject
should
be
is
enough
for
us
to
get
to
reasonable
commonality.
A
That's
that's
an
excellent
idea:
yeah!
That's
a
really
really
good
idea.
Okay,
let
me
make
some
notes
in
the
by
the
way,
I'm
the
world's
worst
scribe
in
terms
of
making
notes
for
minuting
and
stuff
so
I'll.
I
guess
we'll
just
have
to
do
a
wii,
so
scope
of
group,
other
indications.
A
Does
someone
have
a
contact
at
drop
wizard
who,
who
might
be
a
good
commenter
or
maintainer,
that
we
could
talk
to
and
pick
their
brains
and
enlightenment
to
this.
B
Yeah
yeah,
I
know
yoshi,
but
I
don't
know
if
he
will
have
time,
but
I
could
ping
him
and
ask
him.
B
A
Yeah,
that's
brilliant,
okay,
so
dot
wizard,
anything
else
that
we
think
we
we
want
to
include.
I
mean
I'll,
put
data
dog
in
brackets.
I
don't
know,
I
don't
know
how
much
marcus
and
ko
are
going
to
want
to
participate,
but
you
know
they
might
do
what
else.
B
Yeah,
I'm
actually
I'm
sorry.
I
didn't
introduce
myself
sorry,
I'm
maintainer
of
this
prometheus
java,
client
library
and
that's
why
I'm
also
joining,
and
I
added
a
tab
to
the
spreadsheet
actually
with
the
jvm
metrics
that
we
have
as
the
default
exports
in
that
library.
A
Yeah
and-
and
so
I
think
that
if
we
managed
to
get
another
implementation
as
as
well
drop,
wizard-
maybe
later
you
know
at
that
point,
if
we
get
if
we
get
drop
wizard,
which
I
think
I
think
you're
right
on
the
right,
we
probably
should
try
to
that's
then
six
possible
sources.
A
You
you'd
hope
that
at
that
point
we
were
pretty
close
to
being
able
to
define
a
common
core
right
and
the
the
the
other
thing
that
I'm
thinking
about
is
how
do
we
actually
want
to
to
iterate
on
what
our
our
stable
or
are
aimed
for
common
core
would
be.
I
mean,
there's
obviously
a
couple
of
differences
where,
where,
for
example,
for
the
for
the
hotel
standards,
I
think
they
would
really
really
like
us
to
be
jvm.runtime,
whereas
the
microphones
are
all
runtime..
A
Yeah,
so
we
they're
missing
the
initial,
the
initial
runtime
piece,
so
it
just
says
jvm
dot
rather
than
runtime
dot.
I
had
a
quick
chat
with
erin
about
it
and
she
seemed
to
think
that
that
wasn't
necessarily
a
big
problem,
because
you
can
just
use
a
meter
filter
or
something
in
order
to
to
actually
change
that
and
change
the
name
all
the
way
through.
A
A
C
A
I
I
think
that's
right,
and
then
you
know
I
mean
my
my
feeling
was
that
that
was
a
reasonable
take
to
have,
and
then
you
know,
I
guess
we
just
let
the
market
decide.
If
there's
then
a
desire
to
actually
actually
have
an
implementation
move
towards
inflammatory
great
if
it
ends
up
being
the
case
that
if
you
deploy,
you
know
whatever
library
directly
and
you
keep
at
one
set
of
conventions
and
then,
if
you
come
to
open
planetary
well,
you
just
have
to
adjust
to
the
fact
that
conventions
are
slightly
different.
A
I,
I
think
that's
a
reasonable
compromise.
I
I
certainly
don't
want
to
be
in
the
business
of
trying
to
prescribe
to
people
how
they
they
should
organize
their
name
spaces.
So
so
a
bridge
seems
like
the
way
to
go
to
me.
D
I
mean,
I
think,
to
some
degree,
there's
always
going
to
be
differences,
and
so
there's
going
to
have
to
be
some
decision
made
on
one
way
or
the
other
or
completely
new
naming.
But
I
think
the
producer
side
in
bridging
is
not
such
a
problem,
but
when
we
think
about
it
from
the
consuming
side,
so
people
already
have
existing
dashboards.
They
have
existing
alerts
based
on
existing
names
and
thinking
of
how
that
transition
phase
looks
like
from
them.
If
they
want
to
then
adopt
some
new
standard
naming,
how
do
they?
D
A
Well,
like
totally,
I
mean,
I
think,
that
that
we
you
the
current
the
current
stake
of
the
art
of
that
effectively
is
the
same
if
I've
understood
correctly.
As
what
would
happen
if
someone
moved
between
two
vendors
like
if
you
change
between
like
new,
elect
and
data
dog
today,
you
you
would
there
would
be
a
switching
cost.
It's
it's
kind
of
almost
a
little.
A
You
know
a
small
version
of
vendor,
locking
because
you've
invested
in
those
dashboards
and
as
you
say,
you
want
to
keep
running
so
yeah
if
there
are,
if
we
discover
that
there
are
some
some
useful
things
that
we
could
do
to
ease
that
that
transition,
I
think
I
think
that's
that's
fine,
but
at
the
same
time
you
know
it
may
just
be
a
case
of
you
just
have
to
go
through
your
dashboard
and
have
a
have
a
migration
process
where
you,
where
you
change
the
conventions
you
know
so
the
other
but
related
to
that
which
is
not
just
the
naming
conventions,
is
the
question
about
what
actually
is
sent
through
the
the
api.
A
I
I
have
this
concept
that
that,
basically,
we
need
to
define
a
t-shaped
api.
We
need
to
have
one
part
which
is
common,
and
then
we
also
need
to
have
recognize
the
fact
that
there's
going
to
be
different,
shaping
and
different
data
available,
depending
on
which
actual
pipeline
for
exporting
you
use
an
exporter
which
jvm
you
use
and
also
how
you
have
that
jvm
configured.
A
So
to
the
example
that
I
use
is
a
concurrent
versus
a
a
stop
the
world
dc,
because
they
don't
have
the
same
statistics.
You
know
I
mean
yes,
it's
something
like
you
know.
Shenandoah
is
not
going
to
have
the
same
statistics
as
g1
either,
but
but
between
concurrent
and
parallel,
there
is
also
the
concept
that
that
you
have
to
be
careful,
how
you
name
things,
because
if
you
have
gc
dot,
stop
time,
for
example,
as
your
as
your
your
name,
okay,
what
does
that
mean?
A
A
So
there's
there's
that
level
of
detail
that
I
think
we
you
know
we
would
need
to
get
into
and
also
remember
that
a
lot
of
us
are
pretty
serious
java
people,
but
the
people
who
are
our
users
who
are
going
to
consume
this
stuff
are
not
a
lot
of
times.
It
will
be
folks
who
are
setting
up
kafka
or
cassandra
or
some
other
piece
of
effectively
java
infrastructure,
which
isn't
it
may
not
even
have
any
development
or
any
any
bespoke
code
in
it.
A
So
so
they
just
want
some
reporting
on
it
and
do
they
really
understand
the
distinctions
between
a
concurrent
and
parallel
gc?
No
do
they
have
to
probably
no
so
so.
It's
very
important
that
the
and
I
think,
it's
incumbent
on
us
to
make
sure
that
whatever
we
define
has
clear
semantics
and
also
really
will
work
across.
You
know
as
wide
as
possible
a
set
of
cases,
at
least
for
the
common
core
and
then
for
the
other
pieces.
I
think
we
can.
A
You
know
we
can
have
a
hierarchy
like
you
know,
runtime.jvm.gc
dot,
name
of
collector.
C
Do
you
know
if
there's
any
known
sort
of
gaps
or
issues
people
have
with
commonly
reported
metrics
right
now
like,
for
example,
I
think
all
the
metrics
libraries
report
long
bullet,
dc's
short
pc
time?
Is
that
known
to
not
be
enough
like?
Are
there
problems
they're
supposed
to
be
solving,
or
would
it
just
be
enough
to
refer
to
what
we
have
right
now.
A
A
You
know
if
you
were
to
stop
the
world
gc,
it's
fine,
because
all
the
time
the
cpu
is
stopped,
you're
not
doing
application
work,
so
your
throughput
is
easy
to
calculate,
but
in
a
concurrent
situation
you
have
half
your
course
operational
until
the
collections
get
closer
and
closer
together.
So
you
have
like
a
window
of
time
where
the
dc
is
running
where
you
have
after
floors,
and
then
you
have
a
small
window
of
time
or
whatever.
The
window
of
time
is
where
all
your
cores
are
doing
application
work.
A
A
The
collections
basically
run
out
of
gap
between
them
and
they
go
into
a
back-to-back
collection
and
then
it
goes
into
40c
and
then
that
triggers
the
the
the
load
balancer,
because
now
that
jvm
is,
is
not
responsive,
so
it
gets
taken
out
of
the
load
balancer
and
if
it
happens
to
be
a
kafka
machine
that
triggers
a
category
balance
which
triggers
a
downstream
failure.
A
So
ultimately
it's
that
type
of
information
that
I
want
operationally
to
be
able
to
get
out
of
this
data.
So
the
data
model
needs
to
be
both
flexible
enough,
but
it
it
does
something
useful
right
out
for
the
box,
but
also
sensitive
and
flexible
enough
that
you
can
start
to
build.
The
kind
of
you
know,
detection
and
the
sort
of
problems
that
I
just
outlined.
A
A
Now
there
is,
of
course,
the
problem
that
currently
shenandoah
isn't
actually
a
generational
collector,
so
it
doesn't
have
a
notion
of
young
and
old
collections,
but
let's
leave
that
on
the
side
for
a
moment,
so
so
yeah.
So
so
so
if
we
can
have
a
design
where
we
have
like
a
general
pool
of
gc
metrics,
maybe
we
actually
need
to
two
namespaces.
Maybe
we
need
runtime.jvm.gc
and
runtime.jvm.collector.nameofcollector.
A
And
are
there
are
there
people
who
are
going
to
want
to
go
down
to
that
level
of
detail?
Yes,
absolutely
I'm!
I
was
hoping
that
that
one
of
the
folks
from
morgan
stanley
was
going
to
be
here
this
morning,
but
it's
straight
after
christmas.
So
so
I
wasn't
sure
whether
or
not
he's
actually
they're
even
back
yet
today,
but
you
know
so.
D
So
I
think
to
honorable's
question
about:
are
the
existing
metrics
good
enough
or
not?
I
think
a
lot
of
the
challenge
there
around
existing
open
source
projects.
I
guess
I
can't
speak
for
the
commercial
products,
but
on
the
open
source
side
a
lot
of
times,
you
don't
know
exactly
who
your
users
are
and
they
don't
always
give
the
most
feedback,
and
you
don't
always
have
a
clear
line
of
communication
with
all
of
them.
So
I
think
to
a
degree,
maybe
some
are
getting
along
fine
with
the
current
metrics.
D
Maybe
some
have
issues
and
they've
dealt
with
that
themselves
without
contributing
anything
back
and
maybe
some
cases
there's
something
missing
and
they're.
You
know
troubled
by
that
and
they
don't
know
what
to
do
about
it.
So
I
think
there's
a
variety
of
cases
out
there
and
it's
kind
of
hard
to
to
assess
that.
A
B
I
mean
I
I
agree
about
the
level
of
detail.
I
think
it
makes
sense
like,
of
course
it
must
be
optional,
because
it's
not
available
everywhere,
but
if
somebody
wants
to
drill
down
and
the
information
is
available
and
to
have
a
namespace
where
we
could
do
that-
that's
cool.
I
have
one
example
of
like
that.
B
We
recently
had
in
the
in
the
prometheus
library
we
we
have
this
number
of
deadlocked
threats
which
is
coming
out
of
jmx,
and
some
people
complained,
and
it's
also
in
the
java
dock
of
the
jmx-
means
that
in
some
cases
it
might
cause
performance
issues.
If
you,
if
you
count
the
number
of
deadlocked
threats,
so
maybe
if
there
are
many
threads
and
many
deadlocked
or
whatever,
and
so
we
had
a
feature
to
make
this
optional
so
to
disable
it
and
to
make
sure
that
these
metrics
are
never
collected.
B
So
that
was
one
one
thing
we
recently
did,
and
so
it
doesn't
help
to
first
collect
it
and
then
throw
it
away
because,
like
the
collection
itself,
causes
performance
issues
in
that
specific
case.
So
that's
just
one
one
thing
we
should
keep
in
mind:
there
are
probably
some
metrics
that
are
useful.
I
mean
deadlocked.
Threats
is
definitely
something
maybe
some
people
want
to
alert
on,
but
in
some
cases
collecting
these
metrics
is
an
issue
and
some
people
might
not
want
this.
A
That's
that's
a
really
interesting
point,
because
if
I
can
just
riffle
that
slightly
in,
I
think
it's
java
10
what's
in
included,
is
a
lightweight
deal
of
safe,
pointing
and
obviously
to
detect
a
deadlock
thread.
You
need
to
take
a
safe
point
and
to
do
that
across
all
the
threads
prior
to
java
10.
It's
actually
one
one
save
point
per
thread,
so
that's
an
expensive
operation
on
anything
below
driver
11.
A
So
so
I
can
understand
where
that
that
has
come
from.
But
that
also
raises
the
question
about,
given
that
our
baseline
for
open
telemetry
is
java
8.
What
do
we
do
about
metrics,
which
they
are
expensive
in
in
8,
but
not
in
11
or
17?
B
A
Yeah,
so,
okay,
that
makes
total
sense.
Maybe
the
answer
is
that
people
who
are
running
below
six
and
seven
but
running
six
and
seven.
They
aren't
running
open
telemetry
anyway,
because
we
don't
support
it.
So
it
kind
of
doesn't
matter
what
the
open
telemetry
spec
says
about
that
case.
So
a
project
like
prometheus,
which
supports
lower
versions
than
eight
you
carry
on
doing
your
defaults.
A
The
things
which
were
useful
but
potentially
expensive,
obviously
they
can't
be
in
the
default
configuration
for
eight
and
then
maybe
we
just
have
a
like
a
separate
profile
which
says
these
are
useful,
but
you
need
to
be
running
11
and
above
or
be
prepared
to
take
the
performance
hit
on
them.
A
D
A
To
do
that,
but
users
always
want
to
do
something.
You've,
never
thought
of
that's
one
of
the
first
rules
of
software.
A
Okay,
that
sounds
good,
so
let
me
just
flick
back
to
the
spreadsheet
and
see
what
else
we
wanted
to
capture
in
the
minutes.
Well,
I
really
am
terrible
about
taking
minutes.
A
A
Okay,
is
there
anything
else
specifically
on
the
spreadsheet
you
want
to
touch
on
now,
because
I
sort
of
feel
like
if
we
can
get
drop,
wizard
and
maybe
maybe
later
dog
as
well,
that
once
we
have
that
it
might
be
time
to
actually
sit
down
and
try
to
actually
start
drafting
like
what
a
subset
should
look
like
and
actually
capture
some
of
this
into
into
it's
just
a
document
at
this
point,
but
you
know
I
don't
know,
I
think
you
know
the
the
specification
process
for
otel,
probably
the
best
of
anyone
here.
A
So
what
do
you
think?
Do
you
think
it's
time
to
start
capturing
some
notes
that
would
lead
towards
a
a
draft
doc.
C
Yeah
I
mean
we
should
start
with
the
notep
and
there
isn't
really
any
requirement
for
notep.
If
we
have
some
metrics,
we
think
we
should
start
with.
Then.
Obviously
we
shouldn't
we
always
need
to
keep
our
scopes
small
for
the
beginning
to
get
something
done
or
we
never
get
anything
done.
So
maybe
we
just
design
thread
or
something
and
start
with
that.
You
know
just
create
a
first
graphic
note
up
from
there.
A
C
A
Okay,
well,
let's,
let's:
let's
do
that?
Let's,
let's
call
that
a.
C
A
Yep
so
so.
C
A
I
mean
what's
the
best
way
to
do
that,
is
that
just
to
do
a
github
dock
in
in
an
existing
repo,
or
do
we
want
to
do
this
in
in
in
google
doc
yeah
so
we'll
do
it.
C
A
Okay,
so
yeah
so
yeah
all
right.
So
let's
do
it
in
you
know
text!
Oh
I
mean
if
I
put
something
in
the
slack
channel,
I'm
happy
to
take
a
first
stab
at
this
and
to
just
try
to
do
something
into
oteps,
and
then
you
know
I'll.
A
I
might
wait
and
see
if
we
can
get
the
drop
wizard
folks
to
actually
actually
dump
some
data
from
the
spreadsheet,
just
because
it's
polite
to
wait
for
them
for
a
little
bit
first
and
then
I'll
take
a
first
stab
at
this
and
I'll
it's
just
terrible.
This
is
my
first
meeting
of
the
year
and
somehow
I've
walked
away
with
an
action
item.
This
is
this.
Is.
C
C
C
A
C
A
C
B
B
So
I'm
thinking
of
more
of
renaming
packages
there's
some
some
issues
that
it
currently
doesn't
work
exactly
with
jigsaw,
because
we
have
multiple
maven
modules,
exposing
the
same
packages
and
maybe
renaming
some
maven
modules
and
like
this
stuff,
and
that
would
probably
fit
well
with
a
1.0
release.
And
since
since
last
week,
there's
a
github
issue
where
we
collect
ideas
and
we'll
keep
that
discussion
running
for
a
bit.
And
then
we
create
a
branch
and
it
will
be
a
breaking
change.
B
C
B
B
Yeah
yeah,
but
two
months
I
think
that's
realistic.
So
hopefully.
C
C
A
Okay,
I
guess
I
guess
that's
it
thanks
everyone
and
I'll
see
everybody
in
a
couple
of
weeks.
Time
have
a
good
rest
today,.