►
From YouTube: 2021-04-08 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
Hello:
everyone
thanks
for
joining.
Let's
give
it
one
more
minute
for
folks
to
join.
A
A
Okay,
we
can
start
so.
I've
listed
some
of
the
topics
here
and
I'll
quickly
go
through
them.
If
you
have
any
other
topics,
please
append
them
in
agenda,
we'll
cover
them
one
by
one
and
I'll
quickly
go
through
these
topics
and
then
I'll
switch
back,
because
here
I
want
to
use
the
like
the
majority
of
the
time
in
this
meeting
to
discuss
the
the
other
instruments-
and
I
believe,
is
the
the
only
remaining
like
issue
for
the
api
spec.
A
So
the
first
item
here
the
asynchronous
contour
api.
So
this
api
has
like
the
pr
has
been
out
for
a
week
and
we
received
a
lot
of
very
valuable
feedback.
So
now
all
the
outstanding
issues
are
resolved
and
we
got
multiple
approvals.
There's
still
some
discussion
about
things
like
nice
to
have,
for
example,
if
we
could
change
the
wording
here,
it
might
give
people
a
clear
understanding
or
something
we
mentioned
in
the
spike.
But
we
we
don't
have
a
good
example.
It
would
be
great
if
we
can
clarify
the
scenario.
A
As
many
of
them
as
possible
today
and
after
that
I'll
I'll
ping
josh-
and
he
could
help
us
to
merge
this
pr
for
the
other
things
that
we
don't
have
energy
to
address,
for
example,
providing
more
examples
or
trying
to
give
a
top-level
description
like
monotonic
versus
non-monotonic.
These
are
very
good
nice
to
have
things.
I've
created,
separate
issues
to
track
them
and
assign
these
issues
to
me.
So
once
we
get
the
apis
back
out,
we
can
move
forward.
So
multiple
teams,
like
the
six,
can
work
in
parallel.
A
In
this
way,
I
can
probably
come
back
and
address
those
issues
you
know
in
an
asynchronous
way.
So
so
please
take
a
final
look
and
if
you
have
any
like
comment
there,
please
just
put
your
comments
and
I'll
I'll
try
to
address
as
many
as
possible.
But
the
key
message
here
is
we're
not
going
to
block
this
pr,
because
we
already
have
a
lot
of
approvals
and
anything
that
we
notice
that
we
cannot
solve,
will
I'll,
convert
them
into
issues
and
track
them
separately.
A
So
the
next
one,
which
is
a
big
topic
I'll,
come
back
later,
but
the
idea
is
now.
We
have
the
synchronous
and
asynchronous
counter
and
already
figured
some
name,
and
I
know
the
naming
thing
is
always
the
hardest
problem
for
for
us.
So
it's
a
good
progress.
At
least
we
find
something
that
makes
everyone.
Okay,
I'm
not
saying
everyone
is
happy,
but
since
nobody
is
very
unhappy
with
that,
it's
already
something
like
I
think
it's
a
small
achievement.
A
So
so
congratulations,
everyone,
so
next
step
is
take
a
look
at
this
link
where
josh
has
an
awesome
summary
of
the
the
instruments
that
we
have.
It's
mainly
around
whether
a
particular
instrument
is
focusing
on
the
monotonic
thing
versus
normal
tonic
and
also
like,
if
that's
synchronous,
all
asynchronous.
A
So
originally
we
have
six
instruments
and
the
general
feedback
is
for
people
who
are
not
expert
in
metrics.
They
find
it
very
hard
to
understand,
so
we
find
some
tricks.
For
example,
we
decided
to
call
the
asynchronous
version
of
the
the
counter
the
like
counter
func,
so
it
at
least
gives
people
the
hint.
Oh,
it's
related
to
the
counter,
instead
of
something
like
counter
corresponding
to
the
some
observer
or
people
have
to
do
some
like
internal
connection
in
their
brain.
So
so
that
part
is
good.
What
covers
the
down
counter?
A
So
currently,
what
we
have
is
the
monotonic
version,
what
about
non-monotonic
version
and
what
about
like?
If
we
want
to
take
histogram
or
here
we
also
have
something
called
the
value
recorder,
so
we
it's
mainly
like
we
find
some
name,
and
what
I
will
do
is
I'll
copy.
The
the
existing
spec
section
about
the
counter
and
the
counter
func
and
change
the
name
put
some
example.
Then
we're
done
so.
The
naming
thing
is
hard,
we'll
spend.
A
I
I
plan
to
spend
at
least
30
minutes
in
this
meeting.
Talk
about
that.
The
next
one
is
a
I
already
mentioned.
So
during
the
pr
review,
I've
received
a
lot
of
comments.
People
are
saying
hey,
it
would
be
great.
We
can
clarify
why
we
care
about
monotony,
and
can
you
give
some
example
and
also
their
questions
about
hey?
A
Can
you
give
example
when
people
should
use
asynchronous
api
and
normally
I'll
say
like
if
you
look
at
the
cpu
time,
you
ask
the
operating
system
to
give
you
that
statistics,
it's
already
given
to
you,
so
you
don't
want
to
call
that
periodically.
Unless
someone
is
asking
for
that,
then
the
question
is
hey:
if
we
have
a
pertinent
cpu,
it
might
be
a
good
fit
for
synchronous
api.
A
I
I
don't
think
this
is
a
blogger,
but
I
understand
the
value
here,
and
this
is
not
a
blogging
issue,
so
we
can
do
that
in
parallel,
and
another
message
I
want
to
deliver
is
after
we
finish
this
pr
like
today,
and
we
talk
about
the
names
I'm
trying
to
lock
down
the
names
by
end
of
next
thursday,
so
it
means
we
give
one
week
to
everyone
to
think
about
these
names
and
gather
feedback,
and
hopefully
we
can
close
this
by
next
week
meeting
and
that
that
should
give
us
six
weeks
to
work
on
the
ick
experimental
version
of
the
spec,
which
I
I
think
is
a
reasonable
time
and
which
means
we're
able
to
hit
the
current
schedule.
A
So
if
folks
are
new
here,
they
don't
know.
What's
the
current
schedule,
I
think
you
can
find
it
somewhere
or
I'll
I'll
put
put
the
link
here
on
open,
telemetry,
github
products.
There's
a
top
level
projects.
We
have
10
or
11,
and
each
of
them
has
a
timeline.
So
the
the
current
timeline
they
were
saying
we
want
to
get
the
experimental
version
of
the
matrix
api
and
isd
case
back
by
end
of
mates.
A
I'm
trying
to
push
hard
for
us
to
hit
the
date,
and
one
thing
we
decided
not
to
cover
today,
but
we
understand
this
is
part
of
the
api.
Spec
is
the
hint
api,
so
hint
api
is
basically
trying
to
tell
hey.
If
you
have
a
library,
the
library
is
trying
to
emit
10
dimensions
for
a
single
instrument,
and
you
know
that
from
your
expertise,
you
want
the
user
to
use
three
of
them
in
most
other
cases,
so
you
can
give
the
hint
telling
people
hey.
A
These
are
the
three
dimensions
I
think
you
should
use
and
also,
potentially
you
can
give
a
hint
saying:
hey
this
dimension
is
a
high
cardinality
once
you,
you
should
take
care
of
the
memory,
consumption
and
the
cost,
so
we
decided
to
come
come
back
after
the
sdk.
Spec
is
outside
estimate
that
we
can
do
this
in
late
may
time
frame
any
questions
about
the
execution
and
the
timeline
here.
B
A
Cool,
thank
you
you're,
doing
great,
thank
you,
yeah
and
then
the
high
top,
so
so.
Based
on
this,
I
I
think
once
we
discuss
the
the
instrument
like
later
in
this
meeting.
I'll
have
a
reasonable
idea
if
we
can
finish
the
experimental
version
of
the
api
spec
on
time,
and
that
means
next
tuesday.
I
want
to
take
this
feedback
and
and
report
back
to
the
op
sig
meeting,
so
we
can
ask
more
folks
to
come
and
and
take
a
look
and
help
us
to
improve
or
fix
any
any
issue.
A
We
have,
or
at
least
called
hey,
there's
something
obvious,
but
we
miss
that
and
then
I'll
make
the
ask
in
the
spec
meeting
that
we
want
the
following
language:
6
to
start
their
implementation
and
the
information
would
be
around
the
api.
Only
so
I
expect
them
to
build
the
api
based
on
the
spec
and
also
focusing
on
the
old
type
scenario
where
we
described
a
very
concrete
scenario.
So
they
can
use
that
to
implement
things
and,
and
that
doesn't
mean
they
have
to
have
the
entire
sdk
exporter
work.
A
But
if
they
want
to
build
some
very
like
down
version
of
that,
you
can
simply
drop
the
data
on
the
floor
or
dump
that
to
a
text
file.
It's
probably
fine.
That's
the
heads
up.
Another
thing
I
haven't
mentioned
here
just
quickly
quickly
bring
it
so
so
so
the
other
josh
from
google.
He.
He
asked
me
a
question
about
tendency
and
I
I
see
the
need.
I
just
want
to
ask
here.
A
If
any
of
you
like
believe
that
tendency
is
very
important
and
you
have
some
experience
or
you
want
to
work
on,
that,
you
can
ping
the
google
josh
and
me
offline,
and
if
you
don't
know
what
tenants
is
it's
fine?
That
means
you
don't
have
to
worry
about
it
at
this
moment.
C
C
A
Big
topic
and
then
screw
up
all
the
existing
work
stream,
because
they're
making
steady
progress.
We
believe
we
we
can
explore
that
and
see
if
it's
too
dangerous
to
bring
this
topic
at
this
moment
or
we'll
yeah.
C
Yeah
well
I'll
ping,
you
offline.
C
A
Okay,
thanks
okay,
cool
yeah
and
for
folks
who
don't
know
attendance.
That
means
you
don't
have
to
worry
about
right
now.
So
that's
good,
don't
don't
think
about
it!
It's
a
hard
topic.
Okay!
So,
coming
back
to
the
the
instrument
names,
you
already
got
the
link
in
the
in
the
agenda
dog.
So
this
is
the
summary
from
from
josh
and
the
names
are
based
on
the
the
the
previous
version
of
the
api
spec.
So
the
names
we
came
up
in
the
in
the
past
now
we're
changing
the
name.
A
So
this
one
is
still
counter,
but
this
sum
observer,
we
decided
to
call
that
counter.
Func
and
the
name
was
was
just
like.
We
steal
the
name
from
prometheus
for
the
other
things.
I
think
my
number
one
question
is:
do
we
need
them
all
like
all
of
them
or
we
can
reduce
the
number?
I
I
personally
believe
in
histogram
people
mentioned.
We
probably
don't
don't
need
to
distinguish
whether
it's
monotonic
or
not,
so
just
want
to
quickly
get
idea
here
when
you
think
about
the
number
of
instruments.
A
I
I
can
try
to
explain
that
in
a
different
way.
So
if
you
look
at
the
matrix
api
from
my
perspective,
it's
just
a
it's
just
one,
one
way
of
having
people
to
report
a
number
plus
a
bunch
of
key
value
pairs.
So
initially
I
was
asking
people
what
if
I
just
have
one
api.
Let's
say
like
a
report,
some
data
and
it
takes
the
value.
I
don't
care,
whether
it's
monotonic
or
not,
whether
it's
positive
number
negative
number
or
anything.
A
And
then
I
have
a
bunch
of
key
value
pairs
which
we
call
the
attributes
would
that
work.
Then
I
heard
a
lot
of
feedback
from
people
saying
no,
no,
it's
not
going
to
work
because
it
doesn't
give
you
enough
semantic
like.
If
you
have
a
counter,
you
might
have
something
called
increment
or
add,
but
if
you
have
something
like
reporting
a
value,
you
don't
want
to
use
ad.
You
might
want
to
use
like
report
or
like
record
so.
A
So
this
is
the
number
one
feedback
number
two
is
people
think
having
those
apis
will
help
people
to
think
about
their
scenario
and
based
on
this
scenario,
like
the
hint
we
got
from
the
separation
of
apis,
we
will
be
able
to
provide
better
default
experience
like
if
people
use
counter
we
might
figure
out.
Oh,
we
can.
We
can
like
actually
show
the
rate
like
how
many
like
additional
memory
allocations.
You
have
in
the
past
five
seconds
things
like
that.
A
That's
why
we
won't
have
that
separation,
and
then
you
see
the
problem
so
on
one
extreme
is
we
have
one
api
that
has
no
semantic
at
all?
We
just
allow
arbitrary
value
and
key
value
pairs
on
the
other
side.
Is
we
have
very
fine,
current,
larger,
like
six
or
seven
or
even
more
and
and
what
I've
seen
is
normally
in
the
well
established
api
like
micrometer
and
premises
they
have.
They
have
like
three
four
five,
for
example
like
this
one:
they
try
to
explain
the
four
types.
A
A
D
Yeah
hi
well
help
me
out
riley.
What?
Where
do
you
want
to
start
the
discussion?
Among
all
the
things
that
you
just
summarized.
A
Okay,
so
I
I
think
we
figured
out
very
clearly:
we
need
the
counter
and
the
asynchronous
counter.
So
for
the
other
stuff,
my
thinking
is,
we
need
the
synchronous
and
asynchronous
version
of
the
up
down
counter
and
we
can
call
whether
this
is
up
down
control
or
different
name
or
gauge,
or
something-
and
it's
just
a
naming
thing,
so
is
that.
D
D
Just
to
make
sure
that
we're
on
the
same
page,
though,
we've
agreed
about
the
asynchronous
form
of
gauge
and
we've
agreed
about
the
synchronous
form
of
histogram
independent
of
the
naming
discussion
yeah.
So
it's
a
question
about
essentially
two
more
that
would
bring
us
back
to
the
six
that
the
the
original
proposal
had,
and
so
one
of
the
most
frequent
questions
that
has
arised
risen
arisen
is
about
the.
D
If
you
have
a
gauge
an
asynchronous
form
of
gauge,
that's
almost
the
same
as
the
up
down
some
observer,
so
it's
always
been
hard
to
explain
why
we
think
there's
a
difference
and
at
some
level
this
this
exists.
This
difference
was
there
all
the
way
back
into
open
census
and
it's
in
the
data
model.
Still
you
know
we
have
we've.
We
try
to
defend
this
every
time,
but
it's
pretty
easy
to
just
fall
back
into
saying.
D
You
should
use
a
gauge
for
your
memory
size
and
your
cue
size,
and
yet
we've
we've
held
that
line
pretty
clearly
you
know
the
up
down.
Form
of
gauge
is
different
than
the
than
the
counter
and
prometheus,
and
it
produces
a
value
that
is
just
the
same
as
a
counter
except
it
goes
up
and
down
and
and
the
choice
of
calling
it
gauge
versus,
as
we
do
in
the
data
model
of
the
non-monotonic
cumulative
sum.
D
Instead
of
having
up
down
counter
and
up
down
some
observer-
and
I
think
probably
when
this
conversation
came
around
the
first
time.
I
didn't
truly
understand
all
the
nuance,
especially
about
this
point
about
non-monotonic
cumulative
sum
versus
gage,
because
I
do
remember
being
really
baffled
at
the
time
when
the
words
cumulative
gauge
kept
coming
up.
D
What's
like
cumulative
gauge
cumulative
gauge,
didn't
make
sense
to
me
at
the
time,
and
now
I
see
it
as
this
non-monotonic
cumulative
some
type
that
we've
identified
and
so
at
one
point
there's
a
proposal
to
have
just
a
flag
on
the
gauge
to
say:
are
you
cumulative
and
at
the
time
bogdan
was
asking
for
it,
and
I
didn't
understand
it,
and
now
I
get
it
so
you
could
do
a
flag
on
the
on
the
gauge
to
say
I'm
I'm
one
of
these
some
types
of
gauge,
rather
than
one
of
these
measurement
types
of
gauge
or
you
could
put
on
the
counter
and
say
I'm
one
of
these
non-monotonic
types
of
counter,
as
opposed
to
one
of
these
monotonic
types
of
counter.
D
I
I
don't
know
whether
it's
better
to
call
it
an
optional
gauge
or
an
optional
counter
or
to
call
it
a
new
instrument,
but
I
feel
like
it
actually
is
a
different
discussion
for
the
synchronous
case
this
up
down
counter
or
the
in
prometheus.
The
gauge
that
has
an
up
up
down
operation
suite
that
that
you
could
make
that
an
option
on
the
counter
or
you
could
make
a
separate
instrument.
I
think
that's
all
the
options.
I
don't
know
if
I,
if
I
should
say
anymore,.
A
Yeah
I
haven't
seen
jonathan
here,
but
what
one
thing
I
noticed
the
the
micrometer
api
that
it
seems
we
have
like
there's
a
counter
api,
which
is
almost
the
same
as
the
control
api.
Here
we
have
and
there's
a
function
counter
in
micrometer,
which
is
the
same
at
the
counter
func.
We
just
have
a
naming
difference,
but
in
micrometer
it's
interesting
to
see,
there's
a
gauge
api,
which
is
asynchronous
thing
that
can
go
either
up
and
down,
but
there's
no
synchronous,
equivalent.
D
Yes,
I
agree:
I've
had
this
discussion
with
a
few
other
teams,
people
who
are
involved
in
google's
metric
system-
and
I
know
that
there
comes
a
point
in
time
where
you
can
essentially
try
to
push
the
boundary
of
like
where
the
responsibility
for
counting
things
lies.
And
you
know
we
are
metrics
sdk.
D
You
just
you
know,
have
a
gauge
and
tell
the
user
count
your
own
stuff.
You
know
if
you
have
a
queue,
have
a
length
operation
or
a
size
operation
or
keep
an
atomic
counter.
That
tells
you
how
many
items
are
in
the
queue
and
then
just
gauge
that
thing
and
forget
about
this
up
down
operation
synchronously
and
I
feel
like
there's
just
enough
examples
out
there
and
in
my
own
work,
instrumenting
code.
D
That's
only
for
observability-
and
I
remember
like
one
of
the
sort
of
like
long-range
goals
that
I've
always
kept
in
mind.
Is
you
should
be
able
to
turn
everything
off
like
turn
off
all
your
instrumentation
see
what
happens
like
I
see:
what's
it
really
cost
and
if
you
force
the
user
to
like
maintain
their
own
counts
just
for
observability,
it's
hard
for
them
to
turn
it
off.
D
A
I
see
your
point
so
so
let
me
put
an
idea
here
and
see
if
people
support
that
or
the
thing
is
created.
So
what
if
we
have
something?
Let
me
just
put
gauge
here,
so
we
have
something
called
gauge
and
the
semantic
for
gauge
is.
It
is
something
that
can
go
either
up
and
down,
and
then
we
have
the
the
gauge
and
the
gauge
func
and
we're
telling
people.
Okay,
the
the
gauge
term
is
screwed
up,
so
the
micrometer
gauge
is
always
asynchronous,
but
in
open
telemetry.
A
D
A
A
D
D
You
can
keep
your
own
register
of
information
so
that
when
you
set
it
and
the
observer
comes
along
to
see
the
current
value
that
you
have
that
machinery,
like
that's,
not
truly
very
much
code
but
the
the
the
people
there's
hundreds
of
thousands
of
developers
out
there
who
know
how
to
synchronous,
they
call
gauge,
set
and
they're
familiar
with
it
and
to
tell
every
one
of
them.
Your
clever
programmer
go
write
some
callback
machinery
to
remember
the
last
value
and
observe
it.
That's
that's
where
we
get
into
trouble.
D
D
You
have
this
requirement
that
their
state
that
somebody
keeps
track
of,
and
you
know
what
you're
changing
and
and
you
might
periodically
refresh
the
current
value
with
set
so
that
everybody
knows
what's
happening,
but
otherwise
these
increments
and
decrements
they
either
require
you
to
maintain
state
very
carefully
or
you
have
to
go
back
to
the
beginning
of
time
and
apply
all
the
updates.
And
it's
not
clear
what
you
mean
at
that
point.
D
I
don't
know
what
to
write.
I
I
believe
the
right.
The
right
choice
is
to
have
two
instruments,
one
that
you
can
set
synchronously,
which
is
identical
automatically
to
the
gauge
func,
so
the
gauge
engagehug
are
for
measurements
and
there's
a
separate
type
of
instrument.
That's
like
the
up
down
counter
thing.
Basically,
I.
A
See
so
you're
saying
the
gauge
should
just
take
take
the
set
operation.
People
can
like
people
should
always
report
the
value.
Well,
we
might
need
some
helper
like
whether
it's
a
separate
instrument
or
it's
based
on
like
it's
derived
from
one
existing
stuff,
but
that
should
support
the
delta
value.
D
Right
and
it
could
be
an
optional
counter-
it
could
be
an
optional
counter
func
to
do
this
obscure
case,
but
with
that
essentially
the
up
down
some
observer
case,
which
was
distinct
in
our
model
from
the
value
observer
case.
So
the
gauge
func
equals
value
observer,
but
we
still
don't
have
an
equivalent
for
up
down
some
observer,
and
I
think
this
unfortunately,
is
one
where
we
really
did
want
the
data
model
to
be
held
too.
So
that
means
for
your,
your
cue
size
and
your
heap
size
and
all
those
things
that
go
up
and
down.
D
We
want
those
to
be
to
output
as
some
sums,
and
that
means
they're
they're
almost
the
same
as
gauge
funk,
but
we
want
the
option
of
calling
them
sums
not
gauges,
and
I
don't
want
the
optional
behavior,
which
I
think
is
most
common.
I
think
up
down
counter
sorry
up
down.
Some
observer
is
more
common
than
value
observer
in
the
original
model,
we're
more
more
often
observing
counters
than
we
are
observing
measurements.
A
So,
if
I
read
this
correctly,
it
seems
like
like
folks
like
the
the
name
and
idea
here
and,
and
they
want
to
keep
it
and
in
this
way,
probably
it
will
like.
Would
you
then
sanction
up
down
counter
funk?
E
So
a
question-
and
this
is
my
from
my
naive
tv
for
this
concept
here
so
without
knowing
all
the
specific
details
trying
to
follow,
because
it's
hard
to
follow
all
the
you
know
terminology
here
I
see
a
counter
as
generally
just
something
you
count
which
implies
there's
an
ad
and
then
there's
also
a
decrement.
If
it's
you
know
non-monotonic
right,
but
but
regardless
of
whether
it's
a
synchronous
or
asynchronous,
I
would
imagine
that
a
counter
just
highest
level
is
something
that
tracks
deltas.
E
E
I
guess
my
my
understanding
is
naive
in
that
sense,
then
right
so
so
I
would
have
imagined
that
the
the
way
that
we
have
a
counter
right
now
and
our
counter
funk
is
they.
The
two
operations
are
both
you
know
for
the
counter.
You
have
a
decrement
if
it's
non-monotonic
and
for
the
counter
func.
When
you
report
your
value,
you
don't
report
the
sum,
but
you
report
asynchronously
the
increment
and
decrement.
E
Then
the
gauge
would
be
then
you
know
equivalent
where
the
gauge
is
just
the
set
for
the
synchronous
gauge
will
be
the
set
and
the
asynchronous
gauge
would
be
what
we
you
know
kind
of
consider.
E
You
know
where
you
just
basically
report
a
value,
so
they
at
least
in
my
mind
they
map-
you
know
anyway,
so
I'll
shut
up.
Now
and
oh,
I
listen
to
be
corrected
so.
A
D
I
I
can
add
a
little
bit
of
perspective
on
where
it
comes
from,
although
I
I'm
sure
bogdan
would
explain
it
different
way.
The
one
of
the
things
that
otel
is
trying
to
do
is
to
create
this
statelessness
for
instrumentation,
so
that
we
don't
put
a
requirement
on
the
sdk
that
must
maintain
some
kind
of
state
or
on
the
application
that
muster
can
maintain
some
kind
of
state
in
order
to
do
instrumentation.
D
So
if
I
have
an
asynchronous
way
to
observe
deltas,
you
know
I
have
to
remember
the
last
time
the
sdk
called
me
and
now,
like
I'm
complicating
my
application
logic,
to
keep
track
of
something
that
was
fundamentally
part
of
the
observability
process
and
we're
really
trying
to
avoid
like
stateful
interactions
between
the
sdk
and
the
application.
D
That's
one
way
that
I
think
about
this.
There.
There
is
a
document
in
otep.
I
will
find
it
it's
number
88.
Actually
you
can
find
it.
D
It
was
one
of
the
ones
where
I
kind
of
explored
the
option
of
an
asynchronous
delta,
as
well
as
the
option
of
a
synchronous,
a
synchronous,
cumulative
instrument
which
has
not
been
discussed
either.
You
know
in
in
both
in
statsy
and
prometheus.
If
you
want
to
synchronously
report
a
cumulative
value
like
cpu
seconds,
you
call
it
a
gauge
and-
and
we
just
don't,
have
an
instrument
even
in
the
hotel
drafts
and
that's
because
of
otep
88,
where
I
ruled
those
out
anyway,
you
might
consider
looking
at
that.
D
D
Nobody
could
think
of
an
example
where
up
down
delta
observer
naturally
occurs,
in
other
words,
in
a
stateless
way
like
is
there
a
syscall
api
that
you
can
think
of
that
remembers
the
last
time
you
called
it,
and
then
you
asked
it
to
to
just
read
something
that
resets
as
you
read
it.
That
would
be
the
example
we're
looking
for
and-
and
I
couldn't
find
any
good
examples,
I'm
not
saying
there
aren't
examples,
it's
really
finding
it
it's
just
contrived
to
to
find
them.
I.
D
Call
that
you
call
and
then
what
was
it
sorry,
it
remembers
the
last
time
you
called
it.
It's
basically
a
stateful
interaction,
so
you
say
get
and
reset
the
count.
Since
the
last
time
I
observed
you
and-
and
if
it's
worth
thinking
about
how
prometheus
in
a
poll
based
system,
does
not
have
a
way
to
pull
a
delta
and
because,
when
you
have
two
observers,
they
would
interfere
with
each
other.
They
each
each
observe.
If
an
observation
causes
a
reset,
it
means
that
two
observers
can't
exist
simultaneously:
yeah,
no,
no
yeah
totally.
B
D
They're,
probably
bad
ideas,
though
yeah
and
I'll,
say
that
a
couple
of
oddballs
that
were
similar,
one
was
where
we
there.
If
you're
inside,
of
an
asynchronous
opera
observation
callback
for
like
garbage
collection
statistics,
you
may
have
just
performed
an
expensive
call
like
in
golang,
it's
read,
mems
stats,
and
during
that
read
mem
stats.
You
get
a
list
of
values,
it's
a
deferred.
It
is
one
of
these
cases.
D
It's
a
histogram,
though
you
get
several
observations
that
were
deferred
since
the
last
time
you
called
read,
read
mems
stats,
and
so
there
is
actually
a
stateful
interaction
built
in
there.
It
remembers
the
last
time
it
was
called
and
only
tells
you
what's
changed
and
for
that
reason
we
we
ended
up,
saying
it's:
okay
and
and
well-defined
for
you
to
call
a
synchronous
instrument
api
during
an
asynchronous
asynchronous
instrument
callback.
So
we
have
one
of
these
batch
instrument.
Callbacks
you'd
call
read
mems
stats
once
during
your
batch
instrument.
D
Callback,
you
make
observations
for
all
of
the
asynchronous
instruments
that
are
implied
by
one
read:
mems
stats
call
and
then
there's
this
oddball
case
in
the
go
language,
memstops
call
interface,
which
was
gc
pause,
nanos,
and
that
says,
every
time
a
garbage
collection
has
happened
since
the
last
time
you
called
reed
memstats.
How
many
nanoseconds
did
it
stop
and
so
they're
telling
you
there
were
three
garbage
collections
and
we
stopped
for
a
total
of
you
know
this
many
nails,
and
that
many
knows
and
that
many
knows
which
are
asynchronously
observable.
D
B
B
Then
you're
probably
safe,
there's
a
core.
There
would
be
you
know
in
order
for
that
to
be
useful,
you
would
have
to
be
able
to
call
into
something
who
that's
kind
of
keeping
state
on
your
on
you
and
then
it
just
gets
weird,
and
so
the
argument
would
be
look
if
you're
doing
something
that
weird
go
build
something
on
top,
but
don't
yeah,
plus
one.
E
B
G
So
I
don't
know
if
this
is
a
good
time
to
jump
in
and
and
add
to
our
question
on
instruments
with
the
you
know,
the
monotonic
versus
rate
conversation
that
we
were
having
on
the
pr
I
mean.
I
know
we
already
sort
of
have
multiple
different
but
somewhat
related
questions
in
flight.
So
I'm
not
sure
if
we're
trying
to
answer
these
one
by
one
or
just
sort
of
pile
them
all
in
because
they're
all
somewhat
related
to
the
final
set
of
instruments
that
we.
G
Okay,
I
mean
I'll
well
I'll,
just
repeat
for
folks
who
may
not
have
seen
on
the
pr.
You
know
I
was
just
sort
of
questioning
you
know.
Why
does?
G
So
if
they
don't
care
about
monotonic
versus
don
monotonic,
they
care
about.
Is
it
a
rate
or
is
it
an
absolute
value?
Then
it
feels
like
you
know.
We
shouldn't
have
counter
and
up
down
counter.
We
should
have
you
know
whatever
terms
we
want
to
use,
but,
like
you
know,
rate
counter
and
absolute
counter,
because
now
it's
framed
in
the
terminology
that
the
user
actually
cared
about,
and
this
other
thing
was
just
like
a
you
know,
an
intermediate
thing:
they
didn't
care
about
to
get
to
the
actual
behavior
that
they
did
care
about.
G
D
Me
offer
a
couple
ideas,
then
one
is
there:
sort
of
are
two
categories
of
user
and,
and
one
of
the
hotel
sort
of
library
goals
was
to
have
a
semantic
definition
so
that
the
at
the
instrumentation
api,
like
there's
a
separation
between
like
what
the
the
author
of
the
instrumentation
says
and
and
what
the
implementation
actually
does.
D
So,
from
the
perspective
of
the
author
of
the
instrumentation,
I'm
holding
an
instrument
in
my
hand
that
I
use
to
count
stuff
and
there's
that's
a
different
perspective
and
the
user
of
the
observability
system,
who
goes
to
a
dashboard
or
or
an
alerting
interface
and
says,
show
me
the
metric
produced
by
that
counter
instrument.
The
metric
produced
by
that
counter
instrument
may
be
monotonic
or
not,
and
therefore
have
a
good
rate
interpretation
or
a
good,
absolute
value
interpretation,
and
so
it's
like,
because
there
are
two
different
categories
of
user.
D
We
have
two
different
naming
problems
or
or
different
bike
sheds.
Okay,
I
appreciate
your
observations.
I'd
like
someone
else.
A
To
comment
yeah,
I
can't
explain
my
understanding,
so
I'm
I'm
pretty
new
to
the
matrix
space,
but
I
I'm
thinking
from
the
user
experience
perspective
and
also
the
history.
If
you
look
at
the
micrometer
and
also
premise
api,
they
all
have
the
counter
concept.
Although
mathematically
we
can
see
if
you
try
to
expand
the
scope
like
if
rate
can
go
negative,
like
mathematically
there's,
no
difference,
you
don't
have
to
invent
any
new
operator,
just
like
add
minus.
If
you
shift
that
from
all
positive
number
to
cover
negative
number,
it
still
applies.
A
This
is
math,
we
all
know,
but
the
reason
why
they
have
dedicated
dpi
that
enforces
monotony.
I
believe
it's
when
user.
When
you
look
at
imagine
if
you
look
at
the
dashboard,
if
the
dashboard
is
saying
the
y-axis
is
the
total
number
of
the
requests,
and
if
you
run
the
service
for
1
billion
years,
the
number
will
keep
going
up
and
it
doesn't
make
sense
for
you
to
look
at
that
dashboard
in
that
way.
A
So
what
you
want
is,
instead
of
looking
at
the
like
ever
growing
line
like
keeps
climbing
up,
because
it's
hard,
like
it's
very
hard
for
the
viralization
and
what
you
want
to
do.
Is
you
change
that
to
something
relatively
flat
you
can
see?
Oh
this
is
the
number
of
requests
I'm
getting
in
this
five
minutes.
A
Then
you
can
see
the
the
the
trend
otherwise
like
it
will
be
a
very,
very
big
line
of
like
ever
increasing
number
and
any
subtle
changes
in
that
won't
just
be
ignored
because
it's
very
hard
to
show
that
in
the
ui.
So
I
believe
this
is
why
people
want
to
have
that
con
counter
concept.
It's
not
a
pure
mathematical
thing,
it's
just
for
convenience
and-
and
that
seems
to
be
the
typical
use
of
I.
I
would
imagine
when
people
use
the
matrix
api.
A
Eighty
percent
of
them
would
use
conquer
for
sure,
like
I
can't
imagine
a
scenario
like
if
I'm,
if
you
look
at
the
old
type
scenario,
I
can't
imagine
I
have
a
scenario
where
I
care
about
histogram,
but
I
don't
have
any
ask
for
the
counter.
So
I
believe
this
is
why
we
have
a
such
a
special
thing:
it's
not
mathematically
required,
but
but
it
is
there
and
and
also
for
the
for
the
sake
of
this
hotel
api
design.
A
I
I
think
one
goes
I
at
least
I'm
trying
to
make
it
familiar
for
exa
two
existing
customers
who
are
coming
from
those
well
established
metrics
api.
So
if,
if
we
need
to
tell
them
hey
this,
api
is
more
coming
from
the
math
perspective.
It
doesn't
give
you
the
counter.
You
can
put
arbitrary
like
up
and
down
thing.
A
I
figure
it's
a
little
bit
scary.
That
requires
a
lot
of
explanation.
So
if
they
just
come
here,
they
all
have
the
contrary
and
say:
okay,
I
have
the
content.
If
that's
the
same
name
seems
semantic,
then
it's
much
easier
for
them.
So
this
is
probably
not
a
like
it's
not
a
scientific
problem.
It's
more
like
the
engineering
practice
how
we
can
how
we
can
bridge
the
gap
here.
That's
my
take
so
so
I
totally
agree.
If
you
look
at
the
pure
math,
I
I
don't
see
any
difference.
A
Unless
we
invent
some
like
matrix,
can
be
a
complex
number,
then
we
we
got
to
invent
something
different,
but
but
here
like
we're
all
talking
about
rational
numbers,
so
no
difference
to
me.
F
So
from
a
pure
math
perspective,
there
actually
is
a
difference,
and
that
was
actually
what
drove
prometheus
to
make
the
decision
to
actually
report
raw
measurements
rather
than
make
the
rate
measurement
from
the
start,
and
that's
if
you
think
about
it,
like
you're.
Looking
at
a
rate,
that's
going
to
be
your
derivative
who
says
you
want
to
look
at
a
rate.
F
Maybe
you
want
to
look
at
acceleration,
so
there's
like
multiple
levels
of
your
derivative
there
versus
the
fact
that,
like
if
you
go
the
opposite
direction,
you're
gonna
have
to
integrate
and
then
you're
gonna
have
some
sort
of
offset.
That
is
an
unknown
offset
right.
So
you
have
loss
of
information
at
that
point.
The
other
side
is
the
the
aggregation
of
rates.
F
It's
not
a
well-known
process
as
to
like
what
aggregation
time
frame
you
were
looking
at
when
you
originally
made
that
rate,
and
sometimes
it
can
be
absolutely
arbitrary
and
the
re-aggregation
of
that
rate
is
not
possible
after
the
fact
with
certainty,
you
can
make
statistical
estimates,
but
you
can't
actually
make
certain
estimates,
and
so
that
was
why
the
idea
of
using
the
raw
measurements,
and
even
if
it's
a
sequential,
are
something
that's
always
increasing.
You're
right,
like
maybe
the
visualization,
isn't
actually
what
you
want.
But
then
it
comes
back
to
that
persona.
F
Information
that
josh
was
kind
of
pointing
out
is
like
well.
That
may
be
very
important
for
the
user.
That
is
looking
at
at
the
end,
so
say
like
the
operator,
but
the
instrumenter
wants
to
make
sure
that
they
provide
the
freedom
to
the
final
end
user
to
see
the
data
in
the
form
that
they
want
and
that's
the
pure
way
to
actually
see
that
is.
I
usually
encounter.
G
If
you
want
sync
and
ace
it,
you
know,
like
you,
know,
number
submitter,
that's
like
totally
opaque
as
to
what
you
do
with
the
numbers
is
that
the
type
of
instrument
ultimately
is
just
a
a
hint
or
a
suggestion
as
to
how
you
think
the
value
would
be
effectively
rendered
to
the
user
at
the
end,
and
then,
of
course,
once
you
know
what
you
want
to
do
with
it
at
the
end,
it
also
it's
a
hint
of
what
you
might
want
to
do
with
it
in
process
to
make
the
pipeline
more
efficient
to
get
it
there,
but-
and
I
think
hotel
has
always
maintained
the
principle
of
like
the
the
you
know.
G
App
developer
could
use
the
sort
of
configuration
or
review
type
of
api
to
completely
override
what
the
instrumenter
said
was
desirable
to
do
with
their
number,
as
in
like
any
any
of
the
instruments
ultimately
can
be
number
submitter
and
then
the
develop
app
developer
will
tell
you
what
to
actually
do
with
the
number
if
you
wanted
to
so
so,
it
was
always
my
take
that
sort
of
the
instrument
that
the
instrumenter
chooses
is
just
a
form
of
here's,
a
hint
of
what
I
think
you
should
do
with
the
number,
but
app
developer
and
observer.
G
You
can
just
do
something
different
with
it
if
you
so
decide.
So
in
that
sense,
I
think
of
the
rate
versus
absolute
again
as
as
a
hint
of,
I
think
it
would
be
valuable
to
display,
at
the
end,
this
number
as
a
rate
or
display
this
number
as
an
absolute
value,
but
anybody
else
can
override
what
I
say
and
also
it
and
also
there's
freedom
of
like
well.
What
number
like
crosses
the
data
stream?
What
what's
on
the
transport?
G
You
know,
if
you
say,
hey,
I'm
going
to
show
this
at
the
end
as
a
rate,
but
it
would
be
very
like
efficient
or
convenient
or
whatever
that
on
the
transport,
it's
an
absolute
value
that
doesn't
seem
to
like
conceptually.
That
doesn't
feel
like
a
problem
to
me.
Others
might
you
know,
think
differently.
E
So
I
also
chime
in
that
to
add,
on
top
of
what
noah
was
just
saying,
I,
by
the
way,
that's
kind
of
my
feeling
too.
I
think
there's
one
distinction
is
that
the
value
the
number
that
we
report
you
probably
want
to
report
some
kind
of
a
unit
not
in
the
sense
of
you,
know,
kilo
or
miller,
but
whether
or
not
this
number
is
a
actual
number
or
it's
a
derivative,
as
in
it's
already
a
rate
and
whatever
number
of
derivatives
from
that
right.
So
that
solves
some
of
the
potential
problem.
F
F
And
it's
really
important
to
understand
that,
like
going
from
a
ratio
to
an
interval,
is
something
that's
or
an
interval
to
a
ratio
is
destructive
of
information
and
that's
what's
happening
in
this
situation,
and
so
I
think,
like
it's
important,
to
understand
that,
like
yeah
semantically,
like
we
want
to
provide
something
that
is
useful
for
the
users,
but
it's
not
necessarily
from
the
instrumentation
side.
F
F
If,
in
the
process
of
that,
you
know
reporting
of
information,
you
had
information
and
you
decided
to
go
to
something
that
was
less
descriptive
of
the
scale
or
you
know,
makes
it
opaque
as
to
like
what
you
can
actually
then
do
with
that
measurement
and
in
this
situation,
going
into
some
sort
of
a
ratio
would
do
that,
and
so
it's
important
not
to
actually
have
that
loss
of
information.
E
I'll
add
one
more
other
item
to
it
is
that
I
think
it's
common
that
when
you
report
some
numbers,
people
may
want
to
see
that
as
a
counter
as
well
as
a
histogram
as
well
as
a
rate.
So
there
may
be
multiple
time
series
resulting
from
one
series
of
numbers,
and
today
I
think
that
onus
is
for
the
user
to
create
different
instruments
for.
D
Yeah
can
I
can
I
interrupt.
I
feel
like
we're
a
little
off
track
here,
because
you
know
we're
in
danger
of
starting
from
scratch,
where
I
we've
answered
a
lot
of
these
questions
already
and
I'm
afraid
that
we've
now
erased
those
documents
and
it
there's
there's
danger
of
starting
over.
Essentially
the
hotel
mission,
both
across
spans
and
metrics,
was
to
provide
these
abstract
interfaces
that
can
be
decoupled
from
the
sdk
and
and
in
the
data
model.
D
Conversation
right
now
that
we're
having
we've
explicitly
laid
out
time
series
model
event
model
and
this
concept
of
a
stream
that
we're
trying
to
tie
the
two
together
with
and
there's,
there's
been
a
little
bit
of
confusion
in
the
in
the
recent
conversation
in
this
past
10
minutes,
because
we
we
aren't
actually
talking
about
direct
translation
of
numbers
in
the
api,
where
every
event
has
one
number
and
numbers
in
the
output
data
stream,
because
we
do
aggregation
along
the
way
and
that's
been
discussed.
D
But
I
feel
I
feel
like
the
goal
of
this
meeting
is
not
to
redesign
the
the
data
model.
We
have
a
separate
meeting
for
that
and
we're
pretty
clear
on
what
what
we're
doing.
I
I
want
to
bring
this
all
the
way
back
to
where
riley
was
before
before
several
comments
were
made.
I
fully
agree
with
noah,
but
back
to
riley's
comment.
D
D
D
I
guarantee
you're
going
to
find
more
than
four
good
default
charts
and
we
need
to
have
an
instrument
for
every
good
default
chart
and
what
we're
looking
for
right
now
is
the
instrument
that
tells
you
the
difference
between
this
up
down
counter
instrument
and
the
gauge
instrument
where
you
set
like
current
temperature,
or
something
like
that,
so
we
need
another
non-monotonic
sum
essentially
is:
is
the
outcome
of
that
we
don't
have
enough
default
charts,
and
so
what
I
want
to
do
is
I've
like,
for
example,
I've
got
this
code
that
I'm
working
on
and
I've
got.
D
D
Now
I
always
want
to
go
to
my
my
metrics
system
and
type
sideguard.star
and
say
get
a
dashboard,
because
every
single
metric
that
starts
with
scigard.star
is
interesting
to
me,
and
every
single
one
of
them
has
a
good
default
chart
and
right
now
it's
what's
on
the
line
is
that
we
need
another
instrument,
type
to
make
sure
we
get
a
good
chart
so
for
the
non-monotonic
cumulative
sum,
as
opposed
to
the
gauge
essentially.
G
So
so,
if
it
helps
at
all
I'd
say
my
my
current
position
is
probably
not
that
I
was
pushing
back
against
having
instruments
five
and
six.
I
I'm
fine
with
five
and
six,
and
I
totally
agree
with
the
goal
of
like
have
a
good
default
chart.
G
I
think
mine
was
more
along
the
lines
of
like,
as
in
literally
monotonic
versus
not
monotonic,
isn't
two
different
charts.
That's
just
some
property
that
the
data
has,
like
rate
versus
absolute
value.
That's
two
different
charts
that
you
know
like
you
would
see
different
things
graphed
there,
like
you
know
just
assume,
for
you
know
yeah.
G
D
A
So
we
have
three
minutes
left
I'll
I'll
try
to
wrap
up
the
meeting
so
at
the
next
step.
A
I
think
what
I
I
can
do
is
I
I
send
the
pr
just
propose
some
creative
names
and
based
on
the
discussion
here,
and
I
understand
some
of
the
scenarios
I'll
just
put
some
name
and-
and
you
guys
reply
and
tell
whether
this
is
crazy
or
not,
and
my
focus
would
be
I'll
start
from
the
scenario
like
what
are
we
trying
to
achieve
and
we
can
we
can
debate
on
whether
that
scenario
is
common
enough,
so
we
need
to
have
a
dedicated
instrument
or
it's
not
common
enough.
We
can
ignore
it.
A
For
now
and
later
we
can
see
if
we
can
cover
that
hint
api,
we
might
say:
hey,
we
have
a.
We
have
a
gauge
where
people
report
the
absolute
value
in
the
asynchronous
way
and
that
value
can
go
up
and
down
and
the
if
they
provide
additional
financing.
Oh,
I
know
this
value
can
only
only
go
down.
We
might
have
a
yet
another
diagram.
I
I
haven't
seen
some
number
that
can
absolutely
go
down
without
going
up,
but
we
can't
explore
that
and
probably
say:
okay.
A
This
is
only
like
one
out
of
a
thousand
cases,
so
it
doesn't
make
sense
for
us
to
invent
a
brand
new
api
or
a
new
instrument,
and
let's
table
that
and
use
the
hint
to
cover
that.
So
if
someone
wants
to
put
hint,
they
can
put
arbitrary
combination,
they
might
come
up
with
a
situation
where
they
have
the
asynchronous
instrument
and
they
allow
delta
value.
It
might
be
the
case
I
I
don't
know
it
doesn't
seem
to
be
the
case,
but
I
I
hope
that
can
give
us
the
balance.
A
C
A
And
one
allow
add
another
allow
absolute
value,
it's
kind
of
they
try
to
focus
based
on
the
scenario
like
the
counter,
the
gauge.
When
I
look
at
micrometer,
it's
very
scenario
based,
so
I
I
would
prefer
to
take
that
approach.
If
it's
a
common
scenario,
then
we
have
a
dedicated
instrument.
Otherwise
we
fall
back
to
a
very
generic
thing,
like
a
value
value
or
a
quarter
or
something
and
people
can
put
extra
hint
so
I'll
I'll.
A
A
D
Yeah
I
felt
like
I
couldn't
quite
finish
what
I
wanted
to
say
two
minutes
ago
and
and
it
does
deserve
more
thought-
I
mean
there's
something
about
how
we
have
these
deltas
and
they're
not
present.
By
the
time
you
get
down
to
the
time
series
model
and
so
like
once
you're
in
time
series
land.
Then
you
talk
about
rate
versus
absolute,
but
we're
still
talking
about
events
at
the
api
level
and
that's
why
I
feel
like
there's,
probably
a
reason
for
a
difference,
but
I
feel
like
it
means
more
thought
too.