►
From YouTube: 2022-11-03 meeting
Description
Instrumentation: Messaging
A
A
A
Right,
it's
like
a
little
off
and
it
gets
really
off
yeah
like
Morgan
I,
don't
know
if
he
still
does
this,
but
I
think
he
does
like
he
has
like
his
own
I.
Don't
know
it's
a
DSLR,
it's
like
a
mirrorless,
but
he
has
like
an
external
camera.
He
hooked
up
and
I
did
like
the
same,
but
it's
just
like
so
much
of
your
office
that
becomes
like
a
recording
studio.
It's
like
made
me
feel
like
on
Twitch
or
something
it
makes
sense,
but
I
just
I,
don't
know
I.
C
B
A
B
A
B
A
That's
what
I
heard
like
was
the
biggest
difference
in
this
one
is
like
you
go
to
like
the
last
kubecon
they
had.
Even
the
one
in
Valencia
was
like
all
the
booths
are
still
talking
about.
Like
you
know,
compute
cycles
and
like
optimization
that
kind
of
stuff
and
like
I
was
you
know,
Morgan
was
saying
like
every
Booth,
pretty
much
had
like
an
observability
tagline
to
it
in
a
you
know,
open
summature
as
a
part
of
that.
B
A
D
E
A
Like
you
know,
like
it'd,
be
really
cool
if
there
could
be
a
rating
system
like
if
it's
a
user
rating
system,
it
could
be
really
cool.
If
it's
like,
you
can
run
tooling
to
check
semantic
compatibility
of
instrumentation
to
see
like
if
things
are
correctly
set
up
like
I.
Don't
know
it
just
seems
like
another
one
of
like
downloads.
If
you
could
like
show
how
many
times
a
particular
you
know,
library's
been
used
like
that'd,
be
really
cool,
but
even
just
like
the
user.
A
One
is
like
really
neat
because,
like
yeah,
if
you
see
an
instrumentation
package
and
it's
got
one
star
or
like
two
one
and
a
half
Stars,
that's
right,
it's
like
people
use
this.
It's
just
not
good
right
versus,
like
now.
You're,
just
like
I
have
no
idea.
If
people
even
use
this
package,
like
I'm,
gonna,
I,
guess
I
go
check
out
the
GitHub
repo,
but
yeah.
B
C
A
A
A
C
A
A
Cool
okay,
awesome.
So
to
start
things
off,
I
have
a
few
things
on
the
agenda
right
now,
if
you
have
things
like
I
was
saying,
go
ahead
and
add
them
started
off.
I
wanted
to
bring
up
this
PR
I've
had
open
for
a
while
now
exactly
a
month.
Man
time
flies.
So
this
is
about
restructuring
the
instrument
instrument,
creation
code
paths,
so
appenders.
To
give
you
an
overview
of
this,
the
existing
instrumentation
provider.
A
We
set
this
up
and
it
works,
but
I
was
noticing
you
know
if
you
look
through
each
of
these
different,
essentially
creation
methods.
There's
a
lot
of
repeated
code
here-
and
you
know
that
is
kind
of
outlined
here.
There's
like
I,
think
five
things
I
identified
that
it
does
and
really
the
thing
that
is
unique.
A
Is
this
part
where
it
essentially
says
the
kind
based
on
what
kind
of
Provider
it
is
and
what
kind
of
instrument
you're
actually
creating
is
is
really
the
only
unique
part
of
this,
and
so
what
this
PR
does
is
like
the
main,
the
meat
and
potatoes.
If
you
will
of
this,
is
it
abstracts
this
into
this
unified
single
single
instrument,
provider
and
the
system
provider?
Has
this
method
for
lookup,
which
you
probably
know
where
this
is
going?
A
It
also
takes
in
these
different
kinds,
as
well
as
the
name
of
the
options,
and
it
unifies
that
into
just
the
instrument
kind
here,
so
it
essentially
puts
it
into
a
centralized
location
which
is
really
useful
because,
like
in
other
PRS
already,
we
already
have
to
like
change
this,
and
so
like
say
for
here
like
we're,
returning
empty
eggs
means
that
these
are
all
draw
bags,
and
so
maybe
we
want
to
actually
change
this
error
handling.
Here
we
have
a
centralized
place
to
do
this.
A
It
also
allows
us
to
if
you
didn't
guess,
cache
this
a
lot
easier,
because
the
centralized
place
to
do
the
caching
and
so
yeah
this
it's
also
just
like
simplifies
all
of
this.
You
know,
like
one
provider
now,
all
of
a
sudden
just
has
like
these
simple
methods,
because
it's
just
wrapping
this
internet
provider.
A
So
that's
a
lot
of
the
the
cleanup
that's
going
on
here,
there's
a
few
more
things
that
I've
included
because
of
this
they
kind
of
just
fall
out.
One
of
the
things
also
is
that,
like
this
ability
right
now
is
like
when
we
ask
for
an
async
answer
at
async
float
instrument
provider
we're
creating
a
new
one,
each
time
which
isn't
like
the
end
of
the
world
because,
like
this
is
probably
happening
during
instrument
setup,
but
it
also
is
going
to
be
allocating
this
slice
to
the
stack,
oh
sorry
to
keep.
A
It
may
already
be
allocated.
You
know
after
the
first
time,
but
it
really
doesn't
need
to
be
done.
So
what
this
does?
Is
it
also
just?
It
replaces
the
meter
instrumentation,
which
already
stores
a
resolver,
and
it
will
just
wrap
that
resolver
now
with
an
instrument
provider,
it
looks
really
similar
to
I
was
just
looking
at
this
this
one.
A
That
might
not
be
the
right
way,
but
let's
see
yeah
so
like
right
now.
It
just
already
has
these
that
it'll
use
and
these
just
become
instrument
providers
instead.
So
it's
it's
very
similar.
It
abstracts
it.
There
is
a
performance
Improvement,
it's
slight!
It's
included
in
here.
You
can
look
at
the
docs.
It's
not
really
like
the
big
meat
and
potato
part
of
this
PR.
A
A
That
like
this,
could
become
something
else,
but
this
is
included
in
this
PR
as
well,
just
to
kind
of
like
help
clarify
that,
and
it
also
helps
clarify
that
is
a
provider
that's
getting
created
here
and
then
the
last
thing
is
just
the
scope
becomes
somewhat
redundant,
given
it's
only
ever
used
in
the
inserter.
So
it's
not
sort
of
the
meter
anymore.
It's
just
stored
in
the
instrument,
scope,
so
kind
of
a
heads
up
on
that.
A
A
E
A
Correct
yeah,
it's
all
internal
I,
don't
know
if
you
can
see
it
from
files.
No,
you
can't
see
it
for
files,
but
it
is
it's
all
internal.
If
it
does
change,
then
let
me
know
one
of
the
things
that
it
does
allow
us
to
easily
do
I
think
it's
this
PR
yeah.
So
right
now
we
have
this
metrics
SDK
caching
thing
and
one
of
the
last
things
that's
kind
of
mentioned.
Is
this
cache
instrument
provider
result?
A
It's
not
something
that's
like
required,
but
if
you
take
a
look
at
essentially
what's
already
happening
like
in
each
well
I
guess
we
could
just
look
at
the
actual
one.
One
of
these
is
being
returned
to
this
new
reference
to
these
aggregators.
It's
not
the
end
of
the
world.
These
are
actually
like
a
big
part
of
like
the
work
that
we've
already
completed
and
released
in
the
past
two
release.
Cycles
is
unifying
these
aggregators
to
make
sure
that
if
they
are
the
same
as
what's
already
been
issued,
they're
included
here.
E
A
A
Or
12
I
think
yeah.
There's
a
lot
of
places.
I
think
there
was
okay.
Next
up,
I've
got
this
proposal
that
I
mentioned
in
the
slack
channel.
That
goes
over
a
replacement
for
the
view.
Implementation
I
wanted
to
talk
about
I,
know,
Aaron's
read
this
Anthony
I
think
is
also
plus
one.
This
I
don't
know
if
everyone
else
on
the
call
has
taken
a
look.
A
Currently
the
view
package
is
like
this:
it's
there's
a
lot
of
options
and
I
think
this
comes
from
this
idea
that
we
actually
need
to
do
a
lot
of
matching
and
a
lot
of
replacements,
and
so
that
can
either
pollute
the
SDK
metric
package
or
it
can
be
in
its
own
package
and
we
definitely
don't
I,
think
it
was
right,
try
to
split
it,
but
I
also
think
that
if
we
can
more
concisely
Define
the
new
definitions,
it
would
remove.
This
need
to
have
the
view
packages
being
this
namespace.
A
If
you
can
just
easily
just
say,
like
you
know,
there's
going
to
be
like
three
things
or
five
things
or
some
some
not
like
infinite
number
of
things
that
are
going
to
be
added
to
the
SDK
metric
package.
It
makes
it
a
lot
easier
to
include
it
there
because
of
this
split.
It
also
means
this
like
I've.
Had
this
package
needs
to
include
this
instrument
and
instrument
kind
type,
which
are
really
concepts
of
the
metrics
package.
South
the
SDK
metrics
package
But.
A
It
includes
an
import
cycle
if
you
include
them
in
the
SDK
metrics,
because
that's
going
to
import
the
views,
which
is
then
also
importing
the
metrics
package,
so
there's
this
Import
Cycle,
which
goes
away
if
we
can
resolve
this
like.
If
you
can
simplify
this
so
that
this
package
doesn't
have
to
exist,
they
could
all
find
their
way
into
the
SDK
metrics
package.
A
This
is
I
think
the
thing
that
people
are
really
kind
of
wanting.
This
starts
to
build
sprawl
like
I,
definitely
like
when
we
did
the
the
ghost
sequel
Hotel
go
SQL
other
instrumentation.
We
had
to
do
like
a
bunch
of
views
to
do
like
renames
like
that
function
to
Define
all
those
renames
with
error,
handling
turned
out
to
be,
like
you
know,
50
or
80
wise,
or
something
like
that,
and
it's
like
they
didn't
need
to
exist.
A
Don't
get
me
wrong
but,
like
let's
just
say
like
you
want
a
user,
that's
wants,
like
you
know,
send
views
like
it's
going
to
take
a
lot
of
code
to
actually
Define
those
views
and
I.
Think
it's
a
little
bit
harder
to
then
separate
as
to
like
where
those
users
are
defined
versus
where
they're
used
and
it
would
I
think
make
people
easier
to
like
Define
them
as
well
as
to
like
use
them.
A
A
The
error,
handling
system
of
hotel
and
I
think
I
think
that
this
could
be
resolved
by
just
using
implicit
errors
and
using
the
logging
system
to
Define
this,
because
I
think
this
is
a
worthwhile
thing
to
try
to
resolve,
but
just
kind
of
raising
one
of
the
issues
that
this
is
trying
to
resolve.
Just
so
everyone
understands
it,
the
multiple
user
options
also
is
a
little
bit
confusing
and
this
kind
of
goes
back
to
the
simplifying
of
design.
Currently,
it's
not
like
this
is
I.
A
Think
one
of
the
bigger
issues,
but
it's
just
something
to
kind
of
like
raise
and
point
out
that,
like
this
new
function,
definitely
has
a
precedence
of.
If
you
pass
the
same
option
twice,
the
second
one
is
going
to
be
used
or
the
last
one
is
going
to
get
used
right,
and
this
is
kind
of
a
natural
consequence
that
some
of
these
things
can
only
be
defined
once.
A
But
the
problem
is
that,
like
it's
not
like
the
big
problem,
people
need
to
read
the
docs
and,
like
you
can
kind
of
expect
users
to
have
to
read
the
docs
to
understand
this.
But
it
also
is
not
intuitive
like
if
somebody
wants
to
match,
you
know
say
like
both
the
foo
and
the
bar
instrument,
and
they
want
to
drop
them
like
it
seems
reasonable
that
they
would
also
just
pass
like
match.
Name
this
match
name
this
and
then
do
this
action.
A
A
It's
just
that,
like
the
view,
is
not
extendable
by
users
currently,
and
so,
like
I
I
mean
we
feel
that
a
lot
of
issues
in
this
project
when
users
come
up
with
things
that
we
don't
anticipate
beforehand,
that
they
want
and
I
think
we
kind
of
discussed
this.
You
know
like
one
of
the
big
ones
was
like
a
unit
like
matching
a
unit
or
using
a
unit
and
a
replacement
like
you
know,
it's
just
something
that
we'll
have
to
add
at
a
later
point
in
day.
A
So
those
are
kind
of
the
issues
so
from
there
like
this
proposal
fell
out.
I
played
with
this
for
a
little
bit
and
it's
it's
getting
close
I
think
that
maybe
there's
some
some
issues
to
think
about
as
well,
but
to
start
off
the
the
instrument
and
Israel
kind.
Just
move
to
the
SDK
metrics
package
like
this
is
going
to
resolve
it
by
putting
everything
into
the
sdks
metrics
package.
So
this
Import
Cycle
goes
away
when
you
move
it
over.
A
This
instrument
kind
actually
gets
redefined
as
being
anything
that
all
of
all
of
the
properties
that
an
instrument
is
created
with
so
that
includes
the
unit
includes
the
kind
like
the
scope
is
already
kind
of
there
as
well.
The
matching
criteria
but
like
it
includes
all
of
the
properties
right
that
you
would
actually
want
to
match
or
that
exist
at
instrument
creation
time.
Essentially,
it
fully
specifies
the
instrument
just
for
a
heads
up
this.
A
There
is
a
complete
example
here
and
it's
I
don't
know
15
000
lines
or
1500
lines,
so
I
didn't
want
to
like
just
shove.
This
down,
everyone
started,
say
like
this
is
what
we
should
do
and
it
changes
to
a
draft
I've
got
a
proposal
at
the
end
to
fix
this,
but
one
of
the
things
I
just
wanted
to
point
out
here
is
that
in
the
in
this
process,
I
also
say
like:
let's
make
this
not
comparable
right
off
the
bat.
A
A
If
they
want
to
do
regex's,
they
can
go,
do
it
if
they
want
to.
They
want
to
I,
don't
know,
take
a
unit
from
the
instrument
and
add
it
to
the
description
and
take
that
whole
description
and
hash.
It
and
I
I,
don't
know
like
you
just
like
they
could
use
all
kinds
of
crazy
things
or
as
simple
things
as
they
want,
and
it's
it's
really
open
to
them.
A
A
The
problem
is,
is
that
this
doesn't
like
allow
for
the
recreation
of
common
things
like
renames
aggregation
settings,
that
kind
of
stuff-
and
it
also
doesn't
like
provide
some
of
the
nice
cities
that
otel
specifies
and
namely
the
Wild
Card
matching.
So
with
that,
I
think
that
we
can
solve
those
by
using
this
Creator
or
creation
function.
New
View,
which
would
do
that
this
takes
a
matching
criteria
to
take
some
sort
of
output
mask.
Both
of
these
parameters
are
complete
in
that
they
only
Define
if
they're
non-zero
values
are
defined.
A
A
Don't
we
want
to
Define
this
as
our
standard
option
pattern
here
and
I
think
this
is
where
you
have
to
ask
yourself
like:
when
is
a
user
going
to
be
passing
an
emcee
Instagram
or
an
empty
stream
and
I
think
the
only
time
I
can
think
is
valid?
Is
I
can
test
otherwise
like?
Why
are
they
defining
a
stream
in
the
first
place
place,
and
that's
not
a
that's,
essentially
the
The
Uncommon
position
that
people
will
actually
be
using.
A
This
is
well
unseen,
as
as
far
as
I
can
tell,
and
so
I
think
that,
because
we
already
know
completely
that
they
need
to
be
passing
some
sort
of
matching
criteria
and
some
sort
of
you
know
replacement
or
mask
criteria,
and
we
can
Define
this
concretely
with
parameters
that
are
extensible.
Both
the
instrument
and
the
stream
are
defined
non-comparatively
and
since
they
only
are
used,
the
the
non-zero
values
to
actually
have
any
effects
like
adding
another
field
to
this
doesn't
actually
have
any
problem
with
forward
compatibility.
A
I
think
that
there's
also
an
important
thing
to
point
out
is
that,
like
this
doesn't
return,
an
error
as
well
I
think
that
it
gets
rid
of
a
few
of
the
errors.
Aaron
pointed
out
that
there's
still
an
error,
that's
exists
in
where
you
have
an
instrument
criteria
that
matches
multiple
instruments
and
the
stream
defines
a
rename.
The
specification
says
that
should
not
be
allowed
and
I
think
that
what
we
can
do
similar
again
to
if
the
stream
provides
an
aggregator
that
has
an
error.
A
E
B
A
A
Provides
that
like
it,
it
won't.
Let
you
do.
You
know
a
multi-match
instrument
to
a
rename
there,
because
we're
gonna,
we're
gonna
say
like
oh,
the
spec
says,
like
that's,
probably
an
error
that
you
don't
actually
want.
So
we're
gonna,
we're
gonna,
put
those
guardrails
in
place
for
you,
but
I
think
that
like
if,
if
you
do
that
and
then
a
user
says
like
whoa
like
what
are
you
talking
about
like
I?
Have
these
two
instruments?
A
I
know
what
they
are
they're,
both
sums
they're,
just
you
know
named
incorrectly
I,
want
I
want
to
merge.
Those
I
actually
want
to
do
that.
I
want
to
override
that
like
then
it
becomes
an
argument
of
like
well.
Okay,
like
does.
Does
the
hotel
Community
like
really
need
to
be
asserting
some
sort
of
dominance
and
saying
that,
like
your
coach,
should
never
be
allowed
to
do
that
like
I?
A
Think
that's
a
great
way
to
like
have
people
want
to
fork
and
just
go
build
their
own
instead
of
saying,
like
you
know,
like
hey
like
okay,
if
you
want
to
go
outside
of
the
guardrails
here,
you
go
like
here's
the
tools
you
can
go,
do
what
you
need
to
do.
If
you
want
the
guardrails,
the
new
view
function
allows
that.
Does
that
make
sense.
E
I
think
so
I
I
just
worry
that
potentially
some
of
those
restrictions
were
created
to
ensure
correctness
and
if
we
give
users
an
easy
way
to
get
incorrect
data.
They're
gonna
be
upset
about
that
too,
when
they
realize
that
the
thing
they
wanted
to
do
just
really
isn't
a
logical
operation
on
metrics.
A
Responsible
enough
to
be
trusted
that
if
they
want
to
write
their
own
code,
they
can
they
can
do
what
they
want
like.
If
the
user
comes
back
to
us
and
says,
like
I'm,
writing
a
view
that
transforms
things
in
a
way.
That's
that
is
destroying
the
output
Telemetry,
that
I'm
getting
I
mean
I
like
I,
don't
see
why
you
come
back
to
them
and
say
like
yeah!
Well,
I!
Wouldn't
do
that
like
that
that
was
a
bad
idea
like
I
mean
I.
A
Find
a
way
to
do
it
right,
like
they
they're
gonna,
go
reset
the
context
they're
gonna
get
like
they
want
some
way
to
do
that
and
they
want
their
worldview
to
like
match
what
they
want
to
do
and
I
think
that
that's
that's
kind
of
the
key
is
like
saying
like
yeah.
Here
you
go
like
here
are
the
raw
tools?
Here's
here's
the
raw
definition
of
a
view.
You
can
do
whatever
you
want
with
this,
but
like.
A
If
you
do
want
the
guardrails
and
not
like
have
things
that
are
gonna
bite
you
in
the
you
know
in
the
butt.
Here's
the
new
view
like
you
can
use
I,
don't
know
like
I,
don't
I
personally,
don't
think
it's
the
place
to
say
that,
like
we
are
in
charge
of
of
a
user's
correctness
of
their
code,
I
think
that
it's
them
like
I,
think
that
at
the
end
of
the
day
like
we
need
to
provide
tools
that
make
it
easy
for
them
to
produce
valid
data.
A
But
I
also
think
that,
like,
if
we're
going
to
be
the
Guardians
and
and
like
the
babysitters
of
all
of
their
code,
then
we're
gonna
inevitably
run
into
that
conflict
of
like
the
moment
that
somebody
tries
to
paint
outside
the
lines
like
in
a
valid
way.
We've
already
blocked
them
from
doing
it.
Foreign.
A
E
A
Yeah
so
I
was
looking
at.
This
is
actually
kind
of
inspired
by
some
of
the
Python
and
Java
stuff.
They
don't
explicitly
allow
you
to
do
like
those
Replacements,
but
they
do
essentially
allow
for
this
extensibility
of
parameters,
essentially
anything
that
a
view
can
be
or
sorry
an
instrument
can
be
defined
with,
like
you
could
do
matchings
on
in
in
both
of
those
languages.
A
Are
like
you
know
not
explicitly
stated
in
the
specification
they
do
allow
for
I.
Think
like
that
extensible,
like
ability
to
say,
like
you
know,
give
me
all
your
match
criteria.
Here's
all
your
Replacements,
the
key
thing
that
they
don't
allow
currently
is
here's
all
your
Replacements
in
the
context
of
what
you're
matching
on
I
think
that's
like
the
only
thing
that
this
is
really
doing
outside
of
that
and
allowing
you
to
do
much
more
complex
matching.
A
You
know
like
the
thing
that
really
stands
out
is
like
hey.
Wild
cards
are
great
I,
don't
even
know
if
I'd
say
that,
but
regex's
are
better
like
I
mean
we're
already
switching
to
a
regex
right
like
why
not
allow
a
user
to
Define
their
own
regexes
and
if
you're
doing
a
regex
with
capture
groups
like
I,
don't
know,
I,
think
it
there's
there's
some
value
there.
Like
one
of
the
things.
Let
me
see
if
I
can
share
my
screen
again
that
really
stood
out
to
me
was
okay.
A
A
Like
this,
where,
like
a
user,
wants
to
do
some
sort
of
name
match
on
understanding,
like
you
know,
maybe
they've
prefixed
all
of
their
instruments
with
some
sort
of
like
instrument,
I,
don't
know
schema
that
they
Define
and
they
can
find
all
of
those
values
right
and
then
they
can
start
to.
You
know
scope
that
by
changing
the
unit
of
whatever
is
actually
being
output
automatically
like
they
don't
have
to
do
this.
You
know
by
pring
their
code
to
get
it
like.
A
You
know
in
this
into
the
state
that
they
want
if
they
can
just
jump
right
off
the
bat
and
I
think
this
is
something
that
like
yeah,
they
they
wrote
wrong
code
right
like
they.
They
made
a
mistake
already
right,
they've
written
an
instrument
that
doesn't
Define
a
unit,
but
they
Define
the
unit
in
the
name
right
so
like,
but
at
the
same
time,
like
the
operator
for
that
code
can
come
along
and
just
be
like.
Oh,
my
God
I
came
from
a
library
like
I
just
need
to
fix
it
like
I.
A
Don't
really
like
the
hotel.
Spec
does
not
allow
this
like
it.
Just
it
says,
like
you,
can't
do
this
like
what
does
this?
Let
me
say
that
it
doesn't
say
that
you
can't
do
this.
It
just
doesn't
say
anything
about
it.
Right
and
I.
Think
that,
like
this
is
a
really
powerful
thing
that
is
going
to
be
useful
for
users.
A
So
thing
is
like
I
kind
of
like
I
read
the
hotel
spec
for
the
fuse
and
I
read
it
as
a
function
like
they're
they're,
saying
like
you
should
provide
this
so
that
you
can
map
transform
like
these
instrument
properties
into
these
replacement
properties.
Right,
like
I
already
like
they
didn't,
say
it's
defined
as
a
function.
A
I
read
it
as
a
function,
the
second
time
I
after
looking
at
the
python
and
Javas
things,
but
yeah
I
I,
think
that's
fair,
like
I
think
we
can
go
back
in
our
last
in
the
spec
to
say,
like
hey,
is
this,
like
you
know,
do
we
have
any
like
issues
with
that?
I
think
that's!
That's
an
okay
thing:
I'll
edit
there
and
ask
people.
C
A
That's
that's
the
whole
point
right
it's
like
if
they
want
to
do
if
they
want
to
just
build
their
own
string
parsers
as
well
like
really
optimize
string
parsers.
They
can
do
that
if
they
want
to
sit
there
and
sleep
in
this
view
like
go
ahead,
do
some
sleeping
like
I?
Don't
think
that's
a
good
idea,
but,
like
hey,
that's
that's
on
you.
You
know
I
I,
this
that's!
The
kind
of
the
key
is
like
I
wanted
to
provide
it
so
that
there's
like
here's,
the
here's,
the
the
raw
components.
A
If
you
want
to
deal
with
it
and
if
you
don't-
and
you
want
to
have
like
really
easy
ways
to
set
rename
views
if
you
want
to
have
really
easy
ways
to
like
you
know,
do
wild
card
matching,
here's
the
new
view
and
like
we
provide
this
functionality
that
comes
with
guardrails,
like
you
can't
do
certain
things
there.
But
if
you
want
go
ahead
like
here,
you
go:
that's
what
it's
going
to
produce.
A
Yeah
I
think
the
regex
action
was
like
this
huge
thing
for
me
too,
because
I
looked
at
that
and
I
was
like
yeah.
This
is
this
is
useful
Okay,
so
I
will
take
that
as
an
action
item.
I'll
ask
last
definitely
some
spec
authors
there
about
this
and
and
we'll
get
some
some
opinions
from
that
and
then
going
forwards.
I
think
if
that's
that's
the
place,
if
you
haven't
already,
you
had
time
to
put
in
comments
or
questions,
please
do
so
on
that
proposal.
A
B
You
define
it
as
a
function,
but
the
function
versus
an
interface
that
another
user
could
implement
or
another
component
could
implement.
Could
we
do
the
same
thing
with
the
reader?
Should
the
the
reader
be
a
closed
interface
that
only
we
can
interfer?
We
can
Implement
essentially,
but
that
that's
considered
I'll.
Consider
that
a
discussion
for
another
time,
because
I
I
think
it
falls
on
the
exact
same
same
lines
of
like
I.
A
A
B
A
Yeah,
okay,
I
you're
you're,
very
close
to
nerd's
typing,
because
I
really
want
to
talk
about
that.
But
okay,
we'll
keep
it
to
the
agenda.
So
when
the
other
things
Pablo
opened
up
this
with
namespace
option
as
a
proposal
for
the
Prometheus
exporter,
I
think
it's
fair.
He
pointed
out
that
python
does
this
I
haven't
looked
at
others,
I
assume
this
is
valid.
The
idea
is
that
if
you
want
to
have
all
of
your
metrics
show
up
with
a
prefix
on
them,
you
should
be
able
to
so.
A
This
would
be
how
you
would
do
that
just
some
sort
of
option
or
the
prefix
is
defined.
This
looked
good
to
me.
Yeah.
You
only
react
to
it,
I'm
all
about
it.
So
I
left
in
a
comment.
It
looked
Goods
to
me,
but
if
you
have
any
opinions,
I
think
this
is
worthwhile.
Adding
David
Ashwell
saw
you
on
the
call.
Do
you
have
anything
that
comes
out
right
off
the
bat.
D
A
A
A
But
if
you
have
the
view
proposal,
you
could
solve
it
a
lot
more
fine
grains
like
you're,
saying,
like
you,
could
only
prefix
a
certain
instrumentation
library
or
even
a
certain
Transportation
Library
version,
which
might
be
more
useful
than
everything
that
you're
going
to
export
here
and
yeah,
because
I
I
see
what
you're
saying
now
that
you
say
it
that
like
this
is
great,
if
you're
using
one
instrumentation
library
but
like
if
you
use
two
does,
do
you
really
want
them
to
have
the
same
prefix
like
I?
Maybe
maybe
not
right?
A
Okay,
that's
good
feedback.
I!
Think
I'll
I'll,
try
to
I'll
comment
that,
after
the
meeting
thanks
David
thanks,
okay
cool
the
next
thing
up,
I
wanted
to
check
in
on
the
metric
SDK
beta
time
frame.
We've
got
the
triage
meeting
tomorrow,
which
we
can
probably
talk
about
these
issues
over
here.
I
just
want
to
check
in
on
everything.
That's
in
progress,
okay,
there's
a
lot
of
things
here.
Next
16,
which
is
good
to
say
right.
That's
16,
out
of
nine
three,
so
12.
A
so
definitely
make
it
to
progress
on
this
I
think
we've
already
talked
about
the
restructure
of
the
instrumentation
instrument
code
path,
unified,
metrics,
SDK.
Caching,
again,
this
is
again
kind
of
dependent
on
these
two,
so
we've
kind
of
sort
of
talked
about
it.
All
back
should
only
be
called
applicable
instruments
exist.
This
does
have
a
PR
I
think
that
Aaron
commented
he
did
and
I
addressed
the
feedback.
The
issue
here,
though,
is
just
for
those
that
aren't
aware,
like
the
issuing
instruments
currently
like.
A
There's
no
reason
to
register
at
that
point
because
it's
not
going
to
do
anything
for
all
of
these
instruments.
So
that's
essentially
what
this
is
adding.
Is
it
cleans
it
up
so
that
if
it
does
allow
this
to
return
empty
aggregator
sets,
because
that
is
just
all
drop
aggregators
to
signal
to
this,
that
it
shouldn't
actually
do
any
sort
of
registering
of
this
function
called
so
yeah?
That's
got
a
PR.
It
needs
a
review,
something
in
in
tasks.
A
The
metrics
integration
testing
to
the
hotel
HTTP
test
package
that
was
added
I
had
backup
PR
for
this.
This
is
back
in
the
contribute,
repo,
just
a
heads
up
same
for
the
go.
Sql
there's
actually
maybe
just
spend
a
second
on
this.
So
currently,
this
is
there's
a
PR
to
address
this
later
on
in
the
to
do
column.
A
Oh,
this
is
the
assert
metrics
yeah.
Sorry
it
allows
us
to
essentially
be
the
the
testing
framework
right
because
you
can
use
a
manual
reader
here
and
then
just
pull
out
the
metrics.
Whenever
you
need
to
and
then
I
think,
there's
some
niceties
we
can
add
to
the
the
metric
data
I'm.
Sorry,
the
metric
data
test
package
around
things
like
this,
where
you
have
like
a
histogram,
but
you
don't
really
know
what
the
value
is,
because
it's
measuring
latency.
So
maybe
we
could
ignore
it.
A
But
if
you
don't,
then
you
can
I
mean
this
is
literally.
What
I
had
to
do
was
just
call
out
all
of
the
asserts
that
I
want
and
then,
if
you
do,
have
things
that
are
just
standard
and
you
know
what
they're
going
to
be.
That's
what
this
translates
into
it's
just
using
the
metrics
data
test
package.
So
I
think
that,
like
our
testing
utility
for
the
SDK
is
actually
it's
pretty
good,
like
I
think
there's
the
metric
data
test
package
to
be
improved,
I!
That's
what
these
issues
were
to
maybe
improve
it.
D
A
A
A
A
Have
my
approval
once
you
get
the
issue
opened,
which
I'm
guessing
is
right
after
this
meeting?
But
yes,
another
review
is
also
needed
on
this.
Please,
if
you
have
some
time,
take
a
look.
The
code's
not
that
hard
to
understand
it's
mostly
tests
which
are
Big
Blocks
of
test
cases
so
again,
not
too
complex
of
code.
A
Is
it
possible
to
create
instrument,
View
and
sort
of
the
same
name
for
the
different
meter
provider
there's?
Actually,
this
is
related
to
something
that
David
ashball
has
created
in
the
spec,
around
duplicate
descriptions
and
meter
definitions,
all
that
kind
of
stuff
submerged
accepted.
We
just
need
to
fix
this
essentially
I
think
there
needs
to
be
some
sort
of
like
caching
of
instruments.
We've
already
identified
I'm,
not
100
of
the
solution,
but
I
know
that
people
are
thinking
about
it.
So
it's
definitely
in
progress.
A
A
I
will
also
take
that
to
comment
that
it's
not
well.
Actually,
it's
ready
to
go
replacing
view
instrumentation
in
the
SDK.
Oh
we
sorry.
This
is
the
proposal.
I
think
we
just
talked
about.
This
is
the
pr
that
we
already
talked
about.
So
this
is
the
other
PR
there's.
Also
this
Json
encoder
PR
that
has
been
picked
up.
I'm
sorry
issue,
that's
been
picked
up.
I
took
a
little
look
at
this.
A
This
looks
really
hard
with
our
current
definition
of
the
exporter,
so
I
don't
know
how
easily
this
is
going
to
go,
but
I
think
it's
going
to
involve
the
reflect
package
at
some
point
but
yeah.
So
that's
it's
in
it's
in
works,
so
just
kind
of
heads
up
on
that
no
PR
for
that.
Yet
this
goes
back
to
removing
these
views.
We
were
kind
of
talking
about
earlier
Aaron.
This
does
supersede
this
other
PR
that
you
had
here.
It
I
don't
know
like
if
you
want
I'm
fine.
A
That's
I
opened
this
and
I
was
like
wait.
A
minute.
I
thought
this
already
existed
and
I
think
it
yeah,
okay,
so
I.
We
can
probably
close
that
in
favor
of
this,
like
this
is
a
really
minimal
change
that
literally
it's
just
a
deletion
to
those
of
you.
So
okay,
this
is
the
pr
we
talked
about
for
adding
back
to
test
to
the
hotel.
Go
SQL,
do
not
export
aggregations
without
any
data
points.
I
think
this
is.
A
That
is
an
error.
It's
not
supposed
to
happen
and
I.
Don't
think
that
we
actually
want
to
do
that.
If
you
don't
have
any
data
for
an
instrument
like
it
doesn't
seem
like
something
you
should
be
exporting.
So
that
is
also
a
bug
here,
which
is
tracking
essentially,
where
that
came
from
in
the
collector
contribute.
A
But
I
think
this
is
a
positive
change
worth
paying
attention
to,
because
otherwise
we're
going
to
just
be
increasing
payload
size
without
communicating
any
important
values
so
good
to
get
some
eyes
on
and
then
there's
this
last
issue,
which
is
exactly
what
I
was
talking
about.
Yeah.
That's
the
bug.
That's
related
to
this.
We
could
probably
rename
that
to
be
a
little
more
descriptive
cool
all
right.
So
that's
everything
in
progress.
Is
there
anything
anybody
else
wants
to
talk
about
on
that.
A
A
A
I
did
add
these
back
into
the
project
this
past
week,
because
I
finally
could
trip
the
runtime
instrumentation
also
needs
to
get
added.
Some
integration
testing
is
same
for
the
host.
The
thing
is
the
runtime
one.
I
don't
know
if
we
want
to
block
this
because
I
know
there
was
a
question.
If
we
want
to
restructure
some
of
the
instrument
types
there.
There
are
issues
in
contrib,
saying
that,
like
we
should
using
async
instruments
in
certain
places
that
we
should,
in
others,
I
can't
remember
exactly
what
they
are.
A
A
C
I
feel
embarrassed
about
asking
this.
After
all
these
shoes,
any
of
you've
shown
but
I
know
we
originally
put
out
a
thing
saying
we
were
not
going
to
do
or
accept
any
PRS
related
to
the
logs
signal.
How
long
ago
we
put
that
out
a
year
ago.
So
is
there
any
discussion
about
restarting
that
at
some
point,
just
I'm
not
asking
it
to
be
restarted,
I'm
just
interested
whether
anyone
has
really
thought
about
it.
A
A
I
could
find
the
issue
it's
in
the
slack
as
well,
but
that
essentially
restructures
all
of
the
essentially
like
a
new
client
Library
package
that
handles
a
bunch
of
logging
and
it
looks
compatible.
So
the
question
of
whether
or
not
it's
advantageous
to
us
to
actually
support
redefining
a
new
API
I
think
is
an
open
question
and
I
I
would
want
to
pause
to
see
how
that
lands
first.
A
A
That
being
said
like
it
doesn't
like
it's
so
abstracted
from
the
SDK
like
we
may
have
to
I
mean
I
I
have
to
look
like
this,
but
still
conform
with
the
SDK,
but
I
think
this.
This
is
probably
where
I
would
probably
start
if
the
structured
logging
proposal
is
compatible
with
the
API
that
we're
expecting
so
I'll
pause.
There.
B
So
I've
had
thoughts
about
this
too
and
I've
kind
of
Wonder.
So
we
currently
find
ourselves
in
a
situation
where
there's
no
less
than
like
five
different
client
libraries
for
logging
and
there's
the
structured
logs
that
are
also
like
on
the
horizon,
as
Tyler
said
and
I,
wouldn't
be
opposed
to
supporting
something
that
is
sort
of
the
exporter's
version
of
of
logs.
B
But
the
goal
would
be
to
have
essentially
logging
plugins
or
logging
back-ends
for
the
compatible
logging,
libraries,
so
like
zap
logress,
the
other
ones
Escape
my
name,
but
essentially
that
that
exports
in
an
otlp
fashion.
For
us
there
might
be
some
kind
of
code
that
that
needs
to
be
there
but
I'm
wondering
if
we
are
ready
to
build
ourselves
an
actual
API
around
that,
especially
with
the
structured
logs
proposal
on
the
horizon.
B
That
being
said,
I
don't
think
structured
logs
is
going
to
land
in
1.20
and
maybe
not
even
to
121.
So
that
puts
the
timeline
for
actually
being
able
to
use
that
fairly
far
out
before
we
can
actually
do
something.
So
I
feel
like
that.
We
need
to
do
something
we
probably
need
to
have
something
and
I
think
probably
the
best
first
step
would
be
to
have
essentially
what
Tyler
just
showed
for
the
structured
logs,
but
for
other
logging
libraries
as
well.
If,
if
at
all
possible,.
C
E
E
A
So
that
being
said,
I
also
want
to
I
think
this
is
all
like
really
useful
to
start
capturing
issues
or
some
sort
of
discussions,
maybe
or
something
like
that.
But
I
would
also
not
want
to
try
to
divert
a
lot
of
the
attention
of
the
Sig
away
from
the
metrics
development
Kevin,
we're
still
behind
the
eight
ball
on
getting
a
stable
release
of
that
out.
So
I
I
I
mean,
as
Aaron
pointed
out,
it's
probably
going
to
take
like
another.
A
You
know
one
or
two
major
releases
or
certain
amount
of
releases
of
go
to
get
this
merged
up
stream,
maybe
maybe
more
so
I
think
that
I
would
probably
say
like
keeping
our
status
with
where
it
is
and
starting
to
track
open
issues
in
a
project
or
with
a
label,
or
something
like
that
is
is
probably.
Why
would
I
would
recommend
at
this
point
in
time
if
everyone
else
is
on
the
same
page,.
C
A
B
A
That's
that's
a
very
valid
approach.
You
know,
like
you,
saw
Sean
posting
something
like
one
of
the
things
we
do
in
trib
is
having
other
people
host.
The
instrumentation
provides
a
lot
of
user
feedback
without
it
being
stabilized
in
in
go.
So
if
you
get
a
lot
of
traction
there
and
there
are
ways
to
we
can
try
to
amplify
any
sort
of
packages
you
know
via
slack
via
Registries
via
you
know,
posts
that
kind
of
thing.
A
C
E
C
A
A
E
It
was
good
there
was
a
lot
of
people
that
are
actively
using
open
Telemetry
now,
rather
than
just
you
know
what
is
Hotel,
how
do
I
use
it
more
specific
questions
from
from
people
who
have
it
deployed,
which
is
good
yeah.
It's
basically
my
take
this
is
that
we
just
keep
growing
and
that
growth
seems
to
be
good.
A
Yeah,
that's
a
that's
a
cool
one
that
that
also
relates
to
some
of
the
there's,
like
a
little
mini
working
group,
spun
up
to
deal
with
Hotel
configuration
file
by
the
way
that
is
becoming
more
public
as
more
people
are
having
interest
in
it.
So
I
think
that
there's
overlap
there.
So
yeah
I
want
to
step
part
of
that
as
well.
C
A
A
E
To
come
so
one
one
thing:
we
should
note
if,
if
that
is
going
to
include
view,
configuration
and
we
give
a
facility
for
a
user
provided
view
implementations,
we
either
need
a
way
to
also
allow
them
to
specify
how
the
configuration
gets
used
or
make
very
clear.
If
you
go
this
route,
you
don't
get
any
file
based
configuration
for
your
views.
A
A
Another
question
is
like
you
know:
should
this
allow
multiple
meter
provider
support,
and
you
know
things
like
that
where
I
think
our
answer
was
no,
but
you
know
there's
other,
like
general
questions
of
what
this
should
support,
which
is
unfortunate
because
we're
having
them
at
such
an
early
stage
in
a
lot
of
the
the
Otep
is
going
to
not
be
around
what
the
view
is
going
to
or
the
config
is
going
to
include
that
around
how
to
define
the
config
using
some
sort
of
schema
language.
So
I
think
that's
the
the
key
there.