►
From YouTube: 2021-07-15 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
B
A
A
A
Okay,
so
I
I
only
have
one
topic
I
want
to
see.
We
can
finish
the
view
pr
and
it
seems
walton
and
and
josh,
like
both
talked
with
me
like
early
this
week
and
I'll
I'll,
show
folks
this
comment
here.
A
So
the
the
major
feedback
I'm
guiding,
I
I
think
from
from
josh
storage
that
currently
the
pipeline
part
is,
is
very
like
tied
to
how
the
sdk
should
be
implemented
and
his
suggestion
is
we
step
back
and
try
to
describe
what
we
need,
instead
of
like
forcing
the
sdk
to
do
something?
So
specifically,
it's
about
this,
and
I
I
agree
with
him
a
hundred
percent
and
and
also
it
seems
like
I
started
with
view,
and
I
have
a
clear
goal.
I
I
don't
want
to
put
pipeline
in
this
pr.
A
A
That's
where
I
start
to
make
this
pr
like
trying
like
oil,
ocean
and-
and
it
seems
like
we
failed
here
so
my
portal
would
be
we
step
back
and
we
just
describe
how
views
should
be
applied
to
the
meter
provider
and
with
the
understanding
that
currently
we
leave
pipeline
in
a
separate
pr,
I'll,
follow
up
and-
and
I
want
to
follow
the
spirit
that
we
just
described-
what
we
need
instead
of
what
the
isdk
should
implement,
that
and
and
for
people
who
might
have
concern
about
hey
in
this
way.
A
Are
we
saying
all
the
views
should
be
global
to
everything?
My
suggestion
would
be
later.
If
we,
we
won't,
have
multiple
pipeline,
we
can
have
pipeline
specific
view,
but
the
view
we
add
on
the
meter
provider
will
be
visible
to
to
all
the
exporters
and
and
and
based
on
the
feedback
from
bogdan.
I
think
there's
a
way
out
so
different
exporter
different
pipeline.
They
can
select
whether
they
want
to
subscribe
to
a
specific
thing,
so
that
shouldn't
be
a
problem.
A
Just
to
summarize,
I
want
to
remove
the
pipeline
part
from
this
pr,
so
we
can
focus
just
on
the
view.
Part
and-
and
I
can
follow
up
on
the
pipeline
in
a
subsequent
pr
with
the
direction
that
I
try
to
not
focus
on
how
it
should
be
implemented.
But
what
do
we
expect
from
the
sdk
that
makes
sense.
A
At
least
for
the
for
the
initial
like
stable
version
of
the
sdk,
I
don't
even
see
that
we
need
to
expose
an
aggregator
type
in
the
sdk.
So
what
I
mean
is
aggregator
can
be
the
implementation
detail.
It
doesn't
have
to
be
an
isdk
at
a
certain
point.
We
will
have
the
need
that
we
want
people
to
implement
their
own
aggregation
logic.
For
example,
people
want
unique
count.
We
don't
have
that
in
in
our
current
spec
or
even
in
the
data
model.
A
D
A
A
E
E
Maybe
if
you
just
change
the
words
a
little
bit,
it
could
be
fixed,
not
that
I'm
saying
you
have
to
do
it
that
way,
but
to
me
that,
like
the
pipeline
was
a
logical,
abstract,
abstract
idea
like
something
the
sdk
is
going
to
make
happen,
and
it's
okay
to
implement
that
using
a
storage
and
export
model
as
opposed
to
boden
summarized
it
very
well.
I
don't
want
to
try
and
say
it
again
as
opposed
to
a
query
model.
I
guess
you'd
say
I.
The
the
go.
E
Prototype
also
uses
a
storage
model,
and
I
had
I
had
created
this
new
reducer
processor,
which
was
meant
to
help
produce
multiple
outputs
from
a
single
sort
of
storage,
but
that
didn't
address
every
single
question.
There
was-
and
I
think
that
you
know
another
prototype
can
very
easily
find
a
way
to
do
it
differently.
So
I
don't
think
we
should
try
to
pin
sdks
down.
D
A
question
just
sorry:
if
we
are
not,
if
we're
not
going
to
use
pipelining
or
spec,
then
no,
let
me
go
back.
Maybe
I
did
not
understand
this
right,
but
in
the
data
model
we
kind
of
define
a
process
that
goes
from
instrument
to
entrance
it
to
time
series
right
and
I
was
under
the
impression
that
the
pipeline
was
trying
to
represent
that
process
of
metrics
flowing
from
one
place
to
the
other.
Is
that
not
the
case?
B
F
No,
no
so
so
I
wanna,
I
wanna,
make
two
comments.
One
is
there
is
a
difference
between
how
we're
defining
pipelines
here
than
on
traces.
F
If
you
look
at
how
pipelines
are
done
on
traces
and
so
to
the
extent
that
we
deviate
from
traces,
because
metrics
are
different,
that's
cool
to
the
extent
we
deviate
because
we're
a
different
group
of
people.
I
I
that
that's
the
bit
that
I
think
we
should.
We
should
take
a
look
at
how
pipelines
are
done
on
traces
today
and
and
try
to
as
best
we
can
kind
of
accommodate
that.
My
I
had.
I
had
two
main
concerns
with
pipeline.
That
I
want
to
talk
through.
F
One
is
the
notion
that
you
have
different
sets
of
views
per
pipeline
and
kind
of
the
the
complexity
that
that
adds
and
whether
or
not
we
should
just
wait
to
do
that
and
start
with.
F
You
have
a
single
pipeline
with
multiple
exporters
right
and
a
single
set
of
views
for
multiple
exporters
is
just
the
initial
v1
to
get
that
out
the
door
before
we
add
in
this
complexity
of
what
the
hell
does
it
mean
and
and
the
the
fun
of
memory
right
like
the
way
to
define
a
pipeline,
I
think,
is
okay,
but
the
way
we
phrased
everything
in
the
specification
kind
of
implied
a
default
implementation,
and
that's
where
you
know
to
the
extent
that
we
say
if
the
user
writes
this
code.
F
Here
is
what
happens
but
without
trying
just
to
like
specify
an
algorithm
for
how
it
happens.
I
think
that's
where
we
should
try
to
stick
to
in
in
the
in
the
specification.
If
we
define
an
interface
right,
we
have
to
define
that
interface
and
say
here
is
what
comes
in
here's,
what
comes
out,
but
we
don't
have
to
specify
how
it
goes
in
or
out
right.
F
We
just
have
to
specify
what
it
is
and
there's
a
few
things
in
here
that
have
me
a
little
bit
nervous
that
I
think
haven't
gotten
pushed
on
across
languages
enough
I'll
give
you
an
example.
The
the
notion
of
measurement
processor,
the
way
it
turned
out
in
practice,
I'm
not
super
happy
with
it
to
the
point
where
I
think
we
can
mention
it
as
a
concept
and
an
architecture,
that's
possible,
but
I
don't
think
we
specify
it
at
all.
I
think
we
we
leave
that
hook
completely
out.
F
I
don't
think
it
actually
solves
a
use
case
today
that
we
need
to
worry
about
too
much
outside.
Like
the
views
use
case,
I
totally
buy
pipelines.
I
think,
there's
the
the
use
case.
We're
trying
to
solve
is
I
want
to
send
metrics
to
multiple
locations
and
to
me
I
will
always
have
two
locations
for
every
metric.
F
I
have
in
open
telemetry
one
will
be
the
otlp
exporter
and
the
second
will
be
the
prometheus
exporter,
specifically
for
a
debug
use
case,
where
I
want
to
hit
that
metrics
endpoint
and
see
what
the
hell
is
going
on
right
and
I
will
always
have
two
and
so
like
to
me.
We
need
to
solve
that
use
case
for
multiple
exporters,
but
I
don't
want
to
solve
that
use
case
in
the
view.
F
Pr
when
I
think
the
rest
of
the
upr
of
how
do
I
specify
a
view,
and
what
does
it
do
is
really
darn
good,
but
that
other
aspect
of
like
pipelining
and
like
understanding
when
a
view
applies
and
when
it
doesn't
apply.
I
I
think
we
need
a
little
bit
more
experimentation,
a
little
bit
more
understanding
across
languages
and
a
little
bit
more
time
to
to
noodle
on
that
discussion.
F
Personally,
you
know
to
the
extent
that
the
sdk
configuration
is
declarative
with,
with
known
semantics
great,
I
think
we're
we're.
I
want
to
not
over
index
on
existing
implementations,
and
I
want
to
kind
of
you
know:
have
people
have
a
chance
to
prototype
through
this,
so
that
those
are
my
concerns
there?
I
don't
think
anything
material,
materially
changes
related.
If
you
look
at
bogdan's
proposal,
there's
still
a
mechanism
to
do
multi
pipelines
in
that
proposal,
it's
just
the
dividing
line
is
at
a
different
spot.
F
But
that's
that's
that's
for
us
to
discuss
then
anyway,
but
so
so
my
two
cents
are
the
the
way
you
define
a
view,
the
configuration
options
and
the
the
limited
set
of
things
that
you
define
there,
I
think,
are
great
the
addition
of
all
the
pipeline
stuff
in
the
semantics
around
pipelines
and
some
of
the
it
starts
to
feel
very
it's
okay
to
have
it
prescribe
a
possible
implementation,
but
if
we're
going
to
do
that,
we
need
to
make
the
language
very
clear
that
this
is
a
way
that
this
could
work
to
help
aid.
F
A
Thanks
josh,
so
I'll
summarize
with
this
like
we're
not
saying
the
pipeline
is
a
bad
idea
like
logically,
we
need
something
like
that,
but
we're
we're
trying
to
remove
the
pipeline
thing
from
this
pr,
because
we
want
this
pr
to
focus
on
the
view.
Otherwise
it's
just
too
big.
We
already
have
like
a
hundred
more
than
120
comments.
I
like
I,
I
want
to
avoid
us
reaching
200
comments.
A
Otherwise
my
brother
will
just
crash
so
focus
on
the
view
part
and
and
I'll
I'll
split
the
pipeline
part
in
a
separate
pr
and
I'll
try
to
change
how
how
we
describe
the
entire
thing
like,
instead
of
focusing
on
how
it
can,
like,
I
probably
put
some
example,
it
gives
people
the
feeling
that
trying
to
advertise
for
what?
What
should
should
be
the
implementation
I'll
try
to
change
that,
based
on
the
feedback
from
both
and
and
josh.
But
that
should
be
a
separate
pr.
C
You
know
thing
I
I
don't
see
anywhere,
you
know
in
the
spec
or
whatever
that
actually
calls
out
specifically
in
memory.
So
my
my
suggestion
is:
maybe
we
swap
out
the
box
that
you
know
where
riley
has
that
says
you
know?
Measurement
processor
goes
to
in-memory.
That
goes
to
you
know
downstream.
It's
just
change
the
word
in
memory
to.
F
I
once
again,
I
think
that
the
fact
that
in
memory
isn't
you
know
specified,
is
actually
fine,
because
again
we
don't
want
to
specify
an
implementation
and
when
it
comes
to
aggregator
and
when
it
comes
to
storage.
I
think
I
mentioned
this
on
on
your
pr
like
in
java.
We
completely
split
those
two
concepts
specifically
when
it
comes
to
async
instruments.
F
You
know
the
aggregator
doesn't
necessarily
need
to
do
a
lot
of
in
memory
storage,
and
so
I
I
I'm
curious
why
you
would
throw
aggregator
there
and
like
what
benefit
we
get
in
terms
of
the
specification
right.
There's,
there's
teaching
people
how
to
implement
this,
which
is
not
the
job
of
the
specification,
the
specifications
just
more.
Here's
how
you
can
understand
what
these
methods
do
it's
more
like
a
javadoc
kind
of
thing
right.
F
If
I,
if
I
call
this,
if
I
add
this,
if
I
add
this
particular
interface,
it
will
do
this
and
will
be
called
you
know
in
these
instances
and
here's
the
effect
of
it
in
terms
of
the
actual
implementation
in
memory
storage.
I
really
want
to
save
that
for
the
sdks,
as
as
their
responsibility
to
figure
out
how
that's
done
as
much
as
we
can
just
because
so
far
you
know
looking
at
c
plus
looking
at
java,
it's
different,
I
don't
think
you're
going
to
do
it
the
same
way.
E
E
I
I
made
a
comment
on
your
pr
recently
riley
saying
I
had
a
different
thing
in
mind
when
I
wanted
to
talk
about
memory
requirements
as
far
as
what
you
have
to
remember
forever
and
ever
that
if
there
are
cumulative
exporters,
they
have
a
memory
requirement,
but
that
that
I
want
to
be
able
to
implement
delta
exporters
that
don't
have
a
memory
requirement
and
that's
like
a
different
sort
of
the
nature
and
so
so
sort
of.
E
So
so
there
are
so-called
stateless
export
strategies
that
don't
require
memory
for
in
the
long
term,
but
you
know
in
the
short
term,
so
we
understand
why
synchronous
instruments
require
memory
in
the
short
term
and
that's
up
to
the
sdk.
I
think-
and
you
recently
said
something
about
asynchronous
and
memory,
and
I
I
want
to
ask
if
you've,
if
we're
thinking
about
the
case
where
you
know
an
asynchronous
instrument
produces,
is
produced
with
several
dimensions
that
you
want
to
erase.
E
So
I
think
of
an
aggregator
is
taking
place
and
in
my
implementation,
there's
basically
a
special
case.
I
mean
not
a
special
case,
but
a
case
that's
handled
of.
Are
you
the
first
copy
of
a
value
coming
in
because
I'll
just
refer
to
you?
I
don't
need
to
copy
you
yet,
but
as
soon
as
two
values
come
in,
I
need
to
own
an
aggregator,
so
I
can
store
a
copy
and
so
inside
of
the
processor,
the
the
storage
processor,
as
we
as
we're
now
kind
of
all
referring
it
to
to
it.
E
As
there
is
a
question
of,
will
I
become
the
owner
of
an
aggregator,
or
will
I
just
refer
to
one
that
is
guaranteed
to
be
like
okay
to
refer
to,
because
of
there's
only
one
of
them
and
there's
some
sort
of
locking
synchronization
contract
between
processor
and
and
that
first
stage,
and
in
some
of
these
implementations
like,
for
example,
in
my
inline,
there
were
sort
of
two
copies
of
the
aggregator
state
and
whenever
you
did
a
collect,
you
snapshot
one
and
it
was
safe
to
refer
to
the
snapshot
until
the
next
collect
and
the
person
calling
collect
was
responsible
to
not
use
the
data
between
you
know,
while
they're
collecting
it
essentially.
F
F
But
to
me
the
in-memory
state
is
the
accumulation.
The
aggregator
is
just
a
strategy
for
how
to
do
that
right
and
so
we've
divorced
the
notion
of
accumulation
from
aggregator
to
implement
our
storage.
Specifically,
you
can
have
the
same
aggregator
instance
handle
synchronous
and
asynchronous
instruments,
but
the
actual
flow
and
storage
of
data
is
very
different
between
the
two
and
that's
that's.
What
I'm
trying
to
push
on
is
I
like
previously
aggregator
and
storage
were
the
same
thing
and
there
was
some
really
wonky
looking
code
to
deal
with
the
two
like.
F
I
think
I
found
a
bug
actually,
but
we
can.
We
can
go
into
that
later,
around
aggregation
and
asynchronous
instruments
right
that
do
not
have
views
where
you
we
are
supposed
to
not
allow
certain
types
of
measurements
to
come
in
and
yet
we
were
merging
them
in
a
way
that
I
think
was
not
good
for
the
user
right
and
it
was
impossible
to
determine
this
just
from
an
aggregator
alone,
because
the
aggregator
was
supporting
both
synchronous
and
asynchronous
instruments.
F
You
can
specify
what
needs
to
be
stored
for
this
kind
of
aggregation
by
something,
but
the
aggregator
doesn't
need
to
store
it.
Something
needs
to
store
it.
We
call
that
thing
an
accumulation
in
java,
but
I
don't
want
the
to
force
the
aggregator
to
be
that
point
of
storage.
If
we
decide
to
divorce
those
two
concepts
in
our
sdk,
practically
it's
the
same
thing
for
the
user.
They
don't
care
right,
but
but
again
I
don't
want
to
lock
down
the
implementation
by
the
specification.
C
So
josh
then,
given
what
you
just
said,
then
why
do
we
in
the
spec
even
want
to
call
out
an
in-memory
leave
that
as
implementation
detail
right
and
if
so,
and
if
assuming
we
assume
that,
then
we
need
something.
Maybe
aggregate
is
the
wrong
term,
but
we
we
have
some
concept
that
takes
measurements
and
convert
it
to
metrics.
Whatever
that
thing
is
called,
why
not
just
specify
that
and
call
it
good.
F
Yeah,
no,
no,
I
there's
an
aggregator,
that's
responsible
for
taking
measurements
and
turning
them
into
either
accumulations
or
metrics,
and
I
think
you
need
to
specify
both,
but
the
the
important
thing
here
is.
You
mentioned.
Why
not
take
out
this
notion
of
in
in
memory
right?
I
would
argue
that
that
notion
of
in
memory
and
the
way
it's
meant
to
be
specified
now.
Is
it's
not
a
specification?
It's
guidance.
It's
it's!
It's!
F
F
It
is
just
guidance
on
on
a
way
to
view
the
problem,
that's
fair,
and
if
we
want
to
like
use
a
stream
based
cue-based,
you
know
metric
system
to
how
to
provide
guidance
for
a
way
to
think
about.
Metrics,
that's
fair,
but
when
we
put
must
and
should
I
want
to
be
careful
that
those
must
and
shoulds
are
actually
around
semantics
or
interfaces
and
not
around
implementation,
details
related
to
the
guidance
like
we
need
to
be
very
explicit
about
those
two
things.
C
F
Yeah,
I
I
can't
implement
that
a
measurement
process
that
takes
in
a
measurement
and
outputs
a
metric
that
that's
not
what
we
have
is
a
measurement
processor
that
takes
in
knows
how
to
take
measurements
coming
in
from
an
instrument
and
route
them
to
the
storage.
F
D
Sorry,
thank
you.
This
is
directly
related
to
the
python
template
implementation
that
I
have
the
I
see
an
aggregator
as
something
that
is
directly
and
closely
related
to
an
aggregate
function.
So
I
see
it
like
this
aggregator,
it's
a
main
aggregator.
It's
directly
related
to
a
main
aggregation
function,
so
just
to
make
sure
that
I
understand
you
right
josh.
F
A
A
You
can
to
turn
those
views
into
that
black
box
when
your
job
is
done,
whether
you
collect
aggregate
or
some
other
thing,
it's
your
problem,
and
and
with
that
we
can,
we
can
have
the
first
version
of
the
spike
and
later
we
have
the
need
we
say:
oh
people
want
to
extend
that
into
either
custom,
rightly
aggregator
or
the
unique
count.
Then
we
come
back
and
hammer
them
out,
but
it
doesn't
have
to
be
not
and
and
currently
if
we
try
to
specify
something
in
the
spike
we
make
it
must.
F
Exactly
exactly
and
and
to
follow
on
with
that,
when
we
define
aggregators,
if
we
define
them
as
those
whatever
they're
called
decomposite
value
functions
or
we,
we
can
define
those
as
a
set
of
things
that
sdks
must
support
almost
like
in
a
new
or
like
a
you
know,
a
list
of
we
want
a
last
value
aggregator.
We
want
a
sum
aggregator.
We
want
a
max
aggregator.
We
want
account
aggregator,
whatever
the
heck
we
decide.
F
You
know
we
have
three.
We
know
we
have
to
provide
of
histogram
sum
and
last
value,
but
you
can
specify
what
those
are
in
the
semantics
of
what
they
do
without
having
to
specify
a
straight
up
interface
across
all
the
different
languages,
and
we
can
all
implement
that
in
v1
and
be
okay
and
then,
as
we
get
demands
for
I
want
an
aggregator
that
does
xyz.
I
want
an
aggregator
that
does
this.
F
G
Okay,
so
I
have
a
meta
comment
here.
I
I
observed
this
discussion
for
the
past
20
minutes
and
I
feel
I
feel
there
is
no
clear
understanding
of
of
the
another
data
flow
of
the,
how
the
data
models
or
or
or
the
the
the
different
apis
public
apis
that
we
have.
G
A
G
Do
we
all
agree
that
metric
processor,
when,
when
that
part
starts,
we
have
otlp,
like
representations,
probably
not
directly
the
protoss,
because
we
we
do
the
same
thing
as
we
did
with
trace?
We
declare
that
the
struct
that
that
type,
because
we
don't
want
to
take
a
dependency
on
protons,
is
that
clear
for
everyone.
G
G
Sdk
is
just
a
simple
metric
producer
that
for
synchronous
thing
will
always
produce
deltas
for
asking
things
will
always
produce
cumulative,
because
that's
how
we
define
the
asking
things
and
then
later
we
have
to
deal
with.
What
do
we
do
with
this
for
prometheus
case?
G
And
what
do
we
do
with
this
for
for
for
otlp
case
where,
where
things
are
passed
through
or
whatever,
because
we
don't
care
about,
or
maybe
we
give
user
a
possibility,
even
if
they
communicate
otlp
to
produce
always
cumulative
because
may
later
go
to
a
prometheus
back-end
and
they
really
want
to
to
have
them
cumulative
from
the
beginning,
but
now,
based
on
this,
what
I'm
trying
to
say
is.
I
think
we
should
separate
in
in
couple
of
big
blocks,
a
big
blo
boxes.
D
G
G
E
Yeah,
I
I
agree
with
you
bogdan
that
sounded
really
good.
I
do
want
to
say
one
more
thing
is
that
we
should
not
be
talking
about
converting
cumulative
to
delta,
because
it's
a
different
type
of
transformation
than
we've.
Then
we've
talked
about
in
this
sort
of
sdk
context,
and
it
requires
more
of
the
aggregator.
It
requires
a
subtract
function
and
we
we
talk
about
decomposable
or
mergable
like
aggregators
and
like
this
there's
a
sort
of
subclass
of
those
that
support
subtract
and
it
just.
E
E
G
One
thing
for
the
otlp
like
for
sums:
we
don't
have
that
problem.
We
know
how,
because
these
are
now
now
these
are
otlp
like.
So,
if
it's
a
sum,
we
know
how
to
do
the
subtract
correct.
If
it's
a
histogram,
we
know
how
to
subtract
them
at
least
the
types
that
we
have
right
now.
The
only
problem
that
you
may
have
is
for
gauges
for
gauges,
but
gauges.
E
G
E
G
E
G
So
that
being
said,
that's
that
these
are
my
two
cents,
so
our
sdk
will
always
force
this,
for,
for
synchronous
instruments
will
always
produce
deltas
and
for,
I
think,
we'll
produce
the
cumulatives
and
then,
if
we
really
need
to
to
merge
them
again,
I
may
be
wrong,
but
I'm
trying
to
simplify
the
problem
in
a
way
to
that
we
can
put.
G
Correct
but
victor
one
thing
that
I
I
mentioned
while
I
was
explaining,
I
was
explaining
what
is
the
input
and
what
is
the
output
of
this
block?
That's
right
so
so
I
think
this
is
how
probably
we
should
define
the
specs,
so
so
we
we
receive
measurements
and
we,
the
the
result
of
this,
is
metric
data.
Yes,
so
at
least
let's,
let's
define
like
what
is
the
input?
What
is
the
output
for
for
all
these
blocks?.
G
You
can
call
it
in
memory
state
as
long
as,
in
my
opinion,
as
long
as
you
define
the
input
and
the
output
of
this
yeah
and
define
what
what
are
the
features
of
this
or
functionality,
but
not
not
implementation,
detail
right
and
probably
probably
say
that
this
should
not
be
exposed
publicly
as
a
standalone
thing.
It's
just
an
implementation
detail
how
yeah
it's
implemented.
G
C
When
I
see
in
memory
state,
the
first
question
I
want
to
ask
is:
what's
in
memory
what
specifically
says
the
memory
I
mean,
so
that's
why
that
word
in
memory
state
was
was
troublesome
to
me.
Instead
of
just
some
arbitrary
logical
block,
then
I
just
think
about
more
interfaces,
rather
than
the
actual.
What
I'm
storing
in
memory
that
that's.
My
only
comment
on
that.
G
C
A
Okay,
I
have
some
ideas
I'll
try
to
cover
that
in
a
separate
pr,
but
I
I
think
we
concluded
that
I'm
going
to
scope
down
the
pr
just
to
focus
on
the
view
and
then
leave
the
like
whatever
and
the
memory
pipeline
in
the
second
pr-
and
I
have
a
good
idea-
how
I
can
refreeze
that
to
make
it
like
more
like
a
giving
a
higher
level
view.
Instead
of
focusing
on
the
implementation
details,
okay,
I
I
think
we
can
move
on
so
so
josh.
Your
turn.
F
Yeah,
I
just
wanted
to
call
out
so
we
had
this
this
proto
issue.
Sorry
for
letting
this
slip
through
the
cracks
it's
until
the
collector
is
is,
is
migrated
to
the
latest
proto
version,
I'm
not
as
worried,
but
that's
happening
relatively
soon.
So
we
have
an
issue
right
now,
where
we
can't
determine
the
difference
between
missing
values
and
zeros
in
proto3,
and
this
is
partly
because
I
totally
forgot
that
proto3
was
a
thing
where
you
can't
check
the
existence
of
a
a
particular
field.
F
So
we
made
some
decisions
around
there
and
I
think
we
need
to
go
fix
them.
Victor
had
a
a
pr
to
fix
this
that
that
the
comment
was
we
wanted
to
take
one
aspect
of
the
pr
without
the
rest
of
it.
If
do
you
want
me
to
do
you
mind?
Do
you
mind
clicking
through
to
the
the
issue.
G
To
clarify
this
applies
only
for
sums
in
histogram,
because
because
the
new
values
for
gauge
and
for
some
for
the
some
the
metrics
are
in
a
one-off,
will
you?
Yes?
Yes,
this
only
applies
to
histogram
sound.
F
Yes,
yeah
right
now,
I
think
there
might
be
there
was
some
other
part
of
histogram
as
well.
That
like
could
possibly
be
there
or
not.
But
I
don't
remember
the
specifics
sums
the
the
main
problematic
one.
So
if
you,
I
think
I
think,
there's
a
pr
linked
here
that
we
can
click
through.
F
This
one
right,
no,
that's,
that's
another
bug,
where's
the
pr.
A
Or,
or
do
you
want
to
take,
take
over
and
share
your
screen,
except,
I
don't
have
the
pr
up.
F
It's
a
no
it's
it's
pr
316
is,
is
the
current
one
from
josh?
I
think
that
this
is
meant
to
handle
this,
and
I
just
wanted
to
check,
because
this
has
been
sitting
for
a
little
bit,
and
I
want
to
try
to
get
this
get
this
through.
So
there's
this
flag
for
no
recorded
value.
F
That
is
added-
and
I
guess
the
question
here
is:
is
that
going
to
work
for
histograms
and
are
we
comfortable
making
this
change
and
pushing
it
through?
I
just
want
to
make
sure
that
people
are
it
has.
It
has
two
approvals.
I
want
to
make
sure
people
had
a
chance
to
look
at
this
and
validate
it,
because
I'd
like
to
get
this
fixed
and
in
the
next
version
of
otlp,
because
when
the
collector
jumps
to
whatever
version
it
jumps
to
an
otlp
I'd
like
to
have
this
fix
available.
G
So
so,
let's,
let's
get
one
by
one
in
the
in
the
in
the
gauge
matrix,
okay
in
the
gauge
metrics,
we
can
send
right
now
with
the
current
protocol.
We
can
send
a
point
without
a
value
without
having
anything
in
the
one-off
and
we
have
a
way
from
proto
to
determine
if
there
is
a
value
or
not
in
the
one-off.
F
No,
no
so
bogdan.
This
is
actually
the
way
it's
worded
sum
is
zero.
If
any
of
the
measurements
could
be
negative
I.e
if
it's
non-monotonic,
it
is
not
filled
out,
which
means
it's
zero
correct,
so
you
could
have
a
positive
count.
You
could
have
a
histogram
and
you
could
have
a
sum
of
zero.
How
do
I
know
that
my
sum
is
zero
because
it's
non-monotonic
or
because
the
sum
is
actually
zero.
F
G
F
Okay,
and
if
you
disagree
with
the
one,
that's
fine,
I
still
want
a
solution
to
the
non-monotonic
someone
because,
as
victor
raised,
it's
actually
an
issue
with
our
protocol
right
now
that
you
can't
address
it
basically,
but
it's
it's
okay,
because
so
far
the
collector
hasn't
adopted
it
and
I
don't
think
people
are
sending
non-monotonic
histograms
yet,
but
we
should
allow
it
so
I'd
like
to
get
a
fix
out
with
the
next
version.
F
E
I
would
most
support
the
idea
of
adding
two
bits
worth
of
information
to
to
lay
out
which
of
those
three
fundamental
types.
Each
histogram
is,
but
it
goes
up
in
a
different
level
of
the
protocol
than
this
thing
here
that
you're
looking
at
this
thing
here
says
the
data
point's
invalid
or
the
scrape
failed,
which
is
orthogonal.
I
think,
to
questions
about
whether
histograms
have
meaningful
sums
or
have
monotonic
counts,
or
you
need
two
more
bits
of
information
for
meaningful
sum
and
monotonic
count,
but
they
go
in
the
histogram
field,
not
the
data
point
field.
F
Can
we
agree
that
if
we
put
some
bit
up
at
the
histogram
level,
that
says
that
this
is
a
non-monotonic
instrument
or
that
the
sum
is
non-monotonic
right?
Are
we
okay
with
that,
and
can
we
get
a
like?
I
I'm
happy
to
throw
together
that
pr
and
get
that
out
the
door
I
just
want.
I
want
us
to
make
progress
and
we
have
a
lot
of
cooks
trying
to
solve
the
problem
and
different
problems
in
in
different
ways.
So.
E
Yeah
I
had
one
idea:
what
was
to
avoid
adding
a
new
field
in
a
backwards
compatible
way
is
to
take
over
the
temporality
field
of
the
histogram
and
turn
it
into
an
enum.
That
goes
more
ways
because
you
have
really
five
choices.
It's
gauge
like
histogram,
or
is
it
sorry?
It's
two.
That's
not
true.
They're
independent.
I
don't
take
back
what
I
said
you
know
like.
There
are
three
fundamental
measurement
types
and
then
there's
two
temporalities.
G
E
F
Histogram
and
we
keep,
we
keep
diving
into
a
bunch
of
interrelated
issues.
Again.
My
question
is:
if
we
we,
this
is
currently
a
problem
today,
so
either
we
need
to
change
the
specification
to
say
we
do
not
allow
non-monotonic
measurements
for
histograms
flat
out.
Like
that's
one
solution,
you
mean
not
non-negative
or
non-negative
yeah.
We
don't
allow
negative
measurements
at
all
when
we
make
histograms.
F
So
that's
that's
something
we
could
do
to
fix
the
current
bug
and
then
we
can
come
back
and
try
to
find
a
way
to
relax
that
going
forward.
But
given
how
protocol
buffers
work
that
I
had
forgotten
about-
and
I
apologize
for
this-
the
previous
solution
that
I
added
to
say
that,
like
this
isn't
filled
out
when
there
are
negative
measurements,
is
not
actually
going
to
fly
right,
that's
not
good
enough,
so
we
either
have
to
disallow
negative
measurements
going
forward
or
we
need
some
way
to
denote
that
the
histogram
had
negative
measurements.
G
And
I
would
do
it
as
we
do
in
the
sum
as
a
property
of
the
histogram
that
has
negative
measurements
or
has
negative
whatever
we
call
it.
It's
probably
monotonic
is
not
it's
not
the
right
thing
or
no
negative
values
or
not
or
or
only
positive
or
whatever.
You,
I
think,
is
not
negative
that
you
care
about.
So
I
would.
I
would
go
with
that,
because
it
makes
things
look
more
similar
with
some
and
consistent
with
some.
F
That
also
pairs,
if
we
ever
have
max
min.
E
E
The
reason
why
so
so
as
I
was
trying
to
say,
if
we
model
histogram
as
having
like
three
flavors,
one
is
for
counter
ones
for
up
to
encounter
one's
for
gauge
the
difference.
The
question:
if
you,
if
you
have
a
counter
event
going
in
then
you
have
a
monotonic,
sun
and
monotonic
counter.
If
you
have
an
up
down
counter
going
in,
you
have
a
non-monotonic
sun
and
if
you
have
a
gauge
going
in,
you
don't
have
a
sum.
That's
the
definition
of
a
gauge.
E
F
E
Either
like
we're
talking
about
whether
the
histogram
contains
positive,
only
values,
because
deltas
went
in
we're
talking
about
counter
events,
they're
delta,
so
a
counter
event
means
non-negative
event
and
an
up
down
counter
event
means
a
number
that
you
can
add
up.
That
might
be
positive
or
negative.
So
the
it's,
the
up
down,
flavor
left
on
counter
flavor
of
histogram
versus
the
counter
flavor
of
histogram
versus
the
gauge
flavor
instagram
and
just
to
make
sure
bowden,
doesn't
think
I'm
ignoring
gage
histograms.
E
Here
I
want
to
point
out
that
much
like
with
count
like
we
have
a
conversion
from
the
synchronous
up
down
counter
into
asynchronous
up
down.
Compounder
ie
cumulative
up
down
counter,
which
is
essentially
saying
like
like
models
of
queue
where
you
have
things
entering,
and
you
have
things
exiting
this
gauge.
Histogram
concept
which
keeps
coming
up
is
poorly
understood,
but
I
think
we
can
model
it
very
well
by
modeling
it
as
a
histogram
that
has
up
and
down
counting
operations.
E
The
opposite
of
observe
is
unobserved
and
over
time.
If
you
have
a
histogram
counting
things,
you
can
observe
them
and
then,
when
they
they
disappear
from
your
gauge.
Histogram
set
that
then
you
unobserve
them.
That's
the
synchronous
model.
The
cumulative
model
of
that
gives
you
a
gauge
histogram,
the
one
that
that
everyone
knows.
E
I
I
feel
like
that's
a
really
good
way
to
model
that
that
stuff
and
it
it
models
orthogonally
with
the
stuff
that
we're
talking
about
so
histogram
then
can
have
one
of
three
types
of
flavor.
In
addition
to
temporality,
and
then
there's
this
other
bit,
which
says
actually
these
counts,
the
histogram
counts
are
not
monotonic,
it
counts,
rise
and
fall.
That's
what
a
gauge
histogram
is
so
depending
on
the
the
flavors
of
histogram.
E
I
think
now,
there's
like
very
many
of
them,
but
it
corresponds
with
the
fundamental
types
and
whether
you
can
have
a
monotonic
count,
which
is
over
time,
meaning
you
can
do
rates
on
this
histogram
or
whether
you
don't
have
them
on
monotonic
count,
which
is
like
you're
an
up
down
counter,
and
you
only
have
a
current
value.
That's
your
gauge!
Histogram!
E
E
That
wants
us
to
tell
up
tell
them
when
a
sum
is
monotonic,
when
I
want
to
tell
them
when
a
sum
is
also
non-monotonic
and
there's
a
there's
three
ways
that
that
can
be
not
just
two,
so
I
I
kind
of
object
to
having
a
some.
Some
is
non-negative.
I
I
want
to.
I
want
to
know
whether
it's
a
measure,
the
measurements
that
are
captured
or
up
down,
counts
or
accounts
so
pages.
F
The
the
question
is
so
we
we
have
an
issue
with
our
spec
there's
a
bug
in
our
spec
that
victor
pointed
out.
I
want
a
resolution
to
that
bug
that
helps.
People
understand
how
to
make
use
of
this.
You
are
100
correct.
The
whole
reason
we
made
this
change
was
so
we
know
how
to
export
to
prometheus
correctly.
That's
the
only
reason
we
made
the
change
at
all,
so
we
could
say
you
know
what
we
don't
care.
We're
going
to
live
with.
F
The
bug
makes
me
a
little
uncomfortable,
but
it's
fine,
and
that
will
figure
this
out
later
and
that's
the
resolution
right
now
or
I
can
go
in
and
just
say
for
now.
F
If
you
see
a
sum
at
all,
like
sums
will
always
be
monotonic
in
this
histogram
right
and
we,
if
you
misuse
it,
that's
on
you
as
a
as
an
implementation,
and
we
can
expose
the
capability
for
non-monotonic
sums
going
forward
in
different
ways.
I
think
that
you're
right
there's
a
lot
of
discussion
to
have
here.
F
E
E
I'm
sorry,
then
then
that
means
the
protocol
will
sit
well
for
now.
The
the
current
histogram
will
always
have
a
meaningful
sum
that
will
be
non-negative.
Then
hotel
will
be
restricted
to
histograms
that
take
non-negative
measurements.
For
now,
until
we
agree
to
extend
the
data
model,
extend
the
histogram
point
to
include
those
variations
hopefully
and
the
model,
hopefully
the
model.
The
way
I
like-
or
you
know
at
least
one
way,
so
if
the.
F
E
F
It's
not
this.
The
the
finding
agreement
for
that
particular
issue
is
not
a
high
priority
for
me
over
the
sdk.
I
just
want
to
not
have
a
specification
that
is
broken,
that
people
can't
follow.
That's
that's
the
main
thing
like
if
people
start
producing
histograms
that
you
literally
cannot
read
correctly
or
accurately,
we
have
a
problem.
So
so
that's
what
I
want
to
solve.
E
Would
anyone
here
object
to
one
new
enum
on
histogram
that
has
values
zero,
one
and
two
corresponding
with
counter
up
down
counter,
engage
and
and
prescribe
like
just
tells
you
if
this
is
zero,
it
means
sum
is
meaningful.
E
So
you
record
the
instrument
that
was
used
to
make
the
histogram
I
I
kind
of
like
it.
Well,
it's
it's
logically,
the
instrument
that
was
so
that
if
you
converted
a
counter
a
gauge
or
a
or
well
sorry
there's
you
invert.
E
I
just
used
the
word
gauge
like
it's
a
synchronous
instrument
which
is
sort
of
doesn't
doesn't
have,
but
but
we,
but
we've
talked
about
it
enough
that
we
all
know
what
I
mean.
So,
if
you
record
take
one
of
those
counter
up
down
counter
or
gauge
instruments
and
translate
it
into
a
histogram,
it
would
carry
exactly
the
type
of
information
that
we
were
just
talking
about,
and
it
would
tell
you
whether
some
is
meaningful,
monotonic
or
not.
E
Oh
yeah,
I
would,
I
would
definitely
support
that
and
I
was
trying
to
like
rationalize
it
with
lengthy
documents.
I
don't
think
anyone
wants
to
read
it.
That's
otep156
and
it
was
like
the
bottom
of
my
bottom
of
my
list
so
because
of
histograms
and
sampling
it's
time
to
eat
lunch,
everybody
or
whatever
time
of
day
it
is.
I'm
hungry
I'll,
see
you
all
later.
I
I
would
be
happy
to
make
this
proposal,
but
I'm
feeling,
like
I've,
got
two
other
higher
priority.
Things
way.