►
From YouTube: 2021-03-19 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
A
So
we
have,
we
have
jonathan,
also
in
this
sig,
and
he
he's
an
expert
on
that
and
he's
in
touch
with
the
owner
of
micrometer
and
he's
giving
a
lot
of
valuable
feedback,
and
sometimes
I
can
see
we
struggle
with.
Do
we
want
the
matrix
api
to
be
totally
different
from
existing
one
or
one
that
to
be
a
little
bit
similar
because
people
from
that
background
they
might
find
it's
very
hard.
It's
too
different
yeah.
B
I've,
you
know,
I
it's
an
unpopular
opinion,
but
I
have
often
wondered
whether
we
should
for
languages
that
already
have
strongly
established
metric
libraries
like
micrometer
in
java,
to
not
try
to
introduce
a
new
api,
but
just
have
a
way
to
bridge
it
into
otlp.
B
A
Yeah,
I
I
see
for
logging.
I
I
see
like
we
have
a
clear
understanding.
If
there's
already
like
log4j
there's
a
built-in
python,
logger
or
there's
I
logger
for
dongle,
then
we
should
just
use
that,
if
that's
not
good
enough,
we
should
improve
that
together
to
make
that
work.
Instead
of
inventing
yet
a
whole
new
login
api
and
for
tracing,
we
decided
we'll
have
a
brand
new
tracing
type
metric
somewhere
in
the
middle
yeah.
It's
it's
established
in
some
languages,
but
not
a
lot.
Yeah.
C
A
Let's
give
couple
minutes
for
people
to
join
and
I
I
have
a
pr.
This
is
my
number
one
topic
this
time,
because
I
try
to
take
what,
like
we
discussed
in
the
previous
meeting
and
and
try
to
make
progress
and
and
there's
a
there's,
a
struggle,
because
I
I
try
to
avoid
making
big
changes,
but
sometimes
we
might
have
to
so
bogdan
has
a
suggestion.
We
might
start
a
separate
document.
A
D
Yeah,
so
one
one
quick
thing,
my
video,
my
reasoning
to
ask
for
a
new
file
was
because
github
sucks
on
this.
Yes,
there
was
a
thousand
line
file
and
now
it's
a
100
and
we
have
buys
to
to
make
sure
that
some
words
were
not
change
and
then
you
see,
like
one
word,
10
000
lines
deleted.
Another
word
of
the
phrase
I'm
like
I'm,
not
saying
necessary
to
merge
as
a
new
file.
But
let's
let
me
just
see
as
a
new
file
and
then
right
before
we
merge.
We
can
override
the
old
yeah.
A
Understand
totally
understand
so
I'm
like
I
mean
we
have
three
options:
I'm
just
sending
one
to
at
least
to
start
the
conversation.
So
how
about
this
I'll
quickly
go
through
what
I
I
I'm
trying
to
address
here,
based
on
what
we
discussed
before
so
give
people
understanding
what
I'm
trying
to
do.
So,
first
of
this
pr
I
spoken
to
mentioned.
If
you
look
at
the
div,
it's
very
confusing,
so
I
wouldn't
use
a
div.
I
put
a
link
here.
You
can
see
the
preview
document.
This
is
what
I'm
trying
to
do.
A
So
I
want
the
matrix
api
spec
to
to
follow
what
we
already
have
in
the
tracing
spike.
If
you
look
at
the
tracing
spike,
instead
of
giving
a
lot
of
concepts,
it
tells
you
these
are
the
classes
and
you
go
to
specific
class.
It
gives
you
a
clear
description
of
what
you,
as
the
owner
of
like
you,
implement
the
client.
What
you
should
do
like
this
is
the
api
that
you
should
expose,
and
these
are
the
parameters.
This
is
the
semantic.
A
So
I'm
trying
to
change
the
metrics
back
to
follow
the
same
thing,
because
I
think
it's
a
it's
proven
to
be
successful
and
I
want
that
and
the
number
two
thing
is,
I
think,
in
meter
provider
in
meter
we
have
a
different
explanation
and
still
a
lot
of
people
they're
confused
like
what's
the
uniqueness
and
those
things
I
figured.
The
wording
in
the
tracing
document
is
good
enough.
So
by
just
taking
this
and
replace
tracer
with
meter
we're
almost
there.
The
only
difference
is
we
have
four
layers.
A
So
with
tracer
provider
you
have
threesome
provider,
you
create
tracer
and,
with
tracer,
create
span
you're
done
with
matrix.
It's
four
layers.
You
have
the
meter
provider,
you
create
meter
and
meter
liquid
instrument
and
instrument.
You
create
the
actual
data
point,
so
the
actual
layer
and
there's
a
identity
bogdan.
You
have
something
to
say:
yeah,
you
don't
create
measurements,
you
record
measurements,
yes
exactly
yeah,
but
that's
the
data
point
so
for
tracer
you
you
have
spam.
A
This
is
the
this
is
the
data
you
have
the
class,
but
you
also
have
the
data.
So
this
is
what
I
refer
to.
But
when
you
look
at
the
tracer
provider
and
tracer
the
same
model
can
be
applied
directly
to
meter
provider
and
meter.
I
I
don't
see
any
difference,
so
I
basically
borrow
the
wording
from
here
and
make
that
the.
A
The
proposed
spec,
so
meteor
provider,
the
similar
wording
here,
and
this
is
how
we
treat
the
uniqueness
what's
the
functionality,
and
this
is
what
we
expect
for
meter
and
and
for
instruments.
This
is
something
I
think
it's
it's
pretty
clear
like
we
have.
We
need
that
concept.
What
is
not
very
clear
is
today
we
have
six.
We
have
the
counter
up
down
counter.
A
We
have
this
like,
like
many
different
ideas,
how
how
we
can
map
the
instrument
to
its
semantic,
and
I
think
there
are
different
pillars,
whether
the
value
is
ever
increasing
or
it
can
go
up
and
down
whether
it
is
something
that
can
be
accumulated
or
it
can
be
only
like
sampled
and
and
based
on
that
we
we
have
these
names
and
a
lot
of
feedback
were
actually
pointing
to
these
names.
A
So
in
the
previous
meeting,
I
think
we
got
the
idea
that
we
might
want
to
keep
this
semantic
in
the
data
model,
but
for
the
api
we
want
to
give
people
something
that
looks
familiar
to
them,
instead
of
forcing
them
to
learn
a
new
different
concept.
So
this
is
what
I'm
trying
to
find
the
balance.
The
basic
idea
is
try
to
borrow
some
existing
ideas
from
premises
and
micrometer,
try
to
make
them
like
familiar
to
existing
folks
and
still
try
to
support
all
the
semantic
we
want.
Okay,.
D
We
can
do
that,
but
that's
that's
where
that's
where
we
start
adding
new
concepts
or
changing
change,
no,
not
necessarily
adding
new
concepts
for
users,
adding
new
concepts
compared
with
the
previous
doc,
let's
clarify
or
or
changing
radically
the
the
previous
talk.
So
so
what
I
would
do,
if
I
were
you
I
would.
D
I
would
retain
myself
from
doing
that.
In
the
same
time
when,
while
you
are
cleaning
up
other
things,
so
so
it's
a
mix
of
cleanups,
I
see
adding
new
concepts
and
is
very
hard
for
me
to
identify
when
things
are
changing
versus
when
things
are
just
improving
for
consistency
with
tracing.
So
so,
if
I
were
you,
I
would
split
this
into
two
parts
like
one
that
just
makes
the
document
or
makes
the
new
thing
look
more
or
less
like
the
tracing
side
and
then
start
to
to
say.
D
A
I
see
your
point
so
the
pr
like
every
pr
server,
very
single
purpose
and
make
that
like
granular,
okay,.
A
D
E
Sorry
would
it
make
sense
to
do
this
split
like
for
one
part
of
it
is
how
you
can
get
a
instrument,
and
the
other
part
is
what
are
those
instruments.
A
Yeah,
okay,
yeah,
so
so
my
my
thinking,
I'll
I'll,
follow
up
and
split
this
pr.
So
the
first
pr
will
just
be
introducing
a
side-by-side
document,
a
new
api
document
which
gives
the
outline
hey.
We
have
meter
provider,
we
have
meter,
we
have
instrument
and
then
the
second
pr
will
be
just
taking
the
existing
wording
from
the
trace
tracing
dock,
make
the
meter
provider
and
meter
clear.
Because
currently,
if
you
look
at
the
the
meter
provider
interface
in
the
in
the
current
matrix
api,
it
talks
about
global
meter.
A
These
are
not
existing
in
the
tracing
part.
I
believe
we
just
take
the
tracing
part.
We
should
be
okay
and
that
meter
provider
meter
should
be
done
yeah
and
then
the
instrument
will
be
a
section.
We
can
debate
whether
we
want
to
keep
the
six
names
or
want
to
have
yet
another
like
seven
names
or
five
or
three.
That
should
be
a
separate
pr,
yeah
and
so.
D
A
Yeah,
I
understand
okay
cool,
so
I
have
some
some
questions
like
I,
I
think
once
we
have
the
skeleton,
the
actual
content
we
can
divide
and
conquer.
Once
we
have
the
skeleton
we
can
probably
like
split
the
work.
So,
for
example,
if
jonathan
have
idea
about
the
instrument,
probably
he
could
help
on
something
and
meanwhile
I
can
focus
on
getting
the
meter
part
cleaned
out
and
move
some
concepts
to
the
top
level.
So
question
about
the
top
level
concepts.
A
If
you
look
at
the
matrix
api
spec
today,
let's
just
go
to
the
master
branch.
It
is.
It
is
not
a
matrix
api
spec.
It
has
a
lot
of
concepts
like
labels.
Labels
should
apply
to
the
api,
the
isdk
and
the
data
model.
So
my
thinking
is
for
things
that
are
generic
enough.
I
want
to
move
them
to
the
top
level.
Readme
document
I'll
switch
to
my
branch
so
create
readme
document.
It
has
the
high
level
concepts
and
I
my
hope,
is
remove
anything
that
is
not
specific
to
the
api
here.
D
A
Yes,
that
that
I
already
agreed
so
so
totally
so.
My
question
about
this
is
for
these
concepts.
I'll
need
some
help,
because
some
concepts
they're
not
related
to
the
api.
For
example,
we
talk
about
aggregator
aggregator
is
a
concept,
that's
only
valuable
for
the
isdk.
So
my
question
is:
what
what
do
you
think
we
should
do
here?
Should
we
just
remove
the
aggregator
entirely
from
the
api
spike,
or
we
should
spend
time
to
migrate
those
things
to
the
data
model?
D
One
option
is,
to
put
there
replace
all
the
processor
exporter
in
the
high
level
thing,
with
just
one
box
called
sdk
and
that
and
unbox
that
sdk,
while
you
define
the
sdk
and
define
what
that
black
box
for
for
for
the
the
thing
means.
So
what
I'm
trying
to
say
is
if
you
look
at
the
schema
there
that
you
have
at
the
bottom,
there
was
a
schema
from
instrument
going
to
the
diagram
down
the
bottom.
D
E
Also,
just
to
just
to
double
check
those
parts
like
the
the
processor
aggregator
exporter.
Those
are
those
will
never
be
part
of
the
api
right,
because.
E
A
D
So,
for
from
from
the
aggregation
perspective,
you
need
to
tell
users
that
there
is
gonna,
be
an
aggregation
that
is
defined
by
the
sdk
and
so
on.
Just
let
them
know
that
something
will
happen,
but
not
necessarily
get
into
details,
but
explain
that
hey
once
you
record,
this
measurement
doesn't
mean
that
it
goes
out
of
the
process
as
a
unique
measurement.
It
may
be
an
aggregation
step
during
this.
A
And
I
guess
that
should
be
moved
to
the
top
level
readme
instead
of
the
api
spec,
okay
cool.
Well,
I
I
I
think
I
understand
how
we
can
move
forward.
Okay,
the
next
topic.
This
is
where
I
haven't
touched,
the
the
actual
instrument,
so
just
try
to
get
some
idea
about
the
synchronous
and
asynchronous
api.
I
have
a
offline
discussion
with
jonathan
and
he
showed
me
some
the
java
code.
I
also
look
at
the
like
the
problem,
client.
A
So
one
thinking
is,
if
we
have
the
gauge
api,
like
it's
just
called
gauge,
but
that
gauge
can
either
be
a
synchronous
and
asynchronous
one.
I
have
some
example
here
from
the
micrometer
one
and
it
looks
reasonable
to
me.
I
just
want
to
understand
from
people
who
are
more
experienced.
A
D
E
Yeah,
isn't
isn't
the
d-value
observer
the
pair
of
the
value
recorder,
so
it
is
a
distribution
right,
no,
not
well.
D
So
yes,
indeed,
maybe
maybe
if
we
rename
the
value
observer
with
gauge,
do
we
still
need
to
rename
the
other
one
still
be
named
gauge,
because
I
think
will
confuse
people
the
fact
that
you
have
two
types
of
gauges.
So
so
one
of
the
things
that
we
consider
initially
was
like
more
or
less
gauge
by
the
english
definition
means
something
that
you
read
at
one
moment,
like
kind
of
a
snapshot,
thingy
yeah.
C
C
Reading
speed
or
a
gauge
for
reading
air
pressure,
but
you
also
have
a
gauge
block
which
is
for
measuring
a
distance,
and
you
have
you
know
a
feeler
gauge
for
measuring
a
spark
plug
gap
or
something
like
that.
It's
just
like
a
really
ambiguous
overloaded
word
in
english
and
in
some
sense
it's
a
perfect
fallback.
It's
a
catch-all
word
in
english
too,
so
maybe
it's
why
it's
the
right
word.
D
By
the
way,
by
the
way,
their
their
use
of
of
synchronous
gauge
is
the
the
up
down
counter.
I
think,
if
I'm
not
mistaken,
so
it's.
E
D
No
so
yes,
josh
forget
about
the
name.
D
Let's
talk
about
semantics,
I
think
one
thing
jonathan
and
riley
that
we
try
to
avoid
is
having
the
same
instrument,
accepting
add
and
sub
or
add
and
re
yeah,
add
sub
stinky
and
a
set
in
the
same
time,
because
because
it
was
very
unclear
for
us,
if
you
need
to
ever
combine
them,
so
you
either
use
the
add
sub
combination
of
them,
which
is
a
sum
like
an
up
down
sum
that
can
go
up
and
down
or
you
use
the
set
part
of
it,
which
is
more
or
less
like
a
different
type
of
instrument.
A
That
was
our
understanding
yeah,
I
I
I
understand
so
so
what
my
understanding
is
we
have
a
like.
We
have
a
strict
starting
point.
We
want
the
api
to
give
more
clear
semantic
when
people
describe
that
and
on
the
other
side
we
have
the
challenge
where
the
usability
of
the
api,
and
especially
for
people
who
come
from
existing
world,
they
might
have
a
hard
time
trying
to
map
that.
So
I'm
trying
to
figure
out
if
you
can
solve
this
by
finding
a
right
balance
or
we're
saying.
A
A
A
We
probably
can
help
have
this
like
a
new
guy
without
a
lot
of
understanding
about
metrics,
just
try
it
and
see
if
they
can
use
this,
and
if
the
people
coming
from
existing
background
use,
prom
client,
we
give
them
the
basic
document,
they
will
be
able
to
understand
if,
if
that
should
work,
I'm
happy
to
do
that.
Just
just
feel
like
we're
a
little
bit
stuck
here.
Meanwhile,
we
have
six
names.
A
lot
of
people
give
me
feedback,
they
don't
understand
or
is
hard
to
understand.
A
C
I
think
I
like
what
you
proposed
at
this
point
riley
I
just
want
to
reiterate
it
so
counter
was
unambiguous.
It
never
had
any
difference
of
meaning
between
all
the
systems
that
we
looked
at
gauge,
I
think,
is
also
fairly
unambiguous
as
the
in
the
synchronous
form.
As
for
how
you
use
it
and
what
it
means.
C
The
word
histogram
is
unambiguous
in
the
synchron,
but
in
synchronous
form,
but
is
not
traditionally
the
name
of
an
instrument
in
the
in,
at
least
in
the
english
language,
it's
sort
of
a
math
concept
and
we're
sort
of
making
a
new
instrument
name
out
of
it,
and
I
think
at
this
point
I
want
to
go
with
the
community
and
I
absolutely
think
we
should
go
with
the
word
histogram.
So
that
gives
us
three
conventional
names.
C
There's
one
more
single
instrument.
We
talked
about
that
we
may
want
to
talk
about
adding
that's
the
up
down
counter,
which
is
the
and
deck
version
of
gage
from
prometheus.
Essentially
so
we
split
that
out,
and
we
could
add
that
and
then
there's
this
asynchronous
question
and
I
think
the
question
is
whether
we
want
to
choose
different
instrument
names,
which
is,
I
think,
what
bogdan
just
suggested
or
whether
we
want
to
just
kind
of
like
for
familia
for
the
sake
of
familiarity.
C
Have
these
and
there
be
an
asynchronous
form,
but
I
just
mentioned
so.
The
asynchronous
form
of
counter
might
be
some
observer
or
it
might
be
counter
callback
or
counter
custom
collector
or
count
em
async
the
same
for
gauge,
but
then
in
histogram.
You
end
up
with
this
like
it
creates
trouble,
because
you
now
have
to
support
a
data
type
that
is
a
histogram
crossing
the
api
boundary,
which
means
you
need
a
data
type
to
represent
a
histogram
which
means
you're
not
entering
a
raw
number
anymore.
C
So
there's
not
really
an
asynchronous
form
of
histogram
in
our
model
data
model
in
the
api
model
of
of
before.
So,
if
you
just
like
blindly
state
that
there's
going
to
be
an
asynchronous
form
of
every
instrument,
you
end
up
needing
to
create
a
bunch
of
stuff
that
we
don't
really
want.
For
instagram.
A
A
C
I
think
of
those
as
the
output
is
a
type
of
data
which
might
be
called
distribution
or
a
histogram,
but
what's
the
instrument
that
we
use
and
that's
why
we
created
value
recorder
because
there's
what's
different
between
a
histogram
instrument
and
a
gauge
instrument
is
like
the
number
of
times
you
call
it
matters
like
that's,
there's
something
different
and
we
don't
have.
I
don't
know
it's
like
a
gauge
counter,
almost,
which
is
just.
F
F
C
Actually,
I've
tried
to
create
that
concept
of
adding
versus
grouping
in
the
past
and
I
don't
want
to
go
there,
but
you
certainly
can
change
that.
Could
change
the
aggregation
applied
to
a
counter
instrument
or
a
gauge
instrument
to
get
those
results,
but
we've
traditionally
been
debating
in
this
group
what
the
default
behavior
should
be
so
there's
an
instrument
that
has
default
behavior
of
produce
a
histogram,
and
I
don't
know
that
we
have
to
name
it.
E
And
I
I
believe
it
is
like
they
they
should.
They
should
be
like
different
concepts
because,
like
they
do
different
things,
you
can
get
like
different
value
out
of
them
or
they
represent
a
different
thing.
For
example,
you
should
never
really
gauge
something
what
you
can
count,
and
you
should
never,
for
example,
count
something
that
you
can,
for
example
like
count
or
like
represent
as
a
histogram.
C
D
So
there
is
another
thing:
there
is
another
thing
as
a
good
example:
jonathan
bites
by
sand,
for
example
like
in
a
in
an
http
or
rpc
called
you
want
to
record
the
number
of
bytes
and
most
likely
you
can
say
it's
a
counter,
because
you
want
to
know
how
many
bytes
you
send
on
the
wire.
But
people
may
want
to
see
that
as
a
histogram.
D
Hence
what
would
you
use?
Because
it's
it's
a
personal
taste
I
would
say,
and
whatever
we
can
make,
we
can
make
recommendation,
but
there
will
be
people
that
they
are
interested
only
in
the
rate
of
bytes
that
they
send
per
second
and
people
that
may
be
interested
in
the
distribution
of
the
the
every
request.
So
that
being
said,
I
think
it's
still
one
instrument
that,
based
on
whatever
configuration
user,
may
want
to
see
that
as
a
as
a
histogram
or
as
just
a
simple
counter.
D
E
And
also
a
set
like
the
yeah.
D
D
C
Had
this,
I've
had
this
debate
with
some
of
the
x
monarch
people
and
we
ended
up
using
the
word
up
down
gauge
a
lot
because
there's
sort
of
a
like
semantically.
What
you're
saying
when
you
enter
the
api
event
is
like
I'm,
adding
or
deleting
from
this
quantity
but
like
for
most
purposes.
We
expect
systems
to
pro
to
in
memory,
add
up
that
quantity
and
export
it
as
a
cumulative
value.
So
it's
it's
a
gauge
in
a
sense,
and
we
have
we've
called
this
up
down
counter
and
that's
prevents
the
new
name
there.
E
D
E
That
that
would
be,
I
believe,
maybe
I
can.
I
can
imagine
like
a
like
subtypes
of
pages,
but
I
I
find
it
very
like
useful
that
you
can.
You
can
just
like
set
something
on
a
gauge,
and
you
can
also
like
do
like
up
down
as
well,
but.
E
I
believe,
if
you
are,
I
believe,
not,
I
believe
you
are
using
set
exclusively
or
you
just
do
up
and
down,
but
it
is
still
the
same
gauge.
C
C
And
then,
when
you
export
into
a
prometheus
or
whatever
system
that
doesn't
know
about
nmcs
those
become
gauge
as
well.
So
you'd
end
up
getting
the
gauges
out,
but
we
wouldn't
allow
the
api
to
mix
set
with
add,
add
and
delete
or
document.
G
Hey
can
I
can
I
say
something
so
so
today
I
see
that
the
the,
for
example,
the
prometheus
receiver.
It
basically
does
cache
the
first
sample
and
then
does
the
delta.
You
know
from
that
first
sample
to
such
with
every
other,
subsequent
samples
and
and
say
that,
as
a
as
a
monotonic,
you
know
counter,
so
is
that
the
definition
in
open
telemetry
that
from
the
first
sample
so
like
I
I
feel
like
we
are
losing
the
the
magnitude
of
the
the
the
number.
G
For
example.
Let's
say
I
have
a
you
know
a
counter
that
counts.
The
number
of
hits
for
a
website
right
and
I
want
to
alert
when
the
weapon
when,
when
there
are
you
know
million,
hits
so.
G
So
why
do
we?
Why
do
we
actually
not
let
the
actual
counter
flow
as
as
a
counter,
rather
than
doing
a
cumulative
delta,
actually
from
the
very
first
sample
that
we
know
about?
Is
this
the
definition
of
counter
in
in
in
in
hotel.
D
No
in
otlp
in
otlp,
we
have
two
types
we
have
cumulative
or
deltas
depends
on
whatever
you
prefer.
I
think
you
looked
at
the
our
sdk
implementation,
which
our
sdk
implementation
for
good
or
for
bad.
We
produce
small
deltas
every
second
or
something
like
that,
and
we
send
that
to
the
next
stage
and
based
on
whatever
they
want,
they
can
produce
cumulative
or
they
can
send
us
deltas.
We
don't
care,
I'm
not
sure.
I
understand
this
is
a
very,
very
deep
implementation
detail
that
we
choose
to
to
produce
initially
deltas
and
then.
C
A
A
So
so,
coming
back
to
the
instrument
names,
I
I
think
this
is
very
subjective
thing
and
we
just
talk
about
this.
It
could
take
forever.
So
just
make
sure
we
make
progress.
How
about
this?
I
would
propose
like
we
have
the
existing
one
and
we
treat
this
as
a
starting
point
and
jonathan
has
some
experience
on
micrometer.
I
I'm
a
fresh
guy
here,
so
I'm
I'm,
I'm
working
with
jonathan
try
to
learn
the
micrometer,
like
I'm,
not
a
java
guy,
so
I'm
trying
to
learn
how
to
use
that.
A
So
probably
I
can
work
with
jonathan
to
give
a
proposal
on
what
we
think
from
micro
meter
perspective
that
should
look
like
and
if
other
folks,
this
the
different
thing
we
they
can
also
make
proportio,
and
we
can
talk
about.
What's
the
pros
and
cons
and
once
we
have
a
clear
understanding,
we
might
decide
okay,
we'll
find
something
in
the
middle
or
we'll
just
take
one.
A
I
I
currently
it's
not
clear
to
me,
but
I
won't
want
to
be
able
to
come
up
with
some
like
one
option
or
two
option
or
three
and
try
to
give
some
folks
outside
this
group.
Let
them
give
us
feedback,
because
my
worries
we
come
up
with
something
that
we're
familiar
with,
and
that's
just
from
us
we're
too
used
to
this
matrix
concept
and
when
we
give
to
the
user,
because,
ultimately,
the
library
owners
are
the
ones
who
are
going
to
consume
this
api.
A
D
That
is
very
good,
but
keep
in
mind
that
if
you,
if
you
just
stick
with
whatever
there
is
already
there,
you
you
force
to
not
have
any
innovation
or
anything
anything
or
any
any
fixing
of
things
that
may
not
be
the
best.
So
it
has
to
be
a
balance
between
between
what
is
commonly
known
and
what,
where
we
try
to
innovate
or
do
different
things.
D
A
F
C
That's
one
way:
to
put
it,
I
mean
like
these
days:
I've
been
focusing
so
much
on
the
data
model
that,
like
we
forget,
one
of
the
things
that
we
set
out
to
do
was
to
support
this
idea
of
a
census
view,
and
the
problem
that
we
were
up
against
is
that
many
systems
particularly
prometheus,
but
also
some
of
the
backends
that
we
know
and
love
sort
of
require
you
to
fix
the
dimensions
of
your
instrument.
So
you
declare
an
instrument,
you
you
give
it
three
dimensions
and
that's
it
for
the
rest
of
time.
C
It's
you
you're
stuck
with
three
dimensions.
You
got
to
change
the
number
of
dimensions,
you
gotta
use
a
new
instrument
or
choose
a
new
name
or
or
deal
with
complications,
and
that's
not
not
what
we
were
after
this
idea
that
you
should
be
able
to
add
and
remove.
Labels
has
always
worked
in
delta
based
systems
and
we
kind
of
now
we
understand
why
and
the
question
is
for
gauges,
how
do
they
work
and
for
our
cumulative
counters?
C
How
do
they
work
and
and
the
assertion
is
that
they
should
work
the
same
for
cumulative
counters
as
they
do
for
delta
counters
and
from
there
you
end
up
with
more
data
types,
and
so
the
question
is:
is
the
reason
why
there's
a
difference
between
a
sum
observer,
which
is
a
cumulative
count
and,
oh
sorry,
the
non
the
non-monotonic
cumulative
sum.
C
A
Statement
or
an
alternative
approach,
I
I
think
how
we
can
break
through
this,
and
we
start
with
just
one
instrument
counter
and,
and
once
we're
done
with
that,
we
try
to
say
hey:
we
need
something
like
up
down
either
we
add
a
gauge
or
we
either
counter
or
we
call
it
something
else
and
step
by
step.
So
we
can.
We
can.
We
can
start
from
something
that
is
very
obvious.
Everyone
would
agree
with.
A
Then
we
start
with
something
that
is
not
very
obvious
but
still
work
out,
and
then
we
work
on
something
that
is
very,
very
crazy,
like
the
histogram,
whether
it's
distribution
and
do
we
have
anything
at
all
or
not.
So
this
way
we
can,
we
can
see
what's
the
right
thing,
maybe
if
you
start
something
too
hard
normally
decide.
Okay,
maybe
we
can
just
use
gauge
and
try
to
have
a
like
async
gauge
or
no.
We
need
to
have
to
introduce
a
totally
different
thing
that
might
help
us
to
make
progress.
E
Then,
when
you
write
when
you
said
that
you
want
to
just
look
like
one
instrument
like
a
counter,
do
you
also
want
to
like
view
the
two
time
or
or
the
or
this
thing
casing
dimension
of
the
counter
like
to
talk
about
like
we
have
a
counter
that
you
can
use
in
a
synchronous
scenario,
but
vios
might
also
need
an
asynchronous
counter.
Okay,.
A
So
so
I
I
will
start
with
number
one
have
a
very
simple
pr,
just
the
synchronous
counter
and
just
call
it
and
that
that
one,
I
think
everyone
would
agree,
we
don't
agree,
then
I
don't
see
how
he
can
also
die
and
once
I
think
that's
clear.
D
A
You
call
it
so
yeah,
don't
don't
if
it's
going
up
and
down,
then
it
should
be
a
different
thing,
so
you
can
see
like
in
this
way.
We
have.
We
have
one
very
specific
topic
that
we
can
say.
Okay
on
this
one,
we
have
two
different
opinions
and,
let's
figure
out,
how
do
we
solve
that
and
before
we
can
solve
that
problem,
I
don't
think
we're
ready
to
touch
the
the
most
difficult
one
like
for
my
histogram.
A
I
I
can
probably
leave
that
in
this
way
you
can
progress
and-
and
by
doing
this
I
I
I
think
once
we
have
something
we
got
to
do
the
prototype
and
also
I
I'll
all
seek
some
feedback
outside
this
matrix
group
just
to
make
sure
whatever
we
put.
There
is
something
that
people
can
use
and
they
will
be
able
to
use
that
to
instrument
their
library,
but
by
the
way.
D
A
But
maybe,
but
perhaps
just
rename
that
and
we're
done
because
you
remember
in
the
in
the
metrics
breakout
session,
like
the
number
one
feedback.
Is
people
don't
understand
the
six
instruments
yeah?
But
but
we
keep
getting
the
feedback,
and
this
is
something
we
should.
We
should
be
able
to
solve
right.
Yeah.
D
Let's,
let's
start
with
counter,
as
you
said,
and
have
an
async
version
or
a
callback
version
of
that
you
can
either
call
it
some
as
we
call
it
or
you
call
it
a
scene
counter
whatever.
But
let's
start
with
these
two,
so
we
fix
two
of
the
main,
the
main
use
cases.
So
we
identify
six,
but
we
already
know
that
two
of
them
we
already
have
a
solution.
Let's
yeah
yeah,
with
this
initial.
C
E
Oh,
why
I
can
give
you
an
example,
for
example:
if
if
you
want
to
measure
like
or
if
you
want
to
gauge
the
size
of
the
collection,
then
you
you
can
basically
like
set
a
the
size
or
the
length
function
or
method
of
the
collection
to
a
gauge,
and
it
will
just
work
it
out
of
the
box.
You
don't
need
to
instrument.
D
C
Oh
so
I
I'm
getting
these
validation
errors
back
that
they're
just
from
my
back
end,
so
it's
like
this
metric
name
was
supposed
to
be
an
integer,
but
we
got
a
double
or
whatever,
like
you
know,
exactly
the
stuff
we're
talking
about,
and
I
so
I
get
back
some
examples
of
metrics
that
have
current
validation
errors
and
I,
but
but
it's
in
a
synchronous
context.
I'm
receiving
this
reply
from
my
backend,
who
said
here
are
several
examples
of
a
metric
name.
C
That
was
bad
so
over
a
30-second
period,
I'm
going
to
get
many
responses
from
my
back-end,
with
perhaps
many
different
examples
of
metric
names
that
are
bad
and
every
time
I
just
want
to
set
up
like
a
like
a
boolean
or
a
single
integer
like
one
I
am
present
and
here's
my
bad
metric
name.
So
I'm
really
counting
I'm
gauging
a
one
with
a
label
to
say
present
invalid
stuff,
but
I
don't
want
to
have
to
maintain
that
set
over
the
30
seconds,
because
that's
just
a
completely
new
data
structure.
For
me,
okay,.
D
C
D
The
set
the
set
one
is
for
me
is
still
okay.
We
can
have
these
edge
cases
and
we
may
we
may
offer
to
the
users
these
in
the
end,
but
I
I
still
I
I
want
to
make
sure
that
gauge
the
most
use
cases,
as
jonathan
pointed
is
the
callback
case
like
I'm
pointing
you
a
function.
This
is
how
you
read
it.
Is
that
what
we
called
before
a
sink
case
so
is
more
or
less
the
assing
part
that
is
very
and
super
useful
for
a
gauge.
D
D
E
But
but
so
good
book,
then
what
what
you
are
saying
is
basically
like.
We
need
a
synchronous,
asynchronous
counter
synchronous,
asynchronous
histogram,
but
maybe
we
only
need
a
asynchronous
gauge
and
we
can
drop
this
synchronous.
One.
C
E
E
D
Know
but,
but
immediately,
I
I
like
this
immediately
after
that
people
would
like
to
count
things
that
go
up
and
down,
which
I
think
is
very
important.
Not
the
gay,
not
the
set
part
of
the
the
synchronous
that
you
have
in
micrometer,
but
the
up
down
part
because
they
will
like
to
do
what
you
said.
They
would
not
like
to
provide
a
callback
for
the
queue
size.
D
They
would
like
to
do
a
plus
one
minus
one
to
track
active
requests,
for
example,
so
they
will
do
a
plus
one
when
the
http
starts
and
the
minus
on
the.
How
do
you
name?
That?
Is
that
a
gauge-
and
this
is
this-
is
where
things
will
get
funny.
But
let's
stick
with
the
first
four
and
the
fifth
one
will
debate
on
the
name.
E
And
just
to
quickly
answer
your
question
to
me
personally,
that
is
still
a
gauge
without
the
set
method.
C
It
is
I
I
got
it
yeah,
but
how
about
the
the
asynchronous
form
of
it?
That's
sort
of
the
question:
we've
called
it
up
down
some
observer
and
it's
this
nmcs
point
and
data
model
non-monotonic
cumulative
sub,
which
is
representative
just
like
a
gauge.
It's
a
number.
But
but
we
are
saying
it
has
different
aggregation
properties,
and
so
it's
like
how
do
you
represent
current
heap
size?
C
How
do
you
represent
current
queue,
size
and,
and
then
beaujon's
example
of
like
I,
I
have
a
htv
request
arriving
so
plus
one
and
I
finished
it
so
minus
one,
that's
those
are
deltas
and
most
forms.
Usually
we
export
cumulatives
in
that
case,
so
you
you,
you
may
get
inc
increments
and
decrements
in
the
api,
but
you're
still
going
to
output
gauges,
which
are
summed
across
all
the
dimensions
that
are
present,
and
this
distinction
between
nmcs
and
true
gauge
is
whether
you
know
when
you're
erasing
a
dimension.
C
Do
you
want
to
add
them
up,
or
do
you
want
to
average
them
out
is
what
we're
getting
at,
but
that's,
okay,
so
so
so
what
instrument
do
you
use
for
your
system
heap
size.
D
No,
no,
the
example
was
to
read
the
q
land
via
the
size
api.
So
you
have
a
list,
and
you
read:
you
set
a
callback
to
read
the
list
size
even
for
that
or
heap
size,
which
is
the
same
thing
yeah
like
that,
like
so
so.
For
that
jonathan
one
difference
that
we
want
to
do
and
call
it
innovation
or
whatever
is
to
ensure
that
for
up-down
sums
or
for
for
non-monotonic
sounds
we.
We
have
a
signal
that
we
separate
that
from
the
gauge.
D
D
That's
the
beauty
that
we
try
to
get
from
here
that
you
tell
us
not
only
that
this
is
a
gauge,
because
a
gauge
we
don't
know-
maybe
you
use
percentage
there
or
average
already
as
a
function
to
produce
that
so
summing
them
will
not
make
any
sense
so
so
by
by
knowing
that
that
actually
is
a
sum
that
indeed
it
goes
up
and
down
it's.
It
is
different
than
the
normal
counter,
but
it's
still
a
sum.
D
We
know
how
to
do
this
merging
of
time
series
if,
if
we
have
to
do
it,
so
this
is
one
of
the
goal
for
us
that
that,
as
long
as
we
can
preserve
some
more
informations
about
the
aggregation
will
be
better
for
for
later
to
to
do
it.
That
may
complicate
the
user
api
indeed,
and
that's
why
we
got
to
the
six
things,
and
so
I
would
like.
E
To
explain
what
is
what
is
the
use
case
of
like
dynamically,
so
what
what
you're
saying
is
that
this
is?
We
have
the
advantage
of
this
when
we
want
to
dynamically,
add
or
remove
labels
right?
D
The
remove
label
is
there
is
somebody
like.
Let's
assume
cassandra
comes
with
open,
telemetry,
metrics,
okay
and
they
export
for
one
of
the
the
metric
they
export
five
labels
because
they
said
you
know
what
better
is
more
is
better
than
less
in
terms
of
labels.
D
For
because
we
don't
know,
we
don't
want
to
preclude
any
any
use
case
or
anything
we're
going
to
add
five
labels.
Okay,
because
it's
the
everything
that
we
can
think
of
now
as
you
as
monitoring
cassandra
and
you
paying
the
bill
to
a
metric
service
or
maintaining
a
metric
service
like
prometheus
and
stuff.
Would
not
you
don't
care
about
the
five
things
I
care
about?
Only
the
three
of
them.
D
D
Let's
assume
grpc
is
instrumented
with
micrometer,
or
something
like
that
and
grpc
fox
will
decide
to
add
seven
labels
because
again,
more
labels
better
for
for
our
users,
because
we
cover
more
use
cases,
but
some
of
them
don't
want
those
for
cost
reasons
for
for
performance
reasons
for
whatever
you
want
to
say,
so,
the
the
ability
to
know
this
and
to
correctly
remove
labels.
It's
it's
extremely
nice
and
we
want
to
use
that
yeah.
H
Yeah
I
mean
this
is
a
very
good
argument.
Bogdan
has
made
because
we're
seeing
several
use
cases
where
you
know
there
is
a
need
to
have
multiple
labels
and
you
know
be
able
to
customize
that,
as
as
you
work
through
different
types
of
workloads,.
A
So
yeah,
it
is
also
captured
by
this
old
tab.
Like
we
mentioned
here,
the
library
owner
would
want
to
give
a
lot
of
dimensions,
but
the
consumer
would
only
want
a
small
set
of
them.
So
my
suggestion,
like
some
sometimes
I
I
feel
like
what
josh
and
bob
bogdan
you
mentioned
like
some
scenario,
those
scenarios
you
mentioned
the
meeting
and
it
was
not
recorded
and
later
people
asked
the
same
similar
thing,
and
you
got
to
repeat
that
again.
A
So
may
I
ask
if
you
see
a
scenario
that
is
important
and-
and
we
should
capture
that
you
send
an
update
to
the
old
tab,
this
one.
We
try
to
use
a
scenario
to
tell
people.
So
if
later
people
ask
why
why
the
hell
do
we
need
this
feature,
then
you
can
simply
point
them.
Look
at
the
old
tab
and
scroll
down
like
you
see
the
example
that
that
helps
us
to
align
on
the
same
page,
because
I
I
expect
a
lot
of
folks
would
come
respect
and
they
need
to
understand.
C
H
D
Only
three
so
extend
your
example
with
the
library
author
to
a
binary,
something
that
is
shipped
as
a
binary,
not
only
as
a
library
like
grpc
or
http,
and
because
that's
where
we're
knowing
this
on
the
wire
is
also
important
not
only
inside
the
aggregation.
D
E
Can
I
have
a
quick
question
around
this
like
dynamically,
adding
and
removing
labor?
So
basically,
after
the
application
starts
up,
and
you
have
the
you:
have
the
media
provider
all
of
the
instruments?
That
is
the
point
where
you
need
to
define.
What
do
you
want
to
keep
and
what
do
you
want
to
drop
after
that,
like
runtime,
for
example,
if
the
service
is
running
like
a
week
after
a
week,
you
don't
want
to
modify
this
right,
mostly
okay,
mostly
yes,
mostly.
D
I
said
mostly,
yes,
I
heard
I
heard
people
that
they
want
to
do
this.
There
is
a
there
is
a
big
discussion
about
this,
especially
in
the
sre
world,
and
I
had
that
discussion
at
google
of
allowing
customizing
these
kind
of
things
at
runtime
and
people
were
not
very
comfortable
to
do
this,
especially
if
you
are
aiming
to
maintain
a
high
availability
for
your
service
and
so
on.
So
so
we
can
discuss
about
this,
but
initially
the
whenever
you
initialize
the
meter
provider
that
will
be
used
to
create
these
instruments.
D
E
Time,
okay,
so
if
you,
if
you
can
do
this
like
at
startup
when
you
create,
for
example,
the
meter
provider
or
the
instruments
at
that
point-
and
let's
say
you
can
inject
a
filter
where
you
can
filter
out
like
whole
metrics
or
just
text
by
let's
say
name
from
the
from
the
like
api
perspective.
E
Isn't
that
the
same
as
you
would
not
be
able
to
do
this
at
all,
because
on
the
sdk
side,
when
a
a
value
will
be
recorded
or
something
will
happen
like
on
the
api
side,
you
are
just
basically
dropping
the
those
labels
or
tags
as
it
would
never
be.
There.
D
Right,
yes,
and
no
so
to
answer
your
question
is
yes,
and
no
so
for
for
for
the
asking
things
is
not
true,
because
for
the
asking
drinks
people
will
give
me
for
the,
as
of
called
for
the
callback
people
will
give
me
for
every
time
series
for
every
labels
combination,
one
value
by
me,
injecting
this
remover
of
labels
there.
I
will
get
five
five
entries
for
the
same
combination
of
labels.
What
do
I
do
right
now
with
them.
D
Sure
I
get
okay,
so
I
get
I
get
an
array
of
values.
What
do
I
do
with
this.
E
So
to
me,
if,
if,
if
you
get
so,
for
example,
if
you
have
an
asynchronous
something,
let's
say
a
gauge
and
you
get
a
measurement,
it
does,
for
example,
a
number.
Let's
say
10.
It
will
have
a
bunch
of
labels
like
let's
say
10
labels
attached
to
it
and
based
on
the
filtering,
you
just
drop
one
or
two
or
whatever,
and
you
will
still
have
that
one
single
value,
but
with
a
different
set
of
labels
right.
D
No,
no
so
so
I
think
the
gauge
in
micrometer
is
a
what
we
call
the
time
series
so
so
anyway,
what
I'm
trying
to
say
is
for
us.
A
gauge
has
multiple
points
like
like
imagine.
For
example,
now
the
user
has
two
gauges
with
the
same
name:
same
label
set
but
have
different
values
for,
for
those
labels
correct
they
can
they
can
do.
That.
D
Is
that
right?
Is
that
correct,
like
so
so,
for
example,
as
a
gauge
I
have,
I
have,
let's
assume,
I'm
measuring
a
queue
that
has
topics
like
kafka,
but
I'm
measuring
with
the
as
engage
so
okay,
so
I'm
gonna
put
there
as
a
label
every
time
when,
when
you
call
me,
I'm
gonna,
give
you
one
of
the
things
he's
gonna
give
you
topic
for
one
and
the
other
one
is
gonna,
give
you
topic
equals
bar
with
value
two.
D
Now,
if
I
put
a
filter
that
removes
the
label
topic,
okay,
I
get
I
get
for
the
same
empty
labels,
no
more
labels.
I
have
right
now
I
get
two
values.
What
do
I
do
with
them?
That's
it
so
so
so
I
still
need
to
know
that
that
was
a
sum
for.
For
me,
it
would
be
nice
if
I
know
that
that
was
a
sum,
because
I
can
give
you
three
and
hence
that
will
be
the
correct
answer
for
you
make
sense.
Yes,.
E
A
Okay,
I
I
think
we're
on
time
so
just
quickly
summarize,
so
I
I
I
think,
for
the
meter
provider
and
meter
and
also
the
instrument
part,
were
able
to
make
progress,
I'll
split,
the
pr
into
smaller
ones,
and
that
means
I'll
send
several
prs.
So
please,
please
help
to
reveal
and
either
approve
or
reject.
So
I
know
like
we
can
make
progress.
A
The
actual
instrument
will
start
with
the
most
simple
one
like
the
the
counter
and
and
everyone
will
be
happy
and
then
like
jonathan.
I
I
expect
you
to
to
work
with
me
on
the
next
one,
a
little
bit
challenging
I.
I
can
definitely
help
yeah
and
yeah,
so
I'll
also
multiple
prs
in
the
next
couple
days.
So
please
help
thank
you.
Everyone,
so.
D
Jonathan
also,
if
you,
if
you
want
ping
me
on
slack
on
the
cnc
of
slack,
we
can
brainstorm.
We,
I
can
tell
you
more
examples
like
these
and
in
scenarios
that
I
have
and
and
help
the
community
by
documenting
everything
that
I
tell
you
for
others
to
also
to
also
know.
D
Appreciate
it,
I
mean
I'm
very
willing
to
share
all
these
crazy
ideas
and
things
that
I
know
from
things,
but
I'm
very
bad
at
documenting
them.
So
if
others
can
can
take
a
stab
and
and
document.
Some
of
these
examples
would
be
great
for
everyone
and
I'm
willing
to
spend
time
with
the
with
everyone
to
to
explain
things
that
I
know
and
probably
I'm
wrong
99
of
the
time,
but
at
least
I'm
good
at
telling
my
opinion.