►
From YouTube: 2021-08-10 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
I
have
three
topics,
one
is
regarding
the
exposure
pr.
I
I
got
some
technical
issue
that
my
my
clone
repo
has
some
corruption,
so
I
I'll
share
my
screen
and
quickly
go
through
the
changes
and
get
some
feedback,
because
I
I
have
questions
and
I'll
polish
the
pr
and
fix
the
technical
issue.
On
my
side
there
are
two
other
pr's,
so
one
is
from
victor.
He
like
he
started
a
new
pr,
try
to
take
the
major
feedback
about
and
another
pr
is
currently
marked
as
draft
from
josh,
and
we
can
talk
about
that
later.
B
Would
you,
and
that
for
the
agenda
will
cover
that
sure?
Thank
you,
okay,
so
for
the
exporter,
if
you
can
see
my
screen,
let
me
see
if
we
can
make
it.
B
B
The
structure
is
very
similar
to
the
the
trace
spec.
However,
there's
a
there
are
two
things
that
are
special
to
the
matrix
part
number
one
is
we
need
to
define?
What's
the
data
type
and
I
believe
our
current
thinking
is,
the
data
type
should
be
a
representation
like
a
per
language
representation
of
how
otlp
models
the
data.
B
So
I,
instead
of
trying
to
declare
that
in
like
the
details,
I
would
just
have
some
very
high
level
like
information
saying
this
is
the
language
choice
as
a
the
native
representation
of
otlp,
without
specifying
any
detail
like
later.
If
we
want
to
add
something
otlp,
we
can
do
that.
Would
folks
be
okay
with
that.
C
The
only
thing
I
want
to
call
out
sorry,
sorry,
it
was
a
little
late
to
this.
The
only
thing
I
want
to
call
out
is
so
in
tracing.
This
is
also
true
resource
and
instrumentation
library
in
open
in
otlp.
C
You
have
this
notion
of
resource
metrics
and
then
instrumentation
metrics,
and
then
you
have
the
actual
metrics
metrics
right
and
we
might
actually
flatten
that
in
practice
which
is
kind
of
standard
intrigues,
so
I
am
totally
on
board
with
like,
let's,
let's
let
languages
decide
the
right
way
to
format
that
you
might
want
to
call
that
out
of
like
here's,
what
most
languages
did
with
trace
and
we're
probably
gonna.
You
know
this
is
a
similar
thing
for
for
metrics.
C
Okay,
the
the
only
reason
that's
important
is
the
the
actual
interface
for
an
exporter.
C
Does
it
take
a
resource
as
an
argument,
or
is
that
bundled
in
like
the
list
of
of
metric
data,
that
it
gets
right
and
if
it
is
bundled
in
there
are
we
bundling?
Are
we
pre-aggregating
or
pre-uh
grouping
the
metrics
based
on
meters
and
resource.
B
B
It
okay,
so
so
here
we're
saying:
the
exporter
must
support
two
functions,
export
and
shutdown
force
flash
is
not
required,
although
it's
mentioned
here.
I
believe
it
is
due
to
the
history.
So
initially
when
we
released
the
spec,
we
only
asked
for
two
force
flash
was
added
later
and
that's
why
for
compats,
this
is
a
nice
to
have,
but
not
mandatory
for
matrix.
B
Okay
and
the
the
biggest
trouble
I
have
is
force
flash
because
false
flash
from
semantic
perspective.
It
only
makes
sense
for
push
export
like
when
you
send
that
to
like.
When
the
sdk
is
actively
sending
that
to
the
destination,
then
you
can
force
flash.
So
what
I'm
trying
to
do
is
from
the
top
level
description.
If
you
look
at
the
exporter
interface,
I
still
try
to
inherit
the
spirit
from
tracing.
Everything
is
basically
worded
the
same
way
as
tracing
past.
B
B
Another
possible
approach
is
we
don't
try
to
restrict
this?
For
example,
people
say
someone
called
force
flash
and
the
exporter
is
still
busy
trying
to
reply
to
the
scraper.
Then
the
flash
can
wait
and,
for
example,
you
can
block
for
a
few
seconds
until
that
http
response
has
finished
the
new
return
that
that
might
be
a
good
idea,
but
I
I
I'm
not
seeing
huge
benefit
and
I
I
think
that's
been
to
create
confusion.
So
here's
my
proposal.
C
So
I
think
the
use
case
that
we've
seen
for
force
flush
from
open
census
has
been
like
cloud
function,
function
as
a
service
style
compute,
where
you
need
to
get
metrics
out
when
the
thing
is
killed
so
flushing
on
shutdown
and
force
flushing,
and
that's
that's
like
specifically,
an
area
that
pool
metrics.
C
D
I
feel
like
this
might
be
a
little
draconian
can't
I
mean
if
you're
doing
both
push
and
pull,
and
you
call
force
flush
and
you've
pushed
your
metrics.
I
would.
I
would
have
expected
that
force
flush
just
means
the
next
pull
will
succeed
at
seeing
the
data
that
I
just
flushed.
It
wouldn't
cause
an
error.
That
seems
a
little
surprising
to
me.
B
Yeah
good
topic
that
brings
my
my
last
topic
here.
So
in
memory
exporter,
I'm
trying
to
say
that
your
memories
follow
her
should
support
both
than
the
pool
number
one
question:
do
people
think
this
is
a
good
thing
or
you
think
your
memory
exposure
should
be
push
only
or
pull.
B
Okay,
so
imagine
if
you
write
a
unit
test,
sometimes
people
might
have
some
like
scheduled
projects,
popular
they're,
saying
every
five
seconds:
harvest
the
metrics
and
send
that
to
the
memory
exporter,
and
then
they
will
check
some
status
like
a
list
or
something.
But
the
problem
is
you
have
to
handle
the
timing,
the
building
of
full
exporter?
Is
you
can
report
all
the
measurements
as
much
as
you
can
and
after
you
think,
you're
done.
B
You
just
call
the
like
the
pool
metric
exporter
using
the
sdk
you're
saying
I
want
to
harvest
the
matrix
and
that's
at
that
point.
It
gets
everything
that
has
been
reported
so
far.
So
it's
very
predictable.
D
That's
what
I
was
trying
to
say
is
that
flush
puts
the
data
into
an
in-memory
place
where
a
pull
exporter
can
get
it.
That's,
that's
my
that's
what
I
would
expect
it's
almost
it's
almost
like
language-wise
calling
a
pool
exporter.
An
exporter
is
hard.
It's
not
really
an
exporter.
It's
a
that's!
That's
why
we're
getting
into
trouble
here.
I
think
that
if
we
described
pull-based
exporters
as
an
operation
over
the
in-memory
exporter,
which
which
makes
sense
as
a
as
a
terminology,
then
we
would
get
out
of
this
trouble.
C
D
B
D
But
which
pr
were
you
referring
to
just
now.
B
B
D
I
would
like
to
talk
about
that
pr
anyway,
I
was
looking
at.
I
was
looking
at
the
pr
and
I
couldn't
respond
to
it
in
github
today,
because
github's
down,
but
I
but
josh's
last
comment
was
something
like
want
to
confirm
a
few
points
and
I
feel
like
conflict
here.
So
the
point
was
josh
wrote,
default,
aggregation
for
synchronous
instruments
is
delta
right
now,
not
cumulative,
and
I
and
that
that
to
me
is
implementation
detail,
because
I
don't
care
how
the
sdk
is
actually
implemented.
D
What
I
do
care
is
the
default
sdk
that
we
put
together
works
for
prometheus
and
if
it's
like
delta,
is
not
the
default
outcome,
and
I
I'm
not
sure
how
to
write
this
down
in
our
specs,
but
but
what
we've
done
is
say
that
the
api
for
synchronous
instruments
receives
deltas
and
that's
not
saying
anything
about
how
you
aggregate-
and
I
thought
josh
had
said
this
really
well
two
or
three
weeks
ago.
You
know
there's
two
different,
viable
implementation
strategies
here
and-
and
I
anytime
we
say
something
about
the
aggregator.
D
It
seems
that
we're
saying
something
about
the
default
implementation
strategy
and
that's
not
what
we
want
to
do
right
anyway.
I'm
just
trying
to
say
I
don't
think
that
the
default
aggregation
should
be
delta.
The
default
behavior
should
be
cumulative
and
it
doesn't
matter
how
you
aggregate
it
matters,
how
you
implement
the
sdk.
D
C
Exactly
what
I
wanted
to
call
at
that
point
is,
I
actually
think
the
the
default
aggregation
should
probably
start
as
cumulative,
and
you
should
have
to
opt
into
delta.
Specifically,
if
we
think
about
this
aggregator
configuration
as
I
configure
a
view,
and
I
get
metrics
out
of
an
exporter
right.
So
what
do
my
exporters
see?
The
default
should
probably
be
cumulative
to
start
with.
D
And
you
opt
into
delta
and
the
implementation
of
that
is
to
have
a
sort
of
store
and
forward
where
I'm
calculating
deltas
over
short
periods
and
then
adding
them
together.
And
that's
how
I
get
cumulative
and
victor's
point
that
I
learned
something
from
is
that
you
could
totally
rearrange
your
sdk
and
do
it
differently
and
have
your
deltas
and
have
your
cumulative
aggregators
be
computed
right
away
on
the
phi.
You
never
get
a
delta
there
and
that's
totally
valid,
but
it
changes
the
memory
and
the
synchronization
and
all
the
management
of
your
data.
C
Yeah,
so
I
guess
the
the
question
I
have
then
is
because
I
I
stated
that,
as
I
think
these
are
implicit
assumptions
in
the
spec
that
I
wanted
to
make
sure
we
we
walk
through
and
agree
on.
My
question
is:
if
we
agree
that
the
default
aggregation
coming
out
of
prometheus
needs
to
be
cumulative
for
these
things,
and
we
agree
that
the
I
don't
know
if
we
agree
on
this,
but
do
we
agree
that
the
default
aggregation
for
otlp
should
also
be
cumulative.
C
C
I
would
argue
that
in
the
spec
it
should
say
the
default
aggregation
from
the
spec
perspective
would
then
be
cumulative
for
all
the
metrics.
C
Specifically
because
again,
the
specification
should
focus
on
the
configuration
that
goes
in
from
the
user
and
the
metrics
that
come
out
in
the
exporter,
or
that
the
exporter
sees
right.
There's
an
open
question
of
how
we
want
to
deal
with
an
exporter
that
gets
delta
metrics
and
can't
deal
with
it.
I
think
that's
one
of
my
other,
like
points
that
I
talked
about
that
I
think
is
not
addressed
in
the
pr.
Nor
do
I
think
we
should
address
it
in
that
pr.
C
I
think
we
need
a
whole
pr
to
address
exporter
influence
of
aggregation,
but
I
did
want
to
call
that
out,
like
that's.
That's
a
whole
thing
that
we
had
talked
about
a
whole
bunch,
it's
not
in
the
pr
I'm
I'm
kind
of
happy
with
it,
not
being
the
pr
and
we
say
cumulative
by
default
for
now,
and
then
we
can
talk
about
exporters
influencing
default,
aggregation
temporality.
C
As
like
a
follow-on
thing,
I
had
a
third
point
too.
I
need
to
go
look
at
what
it
was
come.
C
D
B
C
Yeah
but
but
it
also
means
that
the
collector
can
ignore,
dropped
points
because
it
has
cumulative
points.
So
by
default
it
has.
It
has
some
nice
properties
around
guaranteed
delivery,
where
we
don't
have
to
worry
about
it
as
much
I
mean
you
still
have
those
missing
points,
but
it's
not
as
dangerous
as
say:
deltas.
D
D
B
Do
you
think
that
the
the
collector
could
do
the
delta
to
cumulative
conversion,
and
we
have
a
way
of
reporting
missing
data?
Then
we
would
have
confidence
that
the
conversion
is
accurate,
or
you
think
that
this
is
some
problem,
although
we
can
solve,
but
technically
it
wouldn't.
Work
like
just
accumulate
by
default
would
be
much
easier
to
handle.
B
D
But
having
limited
cardinality
and
high
memory
usage,
it's
just
a
choice
you
get
and
because
of
prometheus
is
the
dominant
ecosystem.
We
make
that
choice
by
default
to
go
with
cumulative,
but
many
vendors
support
deltas
and
I'm
hopeful
that
the
open
source
ecosystem
will
begin
to
support
deltas.
D
C
Yeah,
just
to
echo
on
that,
I
think
I
think,
there's
trade-offs
on
both
sides
that
need
to
be
made,
like
neither
side
is
a
panacea
of
right
and
at
this
point,
bouncing
on
in
favor
of
being
prometheus
compatible
is
how
we've
been
leaning-
and
I
totally
agree
with
josh
that
if
we
could
get
to
a
point
where
deltas
were
the
optimal
way
to
go,
that
would
be
ideal
from
our
own
overhead
standpoint.
C
You
know
if
we
were
only
exporting
deltas,
we
could
actually
really
minimize
the
cost
of
using
our
sdks
and
that's
there's
some
power
there
right,
but
then
there's
a
whole
slew
of
other
problems.
We
have
to
deal
with,
so
it's
it's
balancing
the
two,
and
until
until
the
databases
don't
or
handle
those
problems
for
us,
we
have
to
handle
them
with
cumulatives
a
little
bit
specifically
like
prometheus.
So
anyway,
I
I
still
think
cumulative
is
default.
Is
the
right
way
to
go.
C
Yeah
yeah
it
just
loaded,
okay,
so
the
last
one
is
the
public
names
that
we
expose
in
the
sdk
right.
Now
we
have
there
it's
exposing
the
name
of
gage,
the
name
of
sum
and
the
name
of
histogram,
where
gauge
means
keep
the
last
value
sum
just
means
add
up
points
and
histogram
means
fixed
bucket,
histogram.
C
The
reason
I
raise
this
is
if
we
want
to
provide
other
types
of
aggregators
that
are
not
last
value.
Aggregator
that
produce
some
metrics.
Do
we
think
that's
going
to
be
confusing?
Is
that
worth
talking
about?
The
second
thing
is
for
histogram:
do
we
want
to
use
a
name
in
the
view
api
that
that
is
explicitly
fixed
bucket
histogram
so
that
we
have
freedom
to
change
to
the
new
type
of
histogram
or
prototype
the
new
type
of
histogram
without
overloading
the
word
histogram,
so
that
it
only
means
fixed
bucket
right?
C
B
But
I
think
so
I
I
I
would
guess
that
histogram
can
be
arbitrary
buckets
and
there
can
be
a
special
case
table.
For
example,
if
you
specify
something
every
explicit
boundary,
then
it
should
work
and
of
course
you
can
model
exponential
buckets
in
this
way,
but
you
won't
be
able
to
get
all
the
benefits
and
then
you
can
special.
You
can
special
case
that
if
it's
exponential
buckets
and
especially
with
space
two,
then
you
have
hyper
performance,
but
the
model
shouldn't
just
assume
that
everything
will
be
obviously
buckets
or
it
will
be
exponential.
D
I
agree,
I
think
the
the
term
histogram
should
just
mean
I'm
doing
something
with
histograms
because
likely
the
the
sdk
or
the
distribution
or
the
there
will
have
an
ideal
default
and
you
you
may
not
even
have
the
code
linkedin
for
some
other
type
of
histogram.
You
know
you
may
only
have
one
or
two
options
and
I
think
any
histogram
is
probably
what
is
what
is
meant
in
the
view
and
if
we
want
to
get
more
specific,
I
think
then,
like
it's
a
sub
option.
C
Okay,
so
so
to
clarify
in
in
the
you
know
in
the
proposal
you
would
say
you
know
create
view,
here's
my
instrument,
selection
criteria
and
then
I
want
to
aggregate
as
a
histogram,
and
here
are
my
fixed
buckets
as
options
right
or
or
would
we
say
I
want
to
aggregate
as
a
fixed
bucket
histogram
and
here
are
the
options
you
see.
You
see
what
I
mean
with
the
difference
versus
just.
I
want
to
aggregate
as
a
histogram
with
no
options
and
then
the
sdk
is
free
to
choose
what
that
looks
like.
B
C
Okay,
so
what's
interesting
here,
then,
is:
do
we
feel
like
we
have
room
with
the
current
option
strategy
to
say,
like
you
can
define
a
histogram
where
you
have
these
fixed
buckets
or
we
have
another
optional
configuration
parameter
in
the
future.
We
can
put
there
that
allows
this
automatic
bucketing
strategy
or
some
some
form
of
some
other
form
to
sketch
right.
The
logarithmic.
D
Thing,
for
example-
and
I
see
your
point,
it
sort
of
makes
it
more
difficult
to
spec
out
what
the
options
look
like,
because
you're
saying
histogram
and
then
you've
got
some
explicit
bucket
options
which
imply
a
explicit
aggregation
and
you've
got
some
like
exponential
options
which
imply
an
exponential
and
then
what
do
you
want
to
do?
What
happens
when
you
add
a
third
or
whatever
yeah
the
spec
becomes
a
little
bit
more
murky.
I
guess,
but
the
user
doesn't
have
to
think
about
what
kind
of
histogram
they're
getting
which
probably
they
don't.
B
Yeah,
I
can
imagine
in
python,
you
just
have
something
like
a
bucket
equal
tool
and
you
can
put
an
array
which
is
the
access
list
bucket.
If
you
want
to
put
some
specific
type,
then
you
can
do
the
right
click
and
figure
out.
This
is
the
base
tool
exponential
buckets
or
you
can
put
something
as
like:
smart,
like
smart
buckets
or
something
like
the
isd,
will
automatically
figure
out.
What's
the
best
option
for
you.
D
We
spec
out
long
names
for
all
the
aggregators
and
then
have
like
spec
abbreviations.
That
say
like.
If
you
choose
the
term
histogram,
it
means
best
available
or
like.
C
Yeah
yeah
so,
like
I'd,
say,
use
the
word
gauge
sum:
histogram.
The
sdk
has
freedom
to
pick
the
right
aggregator
for
that
thing.
But
if
you
say
I
want
fixed
bucket
histogram,
then
you
know
you're
getting
that
specific
aggregator
with
this
specific
set
of
config.
But
if
you
use
the
word
histogram
you
don't
get
that
control.
C
That
would
be
why
they
have
the
ability
to
use
an
explicit
name
instead.
So
if
you're
going
to
use
the
word,
histogram
you're
just
saying
make
a
histogram
and
I
don't
care
how,
if
you
use
like,
I
want
to
fix
bucket
histogram
and
hear
my
buckets,
then
you're
saying
here's
the
specific
histogram
I
want.
F
E
E
C
In
this
case,
the
the
major
the
major
concern
there
is
the
the
configuration
parameters
of
the
aggregator,
that's
called
histogram.
C
C
I
think
so
I
think
the
difference
here
is
for
some.
We
don't
have
any
alternative
aggregators
planned
that
I
know
of
gauge.
We
might
have
other
aggregators
planned,
so
so
it
might
apply
there,
but
there's
also
no
configuration
for
it
whatsoever
right
now.
So
I
don't
know
if
it's
as
important,
I
think
histogram's,
the
only
one
that
we
have
to
talk
through,
because
we
know
there's
another
implementation
coming.
D
I
think
I
I
mean
might
be
even
more
general
than
that.
Can
you
imagine
any
other
aggregators
for
some
that
don't
compute
a
sum
I
mean
is
it?
Are
you
thinking
of
like
there's
the
one
that
uses
atomic
operations
and
there's
the
one
that
uses
the
mutex?
That's
the
type
of
thing
we're
talking
about,
they
still
compute
the
same
result,
whereas
with
histograms.
It's
just
that
space
is
so
big
that
we
that
it's
easy
to.
Imagine
other
alternative
implementations.
It's
it's
not
so
easy
with
some
engage.
A
I
think
for
the
histogram,
the
problem
is
the
representation
at
the
end,
how
this
histogram
is
represented.
For
example,
the
hdr
is
to
run
high
dynamic.
Crunch
instagram
has
has
a
different
representation
of
early
a
bucket,
a
bucket
based
instagram,
where
the
bucket
is
fixed.
A
So
the
that
mean
that
if
you
are
an
exporter
and
you
specify
a
different
representation
at
the
end,
the
back-end
and
the
intermediary
system
have
to
understand
this
representation.
Otherwise
they
will
not
be
able
to
do
anything
with
it.
D
I
see
so
you're
you're
propos
you're,
pointing
out
that
that
you
don't
really
care
what
the
aggregator
is,
whether
because
you
care
what
the
data
point
type
you
get
out
is,
and
that's
that's
a
legitimate
point
like
whether
the
view
should
state
the
type
of
histogram
data
that
you
get.
A
D
Well,
at
the
moment,
we're
expecting
a
second
histogram,
and
so
there
would
only
be
two
and
I
think
the
question
that
we're
facing
right
now
is
whether
to
to
choose
a
histogram.
If,
if
you,
if
you
aren't
so
inclined,
do
you
have
to
say
exponential,
histogram
and
explicit
histogram
or
dj
instagram
and
let
the
compiler
or
like
the
build
rules
whatever
puts
together
the
dependencies,
choose
the
histogram
implementation,
which
then
implies
which
data
point
you're
going
to
get.
D
So,
if
you
just
say
histogram,
and
you
only
link
in
the
exponential
histogram
code,
you're
going
to
get
that
exponential,
histogram
data
out
and
if
you
say
histogram,
and
you
only
link
in
the
explicit
histogram
code,
then
you're
going
to
get
the
explicit
histogram.
And
what
we're
discussing
right
now
is
how
do
you
influence
that
decision
in
in
a
specified
string?
I
guess-
and
I
see
both
being
fine,
I'm
not
sure
I.
C
Care
there's
also
a
practical
bit
right
now
of
I
agree.
Your
back
end
should
influence
what
histogram
you
get
practically.
I
don't
know
if
you
have
a
way
to
do
that.
Yet
just
yet,
and
most
people
are
doing
that
with
configuration
in
libraries
that
support
things.
So
if
we
support
multiple
histograms
to
the
extent
we
can
figure
out
how
to
have
the
back
end
influence
that
we
should,
I
think,
that's
going
to
be
through
some
sort
of
config
based
mechanism
that
will
influence
views
and
default.
C
You
know
when
you
see
this
instrument
use
this
histogram
implementation
that
my
backend
supports.
So
we
still
need
to
actually
specify
how
to
configure
that,
so
the
sdk
can
set
itself
up
appropriately
and
that
influence
should
eventually
come
from
the
back
end
implementation,
but
we
still
have
to
specify
what
it
looks
like.
F
To
death
by
now,
anyone
have
any
other.
Any
other
points,
that's
just
a
more
a
question,
but
would
that
mean
that
you
would
either
have
all
of
your
histograms
in
exponential
histogram
or
all
of
your
histograms
in
explicit
histogram?
Or
would
you
be
able
to
to
mix
and
match
those
two,
because
maybe
you
might
want
to
have
a
like
some
histograms
in
an
exponential
form
and
some
not
an
exponential
form.
C
I
I
think
so
we're
discussing
like
the
full
configuration
of
the
sdk,
and
so,
if
you
look
at
the
what
we
specified
with
views,
you
should
be
able
to
accomplish.
C
Actually
all
of
that,
above
all,
right
like
we
should
be
able
to
select
all
you
know,
instruments
of
a
particular
type
that
are
histograms
and
say
use
this
as
your
default,
and
you
should
also
be
able
to
say
here's
the
specific
set
of
instruments
make
these
this
histogram
and
that's
part
of
view,
configuration
we
haven't
gotten
into
how
the
programmatic
view
configuration
turns
into
say
something
like
a
file
based
configuration
or
a
remote
based.
You
know,
protocol
configuration,
but
that's
that's
kind
of
what
I'm
suggesting
here
is
from
a
specification
standpoint.
B
B
Okay,
exemplar.
C
Yeah
I'll
try
to
make
this
quick,
so
we
can,
we
can
get
to
column
or
data,
so
this
is.
This
is
waiting
on
the
aggregator
pr,
because
there's
a
component
of
this,
where
the
aggregator
we
need
access
to
aggregator
in
some
fashion,
to
determine
exemplars,
so
just
waiting
to
see
what
the
names
of
those
aggregators
will
be.
That's
that's
the
one
of
the
open
things,
but
in
the
meantime
there
are
three
things
raised
in
the
pr
to
talk
through.
One
is:
when
should
we
filter
metric
attributes
on
exemplars?
C
I
honestly
don't
care
either
way
that
that's
if,
if
it
goes
all
the
way
to
the
exporter,
I
think
we
need
to
publicly
expose
some
kind
of
filter
mechanism
on
attributes
to
be
able
to
do
this
filtering
in
exporters
in
our
public
sdk,
but
otherwise
it
doesn't
matter
to
me.
The
second
thing
I'm
gonna
walk
into
real
quick
is
we
have
two
ways
of
filtering
or
or
sampling
measurements
in
the
spec?
C
One
is
a
it's
just
a
filter
of
should
this
be
eligible
for
sampling
and
the
only
reason
this
exists
is
to
make
it
easy
for
users
to
turn
on
to
turn
off
sampling
of
reservoirs
or
of
exemplars
to
turn
on
sampling
that
is
attached
to
traces
that
are
sampled
or
to
just
sample
any
possible
measurement.
C
The
the
expectation
here
is
that
that
hook
is
mostly
important
for
sample
exemplars,
with
traces
that
are
sampled
or
turn
this
whole
thing
off,
and
it's
just
like
that
binary
flip
is
the
only
important
bit
of
the
filter.
The
reservoir
will
also
make
additional
sampling
decisions,
and
so
we
actually
have
two
pieces
here
making
sampling
decisions
that
was
raised
as
a
why?
Why
does
this
exist?
What's
it
for
so
explicitly?
That's
why?
So?
We
can
make
this
on
off
decision
with
traces
or
everything,
and
then
so.
The
reservoir
can
do
additional
sampling.
C
Just
from
practical
need
standpoint.
We
don't
want
to
be
sending
every
single
sample
measurement
from
a
trace
for
a
sum,
for
example,
that's
probably
way
too
much
data,
so
the
notion
of
reservoirs
gives
us
a
fixed
memory
cost.
That
is
that's.
That's
the
idea
behind
these
two.
So
that's
an
open
question.
If
we
want
to
walk
into
that
now,
we
can.
C
We
can
also
comment
on
the
pr,
and
the
last
thing
was:
does
the
default
of
always
allowing
does
the
default
of
always
having
exemplars
and
only
sampling
where
traces
are
sampled.
Does
that
make
sense?
C
Those
are
the
three
open
questions.
I
don't
know
if
you
want
to
walk
into
any
of
them
now
or
whatever,
but
I
I
hope
to
see
more
comments
on
the
pr
around
those
three
and
as
soon
as
the
aggregator
pr
is
in.
I
will
open
that
up
for
for
more
review.
D
So
to
summarize,
yours
you're
asking
whether
we
all
agree
that
the
default
should
be
sample.
Only
events
interfaces
sample
only
sampling
on
by
default,
and
I
think
you
were
looking
for
one
more
constraint
and
I
would
propose
that.
It's
like
one
example
or
per
point
report
period,
and
that
says
that
you'll
get.
D
I
mean
at
least
one
so
that
histograms
can
have
one
per
bucket,
but
sums
and
gauges
could
give
you
one
example
and-
and
it
seems
like
that,
might
be
controversial
there
because
there's
prometheus
infrastructure,
it
hasn't
been
built
to
do
this
who's
going
to
care
about
the
example
of
a
gauge
that
may
not
matter
to
anybody.
But
the
sum
example
is
well-defined.
C
C
You
have
one
example
per
thing:
I'm
actually
not
suggesting.
We
only
have
one
per
point
at
all.
I'm
leaving
that
unspecified.
You
can
decide
your
reservoir.
How
big
you
want
to
make
it
if
you
want
to
have
two
per
sum:
that's
fine
like
if
I
want
to
do
min
max
sampling
on
sums
or
on
gauges.
That's
fine
as
well,
that
is
that
is
left
unspecified.
That's
up
to
you.
C
C
Min
max
example,
our
sampling
totally
fine
on
every
point.
That's
fine!
That's
that's
allowed
in
the
spec.
It
does
expose
that
reservoir
interface
to
users
to
define
their
own.
B
And
regarding
the
first
question,
I'm
guessing
the
exemplar
data
point
will
be
very
similar
to
the
span
event
and
if
people
have
the
logins
back
later,
it
might
be
similar
to
the
log
record
as
well,
and
my
word
is
at
least
I
don't
want
to
see
the
exporter
having
some
filtering
mechanism,
because
that's
not
like
what
the
exporter
is
supposed
to
do
and
also
we
give
individual
vendor
flexibility
to
implement
their
exposure.
So
I
can
imagine
eventually
it
will
diverge.
B
I
want
that
to
be
part
of
the
core
icp
functionality
and
whether
we
have
like
five
different
processors
or
we
can
combine
them.
I
I
think
it
might
take
extra
time.
So
my
question
is:
if
we
just
like,
tell
people
we're
going
to
give
all
the
attributes
to
the
exporter
and
by
default,
we'll
export
that
to
premises
and
otlp,
and
if
the
feedback
people
think
some
they're
too
costly
to
collect
or
is
privacy
concerned,
they
want
to
change
or
they
want
to
alter
that.
We
will
cover
that
later.
C
Sense,
the
data
model
already
requires
that
the
otlp
has
filtered
attributes,
so
we
can
provide
all
the
attributes
to
the
exporters,
but
at
least
for
otlp
we'll
have
to
filter
them
down
further
for
prometheus.
I
looking
at
the
implementation-
I
I
don't
know
yet
whether
or
not
in
practice
labels
will
be
filtered.
C
C
So
so
riley,
I
think
we
might
be
spending
too
much
time
on
this.
You
can
always
get
back
all
the
attributes,
because
the
metric
data
point
has
a
set
of
attributes
and
the
example
just
has
the
attributes
which
are
different
than
the
metric
data
point,
so
you
should
always
be
able
to
take
the
metric
data
point
in
the
exemplar
and
restore
every
attribute
like
this
is
just
a
compression
technique.
The
only
open
question
here
was:
when
does
that
happen?
Does
that
happen
in
the
sdk?
Or
do
we
push
that
onto
do?
C
A
Okay,
can
I
show
the
screen.
A
Okay,
so
very
quick
introduction,
so
I'm
lauren
kirell,
I'm
new
in
this.
A
Kind
of
meetings
I
already
met
some
of
you
like
josh
and
josh,
basically
so
the
let's
start
with
the
motivation
behind
this
benchmark.
I
did
and
in
order
to
demonstrate
what
we
could
do
to
improve
the
representation
of
multi-diet
time
series
and,
to
some
extent,
the
representation
of
traces
and
logs
in
general,
so
at
f5,
so
I'm
working
at
f5
and
we
are
producing
a
lot
of
multivariate
time.
Series
mutilate
time.
Series
means
that
we
have
multiple
matrix
related
together
for
the
same
timestamps.
A
So
a
good
example
of
that
is
the
x
y
mouse
move.
When
you
move
the
x
and
y
move
together,
there
is
no
real
interest
to
just
observe
x
and
y
separately,
and
we
can
imagine
many
many
multi-time
series
like
that.
A
multivariate
time
series
like
that,
so
the
problem
with
the
existing
open
telemetry
protocol
is
there
is
no
real
support
for
multivariate
time
series
that
is
efficient.
A
We
need
to,
obviously
we
can
represent
them,
but
to
represent
them.
We
have
to
create
multiple
universe,
time
series
so
one
for
x,
one
for
y,
and
you
can
imagine
that
you
have
to
do
that
when
you
have.
Let's
say
for
a
server
something
like
12
metrics
combined
together,
you
have
to
create
12,
univariate
time
series
the
the
problem
with
that
is
most
of
the
time.
Every
univariate
time
series
will
share
the
same
context.
A
A
So,
for
example,
we
are
talking
about
processors,
some
intermediary
processing.
If
they
have
to
work
on
the
multivariate
level,
they
have
to
recombine
those
univariate
time
series
together
in
order
to
apply
some
modification.
If
you
have
a
backend
that
is
able
to
store
and
process
the
multivariate
time
series
again,
you
have
to
join
again
this
information
together.
A
A
So
the
experiment
I
did
is
comparing
hotel
v1,
like
we
have
for
the
the
current
prototype
specification
compared
with
a
version
of
it.
That
represents
events
and
you
can
map
every
mutilate
time
series
on
events
and
for
those
event,
we
have
a
columnar
representation.
So,
instead
of
having
one
row
per
event
or
one
row
per
matrix,
we
have
multiple
columns
and
every
columns
were
present.
A
So
every
request
every
columns
represent
one
of
the
metric
of
this
multivariate
time
series
and
the
same
thing
for
the
labels,
and
you
have
arrays
like
that.
A
So
for
a
batch
you
will
get,
for
example,
for
multivariate
time
series
with
six
labels
and
six
matrix,
you
will
get
only
12
arrays
six
for
the
labels
and
six
for
the
matrix,
and
that's
it
so
in
term
of
even
in
term
of
memory
allocation,
it's
more
much
more
efficient
because
you
just
have
to
to
instantiate
12
arrays
instead
of
instantiate.
The
number
of
events
multiplied
by
the
number
of
dimensions,
plus
the
number
of
metrics,
so
the
second
implementation
columnar
based
fully
implemented
in
protobuf.
A
A
Okay,
so
the
results
and-
and
we
can
go
in
the
detail
in
the
next
sections
of
this
document-
let's
say
that
this
one
represents
one.
Currently,
the
the
results
are
for
a
typical
mutilate
time
series
something
about
18
times
faster
for
this
representation
and
46
times
faster
for
this
representation.
A
So,
as
you
see,
the
difference
is
huge.
Obviously,
it's
huge
because
we
have
a
lot
of
redundancy
when
we
are
talking
about
multivariate
time
series.
The
difference
will
not
be
that
big
when
we
are
talking
about
traces
and
and
logs.
That
really
depend
also,
obviously
on
the
type
of
the
traces
and
logs
you
have.
If
you
have
some
kind
of
duplication,
then
you
will
see
the
difference.
A
If
the
number
of
duplication
is
very
minimal,
then
you
will
be
close
to
one,
but
we
will
gain
that
the
gain
will
still
be
there,
because
we
have
a
lot
less
memory.
Education,
the
serialization
will
be
faster
and
better.
So
at
the
end,
I
think,
even
for
traces
and
logs,
we
have
some
win
any
question
on
that.
A
Okay,
so
the
the
scenario
of
the
the
bench
I
try
to
to
create
a
bench
where
every
steps
are
represented
from
the
collection
of
the
information.
So
we
collect
a
batch
of
information
batch
of
multivariate
time
series.
We
create
a
batch
create
a
batch.
We
process
the
batch,
so
this
one
will
represent
basically
a
processor
doing
something,
for
example,
doing
some
aggregation
or
doing
some
filtering
and
serialization
step
a
compression
step,
the
compression
deseriation.
A
So
here
you
have
the
otd1,
the
errors
bugs
are
represented
vertically
there
and
you
have
for
the
red,
the
hotel,
columnar
and
the
green
is
the
hotel
arrow.
So,
as
you
see
in
terms
of
total
time
for
all
this
tape,
the
the
difference
is
huge
and
arrows
is
the
for
the
arrow-based.
Our
presentation
is
the
pure
winner.
A
A
I
think
that,
as
you
are
all
aware
closer
when
you
have
to
compute
something
and
when
the
data
is
collocated
in
a
continuous
area
of
memory,
then
you
you
get
the
full
benefits
of
the
the
different
cpu
cache,
optimization
and
acceleration.
A
So
the
batch
processing
also
will
will
be
faster
just
because
we
have
organized
the
information
in
a
way
that
is
more
friendly
for
the
cpu
and
the
memory
for
the
serialization.
It's
the
same
thing,
because
we
have
a
single
array:
it's
just
a
copy
boom
and
we
can
put
that
in
the
on
the
on
the
socket
or
whatever
is
the
the
way
to
to
transmit
this
information
for
the
compression
columnar
data
store
have
been
invented
for
that.
A
A
I
still
have
some
parts
that
need
more
attention
because
they
are
surprising,
but
definitively
what
arrow
did
was
to
really
improve
the
the
time
spent
in
serialization
and
digitalization,
and
even
the
batch
question
is
much
faster.
What
is
surprising
is
the
batch
processing.
I
think
I
have
to.
I
still
have
to
do
some
work
there
to
understand
perfectly
why
I
was
expecting
something
very
similar
to
this
one
or
even
better,
so
take
this
part.
A
We
had
some
discussion
with
bush
and
she
was
with
josh
mcdonald
and
josh
to
regarding
this
multivitamin
representation,
and
the
outcome
was
why
not
representing
for
creating
a
new
type
of
object,
name,
even
that
we
could
use
to
represent
matrix
logs
and
span
all
together
in
a
columnar
or
presentation.
A
So
with
this
benchmark,
we
demonstrate
that
it's
visible
first
and
add
some
good
properties
and
in
terms
of
sdk
evolution.
I
think
what
we
could
do
is
introduce
this
new
event.
We
don't
change
anything
on
the
existing
sdk,
except
that
we
can
add
a
support
for
like
a
switch.
If
you
want
to
use
columnar
representation
that
the
same
sdk
could
be
used,
but
the
representation
of
this
information
will
be
different
and
we
have
a
modification
a
forward
and
backward
compatible
version
of
the
protocol
supporting
this
batch
of
events.
A
The
next
diagram
is
about
more
the
the
decision
that,
in
my
opinion,
we
have.
We
have
two
decisions.
Do
we
want
to
go
in
this
first
representation
based
on
events?
D
Thank
you
very
much.
I
don't
have
questions
that
was
wonderful.
I
speaking
as
a
member
of
tc
think
we
should
review
the
arrow,
I'm
not
very
familiar
with
it,
and
I
think
that
this
is
very
promising.
I
think
we're
out
of
time
to
have
much
more
discussion.
I
really
appreciate
that,
and
I
speaking
as
a
vendor
really
want
column,
wise
or
some
sort
of
efficient
multivariate
encoding,
especially
for
spans,
which
is
another
topic
or
another
forum
to
discuss
how
this
could
really
impact
span
recording
as
well.
D
I
don't
know
that
we
have
any
more
time
to
discuss
it
right
now.
I
think
we
should.
I
think
that
this
should
be
discussed
in
front
of
a
larger
group,
and
I
also
think
we
should
see
a
proposal
for
a
protocol
change.
I
thank
you
very
much.
I
think
we
should
look
for
look
at
moving
this
forward.
Okay,.
C
Right,
I
I
want
to
echo
that,
and
also
thank
you
again
because
now
I
feel,
like
everyone,
can
read
this
and
understand,
what's
going
on
and
and
the
implications,
so
thank
you.