►
From YouTube: 2022-04-28 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
C
E
Nope
there
was
it's
snow
like
three
weeks
ago.
We,
you
also
had
a
sudden
attack
of
winter,
but
it
like
lasted
a
few
days
and
it's
full
on
spring
right
now,.
F
All
right
jack,
I
like
that
you've
had
agenda
items
going
for
the
office
hours
meeting
for
a
while
now.
G
F
F
B
Yeah,
my
so
my
last
day
at
splunk
is
tomorrow
and
my
I
think
my
goal
is
going
to
be
at
least
try
to
do
the
office
hours
so
that
honor,
rog
and
jack,
and
I
have
the
time
to
have
a
chance
to
connect.
B
F
Yeah
I've
been
trying
to
pay
more
attention
to
those
java,
the
core
repo
prs
and
the
the
common
things
that
I
would
just
constantly
miss
over
there,
like
the
log
spamming
one.
I
saw
this
just
a
lot
of
you
guys
do
a
lot
of
good
work
over
there.
Keeping
that
thing
stable.
B
Yeah
log
spamming
is
something
that
I
didn't
really
think
about
a
huge
amount
until
I
started
working
on
this
project,
where
it's
really
critical
that
you
don't
do
that
to
people
where
they
aren't
able
to
really
control
it.
G
Yeah,
so
we
got,
we
have
these
semantic
inventions
for
jvm
memory
usage
and
for
recording
the
maximum
memory.
We
say
that
we
recorded
under
the
metric
name
process
runtime
jvm
memory
max,
but
one
of
my
colleagues
pointed
out
that
there
are
the
there's,
like
a
general
convention
of
like
having
the
the
suffix
of
limit
on
metric
names
that
that
measure
this
type
of
thing,
and
so
you
know
max
you
know,
the
maximum
memory
is,
is
kind
of
a
jvm
thing
and
it
reflects
kind
of
what
what
the
jvm
tells
us.
G
But
should
we
should
we,
you
know,
align
with
the
the
the
general
open
telemetry
conventions
over
the
java
conventions.
That's
kind
of
the
question
here.
F
I
remember
thinking
about
this
mateish
on.
I
think
the
database
connection
pool
stuff
also
because
they
have
max,
but
I
think
over
there
I
was
thinking
it
wasn't,
maybe
exactly
a
limit.
E
It
was
more
like
yeah,
the
maximum
connections
used.
E
To
be
honest,
I
didn't
really
at
the
time
think
of
like
the
limit
versus
max
thing.
B
F
C
Sea
dog
say
anything
about
the
lady
upper
bound
and
the
and
the
lower
bound
like
limit
is
the
upper
bound.
I
guess
in
there,
but
like?
Is
there
anything
there
which
which
says
about
anything
about
me.
F
C
Also,
I'm
not
hundred
percent
sure
about
this
right
now,
but
as
far
as
I
remember,
like,
newer
jvms
has
a
initial
heap
option
as
well,
which
is
not
the
same
as
me,
so
you
can
say
that
minimum
is,
I
don't
know
100
max.
The
max
is
a
gig
and
the
initial
is
500
and
the
jpm
can
resize
the
heap.
So
it
can
go
upper
from
the
initial
where
it
can
go
lower
from
the
initial.
F
I
think
it's
so
good
jack.
I
think
it
sounds
like
a
good
question
to
raise
in
the
spec
about
usage
of
limit
like
if
we
have
min
and
max
together.
G
Because
of
the
symmetry
I'll
raise
an
issue-
and
you
know
I'll
reference,
the
java
memory
and
also
the
database
connection
pools,
because
I
think
those
both
fall
into
that
category.
F
Yeah
yeah,
I'm
I
don't
particularly
have
a.
I
don't
have
a
strong
preference
myself,
but
it
would
be
good
to
have
that
documented
in
the
over
over
here
sort
of,
I
think
right.
B
Yeah
thread
thread
pulls
also
any
kind
of
cool
object,
not
just
not
just
connection
points.
Any
sort
of
pool
can
have
this,
so
we
have
these
same
sort
of
attributes
available
possible.
F
Yeah-
and
I
think
that
limit,
maybe
one
nuance
to
clarify,
is-
is
limit
like
a
hard
limit
like
like
memory.
Right
is
a
hard
limit
like
you
just
can't
exceed
it
versus,
maybe
I'm
not
making
sense.
Nah.
E
The
database
are
actually
this
is
actually
supposed
to
be
like
the
configured
maximum
number
it.
It
can
also
change
during
at
least
for
some
connection,
pools
it
can
change
during
run
time.
You
can
make
it
bigger
or
smaller.
D
F
Yeah,
I
I
really
I
actually
like
this
page
a
lot.
I
think,
the
more
stuff
we
build
out
here,
the
more
of
those
kind
of
common
answers.
We
have
to
fall
back
on
for
naming
those
hard
naming
questions.
G
Oh,
no,
I
feel,
like
I'm
monopolizing
the
the
meeting.
Okay,
so
there's
been
some
discussion
about
a
a
log
api
and
this
is
originally
kind
of
stemmed
from
from
the
client
side.
Instrumentation
group,
where
we're
measuring
events
is
very
common
or
recording
events
is
very
common,
and
you
know
I
think
I
I
think
you
know
myself
and
maybe
ben
evans,
but
like
I've,
been
interested
in
recording
events
from
the
context
of
for
java
flight
recorder
as
well.
G
I
think
there
there
are
some
things
that
don't
quite
fit
neatly
into
spans
or
metrics
and
are
more
event-like,
but
in
open
telemetry,
of
course,
logs
and
events
are
synonymous
with
one
another,
so
you
know
there's
you
know
if
we
introduce
an
event
api,
that's
what
we
want
to
record
should
we,
you
know,
include
the
ability
to
record
traditional
application
logs
as
well,
and
that's
kind
of
always
been
a
a.
G
Subject,
that's
been
debated
over
and
you
know:
do
we
want
to
introduce
another
log
api
to
compete
with
slf
for
j
log
for
j
log
back
and
all
the
other
ones?
I
think
the
answer
is
no
and
so
there's
if
you
scroll
down
in
this
document,
I
I
posed
a
like
a
question
that
you
know
just
keep
scrolling.
G
Keep
scrolling
there's
like
an
open
questions,
section,
open
questions,
and
so
my
my
feedback
is
there
on
b
and
it's
and
the
without
reading
it
out
loud
right
now,
the
what
I
suggest
is
like
okay,
I
I
argue
that
we
should
only
introduce
an
events
api
because
we
that's
kind
of
like
a
novel
use
case.
There's
there's
not
an
events
api
out
there,
that's
popular
that
we
know
of,
and
this
this
paper
here
suggests
that
we
have
a
general
purpose,
log
api
that
provides.
G
You
know
the
ability
to
record
traditional
application
logs
as
well
as
events,
and
so
I
say
we
shouldn't
do
logs
for
a
log
api
in
java.
For
all
the
reasons
we
suggest
and
kind
of,
one
of
the
one
of
the
suggestions
tigran
has
made
is
that,
while
there
is
a
rich
logging
ecosystem
in
java,
some
of
the
other
languages,
don't
necessarily
have
that,
and
so
it
might
be
possible
for
java
to
just
introduce
a
a
a
log
api.
G
G
Yeah
so
like
so
what
I
I
categorize
them
in
two
ways:
there's
like
traditional
log
application
logs,
which
have
a
string
message
and
severity
and
and
sometimes
they're
structured,
including
include
like
a
map
of
key
value,
pairs
and
events,
are,
and
they
have
a
time
stamp
as
well.
G
Events
are
very
similar,
but
I
think
they
have
like
one
distinct,
distinct
feature,
which
is
they
have
some
sort
of
type
associated
with
them,
which
is
has
like
a
name
space,
and
so
you
know
in
in
the
in
the
client-side
world
you
might
have
on
or
like
window
load
events
or
time-to-first
paint
events
that
you
might
be
interested
in
recording.
G
And
so
you
would
you
you
want
to
record
when
that
happened,
potentially
a
bundle
of
attributes
that
describe
what
happened,
and
you
want
to
give
it
a
a
a
type
which
is
like
the
the
first
paint
or
something
like
that
and
you
potentially,
I
argue,
would
want
to
name
space
that
type
so
that
if
you
have
multiple
classes
of
of
events
that
happen,
that
you
can
avoid
collisions.
So
you
don't
have
intersecting
names
and
have
ambiguity
about
what
they
mean.
So
that's.
That's
the
distinction.
B
B
Events
have
not
there's
no
severity
associated
with
events,
that's
not
a
thing
and
that
actually,
I
think,
provides
a
fairly
crisp
distinction
between
what
is
a
log
and
what
is
an
event
event
has
a
type
or
name
depending
on
how
you
want
to
use
it,
but
not
a
severity
and
generally
events
don't
have
messages
either
logs
or
messages
in
severity,
with
maybe
optional
attributes.
Events
are
a
name
and
attributes
and
that's
kind
of
all.
They
have.
A
And
there's
also
the
question
about
whether
there
is
there
is
structure
here,
whether
there
is
a
schema
or
a
static
type
or
whatever
you
want
to
think
about
it,
and
obviously
we
we
need
to
remember
that
we
have
cousins
in
other
languages
who
don't
believe
in
static
types,
so
they're
gonna,
just
they're,
obviously
going
to
see
an
event
as
a
bag
of
stuff.
A
But
perhaps
the
notion
of
a
schema
is
actually
more
appropriate
here
to
me
it's
about
the
level
of
structure,
so
I
think
I'm
I'm
mostly
overlapped
with
with
jack
on
this,
but
I
a
log
to
me
is
just
like
a
dumb
log
line.
It's
got
a
severity
and
it's
got
a
string
right
and
that's
basically,
it
a
time
stamp,
usually
yeah
the
time
stamp.
Sure.
Why
not?
I
mean
everything.
Everything
is
a
timestamp,
because
otherwise,
how
do
we
know
when
to
drop
it?
A
But
to
me
an
event
is
something
which
actually
does
have.
You
know
some
sort
of
structure
and
whether
that's
a
name
or
whether
that
is
something
as
formal
as
a
type.
I
don't
know-
and
it
occurs
to
me
that
actually
the
idea
that
that
yeah,
we
have
this
log
api,
which
is
just
slf
4j
and
with
basically
the
oto,
just
presents
us
a
logopender.
That
makes
total
sense.
A
But
I
think
that
we,
we
would
potentially
also
need
the
ability
to
to
capture
these
structured
events.
Now
the
low-level
plumbing
at
the
otrp
level
and
and
how
you
transport
these
from
a
to
b
and
what
they
look
like
on.
The
wire
may
well
look
extremely
similar.
G
Yeah-
and
I
think
that's
why
they've
been
grouped
together-
is
they
don't
they're,
not
distinct
enough
that
they
deserve
two
separate
types
on
the
wire
and
so
they've
kind
of
been
grouped
together
into
one
thing
logs
and
events,
but
they
do
have
some
kind
of
key
differences
in
terms
of
how
you
record
them.
A
A
If
we
actually
want
to
move
up
the
stack
and
think
about
about
the
semantics
of
it
and
how
this
stuff
is
actually
used
and
how
people
think
about
it
and
how
the
data
will
be
will
be
generated
in
applications
and
how
it
will
actually
be
queried
and
looked
at
and
what
it
actually
means.
Once
it's
in
a
back
end
somewhere,
then,
maybe
that
is
how
you
tease
apart
the
difference
between
a
login
and
event.
B
It
can
have
some
an
attribute
that
tags
it,
whether
it's
an
event,
a
rom
event
or
whether
it's
a
raw
log
or
something
like
that
to
allow
pipelines
to
be
able
to
distinguish
these
things
and
send
it
to
the
appropriate
place,
an
appropriate
analysis
applied
to
them.
So,
like
you
say,
under
the
hood,
it
all
has
the
same
data
model,
which
happens
to
be
called
the
logging
data
model.
B
But
the
way
that
those
are
distinguished
is
via
this
instrumentation
scope
and
then
probably
I
have
always
always
been
pushing
for
a
separate
api
for
events
via
versus
logs,
and
we
wouldn't
want
one
a
new
logging
api
in
java,
because
we've
already
got
too
many.
B
But
we
would
want
to
have
an
event
generating
api
because
that's
actually
a
fairly
novel
and
new
thing
that
isn't
really
captured
by
any
of
any
existing
open
source
framework.
That
I'm
aware
of.
A
And
it's
it's
totally
fine.
I
think
that
if
we,
if
the
event
api
and
we
actually
spin
it
on
its
head,
so
we
talk
about
the
event
api
first
and
the
log
is
actually
just
a
special
case
of
it
right,
because
the
the
logging
api
can
actually
match
against
the
existing
sl4j
or
you
know
some
other
api,
but
we
don't
expect
anyone's
going
to
use
it,
and
then
we
get
into
the
philosophical
question
of.
Should
we
expose
it
if
people
aren't
going
to
use
it.
G
Right
and
that
that's
kind
of
the
question
that
I
pose
like
who
would
be
the
intended
users
of
the
the
special
case,
just
application
log
api
and
like
one
direction
that
we
could
go,
is
we
could
introduce
a
log
api.
We
call
this
whole
thing
the
log
api,
but
it
only
has
apis
for
recording
events
and
we
leave
it
open
like
whether
or
not
we
want
to
add
at
some
later
time,
api
specifically
for
recording
traditional
application
logs.
A
G
A
So
hold
on
a
second,
let's
just
play
with
this
a
little
bit
further.
The
distinction,
one
of
the
the
key
distinctions
that
we've
drawn
between
between
a
a
log
in
an
event
here
is
the
concept
of
severity.
Okay.
So
what
what
are
we
saying?
We
would
have
to
model
severity
somehow,
because
the
log
appender
that
we
would
use
for
in
slf
j,
for
example,
will
have
to
to
to
ultimately
call
our
event
api
so
somewhere
the
event
api
must
have
a
domain
model
of
severity.
No
john.
B
G
And
that's
already
modeled
in
the
in
open,
telemetry
java
instrumentation
today
that
we
we
do
that
exact
thing
with
log
log
for
j
and
log
back.
A
A
G
Exactly
and
I
think
the
reason
you
would
still
recommend
them
to
use
slf4j
instead
of
our
logging
api.
If
we
were
to
even
build
one,
would
be
because
they'd
be
if
they,
if
we
force
them
to
use
our
log
api
for
recording
application
logs,
then
they
all
of
a
sudden
lose
out
on
all
the
richness
and
configurability
of
what
you
can
do
with
those
logs
like.
A
Right
so
so,
actually,
what
we're
saying
is
I
mean,
and
I'm
just
I'm
just
playing
with
this
and
just
see
how
far
we
we
go
with
it?
What
we're
saying
is
we
would
just
issue
guidance
which
says,
if
you
are
a
library,
author,
who's,
writing
an
open,
telemetry
aware
library.
This
is
the
pattern
that
you
would
use
slf
j
and
you
would
configure
it
with
an
open
telemetry,
a
panda
just
to
send
logs.
A
B
Right,
yeah
there's
one
there's
one
extra
little
thing:
that's
been
kicked
around
quite
a
bit,
especially
in
the
the
client
telemetry
group,
and
that
is
the
idea
of
causality.
B
So
logs
traditionally
and
events,
don't
they
don't
traditionally
have
any
way
to
provide
downstream
causality
like
there's
no
id
like
there
is
with
a
span,
for
example,
that
you
could
then
tag
that
this
event
is
a
cause
of
some
other,
some
other
thing,
and
so
there's
been
in
in
that
case,
if
you
have
a,
if
you
have
something
that
requires
causality
or
unfortunately
required
to
fall
back
on
zero
duration
spans
in
order
to
provide
a
way
to
link
things
causally-
and
I
don't
think
anyone
has
proposed
that
causal
connection
to
the
event
api
like
a
way
that,
like
an
event
id
so
that
you
could
provide
causal
connection
to
things.
G
B
One
direction
anyway:
it's
just
something
to
think
about
if
we
are
going
to
design
an
event
api
that
that
the
potential
for
causality
is
there
and
that's
something
that
might
be
interesting
to
consider
and
that
the
log
mod
data
model
does
not
have
the
notion
of
at
the
moment
anyway.
I'll
leave
you
all
with
that
thought.
I
got
to
take
off,
see
you
folks
tonight
see
you
later
see
you
john.
D
Just
fire
and
forget,
but
then
somewhere
in
the
machinery
of
the
processor
or
exporter
they
get
turned
into
logs,
is.
D
D
E
G
Idea
that
the
idea
that
I'm
bringing
to
the
java
sig
is
this
one
that
would
we
be
okay
with
this
as
long
as
we
don't
have
to
actually,
if
we're
not
like
required
to
implement
an
application
log
api
to
be
compliant,
because
you
know,
I
don't
think
we
should
have
like
you
know,
replace
slm
for
j
or
re.
Have
that
same
api
that
exists,
and
you
know
that's
what
I
want
to
bring
back
to
this
spec
level-
is
that
we
should
still
we
shouldn't
have
to
implement
that
to
be
compliant.
A
G
Yeah
I
know
I
was
interested.
Tigran
seemed
pretty
convinced
that
certain
languages
have
have
no
kind
of
like
strong
players
in
the
in
the
logging
space
and
they
might
actually
benefit
from
a
general
log
api
in
a
way
that
java
wouldn't
so
yeah.
D
G
F
So
jack
is,
would
we
need,
I
think,
the
the
consensus?
Is
we
wouldn't
want
to
call
it
a
log
api?
Even
if
we
didn't
have
right,
because
it
wasn't
that
part
of
your.
G
Well,
so
I
don't
know
what
we
call
it.
So
you
know
it
should
only
record
events.
I
think
that's
the
consensus,
but
whether
we
call
it
a
log
api
to
align
with
the
fact
that
we
have
a
log
sdk
and
it
produces
open
telemetry
logs
on
the
on
the
wire
that,
I
think
that's
an
open
question.
I
I
don't
have
a
strong
opinion
on
that.
Yet.
F
G
I
see
that
for
sure
the
the
counter
to
that
is.
Is
it
confusing
that
an
event
api
is
wired
up
to
the
log
sdk,
don't
think
so,.
F
Well,
I
mean,
I
think,
it's
less
confusing,
but
maybe
that's
only
in
my
brain
at
the
because
I've
been
indoctrinated
into
hotel
logs
equals
events.
G
G
D
I
I
do
also
think
it's
just
very
it's
mildly.
Interesting
to
see
the
differences
like
new
relic
definitely
thinks
that
events
are
a
separate
signal
type
than
logs.
They
always
have
like
it's
been
melt
from
the
beginning,
and
you
know
splunk
everything's
a
log.
So
it's
interesting
to
see
that
just
perspective
right.
D
So
we
we
piggyback
on
logs
in
our
profiler,
like
we're,
sending
stack
traces
over
logs
and
I'm
just
thinking
like
that.
It
actually
does
make
a
lot
more
sense
to
conceptualize.
Those,
as
events
to
me
like
logs,
is
just
it.
It
feels
hacky
and
yeah.
So
I
think
that
I
think
I'm
I
think
I'm
growing
on
that
distinction,
so
good
yeah,
good
talk.
F
F
Let's
see,
let's
pop,
let's
move
some
things
above
my
topics.
F
Yeah,
I
saw
the
then,
and
I
guess
only
you
were
at
common
yeah
from
yesterday's
jbm
metrics
meeting
yeah
but
yeah.
I
liked
this
I'd
noticed
this
lack
of
symmetry,
also
in
that
pr
between
loaded
and
unloaded.
F
But
I
had
looked
on
jonathan
I
looked
and
micrometer
named
them.
Similarly,
so
that
seemed
to
convince
me
that
it
was
all
right,
but
did
you
all
have
any
other
thoughts
or
jonathan,
maybe
from
the
micrometer
perspective?
Has
this
caused
confusion
in
the
past?
The
idea
that
loaded
is
currently
loaded
and
unloaded
is
total,
unloaded.
C
I
am
not
aware
of
it,
but
yeah,
so
I
I
haven't
looked
into
this,
but
it
is
weird
to
me
as
well
when
you
are
saying
that
low,
that
it
is
the
the
current
value
and
that
it's
unloaded
is
basically
the
cumulative
value.
C
F
What
is
which
ambien
am
I
googling
class.
G
G
F
So
that
mx
beam
is
more
clear.
It
calls
it
total
loaded,
total
loaded,
although
yeah
you're
right
it
is
it
is
follows
because
loaded
is
currently
loaded
and
unloaded,
is
total
unloaded,
so
yeah.
The
the
mx
beam
is
equally
lacks.
Clarity
in
the
name.
F
A
E
C
I
I
was
out
for
a
while-
and
I
wanted
to
like
reply
on
this
this
week,
but
I
got
distracted,
so
I
I
I
forgot
it,
but
I
will
I
will
write
this
down
as
well.
So
there
are
a
couple
of
things
here.
One
is
kind
of
sad.
We
are
not
going
forward
with
micrometer
to
the
text.
C
Oh
wow
yeah,
so
you
users
like
we,
it
will
be
hard
for
us
to
like
do
breaking
changes
right
now
with
micrometer
to
that
x.
So
we
will
like
postpone
it
indefinitely
and
we
will
continue
the
one
the
text
line.
C
This
means
that
basically
most
of
the
changes
that
we
did
into
the
text,
those
are
like
editions,
so
those
can
go
to
a
new
minor
release
so
that
one
that
then,
will
be
that
one
and
basically
like
other
than
that
we
just
like
removed
like
deprecated
things
and
and
a
couple
of
like
we
renamed
a
couple
of
things
that
we
basically
reverted
so
micrometer
to
the
text
will
not
happen
this
year.
We
don't
know
when
will
it
happen?
C
C
So
this
a
little
bit
frames.
The
the
answer
of
my
question
to
my
answer
to
this
question
and
also,
let
me
give
you
a
little
bit
of
like
background
what
is
happening
in
micrometer.
If
you
haven't
read
through
that
that
issue,
so
in
micrometer
there
is
a
abstraction
called
meter
and
the
meter
can
be
like
a
time
series
or
multiple
time
series
and
the
meter
is
basically
identified
via
two
things.
C
One
is
the
name
of
the
meter
and
the
other
one
is
the
tags
of
that
meter
or
labels,
and
every
meter
has
the
this
description
and
a
unit.
So
that's
that's
the
issue.
C
I
believe
that
the
description
on
the
unit
it
doesn't
belong
to
the
name
of
the
meter,
but
it
belongs
to
the
whole
id
of
it
so
name
and
tags
right
and,
for
example,
in
in
this
case,
I
believe
the
issue
is
that
when
we
create
like
a
matrix
for
for
for
threads,
then
we
will
have
the
thread
state
as
well.
C
C
I
believe
for
the
description.
This
can
be
a
valid
scenario
that
different,
like
different
meters
or
different,
like
a
set
of
texts,
can
have
like
different
description.
I
don't
think
this
is
valid
for
the
unit
at
all.
To
me
that
feels
weird.
C
Unit
as
well
and
having
this
so,
for
example,
like
having
a
different
unit
when,
like
a
value
of
a
tag,
is
different.
C
That's
that's
weird
to
me.
That
should
not
be
like
that
having
a
different
description,
maybe
that
can
be
valid,
but
I'm
not
hundred
percent
sure
if
we
have
a
a
single
registry
as
of
today
that
we
support
that
can
support
this
use
case.
For
example,
prometheus
does
not,
which
prometheus
has
the
description
for
the
whole
metric
group,
and
that
is,
for
example,
if
you
look
at
2d
thread
state
metrics
for
micrometer.
That
is
weird
because
the
prometeous
description
we
said
that
hey.
C
C
C
The
aggregation
is
basically
like
picking
picking
one,
and
I
don't
know
like
based
on
what
so
I
guess
so
we
will
not
be
able
to
fix
this
in
micrometer
one,
but
what
we
can
do
is
we
can
go
to
the
code
base
and
basically
check
these
things
and
eliminate
them.
C
I
believe
for,
for
example,
the
threat
state
we
can.
We
can
give
a
description
which
is
like
general
enough,
so
that
we
don't
need
to
like
generate
them
dynamically
and
I
believe,
when
users
are
instrumenting
their
own
code
base.
I
guess
that
is
the
same
thing
here.
So
descriptions
and
units
are
static
most
of
the
time
they
are
basically
just
hard
coded.
C
There
are
very
very
like,
like
rare
cases,
for
example
this
one.
Then
it
is
generated,
but
if
you
could
give
us
a
list
where
this
can
cause
trouble,
then
yeah
we
can.
We
can
fix
that
in
1.10.
G
Okay,
yeah,
just
like
one
comment,
so
I
I
I
get
I
get,
maybe
why
you
might
want
to
have
a
description
that
varies
based
on
the
set
of
tags
that
you
have,
but
I
I
from
all
the
examples
that
I
found
I
was
going
through
micrometer.
It
seems
like
that
when
the
description
varies,
all
it
does
is
kind
of
restate
the
tags.
G
It
varies
in
a
way
that
restates
the
tag,
so
it's
kind
of
like
a
it's
kind
of
redundant
in
a
way.
You
know
I
know
you're
stuck
into
that
api,
so
you
know.
C
So
when
I
first
saw
that
comment,
that
was
my
first
reaction.
Okay,
like
users,
should
not
do
this
like
a
description
and
unit.
They
should
be
like
usually
hard
coded,
so
it
shouldn't
be
dynamic,
so
it
should
not
cause
any
issues,
but
then
I
saw
that
hey.
It
is
causing
issues,
because
we
are
doing
that
in
our
own
instrumentation
for
the
40
thread,
states
and
yeah,
I
yeah
that
is
kind
of
redundant.
I
can.
I
can
totally
like
agree
on
that
and
yeah
we
can.
We
can
fix
it.
C
G
Yeah
there
was
there's
a
lot
of
them,
and
so
I
ran
a
simple
spring
boot
app
with
micrometer
enabled
so
spring
boot
actuator
activated,
and
then
I
was
using
the
micrometer
shim
to
shim
that
over
to
the
open,
telemetry
metrics
sdk-
and
there
was
just
like
there's
a
ton
of
logs.
G
I
didn't
grab
a
list
of
all
the
offending
metric
names,
but
I
can
I
can
get
that
list.
That
would
be
great
now
that
one
it
it
wouldn't
necessarily
be
the
complete
list,
because
I'm
probably
exercising
just
a
subset
of
the
metrics
based
on
my
configuration,
but
maybe
that's
a
start.
We
can.
We
can
iterate
over
this,
like.
C
Okay,
you
can.
We
can
totally
fix
this
another
thing
that
can
happen
that,
like
if
the
instrumentation
like
happens
in
in
boot
again,
we
can
open
up
requests
there
as
well,
for
example
like
showing
the
committee's
output,
because
that
is
the
like.
That
is
kind
of
proof
that
this
is
not
not
entirely
right.
Well,
there
are
cases
when
this
can
go
wrong
and
if
the
users
are
using
prometheus,
which
is
like
pretty
popular,
the
description
can
be
here.
F
C
C
But
if,
like
the
the
the
description
is
created
by
by
booting
instrumenting
itself,
then
the
pull
request
needs
to
be
created
against
boot
and
it
is
up
to
the
boot
team.
How
will
they
handle
this
yeah?
That
makes.
A
E
Yeah
definitely
and
hearing
that
micrometer
does
it
like
itself
and
from
if
you
just
made
the
idea
even
more
viable
right
right.
C
C
So,
if
you
bump
into
any
place
that
you
will
not
be
so,
there
is
a
library
instrumenting
itself
with
micrometer,
and
because
this
issue
is
true
and
they
don't
want
to
like
change
it
or
fix
it,
then
you
can
actually
like
provide
a
meter
filter
register
it
into
your
own,
like
a
otrb
registry,
and
that
will
basically
just
check
hey.
C
F
Cool-
let's
see
this,
oh
yes,
this
is
still
stuck.
I
think
I
need
to
ping
bogdan
again.
C
No
problem
bro,
I
I
was
just
like
I
was
curious
if
there
is
like
a
any
other
like
under
the
hood
discussion.
I
am
not
not
aware
of
what
what
book
then
like
would
would
need
here
to
to
convince
him,
because
I
believe
his.
C
C
C
E
E
G
G
So
they
so
I
did
an
analysis
of
the
metrics
that
they
emit
and
so
to
the
extent
that
they
collect
information
that
is
represented
by
system
level,
semantic
inventions.
They
follow
those
semantic
inventions.
They
don't
do
everything
that
the
system
level
semantic
inventions-
you
know
document,
but
they
do.
They
do
fair.
Well,.
F
Yeah,
unfortunately,
as
of
today,
it's
still
not
com
considered
not
compliant
for
the
our
ocean.
Metrics
are
considered
not
compliant
because.
F
That's
what
this
issue
is
yeah.
We
went
back
and
forth
with
plugged
in
a
bunch,
and
so
I
I
opened
this
kind
of
essentially
with
one
example
here
are:
we
is
language
based
instrumentation
allowed
to
report,
cpu
time
for
itself
or
disk
io
or.
C
I
I
believe
both
are
valid
right
so
like
they,
they
mean
like
different
things
like
one
is
the
one
is
they
belong
to
the
host
and
the
other
one
is
below
to
the
process
and
those
things
doesn't
necessarily
match,
also
the
the
the
the
one
that
belongs
to
the
project
process
that
can
change
right,
because
just
you
were
able
to
to
make
it
like
different
in,
like
just
one
run
like
without
restarting
the
jvm
right.
The.
C
G
G
So
if
you
have
one
of
the
processes
out
of
many
running
in
that
container-
and
you
ask
the
system
for
what's
my
cpu
and
memory
like
utilization
and
what's
available
well,
I
get
this
the
measurements
that
refer
to
the
containers
environment,
which
has
been
constrained
or
will
I
get
the
overall
node
like
the
overall
hosts
cpu
and
memory
measurements.
C
So
it
depends
on
your
java
version,
but
because,
like
a
previous
like
or
older
java
versions,
they
did
not
have
like
a
darker
support
or
container
support.
C
So
when
you
set
the
cpu
limit
in
docker
or
share
or
whatever
and
for
example,
you
limited
the
container
for
just
one
cpu
or
one
core
java
still
saw
the
the
core
count
of
the
host.
C
If
you
are
using
a
new
word
jvm,
which
should
be
the
case
for
everyone
as
of
today,
because
this
happened
years
years
years
ago,
the
two
should
be
the
same,
but
I
believe
my
point
there
is
that
in
containerized
environment
you
should
not
really
run
multiple
processes
in
one
container.
So
the
usually
the
rule.
G
C
C
I
don't
really
have
an
opinion
on
that,
but
I
feel
that
is
that
is
kind
of
funny,
but
like
having
the
collector
and
the
jvm
running
on
inside
of
the
same
container.
That
seems
to
be
like
a
little
bit
invalid
to
me.
G
Yeah
yeah
that
seems
invalid
to
me
too,
because
those
each
you
know
the
collector
has
its
own
container
that
it
publishes
its
own
image
that
it
publishes.
I
guess
I'm
trying
to
like
distinguish
like.
Is
there
any
situation
where
it
is
useful
for
the
jvm
to
try
to
measure
or
the
jvm
instrumentation
to
try
to
measure
its
system
utilization?
C
C
It
I
can
give
you
a
very,
hopefully,
very
valid,
like
a
scenario
which
can
happen
as
of
today.
So
let's
say
that
you
are
running
like
a
jvm
in
like
a
kubernetes
environment,
and
when
you
create
your
pod,
you
don't
you
forget-
to
define
your
cpu
request
now
when
you
do
this,
the
kubernetes,
I'm
not
hundred
percent
sure
if
this
is
the
the
exact
number
as
of
today,
but
it
was
the
exact
number
like
one
and
a
half
years
ago
or
two
years
ago
we
will
set
the
cpu
share
to
docker
s2.
C
While
the
jvm
will
do
this
number,
it
will
divide
it
by
124
1024
and
it
will
like
get
a
number
which
is
the
core
count
of
one.
C
So
you
can
have
a
a
big
like
beefy
box,
which
has
like
I
don't
know,
64
cores.
You
forgot
to
set
the
the
cpu
request
in
kubernetes
and
you
will
end
up
the
core
count
of
one,
and
this
is
above.
This
should
not
happen.
I
guess
I
believe
in
this
case
the
core
count
should
be
like
64.
C
and-
and
this
has
a
couple
of
consequences,
for
example,
this
will
set
the
the
combo
pull
size
to
one
as
well.
So,
if
you
are
using
like
the
parallel
stream,
you,
those
will
not
be
parallel.
If
you
are
using
the
fortune
api.
That
will
not
be
that
we
run
on
one
thread
if
you
are
using
the
what
is
the
name
of
it,
completable
future
that
will
use
only
one
thread
as
well
out
of
the
box.
C
Also,
you
will
use
the
single
threaded
gc,
because
you
only
have
one
thread
and
the
jvm
will
pick
that
for
you
and
the
cheat
threads
will
be
one
as
well
the
just
in
time
compiler,
so
it
can
have
pretty
significant,
like
effects
like,
I
believe,
knowing
these
values
inside
of
the
jvm
verse
like
it
versus
it.
F
Yeah,
I'm
sorry,
I
have
to
play
time
cop,
but
that
is
my
burden.
No,
no!
Let's
I
will
bump.
I
think,
there's
more
to
be
discussed
on
this
topic.
So
I'll
add
it
to
next
week's
agenda
yeah,
because
it's
it's
currently
it
is
a
blocker
for
us
and
cool
great
to
see
everybody
see
you
later
next
time.
Thank
you
see
you
bye.