►
From YouTube: 2022-03-03 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).
B
B
A
D
D
A
Yeah,
okay,.
D
Now
it's
pretty
good,
although
I
I
lost
my
sense
of
smell,
so
it's
kind
of
a
pity,
because
coffee
right
now
just
tastes
like
you
know:
hot
water
with
ash
and
it's
kind
of
terrible.
But
aside
from
that,
it's
mild
cold
symptoms.
So
not
that
terrible.
A
It's
been
a
bit
quiet
in
the
on
the
instrumentation
side,
with
nikita
and
mateusz
out.
Primarily
this
week,
I've
been
doing
a
bunch
of
trying
to
fix
a
bunch
of
flaky
and
lori
also
has
been
working
on
flaky
tests
in
flaky
tests.
I've
been
trying
to
improve
the
gradle
or
the
github
actions
cache
to
help
with
the
maven
central
download
flakes,
partly
because
we
may
lose
admin
rights
in
the
repo
they're.
A
Considering
open
telemetry
wide
putting
everybody
back
to
just
the
maintainers
back
to
maintain
rights,
which
means
we
won't
be
able
to
click
the
override
merge
anyway,
when
there's
a
flaky
build.
So
I
think
that's
important
to
work
out
the
flakes.
A
So
yeah
so
honorag
had
a
really
good
point
about
that.
I
hadn't
thought
of
when
we
were
chatting
the
last
time
about
how
all
of
the
instrumentation
all
of
the
open,
telemetry
instrumentation
is
tied
to
both
and
the
instrumentation
api
that
we've
been
discussing
a
lot.
It
kind
of
brings
those
two
concepts
together
and
so
in
the
open
telemetry
world.
A
We
expect
them
to
take
our
grpc
library
instrumentation
and
register
those
interceptors
with
grpc
and
for
it
to
flow
through
there.
So
I
think
from
that
perspective,
it's
going
to
be
really
hard
to
only
offer
tracing.
C
So
it's
yeah,
so
I
think
it's
from
the
project
point
of
view.
You
think,
is
like
a
three
pillars
interconnected,
like
a
logging.
Matrix
entry
is
interconnected.
C
So
it's,
however,
because
because
it's
for
the
timing
issue
and
etc,
so
we
have
our
own
metrics
in
micro
profile.
So
do
you
think
I
think,
is
the
other
option.
I
mean
other
solution
we
could
proceed
with
is
from
a
tracing
point
of
view.
It
does
not
rely
on
matrix
right,
so
I,
if
I
choose,
because
I
could
just
plug
in
my
own
metrics
or
I
just
choose-
I
have
a
trees
in
no
matrix.
C
Is
that
is
that
possible?
For
example,
we
just
take
the
open,
telemetry,
apigee
and
basically
repackage
it
doesn't
have
a
treating
apis.
So
it's
these
are
going
to
work.
A
Yeah
and
on
the
for
instrumentation,
if
users,
so
they
use,
say
the
gr
grpc
open,
telemetry,
grpc
instrumentation,
that's
going
to
emit
both
traces
and
metrics.
But
if
the
user
doesn't
configure
a
metric
exporter.
C
A
Metric
reader,
then
that
becomes
no
op
on
the
metric
side,
so
they
would
only
get
traces
flowing
also.
E
A
I
think
the
primarily
it's
the
the
instrumentation,
the
not
the
apis
themselves,
but
the
the
whole
ecosystem
of
open,
telemetry
instrumentation
is
designed
around
emitting
both
traces
and
metrics.
But
from.
E
The
user
perspective,
it
is
completely
like
transparent,
they
don't
care
like
if
the
instrumentation
happens
just
like
once
and
that
the
instrumentation
will
emit
like
both
metrics
and
spans
or
like.
There
are
two
different
instrumentations
I
they
will
never
know
about
it.
E
B
I
think
inherently,
if
you're
constructing
one
of
the
instrumentation
libraries,
it
will
require
an
open
telemetry
object,
not
just
and
that
open
telemetry
object
has
both
metrics
and
tracing
in
it.
So
from
that
perspective,
yes,
they
I
mean
implicitly,
it
depends
on
both
of
those
things,
even
from
the
user
perspective.
E
Because
in
in
that
case,
from
from
amelie's
perspective,
if
they
want
to
use
like
tracing
only,
but
they
want
like
these
like
interconnectedness
features,
then
they
just
need
to
implement
examples
in
mp,
metrics
well.
A
Okay,
cool
yeah,
if
they
want
to
throw
if
they
don't
hook
up
anything
to
the
open,
telemetry
metrics
pipeline,
that's
fine!
I
mean
we
have
a
lot
of
users
who
you
know
send
to
zipkin
which
doesn't
support
metrics
anyway.
A
So
you
know
if
they're
not
using
like
prometheus
or
something
else
for
metrics.
C
A
Yeah
and
on
the
instrumentation
side,
the
instrumentation
is
still
going
to
basically
send
metrics
to
that
no
op
sdk
but
part
of
the
there's
a
lot
there's
a
lot
less
overhead,
because
you're
already
paying
the
overhead.
A
The
reason
why
we're
pulling
tracing
and
metrics
together
in
the
instrumentation
api
is
because
most
of
those
like
attributes
and
timings
are
the
same
that
we
want
to
calculate
capture
for
traces
and
metrics,
and
so
we've
already
captured
it
for
tracing.
So
there's
not
a
lot
of
extra
overhead,
then
for
sending
passing
those
on
to
that.
No
op
metrics
sdk.
C
So
you
see
it's
like
so
just
let
do
not
in
these
cases
are
st.
So
if
we
consume
the
sdk
but
don't
plug
in
anything
else,
I
don't
really
need
to
configure
specify
any
configuration
right
since
it
will
be
in
the
wall.
B
A
You,
since
the
api,
metrics
api
and
metrics
sdk,
are
in
separate
artifacts
use
like
your
your
your
you're,
going
to
have
a
dependency
on
open,
telemetry
api,
which
will
bring
in
the
metrics
api,
but
since
you're
not
bringing
in
the
metrics
sdk,
then
that
would
always
be
a
no
op.
Then,
unless
the
user
explicitly
brought
in
the
f
metrics
sdk.
C
Right,
okay,
so
matrix
sdk
is
separate.
It's
not
matrix,
says
decay
is
separated
from
chasing
sdk
right.
A
Yeah
john,
I
think
we
confirmed
that
last
week
that,
while
the
api
packages
are
merged
together,
the
sdks
there
is
a
common
sdk
bundle,
but
it
transitively
depends
on
the
separate
signal
sdks.
C
Okay,
that's
that's
better
because,
but
at
least
we
could
like
a
manipulator
api.
A
Yeah-
and
it
would
be
great,
I
think,
to
explore
that
idea
of
bridging
the
open,
telemetry
metrics
into
the
microprofile
metrics,
because
that
that
will
provide
a
lot
of
benefit
to
users.
I
mean
they're
going
to
get
auto
metric
capture
from
all
of
the
open,
telemetry
instrumentation,
and
you
should
still
be
able
to
consume
that
metrics
through,
like
a
metrics
reader,
pull
that
metrics
data
out
when
you're
exporting
it
via
micro
profile.
B
So
I
just
confirmed
the
sdks
are
all
completely
independent.
They
just
have
they
have
a
there's,
a
is
a
common
that
pulls
everything
in
or
is
it
no
it's.
I
think
it's
an
all
that
pulls
everything
in,
but
the
common
is
the
things
that
they
all
depend
on.
The
sdks
are
all
independent
of
each
other.
C
C
The
other
thing
is
kind
of
if
we
use
the
open,
open,
telemetry
tracing.
You
said
the
bridge
and
matrix
to
macro
profile.
Metrics.
Are
you
saying
like
I
basically?
Is
we
offer
user
the
open,
telemetry
apis,
however,
the
implementation
will
be
using
micro
profile.
Metrics.
Is
that
what
you're
saying
operating.
A
So
yeah
there's
different
levels
you
could
bridge
at
the.
I
think,
implementing
the
full
metrics
api
would
be
probably
the
most
work
as
far
as
an
option
of
bridging.
A
I
think
the
simpler
bridging
would
potentially
be
let
the
open
telemetry
have
the
open,
telemetry
sdk
there.
The
instrumentation
will
write
to
the
metrics
api
it'll
go
to
the
metrics.
Sdk
that'll
do
all
the
aggregations,
and
then
you
can
configure
what's
called
a
metric
reader
and
periodically,
when
sort
of
you
probably
have
in
micro
profile,
metrics
your
own
aggregations
and
then
say
once
a
minute
you're,
probably
taking
those
and
and
exporting
them,
or
maybe
you
have
a
prometheus
endpoint
that
gets
scraped
for
them.
C
Is
this
the
what
jonathan
has
done
with
the
bridging
to
micrometer.
C
So
you
have
a
pr
about
doing
abrasion
from
open
telemetry
metrics
to
micrometer
right.
E
That
that
wasn't
me
so
there
were,
there
were
two
vrs
one
or
not
two
peers.
There
are
two
approaches,
one
it
was
written
by
matajos.
I
guess-
and
there
is
another
one
which
is
just
a
pr
right
now.
D
There
was
open,
telemetry,
open,
telemetry
micrometer
pr
some
time
ago
in
contrib,
but
I
think
it
got
closed.
I
mean
there
was
no
interest
in
continuing
this.
A
B
B
C
C
A
Not
that
I
know
of
because
primarily
all
of
our
bridges
are
focused
on
bridging
other
things,
into
open,
telemetry
right,
so
open
telemetry
as
the
destination
exporter
supporting
exporters,
collector
story,
the
whole
open,
telemetry
ecosystem.
We
sort
of
need
it
to
come
into
the
into
open
telemetry
world.
C
Okay,
so
the
the
pr
to
the
earlier
is
it
I'm
confused
now
is
the
bridging
from
open
telemetry
to
micrometer
right
or
the
other
way
around.
A
Yeah,
the
the
offici,
the
bridge
that
we're
providing
today
in
open
telemetry
is
from
micrometer
to.
C
A
Yeah
so,
for
example,
this
bridge
is,
creates
a
micrometer
meter
registry,
so
people
can
interact
in
just
the
exact
same
way.
They
do
with
all
other
meter
registries
and
behind
the
scenes.
It
translates
everything
into
open,
telemetry,
metrics
api
calls.
A
Oh,
it
was
those
are
very
old
yeah
they're
supposed
to
be
there's
an
open,
telemetry
yeah,
but
I've
seen
some
people
recently
saying
that
they're
not
always
getting
uploaded
they're
supposed
to
get
auto
uploaded,
but
if
you're
looking
for
one
and
not
finding
it,
if
you
ping
me
or
ping
us
on
slack,
then
I
can
ask
the
folks
who
have
access
to
that.
F
C
A
You
have
this
link
to
this
doc.
A
Yeah
and
honorary-
and
I
had
one
question
for
you-
we
were
talking
about
this
and
just
curious
on
the
it
sounds
like
on
the
tracing
side,
so
on
the
metric
side,
you're
going
with
an
abstraction,
but
on
the
tracing
side.
You're
not
like.
We
weren't
sure
why
we're
curious,
why
you
were
not
creating
an
abstraction
on
both
sides
for
both
metrics
and
tracing.
C
Yeah,
so
the
tracing,
because
at
the
moment
we're
using
open
teaching,
as
you
know,
in
the
open
telemetry
is
the
kind
of
the
merge
or
open
teaching
open
choosing
community
is
is,
is
a
kind
of
the
yeah,
it's
a
part
in
the
past,
so
we
want
kind
of
the
adopt
open,
telemetry
treating
for
metrics
because
there's
the
kind
of
there's
a
lot
other
discussion.
C
So
besides
that
the
other
thing
is
the
there's,
a
different
views
on
the
open,
telemetry
metrics.
Otherwise,
we'll
still
need
a
few
months
to
get
everything
ready
and
so
that
the
matrix
team
they
make
they
make
their
own
decision,
which
magics
is
one.
So
it's
so
I
think
we
just
have
to
go
with
try
out
the
treating
first,
I
think
when,
once
these
logging
is
out,
probably
that
would
be
a
easier,
the
easier
way
to
adopt
a
login,
because
we
don't
have
login
yeah,
yeah
microprofile.
C
So
for
metrics
these
are
quite
difficult,
a
decision
and
but
because
they
want
to
move
forward,
they
have
some
choices
and
directions
and
etc.
C
C
Interesting,
that's
really
interesting
because
we
have
discussed
the
login
api
in
microprofile
in
the
past
few
years
and
then
also
there
was
a
pushback
about
creating
a
new
login
api
because
there's
a
logo
14.
also
maybe
it's
a
java
youtube
login
is
the
other
way
since
the
log
importing
it
had
a
yeah.
B
A
We
haven't
tried,
we
do
have
auto
instrumentation
for
java
util
logging.
I
think
they
do
have
handlers.
I
think
that
I
think
I
would
ask
honor,
I
think
honor
I
could
mention,
and
I
sort
of
I
sort
of
agree
that
most
people
using
java
util
logging
are
like
redirecting
that
to
log
back.
C
So
I
know
somebody
know
something
somewhat:
some
a
group
of
people
they
directly
use
java
youtube
logging.
They
don't
use
any
libraries.
C
C
C
C
A
Yes,
yeah
there's
also
system
logger
in
oh.
C
C
Yeah,
I
heard
a
good
news
about
this
malaga.
I
have
not
tried
them
myself,
but
people
talk
about
system
logo.
A
So
we're
we're
definitely
interested
in
supporting
those.
I
think
we
just
haven't
had
most
the
most
popular
we've
just
dealt
with
the
most
popular
first.
A
Oh
sorry,
one
on
the
metric.
I
just
wanted
to
make
sure
that
the
metric
sdk
open,
telemetry
metric
sdk
stability
wasn't
one
of
the
things
blocking
that
being
a
consideration,
because
that
is
coming
pretty
soon
soonish.
I
don't
know
what
now
that
it
was
supposed
to
be
already
happened,
but
maybe
another
month
or
two.
C
C
So
that's
that's!
That's
the
people
are
leaning
towards
like
let's
go
with
the
micrometer
for
now,
like
let's
wait
and
see,
maybe
two
years
yeah,
two
years
down
the
line,
maybe
it's
a
microprofile
unknown
microphone,
open,
telemetry,
metrics,
again
more
popularity
than
micro
nature.
Maybe
then
it's
a
kind
of
just
use
some
open,
telemetry,
matchings,
so
yeah.
So
it's
a
yeah.
A
We
would
way
prefer
for
you
to
use
micrometer
compared
to
building
yet
another
metric
library.
Just
because
you
know
we
we
completely,
I
think
you
know
we're
going
to
be
bridging.
How
we'll
have
a
really
nice
story
between
open,
telemetry
and
micrometer.
A
You
know
we're
putting
a
lot
of
time
and
effort
on
both
sides
to
that
bridging
and
so
but
building
yet
another
metrics
api.
Is
you
know
it's
just?
It's
proliferating
that
complexity,
the
bridging
complexity.
C
Yeah
yeah,
I
understand
you
know,
is
the
microprofile
matrix
because
also
it
has
a
set
of
apis
and
then
they
go
to
customers
so
and
then
the
customers
also
like
apis.
C
C
A
Sounds
good
should
we
talk
briefly
live
at
metrics,
cpu,
metrics,
jonathan's,
p.r,.
A
So
I
put
various
have
put
various
prs
into
the
spec
repo
seeking
clarification
on
things,
and
so
just
to
summarize,
so
we
definitely
cannot
use
the
system
namespace.
I'm
actually
not.
At
this
point,
though,
I
don't
think
we
even
have
anything
we
want
to
put
in
the
system
name
space,
because
I
don't
know
why
I
wrote
this.
This
is
not
correct.
We
don't
actually
can't
actually
get
cpu
time
system
cpu
time
from
the
jvm.
A
We
get
system,
cpu
utilization
and
the
system.
Cpu
count
turns
out
to
be
process
level.
Cpu
count,
attested
with
you,
can
pin
when
you're
starting
a
here
I'll
show
you
the
what
I
ran.
A
Oh
yeah
yeah
so
like
doing
task
set,
and
then
you
can
do
dash
dash,
cpu
and
pin
it
to
certain
cores
like
you
can,
pin
it
to
just
one
or
two
cores
and
then
you
run
java
and
then
the
runtime
available
processors
will
return
that
number.
So
it
really
isn't
the
system
cpu
count
anyway.
A
So
that
kind
of
leaves
us
still
with
whether
we
would
want
like
the
process
process
cpu
time
and
process
cpu
count.
I
think
they
make
sense
at
the
process
level.
A
I
mean
that's
what
they
are,
but
bugden
is
wants
to
see
if
this
is
a
general
need
across
languages
to
emit
process
level
metrics
or
whether
we
should
just
put
everything
under
if
it's
just
kind
of
special
to
the
jvm
put
everything
under
process.
Runtime
jvm.
E
I
I
don't
think
this
is
like
java
specific,
like
other
languages,
will
react
to
this,
unlike
other
platforms
as
well.
So
if
you
are,
for
example,
running
in
a
docker
container-
and
you
only
give
like
one
core
to
the
2d
process,
it
doesn't
matter
which,
which
language
should
not.
It
should
react
to
that.
A
Yeah
and
then
oh
the
logic
behind
not
wanting
us
to
use
the
system
namespace,
even
though
we
don't
now
have
a
need
for
it
was
that
they
don't
want
to
create
confusion
between
the
they
expect.
The
collector
or
some
os
level
collector
running
and
capturing
those,
and
they
don't
want
to
create
confusion
with
a
process
generating
those
but
yeah
jonathan.
I
I
agree.
I
think
it
makes
a
lot
of
sense
under
the
process,
cpu
count
and
process
cpu
time.
A
I
was
thinking
of
pinging
the
dotnet
maintainers
here,
because
I'm
assuming
that
dotnet
metrics,
probably
produced.net,
probably
produces
some
similar
metrics.
Does
anybody
have
any
other
suggestions
for
languages
that
would
be
worth
pinging?
In
particular,.
A
Then
I
mean
the
question:
is
for
this
pr
in
particular:
do
we
can
either
scale
it
back
to
the
things
we
know
for
now
which
what
do
we
know?
What
would
what's
our
that.
E
I
I
believe
this
pr
doesn't
conflict
with
any
of
these
rights
so
because
it
is
using
the
process
runtime
jvm
prefix,
I'm
not
sure
like
what
are
the
actions
like
on
this
vr.
In
the
light
of
the
the
comments
on
the
on
the
other
discussions.
A
Yep,
that
is
the
the
only
one
like
just
and
process
this
one
is
gonna,
become
process.cpu
count,
okay,
and
I
think
those
are
the
only
two
that
I
think.
E
Could
you
please
take
a
variety
comment,
yeah
yeah
or
like
like
a
review,
because
I
will
not
be
able
to
do
it
today,
but
I
will
do
it
tomorrow.
A
Yep
we'll
do
yeah
this
like
utilization.
There
is
a
process,
cpu
utilization,
but
it
doesn't
match
the
definition.
I
think
I
put
it
over
here.
A
Oh
this
is
system,
cpu
utilization,
but
the
process
cpu
utilization-
also,
I
think,
is
defined
in
terms
of
process
cpu
time
divided
by
elapsed
time,
whereas
the
jvm
just
gives
us
there's
no
like
sort
of
elapsed.
Time
interval
in
that
it's
just
sort
of
a
snapshot
of
in
time.
If
that
makes
sense,.
F
A
Which
actually,
on
the
system
side,
we
don't
get
system
cpu
time,
but
we
do
get
process
cpu
time
right,
yeah.
We
do
get
process
cpu
time,
so
we
could
actually
calculate
process.
Cpu
utilization.
A
Without
having
to
use
this,
that's
a
kind
of
a
good
question,
I
I
tend
to
prefer
the
utilization
being
the
the
delta
divided
by
elapsed,
time
here,
because
that's
your
it's
more!
A
A
I
can
put
all
that
my
thoughts
into
I'll
put
all
my
thoughts
into
a
comment.
Jonathan.
Thank
you
yeah.
Thank
you
for
your
patience.
A
All
right
any
other
topics
we
should
touch
on
today.