►
From YouTube: 2022-08-30 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
B
C
D
B
So,
okay,
let's
start
thank
you
so
much
for
joining.
Let's
go
over
the
identity.
Gender
I
put
the
first
two
one
there.
The
first
one
is
about
reverting
metric
metric
split.
You
know
which
we
discussed
a
pair
of
times
here
in
speckle.
B
We
got
initial.
You
know,
approval
I
think
we
are
good
to
go.
So
please
take
a
look
at
that.
This
was
the
the
one
blocking
the
release
yeah.
Basically,
the
last
thing
I
raised
there
and
it's
something
that
we
still
don't
know
is
whether
we
should
revert
all
the
splits
all
the
metric,
splits
or
just
the
ones.
That
book
then
mentioned
either
way.
I
think
we're
good
to
go,
and
hopefully
we
can
do
very
expected
September
release.
So
if
anybody
wants
to
mention
something
here,
please
do
that.
B
Okay,
in
that
case,
let's
go
to
the
next
Point
yeah,
it's
about
Boolean,
environment
variables.
This
is
also
a
blocker
for
another
PR
which
the
one
for
being
able
to
disable
the
sdks
and
yeah
I
would
like
to
make
a
progress
on
this
side
of
Steve
Bruno
here,
but
Bruno
creative
PR
to
basically
just
you
know,
include
Boolean
value,
support
for
environment
variables.
B
You
need
some
feedback
as
well.
One
of
them
is,
for
example,
whether
we
should
only
use
true
as
a
unique
value,
or
we
should
support
okay.
You
know
K
sensitive
text
there
as
well
yeah,
basically
something
like
that.
So
please
take
a
look
at
that.
I
think
it's
not
very,
not
very
controversial.
We
just
have
to
come
to
agreements
and
let
me
see
Daniel
Daniel.
Maybe
you
can
comment
on.
E
Yeah
I'm
happy
with
that
I,
just
whatever
value
we
decide,
I
think
we
need
to
decide
on
a
specific
set
of
values
and
not
have
it
be
different
per
language.
That
was
my
only
real
concern
right.
E
B
Perfect,
okay:
we
will
comment
that
they're
they're
yeah
perfect.
Thank
you
so
much.
The
other
aspect
is
that
Bruno
left
the
roping
at
least
initially.
So
as
the
case
could
have
other
cases,
but
I
think
we
should
stick
to
only
you
know.
True,
that's
all
we
shouldn't
allow
sdks
to
being
able
to
extend
that
I.
Think
that's
the
general
agreement!
B
Sorry
original
feeling,
okay,
but
this
is
really
here.
Let's
comment
that
there
I
will
add
a
comment
on
this
part
that
you
just
mentioned:
Daniel
next
one
tigrant
events
unlocks
API.
F
Yeah
yeah,
before
we
go
with
that,
did
you
guys
discuss
the
very
first
item?
What
do
we
do
with
reverting
of
the
metric
split?
We
do
this
discuss
the
the
part
that
that
whether
we
want
to
revert
the
system
network
connections
as
well
or
keep
it,
as
is,
if
you
have
a
chance
to
do.
F
So
I
did
I
did
revert
the
26
17,
which
was
the
disc
I
O
and
all
that
stuff,
a
few
metrics
there.
There
was
a
separate
metric
that
was
submitted
as
a
as
another
PR
before
that,
which
was
splitting
the
system
network
connections
metric
into
separate
two
separate
metrics
one
for
TCP
and
another
for
UDP
I
did
not
revert
this
one
I
kept
it
because
I
thought
that
there
was
a
good
justification
for
that
splitting
and
it
was
not
necessary
to
revert
it.
F
However,
if
people
feel
that
it
is
better
to
start
from
from
a
clean,
State,
I
guess
before
any
of
the
splitting
did
happen,
I
can
also
revert
that
one
I
wonder
what
do
you
guys
think.
B
Well,
one
thing
that
I
would
like
I
mean
as
a
external
Observer
is
whether
what
you
specifically
think
about
splitting
in
general-
and
this
is
you
know
something
that
came
from
Prometheus
and
I,
always
added
out
whether
you
think
this
is
something
that
shouldn't
be
done
anymore,
or
this
is
just
a
case-by-case
thing.
I
know
that
we
are
supposed
to
discuss
that
in
more
detail
in
the
future,
but
maybe
based
on
that
we
can
go
one
way
or
another.
F
So
I
guess,
with
with
the
network
connections
the
the
splitting
was
a
result
of
understanding
that
there
is
no
good
way
to
record
TCP
and
UDP
metrics
using
a
single
metric
because
they
they
require
different,
probably
different
attributes.
Each
vcp
has
States.
F
Uvp
has
probably
doesn't
but
has
different
set
of
States,
so
they
they
really
weren't
were
not
the
same
metric
but
again,
I
guess
not
enough
people.
So
maybe
this
this
particular
change
so
I'm
happy
to
revert
that
as
well
like
bring
back
to
where
we
were
before
all
of
this
started,
and
then
we
have
plenty
of
time
to
discuss
it
after
the
release.
If
that's,
what
people
think
is
the
right
thing
to
do,
I
can
do
that.
F
I
I
think
there's
nothing
particularly
wrong
with
preventing
that
because
it
wasn't
released
and
we
lived
happily
with
that
state
for
I.
Don't
know
many
months,
if
not
years,
I
don't
know
when
exactly
it
was
introduced,
but
we
just
go
back
to
where
we
were
for
a
long
time.
So
it
should
be
okay
to
wait,
wait
for
another
release
before
we.
We
make
that
splitting
that's.
F
B
F
No
objection,
you
said:
okay,
no
objections,
cool,
okay,
I
will
revert
that
one
as
well
in
the
same,
reverting
PR
and
then
once
the
kit
merged,
we
can
make
the
release
I.
Believe.
B
F
B
Yeah
I
think
yeah.
Sorry
I
was
going
to
say
that
it
would
be
good.
I
saw
that
only
people
who
are
part
of
this
group
approve
that.
But,
since
you
know
this
is
like
a
big
I
could
say
Milestone.
It
could
be
good
that
anybody,
as
you
could
do
a
you
know,
an
extra
review.
So
I
will
do
that
one
myself
later
today,
even
though
I'm
not
because
you
know
I,
think
it's
good
to
stay
in
the
loop.
F
B
Okay,
that's
it
perfect!
Thank
you!
So
much
okay,
Next
One,
dashboard
metric
Bridges
is
dashboard
here,
oh
yeah
you're.
Here.
G
G
Does
anyone
know
how
to
talk
without
sharing
computer
audio.
G
As
in,
if
I
share
by
tab,
oh
there,
it
is
share
tap
audio
okay,
I,
unchecked,
it
everyone
can
still
hear
me.
Yes,
yes,
yeah.
A
G
Perfect,
okay,
so
this
is
what
we
have
today.
In
particular,
we
want
to
be
able
to
incorporate
some
third-party
source
of
metrics
into
this,
and
the
thing
I
want
to
call
out
is
that
all
this
configuration
here,
the
views
which
configure
a
meter
provider
and
aggregation
and
temporality.
These
are
all
configured
against
open
Telemetry
instruments,
so
they're
actually
configured
against
the
API,
not
really
they
aren't
necessarily
configuring,
like
the
actual
SDK
in
a
sense
they're,
not
saying
for
this
data
type.
Do
this
thing
they're
saying
for
this
instrument?
G
G
G
Copying
90
of
it
into
something
that
looks
very
much
like
a
metric
reader,
but
doesn't
do
any
of
the
AP
open,
Telemetry,
API,
related
stuff
and
wraps
an
exporter
like
it
does
today.
G
But
this
means
basically
having
a
bunch
of
duplicated
code
which
maybe
isn't
that
big
of
a
deal
and
also
that
there's
no
real
connection
to
your
existing
metric
readers
or
meter
providers.
So
you
have
to
do.
G
H
G
I
E
Yeah
I
I
interpreted
it
the
same
way.
Our
Prometheus
exporter
in
go
is
likely
just
going
to
be
a
reader.
It
hasn't
been
implemented
yet,
but
that
was
that's.
The
plan.
G
But
in
that
case
right
it
would
need
the
the
Prometheus
exporter
would
need
to
be
able
to
read
from
both
the
bridge
and
the
meter
provider
and
somehow
merge
the
two
into
the
endpoint.
So
the
export
would
have
to
be
able
to
support
that.
I
I
G
Okay,
I
I,
think
I
understand
what
you're
saying
I
the
exporter
would
need
to
merge
stuff
from
both
of
these
onto
the
same
endpoint,
though
right
I
think
that's
what
we're
all
saying.
Well,
yeah.
H
So
if
we
want
to
support
Prometheus,
though,
fundamentally
you
want
to
pull
metrics
when
that
and
choose
B
endpoint
is
hit,
or
at
least
recently
to
when
it's
hit,
that's
an
expectation
from
Prometheus,
so
no
matter
what
the
spec
would
have
to
be
changed,
that
exporters
have
access
to
pool
no
matter
what
that
it's,
not
an
option
for
sdks
It's,
a
requirement
for
sdks.
So
if
you,
if
we
want
to
say
that
we
can
Implement
Prometheus
as
an
exporter,
we
do
need
to
change
the
spec
to
make
that
a
requirement.
H
It
is
technically
possible
to
do
it's
just
something.
We'd
have
to
also
spec,
so
I
just
want
to
make
sure
that
we're
all
kind
of
in
agreement
that
that's
the
case
like
it's
not
a
technical
problem,
but
it
is
today
not
how
it's
implemented
in
several
languages
and
the
spec
allows
us
not
to
do
it
that
way.
H
A
G
Cool
a
different
way
we
could
do
this
is
to
integrate
with
the
existing
metric
reader,
but
have
basically
the
bridge
wouldn't
would
have
to
ignore
the
per
instrument
aggregation
and
temporality,
because
it
only
applies
to
instrument
kinds
and
not
to
whatever
metrics
are
coming
from,
say,
open
census.
E
H
G
You
would
have
to
allow
so
right
now
a
metric
reader
is
allowed
to
have
at
most
one
meter
provider,
that's
enforced
in
the
spec.
We
could
relax
that
and
then
a
single
metric
reader
would
instead
be
able
to
pull
from
both.
H
I
Yeah
I
wonder
we
can
still
return
the
the
one
too
many
mapping
here,
but
in
the
exposure
so
essentially
like
the
exposure
is
owned
by
the
provider
or
the
bridge.
But
you
can't
have
multiple
records
instances
and
they
would
work
together.
So
they
know
underlying
there's
another
abstraction.
Maybe
you
can
call
that
a
premises,
HTTP
listener
or
premises
HTTP
server
whatever,
and
that
thing
is
one
single
instance.
G
I
Poll,
so
the
exposure
would
only
pull
from
One
Source,
but
multiple
exposures
can
share
an
underlying
HTTP
server
and
that
thing
understands
is
trying
to
collect
multiple
responses
from
multiple
exposures
and
they
can
merge.
So
essentially,
it's
like
a
HTTP
reverse
proxy.
That
can
talk
to
multiple
importance
and
merge
the
results,
and
in
this
way
imagine
if
one,
if
one
is
Paul
her
decided,
okay
I
got
a
timeout,
then
the
listener
can
decide
what
to
do.
You
can
return
a
partial
result
or
you
can
just
give
up
the
entire
transaction.
I
H
I
just
want
to
say
that
that's
actually
how
we're
doing
the
open
census
Bridge
today,
so
today,
what
we
do
is
we
make
a
metric
reader
wrapper
thing
that
is
able
to
read
from
both
open
census
and
open
Telemetry
when
it
tries
to
read.
H
That's
that's
how
the
rappers
implemented
David
correct
me
if
I'm
wrong,
because
I
forget
the
details
ago,
but
I
think
that's
how
we
were
approaching.
I
It
seems
we
have
different
understandings
I,
put
a
link
of
the
slack
in
the
chat
David.
Would
you
mind
opening
that
link
just
want
to
show
people?
The
two
diagrams,
I
I
think
we're
calling
both
cases
the
premises
caller.
It's
just
the
the
first
situation.
We
allow
that
exposure
to
be
modeled
as
a
metric
reader,
but
but
functionally
it's
still
and
Explorer.
So
we
could
go
to
the
the
two
metric
is
called
her
Section
yeah.
I
E
E
I
H
Right
but
see
that
may
right
there
that
David
highlighted
that's
that's
my
concern
right
now
is
basically
because
we
allow
you
to
choose
Con
in
a
metric
reader
or
an
exporter.
We
have
a
specification
for
what
an
exporter
looks
like
we
have
a
specification
for
what
a
reader
looks
like
my
point
is
that
we
need
to
talk
about
the
metric
reader
part
of
the
specification
here
right.
H
If,
because
we
allow
that
choice-
or
we
have
to
remove
that
choice
from
the
spec
and
then
we
can
talk
about
the
metric
exporter,
part
of
the
spec
yeah,
but
it's
like
what
part
of
the
spec
would
we
change
to
make
this
work?
That's
that's
and
yeah.
I
I
also
think
this
is
the
most
confusing
part
of
the
metric
specification
and
we've
repeatedly
seen
people
run
afoul
a
bit,
so
we
we
should
be
very
Crystal
Clear.
When
we
talk
about
this
yeah.
A
H
D
Can
we
talk
about
an
approach
that
I
think
David
has
has
proposed
in
some
form,
maybe
not
presented
today?
But
oh
here
we
go
yeah
where
the
bridge
is
registered
with
the
meter
provider,
and
so
in
this
case
the
bridges
registered
with
the
media
provider
but
and
so
metric
readers
read
from
instruments
that
are,
you
know,
open
Telemetry
instruments
and
also
from
the
bridge
and
in
this
configuration
it's
just
acknowledged
that
some
of
the
data
is
going
to
disagree
with
the
metric
readers
configuration.
D
So
it's
temporality
and
default
aggregation,
configuration
and
potentially
resource
too,
depending
on
how
it's
modeled,
but.
H
D
I
know
it's
it:
it's
just
a
bit
tricky
with
with
Java
to
to
model
that,
because
we
have
this,
we
have
this
interface
metric
data,
which
represents
you
know
a
metric
data
point.
It's
our
it's
our
in-memory
representation
of
the
metric
data
model,
and
that
includes
both
instrumentation
scope
and
resource
and
so
like
the
bridge
would
be
providing
these
metric
data
points
or
metric
data
records
yeah,
which
include
a
resource,
and
so
you
know
our
meter
provider
would
have
to
override
that
with
the
resource
configured
but
with
the
meter
provider.
So
it's
a.
H
D
E
H
D
I
Gives
consistency
and
and
I
I
guess
we're
seeing
a
similar
thing
with
tracing
as
well?
If
there's
a
external
source
using
external
API,
we
try
to
attach
that
life
cycle
to
meet
a
providers.
So,
as
a
user
of
the
istk,
they
have
a
clear
understanding
that
meter
provider
is
the
the
ultimate
root
of
the
entire
object
hierarchy
in
terms
of
life
cycle
management,
how
they
flashing,
how
they
shut
down.
Everything
is
consistent
instead
of
seeing
this
multiple
routes
and
they
can
share
a
certain
object.
H
I
was
going
to
say
the
same
thing
by
the
way
I
had
my
camera
off,
because
I'm
being
attacked
by,
we
have
a
new
kitten
apologies
if
I'm
being
succinct,
but
she
keeps
turning
everything
off
anyway.
I
agree:
life
cycles,
a
really
really
big
part
here,
really
really
big
part
of.
Why
I
think
meter
provider
is
the
right
place
to
put
Bridge
because
media
provider
has
a
defined
life
cycle
and
if
we
need
to
add
life
cycle
things
to
bridge,
we
have
that
natural
pairing
right
of
we
know
when
things
are
getting
flushed.
J
A
J
Also
like
this
organization
with
the
bridge
in
the
meter
provider,
I've
wondered
whether
it
the
concern
over
you
know.
Temporality
selection
and
aggregation
per
instrument
can
be
sidestepped
by
having
the
bridge
play
nicely
with
meter
provider.
So
right
now,
I
I,
don't
I
mean
I'm
not
going
to
speak
for
anyone
else's
implementation,
but
I
have
one
that
I've
worked
through,
and
you
know
the
interface
between
asynchronous
instruments
and
the
media
provider
is
very
different
than
the
interface
between
synchronous
instruments
and
media
provider.
J
But
if
a
bridge
had
cumulative
integers,
it
would
probably
want
to
use
the
asynchrist
instrument
interface
and
the
bridge
had
Delta
numbers.
It
would
want
to
use
the
synchronized
instrument
interface,
so
I'm,
trying
to
say
that
I
believe
a
bridge
could
act
like
a
set
of
instruments
and
then
I
think
the
metric
metric
readers
Machinery
to
do
temporality
conversion
will
work.
J
I
also
think
that
probably
the
metric
readers
facility
for
views
will
also
work.
If
done
this
way
and
I,
don't
think
that's
too
hard
I.
Just
that's
my
opinion.
I'd
like
to
see
it
so
that
everyone
you
tried.
H
It
I
I
really
want
you
to
go.
Look
at
the
open
census.
Api
like
it's
the
way
that
thing
is
defined
right
now,
an
instrument
only
records
either
raw
double
events
or
raw
integer
events.
That's
it
and
all
of
the
aggregation
and
stuff
is
done
via
views
with
expectations
from
users
of
what
those
views
are.
We
don't
have
any
kind
of
granularity
into
open
Telemetry
instruments
from.
H
So
so
you
can't
like
the
injection
point
for
understanding
them
is
in
a
different
location.
So
from
a
technical
standpoint,
this
bridge
is
meant
to
solve
the
area
where
you
can't
get
access
to
an
instrument
equivalent,
like
that's
the
whole
point
of
it.
If
you
think
you
can
with
open
senses
like
please
provide
a
prototype,
because
that
would
be
valuable,
but
we've
tried
and
it's
just
it's
not
a
practical
thing
to
do
with
how
open
sentences.
J
J
Let
me
ask
you
this
way:
Josh
the
the
output
of
your
open
census,
library,
with
your
open
census
views
is
open.
Telemetry
protocol
data
points
right,
they're,.
A
J
Correspondence
between
open
Telemetry
instruments
and
open
Telemetry
data
points,
I'm
I
acknowledge
that
the
mechanics
are
going
to
be
tricky
because
asynchronous
instruments
have
very
different
schematics
and
Stingers
instruments,
but
new
at
the
end
of
this
transformation.
Isn't
the
otlp
data
point
one
to
one
within
a
virtual
instrument.
H
H
J
H
Apis,
the
problem
with
views
and
open
senses
is
you
don't
get
the
data
point
till
after
it's
already
aggregated,
like
it's
already
been
aggregated
by
the
time
you
get
to
see
it
in
open
census
and
one
instrument
can
lead
to
multiple
views.
That's
just
a
common
thing
in
open
census
that
there's
there's
a
lot
of
instances
where
that
happens.
So
we're
going
after
the
views,
but
there's
not
a
one-to-one
correlation
between
a
view
and
an
instrument
right.
H
J
With
me,
meaning
you
go
through
all
of
your
open
census
machinery
and
if,
at
the
end
of
that
pipeline,
you
have
a
cumulative
integer.
It's
now
an
otlp
came
out
of
sum.
You
can
emulate
that
by
by
presenting
to
the
reader
an
asynchronous
counter
numbers
for
every
human
I,
see
what
you're
saying
monotonic
data
point.
You
emulate
an
instrument
that
produces
it
and
then
you
go
to
go
through
all
the
metric
reader,
Machinery,
all
the
temporality
conversion
and
all
the
second.
The
hotel
views
get
been
applied.
D
But
Josh
that
doesn't
that
doesn't
quite
work
because
the
temporality
is
per
instrument
and
you
know
you
might
be
able
to
say
that
a
cumulative
sum
is
a
you
know
is,
is
most
likely
a
counter,
but
you
don't
know
if
it's
an
ace
encounter
or
a
synchronous
counter,
and
so,
if
you
have
a
temporality
that
is
a
different
selection
for
asynchronous
counters
versus
synchronous
counters,
then
you
don't
know
which
one
to
choose.
J
But
but
the
input
tells
you
which
to
choose.
So
if
the
input
is
cumulative,
it
is
as
if
an
asynchronous.
J
Applying
this
after
the
open
census
view
I'm
assuming
there's
an
open
census
view
that's
in
place
that
outputs
otlp
data
points
now.
My
point
is
that
you
can
take
the
otlp
data
points
and
prevent
present
them
to
a
reader,
as
if
instruments
have
produced
them,
even
though
it
was
an
open
census
bridge
that
produced
them.
H
We
we
actually
have
issues
like
we
are
unable
to
do
that,
and
and
there's
there's
when
we
tried
to
do
other
metric,
API,
Bridges,
we've
run
and
file
of
this
as
well
like
we're
missing
gauge.
Histogram
is
a
great
example.
If
we
provide
a
async
histogram
instrument
right,
what's
the
temporality
of
a
gauge
histogram
by
default,
it's
it.
You
actually.
J
Like
this
would
be
an
opportunity
to
solve
the
problem,
I've
pointed
that
out
to
David
as
well.
We
don't
have
a
way
to
report
an
asynchronous
histogram.
We
don't
need
an
instrument.
A
bridge
could
do
that
by
producing
the
otlp
data
point
and
we
would
have
a
good
mapping
if
you
have
an
asynchronous
histogram,
that's
cumulative,
it
better,
be
cumulative.
First
of
all,
if
it's
asynchronous
and
if
it's
synchronous
it
better,
be
Delta,
and
then
the
reader
can
do
the
conversions
as
needed.
H
I
see
so
what
you're
saying?
Let
me
let
me
rephrase
what
I
think
I'm
hearing.
So
we
start
from
the
otop
data
point.
We
reverse
engineer
the
instrument
that
would
be
the
natural
computation
of
that
data
point.
We
look
at
what
the
aggregation
the
reader
wants
for.
That
instrument
is,
and
then
we
try
to
do
a
conversion
on
the
data
point
to
that
temporality
or
or
aggregation
right.
H
Is
that
what
you're
suggesting
so
we
we
have
like
metric
conversion,
so
this
is
one
thing
I
was
actually
proposing
on
the
spec.
Was
we
do
some
metric
conversions
in
the
meter
provider
before
it
hits
a
reader
to
limit
what
exporters
have
to
deal
with?
But
let
me
just
make
sure
I'm
understanding
this
correctly
is
we
take
the
metric
point
right
and
let's
say
it's
a
histogram
or
a
distribution,
sorry
open
census.
Let's
say
it's
a
distribution.
We
reverse
engineer.
H
J
J
I
guess
I
would
have
to
prototype
this
pretty
hard
to
explain
it.
Apparently
so
I'm
I'm,
just
I'll,
step
back
I,
think
the
point
I'm
trying
to
hope
for
is
that
an
instrumentation
Library
could
come
along
and
present
as
a
bridge,
especially
in
cases
where
we
don't
have
instruments
for
it.
Yet
we
know
how
to
produce
an
asynchronous
data.
Histogram
data
point
we
just
don't
have
an
instrument
for
that.
J
A
bridge
I
think
could
produce
an
asynchronous
histogram
and
it
would
be
meaningful
and
it
would
be
convertible
back
to
whatever
form
you
wanted
and
that
will
require
extensions
to
reader,
because
the
reader's
never
seen
an
asynchronous
histogram
before.
But
we
know
what
the
data
point
should
look
like
and
we
know
how
to
convert
between
temporality
for
histograms,
so
I
think
the
reader
can
do
it.
K
You
know
one
one
thing
that
I
want
to
say
is
I:
don't
want
to
necessarily
use
these
this
bridge
as
a
a
way
to
add
more
async
instruments,
so,
if
possible,
to
not
necessarily
add
new
async
instruments,
I
think
we
should
avoid
that
and
do
it
whenever
it's
necessary,
but
not
let's
not
find
artificial
reasons
like
this
one.
The
other
thing
that
I
want
to
say
here
is
indeed
Josh
suret.
K
We
can
I
think
every
view
that,
or
if
you
every
view,
data
that
open
sensors
produce
produces
can
be
mapped
to
all
of
them.
Actually
all
of
them
are
cumulative,
so
all
of
them
can
be
mapped
to
async
instruments.
If,
for
example,
a
cumulative
counter
can
be
mapped
to
a
I
think
a
counter
the
the
gauge
can
be
can
be
a
gauge
in
in
a
hotel,
and
then
you
can
have
let's
say
assume
distribution
as
in
histogram.
K
It
does
the
case
so
I
think
you
can
do
the
the
mapping
if
you
really
want,
as
as
that,
like
and
every
time
when
you
read
the
instruments,
you
actually
go
and
read
the
view
data
and
it's
almost
seems
to
be
an
asking
pattern
for
for
this.
The
the
only
challenge
with
that,
in
my
opinion
is
people
will
get
extremely
confused
because
there'll
be
open
census,
views
and
open
Telemetry
reviews
and
all
of
them
will
will
apply
one
after
each
other
and
will
be
extremely
confusing.
K
D
Jack,
what
about
inside
covers
what
I
was
going
to
say
so
I,
just
you
know
just
in
general,
I'd
I'd,
rather
keep
this
simpler,
not
have
two
ways
to
do
something
not
have
you
have
to
choose
between
whether
doing
the
configuration
in
open
census
or
in
in
in
the
meter
provider-
and
you
know
just
acknowledge
that
the
aggregation
and
temporality
configuration
is
only
going
to
apply
to
to
open
Telemetry
instruments.
D
B
L
Just
wanted
to
point
out
that
I
know
we're
focused
on
enabling
the
open
census
bridge,
but
depending
on
how
you
Scope
this,
this
could
be
applicable
to
any
other
metric
system
that
we
want
to
bring
in.
L
So
there's
not
going
to
always
be
that
that
one-to-one
correlation
and
there's
not
always
going
to
be
that
that
that
instrument
level
information.
So,
yes,
it
might
be
applicable
for
the
open
census
bridge.
But
it
may
not
be
universally
so
think
about,
oh
that
when
you're,
considering
these
this
proposal.
B
That's
a
good
point.
Okay,
thank
you!
So
much,
sadly,
we
have
to
move
on
they're,
accelerating
agenda.
Let's
continue
that
offline.
Thank
you
so
much
for
the
feedback.
The
next
one
is
also
dashboard.
You
want
to
talk
about
that.
G
Yes,
hopefully
I
I
suspect
this
might
be
just
as
long
as
the
previous.
Unfortunately,
but
let's
talk
about
Prometheus
and
namespacing
I
have
so
in
the
linked
spec
PR
I
wrote
up
some
options
for
how
we
could
do
name
spacing
name
spacing
in
Prometheus
in
particular,
I
think
there
was
some
confusion
around
why
we
wanted
to
do
name
spacing
and
what
we
wanted
to
get
out
of
these
proposals.
G
That
I
had
put
forward
to
try
and
add
a
short
name
to
scope,
attributes,
and
so
I've
tried
to
clarify
that
here.
What
the
problem
is,
what
user
experience
I
would
like
as
part
of
this.
G
I
know
Josh.
You
had
said
on
so
I've
been
talking
with
Josh
and
Bogdan
and
Josh
and
Riley
about
this
proposal,
and
one
of
the
ideas
I
think
Josh
McDonald
had
was
actually
to
change
the
way
the
Fields
work.
Josh.
Did
you
want
to
talk
about
that.
J
Oh
I
feel
very
good
on
the
spot.
Would
you
summarize
I'm
not
sure
I
quite
follow
you.
J
Yeah
I
see
well
I,
actually
responded
to
Bogan
wrote
a
document
first
and
I.
Read
it
and
I
was
left
thinking
what
you
just
explained,
but
for
me
it
sounds
complicated,
but
but
the
idea
is
that
we
have
a
name
field
already.
We
all
want
a
name
field.
We
want
the
name
to
be
short.
We
also
don't
want
to
lose
access
to
that
full
identifier,
which
is
the
full
path
of
the
resource
or
of
the
library
that
produced
it.
J
I
think
that
we
could
satisfy
most
people's
desires
here
if
we
swapped
the
fields
essentially
and
made
an
attribute
out
of
the
full
identity
called
a
URL,
or
something
like
that
for
that
library
of
instrumentation
turn
the
name
field
that
we
have
into
a
short
name
field
and
then
make
it
act
like
the
name
spacing
that
Prometheus
has.
This
is
a
very
rough
idea
that
I
got
from
Reading
bookings
documents
I'll,
stop.
K
There
is
only
one
problem
here:
the
problem
is
one
of
your
main
goal
is
to
dedupe
metrics
and
if,
if
the
name,
the
short
name
is
not
unique,
you
lose
the
you
lose
these.
So
so
it's
become
useless
to
you.
So
your
short
name
or
whatever
concept
we
add,
has
to
still
be
unique.
Otherwise
it
defeats
the
purpose
that
you
need
yeah,
so
so
now
now
Josh
my
God
I,
like
the
idea
of
shortening
that
name
but
I,
think
we
need
to
keep
the
property.
That
is
unique,
you
know
or
you
need.
K
Otherwise,
it's
not
gonna
work
for
for
David's,
David's
purpose
and
then
and
then
we
we're
gonna
have
to
come
up
with
another
idea.
F
G
This
is
the
The
Proposal,
mostly
cribs,
off,
of
what
open,
metrics
and
Prometheus
have
done,
which
is
you
put
a
prefix
on
your
metrics
and
it's
short
and
it's
readable,
and
it's
Unique.
If,
in
that,
you
pick
something,
that's
very
unlikely
to
collide
with
something
someone
else
has
chosen
in
the
same
application,
but
it's
not
globally
unique.
K
So
then,
why
don't
we
do
the
following?
Why
don't
we
get
the
last?
The
last
word
from
the
URL,
the
current
name,
that
we
have
and
use
that
as
a
namespace,
because
it
seems
like
as
random
as
that
one
I
mean
not
random,
but
you
you
get
it
like.
We'll
have
a
new
array
like
IO,
open,
Telemetry
grpc,
for
example,
for
the
integration,
and
we
will
use
grpc.
The
last
word
part
of
as
a
namespace,
for
example,.
F
Or
some
other
transformation
right
to
turn
the
the
full
name
into
some
some
form
of
acceptable
prefix
for
from
Prometheus
for
a
Prometheus
metric
I
assume
there
is
some
limitation
on
the
length
of
that
as
well
in
Prometheus
right,
so
we
just
have
to
shorten
it,
and
it's
also
the
character
set
right
that
we
need
to
to
keep
the
certain
subset
of
characters.
There.
F
F
H
H
One
question
I
have
because
I
think
I
missed
the
discussion
around
instrumentation
scope
completely
was:
why
does
that
not
have
an
identity,
That's
Unique
that
is,
can
uniquely
identify
an
instrumentation
scope
and
its
attributes
that
we
can
use
later
as
far
as
I
understand
it
does
not
have
that.
H
So
that's
why
this
is
kind
of
introducing
a
new
restriction
that
we're
a
little
nervous
about,
but
should
that
restriction
actually
just
be
on
instrumentation
scope
to
begin
with,
of,
like
the
name
has
to
be
unique
and
it's
and
it
fully
identifies
that
thing
and
if
you
try
to
register
one
with
different
sets
of
attributes.
That's
a
that's
a
programming
error.
A
So
the
current
guidance
already
says
that
you
should
use
the
fully
qualified
class
name
and
it
would
usually
be
your
comdot
Acme,
something
prefix
or
if
you're
in
JavaScript
your
npm
organization,
name
or
something
like
that.
So
by
that
it
will
already
be
unique
in
that
regard.
K
F
H
H
Don't
want
to
expand
the
discussion
like
so,
if
we're
going
to
focus
this
discussion,
I
think
it
sounds
like
we
have
some
proposals,
there's
there's
two
that
I
think
have
legs.
Okay,
one
is
taking
the
last
part
of
the
name
in
a
URL
of
our
existing
convention
and
calling
that
short
name
that
I
actually
really
like
that
proposal,
bobbin
so
that
one's
kind
of
cool,
the
second
one
is
to
just
start
with
short
names
to
begin
with
and
somehow
reverse
engineer,
a
more
full
name
or
like
have
that
be
the
second
class
citizen.
H
That's
also
one
that
I
think
has
legs
from
this
discussion,
but
we
should
probably
just
evaluate
those
two
unless
someone
thinks
there's
some
other
proposal
here
that
had
a
lot
of
you
know,
agreement
behind
it,
I
think
those
two
are
the
ones
that
I
heard
most
of
keep
our
existing
conventions,
but
take
the
last
bit
as
a
short
name
or
the
second
one
is
change
our
convention.
So
it
looks
better
in
Prometheus.
B
G
G
I
So
I
imagine:
when
the
user
typing
the
the
name
they
normally
want
to
type
in
the
full
name.
They
would
start
with
few
characters
and
premises,
UI
or
grafana,
whatever
UI
would
automatically
list
out
the
thing
based
on
the
prefix.
So
if
we
we
can
only
do
prefix,
then
it
has
to
be
something
that
is
really
user
friendly
or
at
least
that
the
user
can
understand.
G
Foreign
that
would
be
I
ideal
I
would
have
to.
We
had
thought
of
using
the
last
essentially
the
package
name
as
the
prefix
before
and
I.
Don't
remember,
it's
been
a
while
so
I,
don't
remember
exactly
why
we
didn't
like
it,
but
we'll
have
to
see
in
practice.
If
the
package
name
is
sort
of
unreadable
and
makes
this
not
really
a
valuable
option.
Okay,.
D
I
have
a
quick
idea:
I
don't
know
if
this
has
been
proposed,
but
what?
If,
when
you're,
registering
the
Prometheus
reader
or
exporter,
you
register
a
set
of
mappings
and
so
by
default.
None
of
the
instruments
have
any
prefix
at
all,
but
you
register
a
set
of
key
value
mappings
from
a
particular
scope,
name
to
a
prefix
that
is
prepended
in
front
of
those.
So
it's
opt-in
completely
and
you
know
instrumentation
authors
don't
have
to
worry
about
it
at
all.
It's
purely
an
SDK
configuration
concern.
D
H
B
Okay,
I
suggest
we
continue
discussing
that
offline.
We
only
have
five
minutes.
Let's
go.
If
you
don't
mind
over
the
last
items,
I
think
it's
mostly
announcements
and
attention
requests.
B
Okay,
the
first
one
is
Jamie
Martin
elastic,
schema,
plus
Hotel.
You
want
to
talk
about
that
sure.
C
Hi,
all
thanks
Carlos,
my
name
is
Jamie
Hines
I'm,
the
product
manager
responsible
for
elastic
common
skier
elastic
and
I've
Linked
In
the
agenda
previous
Otep.
That
was
created
some
time
ago
earlier
this
year
and
unfortunately,
it
hasn't
made
a
whole
lot
of
progress.
A
lot
of
that
is
on
Austin
the
elastic
side
of
things,
but
we're
certainly
very
keen
to
have
facilitation
of
hotel
to
adopt
ECS
and
and
kind
of
work
towards
an
approval
there.
C
So
we
can
start
merging
and
start
discussing
further
I
think
to
be
honest
at
elastic.
We
probably
thought
were
further
along
in
the
process
than
we
actually
are,
and
we
joined
the
log
Sig
last
week
and
got
some
great
guidance.
There
and
I
have
Team
Grand
who's
here
as
well,
and
but
he
guided
us
towards
the
specification
stick.
C
So
we
just
wanted
to
join,
to
I
guess,
raise
awareness
of
the
the
Otep,
maybe
chime
main
review,
what
we've
done
of
fire,
providing
guidance
on
where
we
can
go
next,
we
can
answer
questions
and
but
just
wants
to
raise
awareness
of
the
of
the
Otep
and
that
we
plan
on
spending
some
Cycles
on
our
side
to
to
get
it
through.
C
I
know
we're
tight
on
time
today,
so
we'll
go
to
too
much
detail,
but
if
it,
if
it
makes
more
sense,
maybe
dedicate
more
time
and
kind
of
walk
through
the
ins
and
outs
of
ECS
and
what
it
would
mean
and
kind
of
dive
down
deeper
into
the
Otep
live.
We
can
certainly
facilitate
that,
but
just
wanted
to
to
raise
some
awareness
today.
That's
okay.
I
H
Well,
that
was
going
to
be
one
of
the
announcements
further
below.
We
still
I
think
we
have.
We
have
a
lot
of
interest,
but
I
think
we
need
at
least
two
or
three
more
people
who
are
willing
to
be
workers
here,
but
just
for
context
we're
trying
to
revamp
the
semantics
convention
group
I,
put
together
a
project
proposal
of
the
things
that
we
think
we
need
to
be
able
to
stabilize
semantic
conventions,
and
this
would
be
a
group
dedicated
to
tooling
and
process
around
semantic
conventions.
H
There's
a
link
to
that
at
the
bottom.
This
is
highly
correlated.
Your
bug
issue
is
actually
one
of
the
reasons
that
motivated
my
proposal
of
we
need
to
be
able
to
make
progress
on
these
things.
So
that's
what
that
is.
Please
take
a
look.
B
Okay,
very
good
Ryan
profiling,
notep.
M
Yeah
I
spoke
a
little
bit
about
this
last
week,
but
yeah.
M
Basically,
we
have
moved
the
dock
that
I
shared
last
week
over
to
GitHub,
there's
a
link
there
and
sort
of
made
the
official
Otep,
and
it
is
mostly
again
just
I
guess
if,
if
anybody
wasn't
here
last
week,
just
a
high
level
overview
of
the
group
that
has
been
meeting
for
you
know
for
a
couple
months
now
what
our
General
Vision
was
for
profiling
and
what
the
motivation
was
and
how
it
sort
of
aligns
with
the
open,
Telemetry
vision
and
we
yeah.
M
We
just
wanted
to
make
sure
when,
when
I
spoke
to
this
group,
a
while
back
the
the
feedback
that
we
got
from
here
was
that
we
that
you,
you
all
wanted
to
make
sure
that
we
weren't
sort
of
like
building
this
profiling
thing
in
a
silo
away
from
the
way
that
the
rest
of
open
Telemetry,
you
know,
sort
of,
does
things,
and
so
we
wanted
to
yeah
kind
of
really
solidify
that
Vision
share
it
with
you
all
and
see
if
we
could
get.
M
You
know
some
some
more
people,
particularly
from
this
group,
to
be
able
to
kind
of
review
that
PR
and
just
generally
tell
us
if,
if
it
all
makes
sense,
and
if
so
then
we
will
kind
of
continue
down
the
path
that
was
sort
of
outlined
in
that
project,
management
issue
or
I,
guess
doc.
That
was
created
a
couple
weeks
ago
and
yeah.
That's
kind
of
pretty
much
the
plan
right
now
and
so
we'd
really
appreciate
any
comments.
M
Concerns
ideas,
anything
of
the
like
in
order
to
be
able
to
kind
of
check
that
box
and
move
forward
into.
Actually,
you
know
coming
up
with
a
more
I
guess,
traditional
Otep,
of
what
an
actual
like
profile
looks
like.
B
Perfect,
thank
you.
Thank
you
so
much
we
are
out
of
time,
but
before
we
go,
Morgan
left
a
comment.
We
can
discuss
it
offline.
Basically,
you
pass
about
whether
attributes
should
be
part
of
identity
or
not.
When
it
comes
to
metrics,
let's
discuss
out
of
line.
We
don't
have
time.
Thank
you
so
much
and
stay
safe,
ciao.