►
From YouTube: 2022-06-21 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
A
Pretty
good
pretty
good,
I
might
be
in
too
deep
with
open,
telemetry
and
lua.
We
will.
We
will
find
out
no.
A
I
guess
it's
not
really
into
I
mean
it's
like
it's
like
d
is,
do
is
there
enough
time
to?
Is
there
enough
time
to
do
it
all,
given
that
I
don't
really
know
lua.
D
B
E
I
returned
thank
you,
I'm
just
catching
up
and
doing
daddy
daycare
excellent.
E
Yeah
a
little
bit
a
lot
a
little
bit
kinda,
you
know,
there's
a
babe
babies
kind
of
do
what
they
want
they're
going
to
do,
what
they're
going
to
do
and
just
kind
of
what's
the
same,
the
strong
do
what
they
can
and
strong
do
what
they
must
and
though
the
weak
do
it
they
can
or
something
I
don't
know
I
basically
just
I
just
do
whatever
the
baby
does.
E
How
are
you
how's
everyone?
How
is
open
commentary,
ruby.
D
B
Yeah
might
be,
there
is.
D
E
A
Ariel
is
the
crusher
I'm
more
of
like
I
like
file
paperwork
around
the
crushing
I
like
I'm
like.
Please
move
your
pull
request
to
this
area
where
they
can
be
crushed
by
someone.
You
know,
that's
my
that's
my
role.
It's.
F
A
specific
recap
and
then
yeah
catch
up
on
what's
going
on
in
in
hotel,
ruby
and
the.
F
F
F
Blah
blah
it
will
not
provide
guarantees
about
code
generator
behaviors.
This
was
something
that
kind
of
came
up
with
in.
In
the
conversation,
the
code
generators
are
too
too
disparate
to
begin
with
kind
of,
depending
on
language,
and
that's.
F
Not
a
super
important
thing,
I
guess,
but
but
in
the
process.
I
think
the
important
thing
that
in
this
run-up
to
1.0
they
there
will
be
a
last
batch
of
changes
and
things
might
get
broken.
I
think
that's
the
the
tltr,
while
resolving
these
open
pr's
issues
before
otop
1.0
is
declared.
We
may
make
breaking
changes.
F
F
F
Cool
all
right,
this
one
is
a
little
in
the
weeds,
but
it
kind
of
came
up.
I
think
during
the
last
it's
like
I
mean
not
that
it's
in
the
weeds,
it's
just
that
it's
a
little
bit
technical
in
the
networking
space
and
trying
to
weed
through
exactly
what
happened,
because
there
are
a
lot
of
changes
around.
F
I
think.
Ultimately,
there
are
the
net
peer
and
net
host
and
they
might
actually
be
named
slightly
different,
but
I
think
things
get
complicated
when
there's
like
a
proxy
in
the
mix,
it's
like.
Who
are
you
actually
talking
to
and
what
do
these
attributes
pertain
to?
I
think
that
is
like
the
the
crux
of
this
issue
and
I
feel
like
I
had
to
like
scan
way
down
the
document
to
understand
exactly.
F
Here:
okay
net,
your
name
and
net
host
name
represent
logical
host
names.
Semantic
conventions
that
refer
to
these
attributes
should
specify
what
these
attributes
mean
in
their
comment.
In
their
context,
semantic
conventions
and
instrumentations
that
populate
both
logical
net,
pure
name
and
net
host
name
and
socket
level
dot.
Netsockstar.Name
attributes
should
set
socket
level
attributes
only
when
they
don't
match
the
logical
ones.
So
I
think
tldr
is
that
there's
like
a
net
sock
version
of
these
things
that
you
can
use
when
the
logical
peer
is
different
than
what
you're
communicating
with
over
the
socket.
B
I
don't
know
this
does
make
a
certain
amount
of
sense,
as
people
start
trying
to
discover
that
service
meshes
are
interstitial
in
between
their
services
and
trying
to
detect
that
and
track
that,
because
yeah
there
are
shenanigans.
But
this
this
comes
from
a
legitimate
use
case
of
trying
to
understand
how
your
packets
are
traversing.
Your
system.
F
Yeah-
and
just
just
so
I
understand
this
because
I
don't
know
I
feel
like
networking
is
something
I
try
to
avoid
at
all
costs.
The
socket
is
what
you're
actually
communicating
with
and
like
the
logical,
pier,
is
kind
of
the
the
thing
making
the
requests,
and
sometimes
those
are
the
same
things
sometimes
they're
going
through.
Something
else
is
that
that
accurate
to
say.
B
B
Those
two
together
represent
a
network
socket
and
then
that
that
name
happens
to
go
through
a
proxy
and
get
proxied
back
to
something
else
is
interesting
information
to
get
in
your
telemetry
so,
like
even
setting
aside
the
complexity
of
service
meshes
that
sit
in
between
your
internal
services.
B
B
I
need
to
read
this
because
I
might
have
opinions
and
certainly.
F
F
Yeah
all
right,
I
think
I
think
that's
my
understanding.
I
just
wanted
to
clarify
that.
I'm
not
a
complete!
You
are
not
up
to
question,
but
on
this
point
maybe
not.
F
F
There
is,
I
guess,
an
issue
and
a
draft
pr
for
feature
flagging
semantic
conventions.
This
was
kind
of
brought
up
because
the
authors,
I
don't
think
the
authors
are
regularly
involved
in
hotel
and
they're.
Just
wondering.
Does
anybody
care
about
this,
like
they
haven't,
really
been
getting
feedback
and
they're,
getting
like
a
little
frustrated
about
the
process
so
yeah?
So
it
was
a
call
for
a
us
to
get
our
act
together
and
actually
help
this
person
out
and
either
tell
them
that
we
like
these
or
we
don't
but
yeah.
F
So
if
anybody
has
opinions
about
feature
flagging
and
what
this
magic
semantic
convention
should
look
like
for
free
to
chime
in,
I
think
I
think
there
is
like
the
hotel
demo
app,
and
I
heard
these
are
being
used
there.
So
I
think
that
was
like
a
reason
for
taking
me
seriously
and
trying
to
accept
them
at
some
point.
B
F
C
F
F
So
I
think
the
message
context
layer
is:
it
should
not
be
altered
by
intermediaries.
However,
this
transport
context
layer
can
be
changed
by
intermediaries.
According
to
the
intermediary
instrumentations
it
the
layer
helps
to
gain
insights
into
the
details
of
the
message
transport,
so
I
probably
not
do
a
great
job
of
explaining
it,
but
it
seems
like
there's
two
contexts.
F
One
is
like
link
up
like
the
parentage
of
of
the
message,
and
one
is
to
actually
kind
of
track
what
the
message
went
through
on
its
way
there,
how
this
would
actually
end
up
applying
to
instrumentation.
In
the
end,
I
don't
really
know,
but
I
only
quickly
scanned
this
this
document.
That
might
be
a
good.
B
B
It
it's
interesting
because
it
I
I
can
I
I
don't
like
that.
It's
more
complicated
honestly,
because
telemetry
in
general
is
just
kind
of
complicated
and
I
hate
complexity
but
they're.
I
can
kind
of
see
the
problem
in
solving
it.
Just
kind
of
sounds
like
as
written
it's
almost
going
to
be
sort
of
up
to
the
individual
language
sdks
to
figure
out
how
they
track
that
context
across
the
cueing
and
dequeuing
boundaries.
B
F
Yeah,
I
think,
probably
definitely
worth
a
read
in
in
any
case
and
maybe
a
scan
already
conversation,
which
seems
largely
resolved.
A
I'm
supposed
to
be
the
police
for
time
on
the
spec
sig
recap
and
I'm
here
to
turn
on
the
siren
to
see.
If
anyone
cares
all
right.
F
All
right,
excellent,
let
me
tell
you
that
the
project
management
proposal
yeah
give
me
two
minutes
to
wrap
up
officer.
You
got
it.
Thank
you
and
yes,
all
right.
So
the
project
management
proposal
we've
talked
about
this
a
little
bit,
but
I
think
yeah
there's
a
whole
hotep
about
it.
Take
a
look,
or
it's
actually
a
spec
saying,
but
basically
for
larger
things,
to
move
them
through
the
spec
say
larger
things
will
get
like
their
own
project
board.
F
They
will
get
like
their
own
lead,
sponsoring
tc
members,
a
group
of
engineers
willing
to
do
this
stuff.
It's
just
kind
of
like
just
making
sure
that,
like
ideas
that
we
are
floating
around
in
the
specs,
they
actually
have
some
way
of
getting
to
the
end
and
that
there's
a
group
of
people
working
on
it.
So
it
seems
like
a
good
idea.
It
seems
like
it
seems.
F
A
good
idea
read
read
through
that's
less
than
what
I
thought
that's
kind
of
cool,
but
I
will
bring
up
this
this
kind
of
got
shoved
in
at
the
end.
It
seemed
very
interesting
context:
scoped
attributes
and.
F
Yes,
exactly
hello
carry
on,
I
think
so.
The
idea
here
is
that
there
would
be
some
attributes.
We
would
use
our
existing
hotel
context
and
whatever
attributes
you
add
to
the
context,
would
automatically
get
stapled
on
all
signals
as
as
attributes.
So
I
don't
know
if
this
is
supposed
to
go
under
like
a
special
key
or
something,
but
yeah
apparently
is
it.
Is.
B
It
all
signal
yeah.
This
is
this:
is
the
idea
behind
carry-on
written
generically
and
then
the
choice
of
whether
you'd
want
to
propagate
these
context.
Specific
attributes,
as
at
the
boundary
you
decide
to
add
them
into
baggage.
I
mean
that's
it
another
thing
I
need
to
go
read.
F
E
F
Cool,
so
let's
move
on
over
to
our
repo.
B
Some
issues
there
are
some
issues
there
are
I
dumped
things
in
there
there's
just
a
bug
that
I
opened
yesterday.
Motivation
was
there's
a
pr
against
the
new
shiny
hotel
demo
web
store
thing.
People
were
adding
manual
instrumentation
to
the
ruby
service,
because
showing
automatic
and
manual
instrumentation
was
part
of
the
design
goals
for
each
language.
Anyways
somebody
I
noticed
somebody
was
adding
a
rescue
clause
to
the
little
sinatra
app
that
I
wrote
and
I
was
like
that's
kind
of
odd.
I
don't
they
have
like
an
error
handling
functionality.
B
Why
don't
we
automatically
catch
exceptions
when
they're
raised
for
sinatra
and
like
log
them
as
errors?
We
don't
because
sinatra
actually
swallows
exceptions
and
then
says
there
is
an
exception.
Let
me
change
the
http
status
code
and
keep
going,
which
is
probably
what
it
should
be
doing
frankly,
but
our
instrumentation
doesn't
notice
that
and
it
could
and
I'm
wondering
if
we
should.
B
So
that's
what
I
opened
the
issue
about,
it
would
be
a
pretty
trivial
fix,
but
I
didn't
really
know
if
there
was
a
reason
that
we
weren't
already
recording
exceptions
logged
during
the
execution
of
a
sinatra
request.
As
exceptions
on
the
span,
I
don't
know
if
there's
a
reason,
maybe
we
weren't
doing
that.
F
Or
maybe
we
thought
we
were
that
we're
not.
I
think
we
should
try
to
capture
these
things
automatically
if
we
can.
B
Yeah
and
I
think
it
would
be
very
simple
in
the
instrumentation
to
fix-
I
just
I
I
thought
like
this
smells
like.
Maybe
there
was,
maybe
it
wasn't?
Maybe
it
wasn't,
it
was
intentional
somehow,
and
I
just
didn't
want
I
didn't
know
so
if
nobody
comes
up
with
any
reasons
against
it,
I'll
assign
it
to
myself
and
just
knock
it
out
real
quick
soon.
F
I
suspect
this
is
an
oversight
but
cool
anybody
else
want
to
challenge
that
assumption.
E
E
Rails
and
yeah,
I
would
say
it's
probably
nervous.
It's
probably
just
whatever
got
ported
three
years
ago
from
datadog
didn't
have
any
error
catching
stuff
and
no
one
noticed.
C
The
does
the
sinatra,
so
is
the
rack
span
cat?
Have
it
has
the
error
on
it.
B
B
B
That
was
all
I
had
on
this.
There
is
a
related
pr
in
the
demo
web
store
thing
like
you
can
take
a
look
at
it
if
you
want.
I
was
very
nitpicky
on
it,
since
it's
supposed
to
be
a
reference
implementation,
but
yeah
people
are
seeing
that,
like
we
have
an
sdk
and
it
works,
and
that's
kind
of
nice.
F
C
Yeah,
I
got
the
credentials
to
the
user.
I
was
going
to
share
them
with
you
all,
but
y'all
don't
have
any
public
pgp
keys
that
I
could
use
to.
You
know
encrypt
the
password.
So
one
thing
that
came
up-
and
I
don't
know
this
is
possible-
is
we
have
like
a
some
sort
of
like
lastpass
or
one
password
account
for
the
hotel
community?
And
if
we
can't
you
know,
if
we
don't
how?
How
do
we
get
one?
C
Is
there
any
funding
for
it
and
and
that
way
we
can
store
the
credentials
in
there,
but
I
haven't
reset
the
password
yet
I'd
like
to
reset
the
password
when
I
can,
I
did
create
a
new
api
key
specifically
for
the
contrib
repo
to
keep
them
separate,
and
the
only
thing
that
this
week,
I'd
like
to
do,
is
once
we
get
a
couple
of
pr's
merged
just
to
test
the
release
out
to
make
sure
the
release
pipeline
works
the
same
way.
I
have
no
reason
to
believe
that
it
wouldn't.
A
F
Yeah,
I
think
this
whole
situation
shows
the
need
for
definitely
having
like
a
shared
lastpass
or
something
or
what
one
password
or
or
other
secure
way
to
share
credentials.
I
don't
know
what
exists
in
in
the
hotel
community
for
us
today.
I
will
say
there
is
a
there
is
a
maintainers
channel
in
in
the
cncf
slack,
and
this
would
be
a
good
place
to
ask
that
question.
F
So
I
think
you
know
anybody
can
join
that
channel
and
if,
if
you
are
a
maintainer
or
if
you
are
kind
of
in
in
some
maintainery
situations
where
you
want
to
get
get
some
some
input,
that
would
be
a
good
place
to
ask
and
I'm
always
happy
to
ask
some
questions
there
too,
on
on
behalf
of
us,
if
necessary,
but
but
yeah
ask,
I
think,
it'd
be
a
good
question
to
ask
there
and
see
if
people
actually
solve
this
problem
or
if
people
just
start
chiming
and
saying
we
also
have
this
problem
and
then
maybe
that
could
be.
A
C
I'll
I'll
reach
out
on
the
maintainers
channel
then
cool,
and
then
the
next
item
for
me
is
just
a
call
to
action.
Please
review
any
migrated
prs,
because
I
know
that
there
were
some
that
people
had
feedback
on
that
they
asked
to
make
requested
changes,
so
I
just
want
to
make
sure
that
we've
covered
all
of
those.
I
don't
have
the
energy
to
go
back
and
look
at
the
original
pr
and
see
what
the
requested
changes
were.
So
you
know
at
the
risk
of
merging
something
that
shouldn't
be
merged.
C
Please
aren't.
A
F
This
is
the
port
of
yaniv.
B
I
think
I
do
have
some
time
today.
If,
after
your
meal,
yeah
I'll
I'll
message,
you
yeah.
G
C
Look
at
this
community
ex
community
collaboration
for
the
win,
and
I'm
sorry
I
did.
I
missed
the
first
part
of
the
meeting,
so
I
didn't
get
on
the
original
agenda.
But
the
last
thing
that's
like
really
coming
up
is
publishing
library,
instrumentation
library
semcomp.
C
So
this
is
this
is
coming
up
now
internally
here
at
github,
so
I
would
like
for
us
to
try
to
figure
out
some
sort
of
like
way
to
roll
in
instrumentation
library
keys
up
to
the
spec
repo
I
kind
of
based
on
the
situation
with
the
feature
flags
and
with
the
elastic
comments
chemo
and
some
stuff
that
they
talked
about
at
hotel
community
day
yesterday.
C
I
feel
like
the
there's
going
to
be
some
friction
to
try
to
get
things
merged
around
some
comps,
but
I
that's
something
that's
gonna
be
on
my
mind
and
I'm
gonna
be
looking
for
feedback
from
folks
and
some
support
to
see
what
we
could
do
to
try
to
like
wrangle
some
of
this
stuff,
even
if
it
means
essentially
keeping
the
conventions
only
in
the
control
repo
for
right
now,
I'm
not
sure
what
that's
going
to
look
like,
but.
F
Yeah,
okay,
so
this
is
like
semantic
conventions
for
like
active
job
or
things
that
you
know
that
we
care
a
lot
about
that.
Maybe
the
spec
sig
doesn't
care
about.
A
F
And
so
I
yeah,
I
think
I
don't
know
semantic
conventions
are
always
a
tricky
thing.
It
seems
like
the
hotel
community
really
cares
about
them,
but
only
certain
ones,
and
I
think,
when
it
comes
down
to
like
individual
library
stuff,
we
do
need
to
find
some
direction
on
that.
F
But
you
were
suggesting
that
if,
if
these
things
are
not
things
that
are
really
kind
of
appropriate
to
be
managed
at
the
spec
sig,
we
can
begin
to
manage
them
just
in
in
the
language.
Repo
and
kind
of
just
have
our
own
process
around
them,
but
just
kind
of
document
them
and
agree
to
some
stability
around
them
more
or
less.
B
I
do
I'm
trying
to
use
that
feature
more
and
more
okay,
so
yeah.
To
make
sure
I
understand
that
sort
of
maybe
extract
some
of
the
things
that
we
think
actually
should
be
upstream
and
like
make
prs
for
those
and
for
the
things
that
just
nobody
else
plus
is
going
to
care
about.
We
should
manage
them
ourselves
somehow
and
I'm
assuming
like
use
that
as
part
of
the
semantic
convention
gem
auto
generation
process
so
like
it
merges
in
like
the
upstream
ones
in
our
own.
B
C
Just
a
former
it's
like
make
it
so
that
people
know
this
is
what
the
instrumentations
are
generating.
These
are
what
the
keys
are.
If
you
know
we
have
find
appropriate
name
spaces
for
them
and
for
things
that
like
like,
for
example,
I'm
not
sure
about
this,
like
I
have
mixed
feelings
about
it.
But
but,
like
you
know,
an
mvc
set
of
semantic
names
say
semantic
conventions.
C
Is
that
meaningful
useful
as
opposed
to
not
having
them
namespace,
or
should
they
be
specific
to
the
instrumentation?
Or
is
it
enough
to
tell
people?
You
know
what
look
at
the
instrumentation
and
you
gotta
infer
that
semantic
value
from
the
instrumentation
scope
as
a
tuple?
C
You
know
I
it's
a
little
bit
ambiguous
to
me,
so
I
like
for
us
to
at
least
publish
them
some
way
so
that
people
will
know
what
to
expect.
I
B
E
Just
to
butt
in
because
this
has
been,
this
has
popped
up
in
the
past,
which
is
like
before
we
even
worry
about,
like
working
with
the
upstream
semcom
and
and
publishing
our
own
and
offering
any
guarantees
like,
I
think,
just
like
moving
these
things
from
like
strings
to
like
constants
in
some
sort
of
like
you
know,
somewhere
where
we
can
expect
to
find
them.
It's
like
a
low-hanging
fruit
way
to
get
80
percent
of
the
benefits
of
some
kind
without
like
all
the
work,
but
we've
talked
about
this
before
and
yeah.
E
I
think
it's
more.
You
know
devil's
in
the
details,
yeah
yeah
that
but
yeah.
If
you
all
I'll
comment
on
the
issue,
if
you
write
it
up.
F
Yeah-
and
I
think
I
think,
ultimately,
we
can't
be
alone
in
this
situation.
You
know,
I
feel,
like
every
other
language.
Sig
has
got
to
have
some
variant
of
this
problem,
so
I
don't
know
if
we
actually
have
a
concrete
example,
I
guess
of
like
some
framework,
specific
attributes
that
aren't
really
covered
by
semantic
conventions.
F
I
think
yeah
I
I
would
not
mind
like
there
is
a
maintainer's
meeting,
at
least
like
bringing
that
kind
of
up
in
the
maintainers
meaning
as
to
like
how
this,
how
how
we
should
handle
this
in
ruby
and
if
the
sh,
if
there
should
be
a
method
for
handling
this
across
the
language
settings.
H
Sorry,
stable
instrumentation,
that
is
offered
by
open
telemetry
should
not
produce
telemetry,
that's
not
described
by
open
telemetry
semantic
conventions.
So
basically
you
can't
add
additional
things
that
are
not
currently
in
the
spec.
H
You
can
work
around
that
by
saying:
well,
it's
not
stable
or
it's
a
fixed,
schemer
or
whatever,
so
don't
use
the
schema
url.
But
it's
basically,
if
you're
using
the
schema
url,
then
you
have
to
strictly
abide
by
the
spec.
F
H
H
Now
there
are
probably
ways
we
can
work
around
that,
including
some
kind
of
option
that
says
like
enable
extended
instrumentation
whatever,
and
then
we
don't
include
the
schema
url
in
that
case.
So
that's
basically
saying
well,
I'm
emitting
stuff,
but
this
is
not
stable
right.
In
that
case,
we
would
probably
tell
consumers
that
you
can't
rely
on
the
stability
of
these
things.
These
don't
like
this
stability
guarantee
doesn't
apply
if
we're
not
using
the
scheme.
Url.
H
Interesting
there
were
caveats
for
language,
specific
configuration
options,
environment
variables,
things
like
that,
so
I'm
trying
to
find
out
whether
there's
a
carve
out
for
hey.
You
know
you
want
to
like
name
space
things
like
hotel,
dot,
ruby
dot,
yeah,
whatever
yeah
right.
B
H
Yeah
yeah
and
there's
some
job
things
in
general
that
haven't
been
successfully
specced
like
there
was
resistance
to
adding
anything
related
to
background
jobs,
because
can't
you
just
do
it
with
messages
like
doesn't
the
messaging
thing
apply?
It's
like
well.
B
Yeah
well,
that
might
be
something
that
we
we
need
to
champion.
Then,
if
there
is
no
language
specific
carve
out,
maybe
we
propose
that
because
we
have
use
cases
for
it
today
and
it
would
be
nice
if
there's
a
way
to
support
things
like
that
for
things
that
will
never
ever
be
shared
by
other
languages,
yeah,
there's
good
context
to
add
to
the
issue.
I'm
writing.
F
Yeah,
thanks
for
bringing
this
up
francis
things
are
always
more
complicated
than
we
would
like
them
to
be,
but
I
think
I
don't
know
if
there
are
any
stable
instrumentations
across
any
sigs
at
this
point
in
time,
so
I
think
we're
all
probably
getting
by
because
we
are
unstable,
but
if
we
want
to
bring
the
stuff
to
stability,
I
feel
like
this
is
a
a
conversation
we're
going
to
have
to
have
at
some
point
yeah.
H
There's
some
april
2023
deadline
for
all
this
schema,
url
stability,
stuff.
So
past
that
point,
I
think
you
can
make
changes,
but
it's
kind
of
complex,
strictly
speaking,
everything's
supposed
to
be
locked
down
right
now
until
april,
no
new
instrumentation
ever.
F
So
yeah
any
more
discussion
on
this
topic,
or
is
this
something
that
we
just
need
to
have
some
more
discussions
about,
probably
at
a
higher
level
than
just
our
cig?.
A
F
Yeah,
I
think,
if,
if
you
were
going
to
write
up
an
issue
andrew,
if,
if
you
could
do
like
a
quick
survey
and
just
find
some
attributes
that
are
like
kind
of
essential
to
us
like
the
active
job
id,
if
there's
anything
else
in
in
that
vein,
that
we
can
actually
use
as
examples
of
like
we,
we
must
have
this
and
it's
not
at
the
spec
level
like
what.
What
is
the
recommended
thing
to
do?
B
A
I
So
what
I
was
trying
to
show
was
this
very
simple
diagram.
So
it's
just
like
the
the
rough
structure.
There
was
a
lot
well,
not
a
lot.
There
was
a
bit
more
previously
and
I've
kind
of
pruned
it
down
a
bit
after
talking
with
francis
for
a
bit,
but
this
is
like
an
easy
high
level.
Talking
point.
I
I
Now,
there's
some
kind
of
like
disconnection
between
the
two
so
right
now
this
is
trying
to
show
kind
of
like
prioritizing
the
fast
paths,
so
the
fastest
path
being
meter
provider
meter
instrument.
So
your
instrument
needs
to
be
able
to
record
its
metrics
very
quickly
right,
so
we
wanted
to
kind
of
prune
down
any
kind
of
intermediary
steps.
So
right
now,
if
you
have
a
single
instrument
with
a
single
metric
reader,
it'll
have
a
single
metric
stream.
I
The
metric
reader
will
have
what
I've
called
the
metric
store
and
I
can
show
this
time
permitting
what
it
kind
of
roughly
looks
like,
but
it's
essentially
just
a
collection
of
different
metric
streams
with
the
associated
data
you
needed
to
export
it,
so
you
can
actually
identify
the
metric,
so
the
instrument
will
say:
if
you
have
a
calendar,
it
says
increment
or
add
it'll
produce
directly
to
all
of
its
metric
streams.
In
this
hypothetical
example,
we
only
have
one
if
you
have
varied
labels
or
attributes
as
they're
called
you'll.
I
Have
multiple
data
points
right,
so
you
think
of
like
whatever
bounded
cardinality
or
unbounded
cardinality
metric.
You
have
that'll,
be
your
collection
of
data
points
within
the
data
stream
now
for
the
ideally,
this
would
be
like
number
two
in
terms
of
second
fastest
in
terms
of
priority
is
reading
these
metrics
and
exporting
them.
I
So
again
you
have
your
one
or
many
metric
reader
it'll
collect
from
its
metric
store,
which
will
have
many
metric
streams
from
there.
It's
going
to
literally
just
pull
this
object.
That
has
its
many
data
points
and
then,
whether
you're,
going
through
prometheus,
console.log
or
otlp
it'll
transform
that
data
into
the
right
structure,
and
so
you
kind
of
have
this
high
level.
This
is
like
this
is
my
my
instrument.
It
has
a
name
description,
maybe
a
unit
you
have
the
beater,
which
is
your
instrumentation
scope.
I
I
You
have
to
say,
hey
meter
provider,
how
many
metric
readers
do
I
have,
and
if
you
have
many,
you
need
to
collect
all
the
metric
stores
and
create
a
new
instrument
or
a
new
metric
stream
for
each
metric
store.
So
there
is
a
bit
of
like
redundancy,
so
your
metric
readers
have
many
or
many
metric
readers,
each
with
one
metric
store,
and
then
your
instrument
is
going
to
have
a
reference
to
those
metric
streams.
I
So
if
you
have
two
metric
readers,
your
instrument
will
have
two
metric
streams
and
each
one
gets
stored
in
the
corresponding
metric
store
in
the
other
direction.
If
you
have
all
your
instruments
registered
at
boot
time
and
for
some
reason,
let's
say
during
the
life
of
your
application,
you
add
three
more
metric
meters
for
each
metric
reader
gets
created.
You
have
three
more
metric
stores,
which
means
it
needs
to
either
iterate
through
all
the
meters
find
each
instrument
and
create
a
new
stream.
I
So
this
is
the
slow
path
and
I
can
jump
to
the
code
a
little
bit
here
to
kind
of
illustrate
what
that
might
look
like
or
what
it
currently
looks
like.
I
should
say
so.
The
interesting
bit
is
so
we'll
look
at
the
metric
stream
here.
So
this
is
what
I
was
saying
when
it
has
some
of
the
information
right.
So
it
knows
what
your
instrument
is.
The
description,
the
unit
it
needs
to
know
the
kind
for
exporting
the
data
the
resource
needs
to
be
there.
This
is
probably
going
to
move.
I
We
can
recap
that
later
it
needs
to
know
the
instrumentation
library,
because
part
of
the
export
format
is
similar
to
tracing
where
it's
like
you
group,
by
resource,
then
you
group,
by
scope.
So
now
you
have
your
your
data
points.
This
is
all
very
much
hard
coded
to
work
with
a
counter
I'm
currently
working
through
changing
that,
so
it
works
with
the
other
instrument
types
again.
The
focus
of
this
is
very
much
on
the
synchronous
instrument,
creation
and
right
path.
I
So,
as
you
get
different
attributes
right,
so
you
have
your
different
kind
of
labels.
You'll
you'll
have
different
measurements
that
get
captured
here.
I
Now,
if
we
look
at
the
metrics
store,
so
a
metric
store
class
is
a
collection
of
metric
streams
right.
If
we
go
back
to
the
diagram,
metricstore
is
associated
with
the
metric
reader.
The
reason
for
that
is,
if
you
have
multiple
metric
readers,
one
reader
might
read
at
a
different
interval
than
the
other
and
they,
depending
on
your
aggregation
type,
say
you
have
kind
of
like
the
delta
aggregation,
it'll
breed
and
then
drop
all
the
data
right.
I
That
doesn't
work.
If
you
have
multiple
metric
readers,
so
you
do
need
to
duplicate
kind
of
this,
the
stateful
information,
so
you're
recording
to
multiple
places
if
you're
using
multiple
metric
readers
again,
this
is
just
hard-coded
stuff.
I
did
just
kind
of
like
a
brain
dump,
so
I
could
discuss
it.
This
is
actually
getting
removed
right
away
if
we
zero.
If
we
go
to
the
meter
provider,
this
is
roasting,
saying
that
it's
like
a
little
bit
slower.
I
If
you're
going
to
add
a
new
metric
reader,
you
you
have
to
go
through
all
of
your
meters
and
then
you
have
to
go
through
each
instrument
and
then
from
there
you're
gonna
take
the
instrument
you
have
to
register
with
a
new
metric
store
so
that
that
way
you
have
that
association.
Again,
there's
there's
potential
here.
I
haven't
kind
of
gone
through
all
the
edge
cases
of
like
potential
race
conditions
where
this
might
not
work.
I
If
we
go
to
meter
where
we
have
our
instrument
creation,
where
it's
going
to
be
my
look
at
my
synchronous
instrument,
so
when
you,
when
you
initialize
a
new
instrument
again,
you
have
to
look
through
all
of
your
metric
readers
and
you
have
to
register
with
a
new
metric
store.
So
you
have
to
say
so
like
it's,
these
two
directions,
whether
you're
creating
a
new
instrument
or
a
new
reader.
You
have
to
make
sure
that
all
the
associations
happen.
I
I
Now
you
need
to
be
able
to
say
what
am
I
there's
some
missing
information
here,
because
you
need
to
specify
the
aggregation
type
so
again,
this
is
very
much
hard
coded
just
for
like
a
counter,
but
it
makes
sense
here
that
you'd
be
able
to
simply
pass
in
what
aggregation
type
is
associated
with
your
instrument
same
here
for
your
histogram,
none
of
the
observable
stuff.
I've
done
counter
the
same
idea,
I'm
kind
of
not
trying
to
think
about
the
asynchronous
instruments
too
much
yet.
I
But
I
assume
they'll
follow
a
similar
structure
in
an
asynchronous
fashion,
trying
to
think
of
what's
worth
showing
here,
but
also
possible
that
people
ask
questions.
B
The
amount
of
duplication
and
locking
and
stuff
is,
I
guess,
annoying,
but
do
we
think
that
it
will
be
it's
a
slow
path,
but
do
we
think
people
are
actually
going
to
encounter
that
very
often
my
general
understanding
of
how
you
were
supposed
to
use
the
metrics
api?
Was
that,
like
you,
don't
dynamically,
add
lots
of
readers
and
things,
even
though,
of
course,
rubios
will
probably
find
a
way
and
a
good
reason
to
do
so?
B
But
you
know
every
example:
I've
ever
seen
like
from
the
golang
docks
is
sort
of
like
it,
creates
all
of
its
meters
up
front
and
passes
them
around
and
things
or
creates
all
of
its
instruments
up
front
and
passes
them
around
you're.
Not
like
you.
You
pay
the
penalty
at
startup.
Basically,
do
you
think
that
that's
going
to
be
the
same
thing
here
or
do
you
think
it's
worth
investing
in
making
it
more
efficient,
because
we
think
people
are
going
to
be
doing
this
dynamically.
I
I
don't
think
so.
I
think
that,
even
if
you
follow
the
documentation
for
best
practices
around
your
instruments,
your
your
instrument
is
instrumentation
should
all
be
registered
upfront
and
just
like
when
we
configure
the
sdk,
it
should
all
be
done
up
front
right,
like
I'm
sure
there
may
be
some
somewhat
valid
use
case
for
registering
a
spam
processor.
I
However,
long
later
into
your
application's
lifecycle,
maybe
there's
a
reason
for
it.
I
think
it's
obvious
that
we
have
to
support
it.
It's
the
same
thing
for
me
metrics,
but
there's
going
to
be
a
slow
path
somewhere,
and
we
should
probably
push
it
towards
registering
new
things
again,
like
the
best
practices
around.
It
are
going
to
be
your
instrument.
You're,
like
you
know
what
instruments
you
want
up
front
or
you
should
you
register
them
everywhere,
but
again,
like
we
still
need
that
flexibility
around
the
actual
life
cycle
of
booting
up
your
application.
I
There
will
probably
be
some
nuance
in
different
people's
applications
where
something
happens
a
little
bit
after
something
else
and
again
throughout
that
whole
boot
life
cycle,
it's
it
should
be
a
little
bit
forgiving.
You
have
yourself
muted.
I
think.
B
I
This
is
a
big
copy
paste,
but
it's
nice
because
the
otlp
http
metrics
exporter
is
a
copy
paste
of
the
trace
exporter,
which
means
that
I
can
probably
simplify
that
and
prove
it,
but
for
what
I'm
doing
here
as
a
test,
it
just
works
like
if
you
were
to
pull
this
down
and
run
a
collector
locally,
you
could
run,
for
example,
this
test
and
you'll
have
metrics
show
up
in
your
collector.
I
So
it's
obviously
just
stubbing
in
some
of
the
data
and
things
like
that
and
the
the
encoding
is
not
complete.
It's
again
very
much
just
set
up
for
some
like
your
counter,
but
again
getting
the
structure
right
and
trying
to
understand
like
the
data
better,
so
that
how
it
structured
memory
before
exporting,
we
can
try
to
again
prioritizing
recording
measurements,
but
also
try
not
to
make
the
export
path
too
brutal.
I
Like
this
looks
pretty
much,
what
like
prometheus
will
look
like
your
exposition
format,
you're
gonna,
take
your
your
stream
you'll.
Look
through
your
data
points,
you'll
aggregate,
some
data
before
and
you'll
spit
out
a
bunch
of
lines
like
I
I
have
that
there
for
for
debugging
purposes,
you
can
like
print
out
your
metric
stream
and
that's
again,
I
used
prometheus's
exposition
format
as
inspiration
for
this.
It's
probably
not
one-to-one
like
I
didn't
actually
read
the
spec.
B
Yeah
looks
very
cool.
It
looks
very
like
there's
a
lot
a
lot
of
work
done,
it's
very
as
it's
a
lot
of
code.
What
do
you
see
is
what
the
next
steps
are
like.
I
I
think
that's
still
a
little
rough
so
like
I'm
trying
to
do
some
hard
boundaries
around
synchronous
instruments.
I
The
in-memory
state
I'd
like
to
maybe
not
api
compliant
perfect
metric
readers,
but
I'd
like
to
have
like
creating
instruments
and
then
collecting
that
done
and
then
from
there
it's
like
finalizing
the
otlp
exporter
will
be
its
own
pr.
I
Observable
instruments
will
be
its
own
pr
views
zone,
pr
things
like
that,
then
there'll
be
I'm
sure,
multiple
iterations
of
api
kind
of
compliance
checks,
but
it's
still
pretty
rough,
but
I
think
I'm
getting
pretty
close
now
to
having
it
to
a
point
where
I
can
say:
hey,
let's
review
this:
let's
make
sure
it's
good,
let's
merge
it,
then
we
can
like
pull
in
people
working
on
different
exporters,
what
kind
of
turbo
instruments
and
views?
I
I
I
think
the
two
big
like
carvable
pieces
are
going
to
be
the
observable
instruments
and
the
views
and
then
various
exporters,
so
I'm
trying
to
like
make
get
kind
of
the
real
guts
of
this
thing
done
right.
So
right
here,
like
I
brought
it
here,
is
because,
like
this
is
the
part
I'm
working
on
right
now,
primarily
it's
just
what
needs
to
be
collected
like
what
needs
to
happen
in
collection
like
how
do
I
actually
want
to
capture
that
data,
like
I'm
realizing?
I
Now
that,
like
you,
the
the
start
time
and
the
end
time,
so
your
end
time
is
not
they
don't
call
it
end
time
in
the
proto.
They
call
it
just
time,
unix,
it's
not
optional,
whereas
the
start
time
is
optional,
but
strongly
encouraged,
because
when
you're
doing
these,
these
collections
in,
like
like
you're
collecting
everything
at
once,
like
really
you
can
do
it
at
a
higher
level
and
just
like
pass
it
into
your
metric
stream
streams,
you
don't
need
to
kind
of
independently
track
these
things.
I
So
I'm
thinking
what
this
collection
path
is
going
to
kind
of
look
like
is
like
there'll,
be
probably
a
collect
method
on
your
metric
stream.
That's
going
to
do
whatever
it
needs
to
do
to
support
the
different
aggregation
types,
whether
it's
cumulative
or
delta,
so
it'll
probably
have
to
do
a
duplicate
of
something
and
structure
a
little
bit.
Maybe
a
little
bit
different,
initially
I
illegally
was
hoping.
I
could
just
like
pass
the
raw
object,
but
I
don't
think
that'll
work
but
yeah.
I
So
I'm
just
kind
of
working
through
this
like
collection
path
right
now
and
then
once
that
gets
a
little
bit
more
solidified
I'll
backfill
the
instruments
and
then
passing
in
kind
of
like
what
kind
of
aggregation
that
they
should
be
doing
like
supporting
things
like
drop
and
some
to
start
and
then
leaving
some
of
the
other
ones
out
and
I'll
pause
again
here.
B
B
But
you
know
it's
okay,
if
there's
parts
of
it
that
should
be
done.
That
aren't
yet
in
the
initial
thing
that
was
just
as
a
encouragement.
I
guess
it's
a
big
big
project
so
like
it's,
okay,
if
it
comes
in
bits
and
pieces
throughout
the
throughout
the
weeks
and
months.
I
Yeah,
like
things
like
the
exporter,
I
know
it's
in
this
pr
now,
but
I'll
probably
rip
it
out
and
make
it
a
separate
pr
later.
It's
just.
I
wanted
to
just
push
everything
I
had
up
so
if
anyone
wanted
to
like
stab
at
it,
because
their
cures
like,
namely
francis,
if
yeah
so
but
I'll,
pull
that
out,
because
I
don't
think
it
needs
to
be
part
of
this
pr,
but
I
do
think
some
sort
of
structured,
stabilized
or
semi-stable
metric
reader
kind
of
interface
should
be
in
there
again
synchronous
instruments.
I
I
I
am
happy
a
lot
happier
with
that
how
it
is
right
now
than
I
have
with
previous
iterations,
so
I
think
it's
getting
close
and
like
even
just
like
configuring
new
instruments
like
I
don't
have
an
abundance
of
tests,
but,
like
things
like
this,
like
this,
like
an
in-memory
metric
poll
exporter,
that's
like
a
reader,
an
exporter
in
one,
and
you
can
kind
of
yank
out
snapshots
snapshots
of
your
metrics
and
test
them
like
these.
Things
are
all
working
like.
I
Creating
instruments
works
configuring
the
sdk
works,
so
it's
in
a
pretty
good
spot
for
improvement
on
and
or
over
time.
So
I
won't
be
offended
if
anyone
jumps.
F
Thanks
for
the
walk
through,
I
just
my
my
only
last
question
and
then
we
can
break,
I
guess
is:
have
you
mainly
just
been
going
through
the
spec
and
kind
of
writing
this
or
have
you
been
looking
at
other
implementations
for
inspiration?
I
I
have
looked
at
a
few
other
ones.
I
looked
at
the
go
one
and
I
was
kind
of
like
confused.
It's
not
easy
to
follow.
I
Javascript,
I
find
to
be
the
same.
I
I
think
it's
just
like
the
nature
of
how
like
javascript
is
kind
of
written.
I
find
there's
a
lot
of
like
interaction
abstractions
that
are
just
by
nature
hard
for
me
to
follow,
like
it's
just
you
feel
like
you're,
always
bouncing
between
like
12
different
files,
but
this
does
have
some
some
parity
with
the
go
and
javascript
just
like
how
I
think
they
both
have
this
kind
of
concept
of
an
asynchronous
instrument
they
keep
track
of,
where
they're
writing
their
metrics
to.
I
I
think
wander
both
have
like
this
concept
of
like
a
view
compiler,
so
it
takes
all
the
views
and
it
does
something
to
make
it
more
efficient
for
writing,
because
the
view
can
split
a
single
metric
stream
into
many
well,
I
think
a
single
view
can
take
an
instrument
and
have
it
create
multiple
metric
streams.
So
again,
like
views
is
another
big
chunk
that
I've
kind
of
ignored,
without
trying
to
completely
like
fork
this
implementation.
So
adding
views
will
be
a
nightmare
later.
I
don't
think
it
will
be.
I
I
think
that,
like
views
get
probably
jammed
in
somewhere.
I
I
Php
didn't
have
much
when
I
looked
java
was
hard
to
follow
as
well
says.
Yes,
sorry
to
answer
your
question
yeah
I
did.
I
did
definitely
look
at
them.
I'm
not
mirroring
them
too
closely,
but
I
am
trying
to
draw
inspiration.
I
I
think
there
there's
some
like
reasonable
consistency.
There.
F
Cool
yeah,
I
don't
know
that
anybody
loves
their
implementation,
so
I
think
it's
a
good
idea
to
not
just
like
blindly
copy
another
one.
I
was
just
kind
of
curious,
yeah,
just
kind
of
curious.
What
the
methodology
behind
this
is.
It's
somewhat
comforting
to
know
that
you
are
at
least
reasoning
through
this
and
coming
up
with
something
that
that
you
and
probably
francis
thinks,
makes
sense.
F
H
The
spec
is
very
dense,
much
more
dense
than
the
tracing
spec
and
the
existing
implementations,
for
example,
in
go.
H
Don't
like
they're
different
enough
from
the
spec
that
it's
hard
to
look
at
them
side
by
side
and
infer
anything
about
how
we
should
be
structuring
things.
So
yeah
we're
trying
to
reason
through
it
from
the
spec
and
then
like
going
and
looking
at
the
the
existing
implementations
and
then
taking
whatever
inspiration.
We
can,
but
mostly
trying
to
stick
as
close
to
the
spec
as
possible.
H
Right,
the
python
implementation
it
looked
like
it
was
about
to
go
through
a
huge
rewrite
to
more
closely
match
the
spec.
I
would
guess
so
yeah
they
were
deleting
stuff.