►
From YouTube: 2022-03-31 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
D
D
Okay,
it
looks
like
we
could
probably
jump
in
and
get
started
here,
I'll
figure
out
how
to
share
my
screen
for
those
joining
the
call,
please
make
sure
to
add
yourself
to
the
attendees
list
and
any
agenda
items
that
you
wanted
to
talk
about.
Please
add
them
as
well,
and
we
can
jump
into
this
in
just
a
second.
D
Cool,
so
I
added
the
first
two
items
on
here
and
it
should
be
pretty
straightforward.
I
don't
think
there's
actually
too
much
to
talk
about
in
this
meeting,
as
it
is
right
now.
If
you
have
something
again,
please
add
it.
First
thing
I
wanted
to
touch
in
on
was
our
next
release
in
progress.
D
Our
last
release
went
out
pretty
recently,
so
there's
not
really
three
days
ago,
not
a
really
big
time
crunch
on
this,
but
I
think
that
I've
identified
a
few
things
that
I
wanted
to
make
sure
we
try
to
address
in
the
next
release.
D
Specifically,
I
think
this
is
probably
the
top
priority,
even
though
I'm
not
working.
I
probably
should
prioritize
that
we
removed
this
in
memory.
Metrics
exporter
last
release,
and
this
is
one
of
the
steps
that
we
identified
in.
D
The
next
progress
to
progressing
the
open
or
the
metrics
api-
sorry
words
are
hard
right
now
and
something
that
we
need
to.
I
think
get
done
in
the
next
release,
so
I
called
it
out
here
is
something
that
could
use
help
if
someone's
looking
for
a
pretty
big
project,
I
don't
think
it's
gonna.
Be
that
easy.
E
It's
actually
surprisingly
easy.
E
E
Both
captures
the
export
interface
that
we
have,
which
is
a
little
bit
confusing
in
the
current
sdk,
of
how
it
kind
of
iterates
through
the
different
layers
of
the
data
model
and
then
something
that
can
manually
trigger
a
collect
so
that
you
can
actually
get
asynchronous
metrics
from
it
like
if
somebody
wants.
If
somebody
wants
to
take
the
time
to
work
on
that,
I'm
more
than
willing
to
take
some
time
and
help
consult
on
it.
E
But
I
got
started
on
it
and
then
I
got
pulled
off
on
other
other
tasks
to
get
the
metrics
sdk
going.
D
Okay,
cool.
That
sounds
good.
I
put
this
comment
in.
I
don't
know
if
maybe
you
just
want
to
post
your
branch.
If
you
have
something
in
here
as
a
work
in
progress,
that's
kind
of
like
a
draft
but
yeah.
I
I
think
this
is
the
next
thing
I
would
try
to
work
on
if
no
one
else
picks
this
up.
So
I
will
prioritize
this
just
I
wanted
to
get
semantic
convention
stuff
updated
because
we
are
behind
on
that
in
a
few
ways.
D
D
The
only
other
thing
that
I
had
listed
and
had
identified
was
this
their
task
that
we
kind
of
wanted
to
make
sure
we
didn't
forget
that
we
added
a
bunch
of
to-do's
waiting
for
the
global
package
to
be
added
back
in
this
pr
was
to
add
that
meter
function
which
was
removed,
which
was
strictly
necessary,
but
this
is
this
is
unblocked
and
honestly,
it
looks
it's
pretty
straightforward.
D
So
if
somebody
wanted
an
easy
one
to
start
in
on,
if
you're
not
a
part
of
the
open,
telemetry
organization,
just
comment
and
we
can
assign
it
to
you,
otherwise,
if
you
are,
we
can
assign
it
so
yeah
just
go
ahead
and
comment
in
there
but
yeah.
I
think
those
are
the
two
identified
tasks
that
don't
have
an
owner
for
this
next
release
that
we
want
to
try
to
prioritize.
D
So,
if
you're
looking
for
ways
to
help
out,
that's
a
good
one,
there's
also
a
bunch
of
other
issues
in
bugs
there's
a
lot
of
stuff
to
do
with
this
project.
Okay,
so
with
that.
B
D
I
don't
know
why
I
think
otherwise.
Sometimes
we
talked
a
little
bit
last
week
in
our
meeting.
We
wanted
to
kind
of
give
a
next
steps
for
the
metrics
signal
and
that
would
be
in
the
sdk.
We
have
the
prototype
draft
out
for
the
metrics
api,
which
looks
like
it's
getting
some
use.
I'm
definitely
seeing
some
of
that
and
now
the
next
thing
is
to
refactor
the
sdk.
D
To
I
don't
know
if
it's
correct
to
say,
match
the
specification
or
more
conform,
maybe
the
better
word,
but
also
to
just
restructure
it.
D
We
have
identified
that
we
want
to
stick
with
118
and
use
generics
for
the
sdk,
so
obviously
there's
going
to
be
a
little
bit
of
a
time
delay
before
we
can
release
it,
given
that
we
need
two
stable
versions
of
go
to
support
it,
and
so
with
that
we
decided-
or
we
came
to
the
action
item
that
I
was
gonna-
give
a
little
demonstration
of
this.
I
don't
know
if
I
want
to
hand
it
over
to
you
aaron
or
you
want
me
to
still
share.
E
Yeah,
I
will,
I
can
drive
it
a
little
bit
if
you
let
me
share
my
screen,
see
skyla
draw,
so
this
is
just
kind
of
the
rough
diagram.
Can
everybody
see
this
for
stuff
yeah
thumbs
up?
Okay?
So
it's
a
little
bit
wide
just
because
this
is
a
complicated
workflow
trying
to
kind
of
suss
out
the
larger
components
that
are
involved
in
a
workflow
of
creating
an
instrument.
E
I
just
chose
one
at
random,
being
a
sync
in
64
counter
and
getting
data
into
the
instrument,
and
then
what's
not
quite
finished
yet
in
this
workflow
is
how
that
is
then
later
collected
and
put
into
the
exporter.
So
that's
still
a
little
too
tbd
or
not
it's
determined.
It
just
needs
to
be
added
to
this
diagram,
so
I
kind
of
want
to
walk
through
at
a
very
high
level
what
we're
looking
at
right.
E
So
again
from
the
api.
You
start
with
the
metrics
new.
This
gives
you
your
meter
provider
right.
So
in
the
sdk,
it's
called
a
provider
and
it
implements
the
meter
provider
under
the
hood
there's
just
a
gaggle
of
meters.
E
There
there's
two
ways
to
access
it.
One
is
for
when
we're
accessing
it
accessing
meters
like
instantiating
new
meters,
we
wanna
cache
them
and
have
very
quick
lookups.
The
other
one
is
when
we're
reading
from
them.
We
just
wanna
kind
of
order,
lists
that
we
run
through,
makes
it
easy.
It
makes
it
quicker
and
makes
tests
more
deterministic,
which
is
very
helpful.
E
E
What
this
does
is
it
takes
the
views
that
you
provided
into
your
meter
provider
and
the
readers
the
which
are
associated
with
an
exporter
and
compiles
down
kind
of
a
list
of
how
to
translate
a
attribute
set
from
your
metrics
into
where
they
should
be
going
in
the
readers.
E
That's
what
this
views
compiler
is
and
does
I
have
a
little
note
here,
contracts
all
known
views
and
readers,
so
that
when
you
call
compile
which
you
do
during
instantiation
of
a
new
instrument,
it
can
kind
of
be
registered
with
what
what
reader
needs
to
be
to
be
associated
with
it.
It
also
has
a
list
of
callbacks.
E
E
When
you
create
a
new
instance,
a
new
instrument-
first,
it
checks
if
you've
already
created
that
in
the
cache.
That's
what
this
slice
of
instruments
is,
but
if
not,
it
calls
compile
for
your
your
attribute
sets
and
creates
a
new
view.
State
instruments
like
it
it
a
viewstate
instrument
is
a
object
that
knows
how
to
create
memory
based
on
the
type
of
instrument
this
is
and
which
readers
it
needs
to
create
memory.
E
For
so
that's
an
accumulator
we
can
think
of
as
a
per
reader
block
of
memory,
so
that,
if
you
have
multiple
view
like,
if
you
have
multiple
views
that
read
the
same
instrument,
each
of
those
readers
would
get
a
a
new
slice
of
memory,
so
they're
they're
not
all
compressed
onto
one,
so
that
aggregation
can
be
done
in
in
one
a
single
shot
and
that
will
return
you
an
actual
sync
state
instrument.
This
is
view
states
are
common
to
all
of
our
instruments.
E
Sync
state
is
the
code
path
specific
for
synchronous
instruments.
There's
an
async
instrument,
that's
similar,
but
is
used
in
the
asynchronous
code
paths
in
that
in
that
instrument
you
have.
E
Essentially,
a
map
of
attributes
to
records
and
a
record.
It
does
a
little
bit
more
than
just
hold
as
an
accumulator,
but
because
it
also
does
its
reference
counting
so
that
you
can
free
those
records
after
they're
not
used
for
a
while,
but
essentially
one
instrument
has
one
or
many
different
records
based
on
what
attributes
that
instrument
has
seen
and
when
you
call
ad,
when
you
call
ad
for
a
counter,
it
goes
through
checks
to
see
if
that
record
exists
already
in
the
map
and
if
not,
it
creates
one.
E
E
I
would
also
like
to
point
out
that
a
lot
of
these
names
are
chosen
as
first
pass,
and
we
probably
could
use
a
more
clarifying
update
path,
so
we're
not
stuck
to
them.
It's
just
something
that
we
use
to
differentiate
it,
so
a
reader
is
essentially
I
would.
I
would
think
of
that,
as
a
reader
is
the
interface
that
a
a
an
exporter
needs
to
provide.
E
It
needs
to
be
able
to
call
produce
on
our
provider
to
get
a
list
of
metrics,
get
get
all
of
the
condensed
metric
streams
down
into
one,
and
what
that
does?
It
will
read
through
each
of
the
meters.
E
And
each
meet
and
call
collect
on
each
of
the
meters.
It
will
actually
call
all
of
the
execute
all
the
callbacks
and
then
call
collect,
and
what
collect
will
do
on
each
of
the
instruments
is
iterate
through
all
of
its
records
and
transform
them
into
the
final
output
stage.
E
So
the
reason
why
there's
a
little
bit
of
complexity
on
this
front
end
is
so
that
when
we're
fetching
stuff,
we
can
synchronously
fetch
very
quickly.
All
of
the
different
accumulator,
essentially
all
of
the
different
accumulator
states
that
exist.
E
And
essentially
we
we
can
work
through
this,
so
that's
sort
of
the
high
level
overview.
Does
anybody
have
any
pressing
questions.
D
So,
just
to
I
think,
josh,
some
call
too
just
make
sure
that
I
understand
views
can
only
be
specified
at
startup
right.
They
can't
be
generated.
E
Right
now,
they're
only
associated
at
startup.
If
we
wanted
to
add
them
ad
hoc,
I
don't
think
it
would
be
very
large
of
the
code
change,
but
we
would
need
to
specify
an
api
for
that.
D
Yeah,
okay,
yeah,
I
think
starting
this
way
is
probably
the
easier
it's
definitely
easier.
So
I'd
probably
just
recommend
that
the
other
thing
was
the
the
reader
interface.
You
said
something
about
the
fact
that
it
needs
to
call
produce
to
the
accumulator
or
to
the
processor,
to.
E
It
is,
it
is
essentially
a
pull
model.
The
difference
with
this
is
we
can
condense
a
lot
of
the
push
logic
like
if
we
want
to
create
a
push
instrument
that
can
be
located
within
the
reader
yeah.
So
we
could.
What
we
are
planning
on
doing
is
creating
a
generic
time-based
reader
right
that
accepts
a
push-based
exporter.
D
Yeah,
that
makes
a
lot
of
sense,
so,
like
a
batching
processor
or
something
like
that,
you
could
wrap.
E
Yeah,
it
would
essentially
be
a
batch,
a
time-based
batching
processor
instead
of
a
size
based
but
yeah.
That's
the
same
idea
is
that
if
you
need
something
that
is
just
going
to
call
collect
periodically,
we
could
do
that.
That
also
gives
us
the
flexibility
of
saying,
like
we
could
have
an
ad
hoc
process
export
or
an
ad
hoc
reader
where
it
has
another
like
you
know
it
has
the
methods
it
needs
to
to
read
the
stuff
and
knows
how
to
produce
and
and
whatnot.
E
E
E
B
Browser
full
of
tabs
to
show
you
a
few
kind
of
concrete
examples
of
the
place
where
this
this
is.
It
is
definitely
a
work
in
progress,
but
I
I
I
did
have
a
tab
dedicated
to
answering
your
question
tyler,
because
I
think
historically,
the
existing
prototype
had
some
confusion
over
what
an
exporter
is
and
the
push-based
exporters
were
properly
exporters
and
the
pool-based
exporters
were
something
else
in
this
new
formulation,
which
I
have
literally
wanted
to
show
you
some
code
to
answer
I
can.
I
can
take
over
presidenting
and
just
start.
B
How
is
that
trying
to
keep
this
quick?
The
pr
is,
there's
no
pr,
there's
a
branch.
I
need
to
rebase
it
because
it's
like
messy
and
it's
it's
been
through
so
many
renamings
as
aaron
said
I
I
I
feel
comfortable
that
it's
close
to
kind
of
fit
kind
of
end
point,
but
honestly
the
way
you
name
things
effectively.
You
understand
them
and
it's
an
iterative
process
here.
So,
let's
see,
I
will
show
you
a
few
key
and
salient
points
all
right.
B
I
just
got
some
of
this
working
yesterday
last
night
this
morning.
I
noticed
that
something
wasn't
working,
but
I
will
show
you
the
raw
form,
so
you,
as
a
user
might
come
in
thinking.
I
just
want
to
set
up
prometheus
and
go.
This
is
a.
B
File,
I
was
going
to
show
in
this
branch.
Sorry
that
was
the
wrong
just
promote
this
example,
and
it's
here.
B
B
B
Examples
I'm
sorry
example
prometheus.
I
mean
this
is
what
I'm
trying
to
find.
So
you
remember
how
complicated
it
was
to
set
up
the
controller
and
the
exporter
and
everything
and
the
fact
that
corinthians
was
not
actually
an
exporter
in
this
new
model.
I'm
going
to
show
you
the
reader
interface
and
what
an
exporter
looks
like
next.
The
new
model
you'll
just
the
constructioning
of
prometheus
server,
gets
pretty
simple.
B
B
The
three
options
are:
I
gave
an
example
for
each
of
them
you
have
a
reader,
which
is
where
you
configure
the
exporter
you're,
using
entirely
the
default
options,
because
pull
exporters
are
very
simple
for
a
periodic
push-based
exporter,
which
I'm
still
working
on
that
that
will
require
some
configuration
and
it'll
be
a
subclass
or
sort
of
an
associate
of
the
reader
with
us
with
a
interface
and
then
explain
it
as
I
go.
B
But
here
it
is
creating
a
simple
view
and
at
the
end
of
this
I'll
show
you
that
it
works,
so
I'm
going
to
take
some
badly
named
metrics
and
and
rename
them,
as
you
will
see,
and
the
rest
of
this
demo
is
the
same
as
it
was
before.
So
there's
nothing
else
to
see
there.
B
B
There
is
a
config
and
an
options
pattern
that
the
configurable
things
are
three
per
instrument
settings.
If
you
follow
the
spec,
we
just
finished
work
on
this.
It's
like
a
per
instrument,
aggregation
kind
per
instrument
temporality
in
a
per
instrument.
Oh,
this
is
my
interpretation,
a
per
instrument,
aggregation
config
for,
like
things
like
explicit
bucket
boundaries,
so
you
can
say
the
defaults
on
a
per
exporter
basis.
B
I'm
going
to
talk
about
how
the
relationship
between
an
exporter
and
a
reader
it
sounds
confusing.
Even
when
aaron
said
it
like,
I
was
like
gosh.
We
all
understand
it's
a
slightly
different
way.
Based
on
what
the
specification
says,
I've
tried
to
improve
the
language
there
recently.
It
says
something
about
there
being
an
associated
reader
and
exporter
they're,
always
a
one-to-one
relationship.
That's
that's
pretty
key
to
the
understanding
here
so
that
really
it's
it's
ambiguous
when
you're
talking
about
a
reader
or
an
exporter
because
they
share
a
lot
of
responsibilities.
That's
that's
exactly!
B
The
problem
is
it's
just
ambiguous
in
the
spec,
though,
I
tried
to
make
it
clear
that
the
reader
is
like
a
a
configuration
mechanism.
It
doesn't
there's
no
sdk
like
it
doesn't
have
any
requirements
for
what
it
does.
It
just
provides
you
a
way
to
configure
what
the
exporter
gets
is
the
way
I
think
about
it.
So
this
is
the
reader
interface
you'll
create
a
new
reader
with
those
options.
Just
your
defaults,
nothing
more
and
an
exporter.
B
The
exporter
interface
is
down
at
the
bottom
of
the
file,
so
I'm
gonna
scroll
around.
For
you,
sorry,
the
export
interface
includes
flush
and
shutdown.
I
haven't
implemented
them
because
all
I've
done
is
communicate
at
this
point.
You
don't
need
to
do
anything
in
flush
and
shutdown,
but
the
point
is
that
these
are
just
context.
Methods
and
all
they
do
is
pass
control
to
the
exporter.
To
do
what
they
want
to
do,
which
includes
maybe
collecting
or
maybe
not
now
the
way
collecting
works
is,
I
think,
a
great
improvement
over
the
old
sdk.
B
So
I've
created
this
kind
of
sub
sub
interface
called
registry,
and
it
has
a
register
method.
With
this
api
we
call
producer.
This
is
the
kind
of
backwards
factory-oriented
constructing
pattern,
whatever
you
want
to
call
it
like.
I,
when
I'm
constructing
my
exporter,
I
haven't
created
the
sdk.
Yet
when
I
construct
my
reader,
I
haven't
constructed
the
sdk.
B
So
every
exporter,
reader
combination
gets
their
own
producer
handle
or
whatever
you
want
to
call
it
produce.
A
producing.
Metrics
just
means
calling
this
so
for
the
pull-based
exporter,
which
I'm
going
to
show
you
through
the
rest
of
these
slides,
all
you're
going
to
do
is
call
produce
when
you
need
it,
and
it's
just
very
straightforward.
B
B
This
is
an
example
of
an
unwritten
test,
so
I'm
just
going
to
show
you
what
an
in-memory
exporter
looks
like,
because
there's
nothing
more
than
this.
It's
it's
these
first
10
lines
of
the
file,
so
an
exporter
has
to
implement
three
methods.
It
has
register
flush
and
shutdown
register
is
going
to
simply
remember
its
producer.
There's
nothing
more
to
do.
You
don't
even
need
a
lock,
because
the
producer
will
be
called
exactly
once
and
you
won't
be
used
until
you
need
until
you've
been
registered.
B
B
This
is
no,
I
haven't
talked
about
the
topic
of
reuse,
but
I
I
am
unable
to
give
up
my
performance
considerations
entirely,
so
this
is
a
framework
for
letting
you
reuse
slices
of
slices
of
slices
of
slices
over
and
over
again
from
one
collection
to
the
next.
B
Now
this
won't
be
useful
in
a
prometheus
context,
or
it
could
it's
a
decision
that
each
exporter
gets
to
make
whether
they
want
to
have
one
buffer
of
memory
that
they
reuse
over
and
over
or
whether
they
want
to
have
each
each
collection,
be
independent
and
there's
a
few
spec
level
questions
that
are
really
going
to
fall
out.
If
you
get
too
close
to
it
right
there
anyway.
So
I
can
show
you
the
reuse.
The
reuse
mechanism
plays
tricks
with,
like
the
go
length,
slice
capacity.
B
So,
like
we
re,
we,
we
set
the
size
of
the
slices
back
to
zero,
but
we
preserve
their
capacity
in
when
we,
when
we
reset
when
we
re
when
we
perform
a
subsequent
collection-
and
you
have
to
like
extend
the
slice
with
an
empty
vowel
with
without
changing
the
existing
value
and
then
return
a
pointer
to
it.
And
it's
it's
a
few
eight
lines
of
complicated
code
here
and
there
three
times,
maybe
only
two
times
I'll
show
it
to
you
perhaps
and
then
so.
B
This
is
this
would
be
a
single
metric
operation.
Just
for
my
testing
purposes
and
here's
one
of
these
reuse
patterns,
I'm
going
to
call
the
exporter
produce
method,
I'm
going
to
get
back
the
current
result
and
I'm
going
to
allow
it
to
reuse
my
current
value
so
that
by
the
time
I
call
this
again,
I'm
reusing
the
same
memory.
B
So
this
will
be
the
basis
of
some
tests.
It's
really
just
going
back
to
the
I
skipped
over
some
stuff
in
this
file
right
here
here
it
is
so
the
when
you
get
called
as
a
as
a
in
this
method
called
collect,
which
aaron
described
in
in
the
block
form
you'll
get
this
sequence,
which
tells
you
the
three
time
stamps
you
might
need,
and
then
it's
going
to
fill
in
this
metric
struct
and
return
it
to
you.
B
So
sorry,
the
the
sequence
is
provided
to
the
mechanism
below,
but
it
doesn't.
Actually.
This
will
not
be
seen
by
the
time
it
gets
the
exporter.
What
you're
going
to
see
as
an
exporter
is
this
metric
struct,
which
contains
the
resource
and
then
a
slice
of
scopes?
The
scope
contains
the
library
and
the
size
of
instruments,
and
it's
one
more
level.
B
This
the
instrument
contains
descriptor
temporality
and
a
slice
of
theories
series
is
the
actual
data,
and
by
the
time
you
see
this
as
an
exporter,
your
temporality
preference
will
have
been
applied
so
that
you
get
two
time
stamps
it's
either
the
start
or
the
last
time
stamp
and
and
the
now
time
stamp,
as
well
as
the
data
in
the
after
applying
the
view
of
course,
and
then
the
set
the
attribute
set.
The
way
this
is
structured.
B
These
are
slices
now
because
and
not
maps,
because
there
won't
be
necessarily
a
unique
name
and
and
somewhere
in
this
code,
in
the
work
in
progress,
we
need
to
call
those
out
as
errors
much
better,
but
right
now
it's
it's
just
a
bunch
of
slices
and
conflict
detection
has
not
been
done
so
so
that
should
kind
of
explain
the
data
structure.
B
It's
a
slice
slices
of
slices
of
slices
and,
and
fortunately
the
exporter,
logic
becomes
so
much
easier
and
so
much
simpler
and
the
fact
that
we're
reusing
that
memory
like
gives
us
kind
of
all
the
benefit
of
that
formerly
complex
interface,
that
had
a
callback
it's
too
complicated
to
even
discuss
okay,
so
I've
shown
you
the
provider
or
the
for
sort
of
fake
test
and
how
you're
doing
reuse.
B
D
B
You
you
could
actually
take
it
as
a
value,
but
I'm
giving
you
the
option
to
explicitly
declare
there's
no
there's
no
reuse.
So
by
passing
nil,
you
get
no
reuse
and
by
passing
non-nil
you
get
reuse
of
whatever
whatever's
in
that
point
or
pointer
address,
and
then
the
returned
value
you
might
have
to
extend
like.
If
you
are
dynamically
registering
meters,
then
then
the
size
of
that
slice
will
grow
over
time
and
as
it
grows,
you're
going
to
need
to
remember
the
new
return
value
for
reuse
to
happen.
B
So
whatever
you
pass
us
we're
going
to
reuse
as
much
as
possible
of
it,
but
then
perhaps
grow
it
and
return
more
and
and
just
for
just
just
for
thoroughness.
The
point
is
that
the
meters
are
remembered
in
the
order
they
are
registered.
Instruments
are
done
in
the
order
they
were
registered
so
that
each
ordinal
position
in
the
slice
of
slices
contains
a
slice
of
series
that
corresponds
to
exactly
that
instrument
so
that
from
one
collection
cycle
the
next,
your
cardinality
preferences
will
play
out
in
in
memory
that
get
that
gets
reused.
B
So
if
I
have
a
high
cardinality
instrument,
it's
going
to
have
a
slice
it's
grown
already
in
that
particular
position
because
it
gets
reused.
So
that's
just
kind
of
a
performance
note
there
there's
definitely
okay,
so
I
have
three
more
slides
here.
I
I
want
to
call
out
kind
of
a
language
technical
thing
for
people
who
are
following
go
and
generics.
B
So
it's
all
very
new
this
this
powerful
and
limited
tool
that
we
have
and-
and
there
are
questions
about
style-
that
I
think
the
entire
community
doesn't
really
have
an
answer
to
aaron
and
I
have
been
having
a
lot
of
back
and
forth
over
this
kind
of
daily
sync
up
where
we
continue
to
evolve
our
understanding.
I
just
want
to
present
the
current
state,
which
is
here's.
What
I
learned
at
least
the
way
I
understand
it,
the
as
a
former
c
plus
plus
programmer.
B
B
One
type
contains
a
type
name
that
I
can
use
right
and
that
gave
me
a
way
to
to
instead
of
having
a
template
that
has
five
variables
in
my
c
plus
plus
code.
I
create
a
struct
that
has
five
types
in
it,
and
now
I'm
templatized
on
one
particular
type,
and
there
were
lots
of
things
you
could
do
with
with
that
in
go.
You
don't
have
any
such
ability,
so
any
type
of
general
function
that
I
build
using
generics.
B
I
have
to
either
use
an
interface
or
I
have
to
use
sorry
there,
there's
a
difference
between
a
struct
and
a
pointer
to
that
struct
or
a
pointer
to
an
interface
or
a
pointer
to
a
primitive
and
there's
no
ability
and
go
for
you
to
make
a
generic
that
knows
about
both
a
struct
and
a
pointer,
meth
head
at
the
same
time
now
the
way,
but
that's
exactly
what
I
wanted.
B
So
I
wanted
to
be
able
to
pass
through
an
integer
type
or
a
floating
point
type
along
with
a
set
of
methods
that
worked
on
both,
for
example,
to
do
atomic
updates,
but
that's
a
pointer
method.
So
I
need
to
be
able
to
generally
to
operate
on
both
the
number,
because
I
want
to
allocate
that
number,
but
I
also
want
to
have
a
pointer
method
on
that
number,
which
is
two
types
to
the
go
generic
system.
B
Therefore,
my
solution
has
been
to
use
two
types
for
any
generic
application
that
I
have
where
I
need
to
do
that
pattern
I
just
described,
and
I
need
to
do
that
twice,
so
we
have
four
template
parameters
or
three
template
parameters,
because
one
of
them
is
by
the
time
you
get
to
the
bottom
of
this
tree
of
templates
or
generic
things.
You
only
need
three,
but
I'll
show
it
to
you
here
it's
this
file.
This
has
not
been
commented
very
well.
B
This
is
where
my
own
understanding
has
been
evolving
and
the
names
kept
changing
as
it
did
and
aaron
has
followed
me
on
this
journey.
So
he's
been
working
on
a
more
readable
way
to
present
this
and
we're
going
to
benchmark
it
and
go
forward
from
there,
but
so
there
are
some
interfaces.
This
is
the
point
where
you
leave
general,
like
golang
interface
with
general
number
type,
and
you
enter
a
code
specific
path.
That's
got
both
the
aggregator
and
the
number
number
type
baked
in,
and
so
these
are
sort
of
the
general
interfaces.
B
The
in
the
synchronous,
collection
path,
you're
going
to
call
accumulate,
you're,
sorry
you're,
going
to
call
update
with
one
a
number
and
then
in
the
collection
path,
you're
going
to
call
accumulate
on
every
series
or
time
series,
entry
or
label
set,
and
then
the
combination
of
that
is
like
what
you
get
when
you
create
a
new
like
a
new
label
set
for
an
instrument
right
now
because
of
views,
you
might
get
more
than
one
instrument
behavior
for
an
instrument,
so
you
have
a
multi-instrument
and
a
multi-accumulator,
that's
very
straightforward!
B
The
views,
compiler
mechanism
kind
of
it
has
to
assemble
all
the
things
it
knows
and
like
process
some
logic,
and
actually
it's
broken
right.
Now
the
the
filter
stuff
doesn't
work.
I'm
getting
100
like
attribute
removal
right
now,
which
I'm
going
to
show
you,
but
now
here's
some
gnarly
code.
This
is
what
we're
talking
about
it's
kind
of
hard
to
read
as
a
former
c
plus
plus
template
writer.
I
I
don't
have
too
much
trouble
with
this,
so
this
is
a
style
question
that
we're
coming
to
a
community
with.
B
So
this
is
take
some
getting
used
to
it's
practically
a
new
language
that
we're
writing
here
anyway.
The
rest
of
this
gnarly
stuff
is:
we've
got
a
code
path
for
synchronous
and
asynchronous
and
they
are
slightly
different
through
the
way
that
they're
associated
with
the
synchronous
path
is
like
multi-readers
and
the
asynchronous
path
is
one
reader
at
a
time
and
then
there's
there's
some
sort
of
like
concurrency
versus
non-concurrency,
like
there's.
B
Only
one
observation
per
label
set
per
period-
maybe
hypothetically
I'm
not
sure
for
the
asynchronous
measurements
and
then
synchronous
measurements
you're,
definitely
getting
a
different
code
path
there.
So
the
way
that
looks
is
if
you're,
a
synchronous
accumulator.
You
have
two,
you
have
two
storages,
there's
a
live
copy
and
the
snapshot
copy
and
and
the
moment
of
collection,
is
to
first
copy
and
and
reset
the
live
copy
into
this
temporary.
B
And
then
you
merge
that
temporary
into
every
reader
that
needs
it
so
that
there's
independence
of
the
readers,
but
whereas,
if
you're
an
async
accumulator,
what
I
did
was
I
had
a
simple
lock
and
a
simple
scalar
value.
Just
tell
me
the
last
value
that
you
observed
and
and
that's
kind
of
like
just
different
semantics
and
and
these
and
there
are
there-
are
some
differences.
B
I'm
not
going
to
go
into
that
play
out
because
of
all
the
things
I
just
described,
and
that's
so
that's
so
so
I
have
a
synchronous
instrument,
an
asynchronous
instrument.
These
are
kind
of
out
of
order.
I
have
async
and
synchronous
accumulators,
that's
one
per
attribute
set,
and
then
I
have
these
four
types
in
the
middle
which
com
build
on
the
other
types
and
play
and
and
expose.
B
Finally,
the
the
combination,
the
cross
product
of
synchronous
or
asynchronous
instrument
and
delta
or
cumulative
temporality
and
and
those
four
paths
have
different
collection
mechanisms
and
they
reset
state
in
different
ways,
and
there
are
four
distinct,
slightly
distinct
collection
methods,
and
I
don't
want
to
show
you
any
more
except
to
say
that
it's
unless
you
are
comfortable
with
the
templating
style
or
the
general
general
generic
code,
it's
going
to
be
pretty
gnarly
like
and
honestly.
The
names
just
still
need
some
work
like
this
new
sync
view
returns
an
instrument.
B
It
shouldn't
be
new
thing
for
you,
whatever
it
needs
some
work.
Okay,
so,
finally,
I'm
going
to
show
you
what
it
looks
like
to
be
an
exporter.
One
thing
is:
this:
is
the
prometheus
exporter?
It's
quite
looking.
It's
looking
quite
stateless
these
days,
except
that
the
producer
I
the
producer,
gets
called
very
early
on
with
life
cycle
of
a
prometheus
exporter
like
the
http
service
goes
live
before
the
sdk
starts.
I
need
a
lock,
but
there's
nothing
really
stateful
going
on
here.
B
You've
got
your
three
existing
prometheus
components
and
you
just
got
your
producer
anytime.
You
need
to
do
to
do
something
in
prometheus,
so
the
described
method
is
the
thing
that
gets
called
like
immediately
on
startup.
You
call
data,
you
call
your
producer,
there's
a
nil
producer
moment
before
you're
registered.
You
have
to
do
nothing,
but
in
this
case
I'm
passing
nil
because
I
don't
want
reuse,
multiple
prometheus
scrapes
might
come
in,
I'm
actually
not
holding
a
last
copy
of
anything.
I'm
just
releasing
memory
whenever
prometheus
is
not
scraping.
So
I
pass
nil.
B
I
still
get,
of
course,
my
data
value
and
then
here's.
This
is
what
I
want
to
show
you.
Exporter.
Logic
became
much
much
simpler.
I've
got
three
for
loops
over
slices
of
slices
of
slices,
and
then
this
is
exactly
the
old
logic
that
used
to
be
here.
This
descriptor
is
roughly
the
same
thing:
the
label
keys,
never
change.
We
still
so
this
this
block
of
code
is
the
same.
It's
just
that
you
used
to
be
wrapped
in
layers
of
back
and
forth.
Callback
collect
is
the
same
ooh.
I
need
a
notepad.
B
I
need
a
mil
check
here,
like
I
did
above
there's
this.
This
should
be
here
because
I'm
gonna
crash.
If
someone
collects
me
before
the
sdk
starts,
but
anyways
you'll
see
that
the
same
for
loop
happens
except
this
time.
I
pull
out
a
couple
of
variables
because
we
use
them
below
so
to
make
it
a
little
bit
shorter
the
code
and
then
basically,
this
code
is,
I
cleaned
it
up
a
little
bit
since
this
is
an
opportunity
to
lose
some
of
the
old
mistakes.
B
There's
no
more
error
values
in
the
in
the
like
get
me
my
sum,
or
something
like
that,
for
example,
so
there's
a
little
bit
of
cleanup,
nothing
more
to
see
here.
Lastly,
this
is
what
happened
when
I
ran
that
code.
The
the
renamings
were
definitely
applied.
B
All
my
attributes
are
gone
because
something's
broken,
but
it
basically
worked
now,
there's
no
push-based
exporter.
Yet
I
would
do
the
standard
output
exporter
next,
probably
a
few
hours
there
a
couple
hours-
maybe
maybe
not
even
that.
But
but
the
point
is
there
needs
to
be
a
new
periodic
exporter
framework
built.
It
has
to
have
options
and
a
config
once
you
and
and
then
its
implementation
is
going
to
have
some
to-do's
or
like
what
happens.
B
If
this
blocks
forever
or
do
we
do,
we
need
a
timeout
here
and
what
happens
if
one
collection
never
finishes,
but
the
like,
you
know
like
that.
Stuff
needs
to
be
answered
and
I
think
the
spec
is
a
little
vague
on
that.
I'm
not
worried
about
it,
but
that
would
be
next
steps.
B
Okay,
that's
it
that's
work
in
progress
and
thank
you
for
listening
and
thank
you
aaron
for
the
block
diagram.
D
Yeah
thanks
for
sharing
that
josh,
that's
pretty
great
good,
there's
a
lot
to
digest
there.
I'm
glad
this
is
recorded,
I'm
interested
to
look
at
the
views
set
up.
You
had
there,
like
you
said
it's
almost
like
a
new
language,
but
yeah
I'm
excited
to
take
a
look.
The
rest
of
that
looked
really
like
straightforward.
I
really
like
how
there's
that
processor
callback
method
so
cool.
This
is
maybe
I'll
just
pause
as
well.
Let's
see
if
anybody
else
has
any
other
questions
and
we
can
jump
forward.
B
I
know
I'll
be
taking
a
look.
I
have
to
rebase
it
it's
it's
pretty
destructive.
I
basically
deleted
everything
that
existed
before,
including
tests
because
I
was
having.
I
was
changing
a
lot
of
stuff
and
I
think
my
goal
would
be
to
start
writing
tests
and
comments
while
aaron
and
I
keep
benchmarking
and
contemplating
other
ways
of
being
generic
and
and
look
at
the
true
cost.
B
D
Yeah,
I
love
it
sounds
great
yeah
I'll
go!
Get
that
right
now,
cool
aaron!
Jumping
back
to
you!
Is
there
anything
else
we
wanted
to
touch
on
for
the
next
steps
for
the
sdk
like
what
are
our
next
steps?
Obviously,
we
have
some
some
work
here
that
we
need
to
get
into
the
review
pipeline
and
what
that
looks
like
and
then
maybe
just
give
a
little
outline
of
that.
E
Yeah,
I
think
it
was,
I
think,
josh
covered
it
very
briefly.
I
think
the
next
step
is
a
periodic
exporter,
so
that
we
can
finish
the
otlp
and
the
standard
out
exporter
and
then
start
rebuilding
the
test,
suite
that
we
have,
plus
whatever
address
any
kind
of
comments
that
people
see
with
either
style
or
or
naming
or
whatnot.
But
that's
the
the
main
thrust
of
this
would
be
the
first
two
points
there.
D
Okay
and
then
for
feedback,
where
can
that
be
registered.
B
We
should
put
together
a
pr
at
some
point,
but
aaron,
and
I
are
still
like
I
would
say,
trying
to
frame
that
question.
I
just
placed
about
how
to
do
the
generic
style,
which
has
performance
implications
that
we
need
to
sort
out.
First,
I
think
I
I
support
more
readable
code,
no
matter
what
and
and
like
an
example
of
the
kind
of
performance
that
I
know
is
going
to
be
a
slight
loss,
but
always
slight
loss.
Who
cares?
B
E
Yeah-
how
about
this?
I
will
create
a
just,
an
issue
for
at
the
outset,
right
now
to
gather
the
feedback
so
that
I
can
start
helping
with
that.
I
want
to
try
and
free
up
josh
as
much
as
possible
to
to
finish
this
so
that
he
can
keep
running
with
it
and
we
can
then,
like.
I
could
start
addressing
those
as
kind
of
pr.
We
could
even
start
addressing
those
as
prs
to
that
branch.
D
I
think
it's
a
that's
a
good
idea.
I
would
also
reiterate
if
you
plan
on
making
a
pr
to
the
metrics
anything
right
now,
I'd
hold
off
and
have
a
second
second
weight
on
that
one
but
yeah.
I
agree
so,
okay,
I
guess
you're
done
as
an
acronym
for
creating
an
issue
to
track
this.
I
imagine
that
over
the
next
week
I
just
anticipate.
There's
gonna
be
a
lot
of
review
of
this.
D
I
don't
know
if
there's
gonna
be
a
lot
of
feedback,
but
I
think
having
a
landing
page
for
the
asynchronous
part
of
it
would
be
great,
so
yeah,
I
think
that's
a
good
idea,
cool
that
sounds
good
from
there.
I
think,
then
we
can
probably
next
week
talk
about
implementation
in
the
pr
structure
going
forward.
That
would
get
reviewed
and
then
get
into
the
code.
So
yeah.
D
Great
timeline,
yeah
and
also
timeline
for
those
interested
or
watching
this
later,
like
keep
in
mind,
this
is
going
to
use
generics
from
go
118,
which
means
that
we
need
go
119
to
come
out
before
we
can
release
this
as
a
stable
version.
So
just
a
heads
up
on
timelines.
For
that
that's
the
sdk
api
is
not.
D
Yeah,
I
I
didn't
realize
that
was
the
conclusion,
but
I'm
not
opposed
to
that
either
yeah.
I
think
it's
just.
I
recall.
B
That
discussion-
and
I
remember
anthony's
giraffe
pr-
showed
it
was
like
as
possible.
I
think
that
that's
a
reasonable
option.
F
Yeah,
basically,
all
you
have
to
do
is
make
sure
that
there's
some
file
there
that's
going
to
build
doc.
Dot
go
is
great
without
the
118
tag
and
then
put
the
go.
118
tag
on
everything
else.
B
D
Aaron,
can
you
create
an
issue
to
track
that
as
well?
I'm
gonna
put
in
the
notes,
but
okay
yeah.
F
D
Okay,
cool
yeah,
that's
exciting!
It
looks
like
we
got
12
minutes
left,
so
I
want
to
prioritize
some
more
community.
You
know
related
tasks,
so
we're
gonna
move
on
here.
Brad
you
put
down,
you
wanted
to
introduce
yourself.
I
think
this
is
a
great
segue.
We
love
to
do
these
kinds
of
things
and
I
keep
forgetting
to
do
it.
Anyone
else
who's
new
on
the
call
that
hasn't
joined
before
or
is
just
really
wanting
to
talk
to
us.
G
Thank
you
very
much.
Tyler
hi
everyone,
I'm
brad
topple,
I'm
at
ibm
and
gonna
start
looking
at
contributing
to
open
telemetry,
and
this
seemed
like
a
great
place
to
start.
So
I
was
going
to
say
I
was
looking
for
some
low
fruit
and
tyler.
It
looks
like
you
mentioned.
There
was
an
issue.
I
think
I
went
ahead
and
put
a
comment
on
it
in
the
github,
so
I'll
connect
with
you
afterwards.
G
But
you
know
this.
This
is
a
really
cool
area.
I
used
to
work
on
it
when
dinosaurs
roamed
the
earth
many
many
years
ago.
So
you
know
sometimes
things
come
full
circle.
The
the
opportunity
to
to
you
know
ibm's,
given
the
opportunity
to
spend
some
time
in
the
space
really
looking
forward
to
it.
So
you
know
any
mentoring.
You
all
can
give
me
as
I
I
have
worked
on
other
open
source
projects
over
the
years,
but
you
know
any
mentoring.
You'd.
Give
me
to
help
me
get
started,
would
be
wonderful.
E
The
only
comment
I
have
is
when
dinosaurs
were
walked
to
space
in
this
space
is
like
last
october,
so.
B
G
Like
a
different
version
with
different
technologies
way
way,
you
know
yeah
exactly
but
really
looking
forward
to
it.
It's
a
very
fun
area.
D
Well,
awesome
glad
to
have
you
brad
I've
already
assigned
that
issue
to
you
so
yeah,
looking
forward
to
working
with
you
right.
D
Yep
cool
anyone
else,
I'll
just
pause
here,
let's
see
if
I'm
gonna
yeah.
C
I'll
go
I'll.
Go
too,
I'm
new,
hey
my
name's
tyler
helmuth.
I'm
I've
been
using
open
telemetry
for
a
while
at
some
other
companies,
but
I
recently
switched
and
now
I'm
part
of
new
relic
and
I'm
I'm
here
in
the
community
doing
stuff.
C
Now,
for
the
last
month,
I've
been
getting
involved
in
lots
of
different
repositories
and
projects
trying
to
focus
around
the
collector,
but
I'm
also
trying
to
find
a
nice
instrumentation
team
to
get
involved
with
and
since
they're
both
go,
I'm
taking
a
peek
at
this
one
right
now,
so
I
definitely
want
to
start
getting
some
work
done
for
you,
guys
and
being
part
of
the
team
and
grabbing
some
low,
higgin
low
hanging
fruit
as
well.
But
I
got
some
other
stuff.
D
Yeah
awesome
welcome
to
have
you
ever
happy
to
have
you
tyler
thanks
for
joining.
Normally,
it's
the
other
way
around
you
come
here
and
then
you
go
to
the
collection
and
I'll,
never
see
you
again,
but.
D
D
I
think
we
can
do
a
better
job
at
identifying
some
issues
that
we
have
open
with
the
help
wanted
label.
I
think
and
then
maybe
also
a
good
first
issue-
that
one's
probably
less
accurate.
These
days.
I
was
just
looking
through
a
lot
of
our
backlog
of
issues
and
there's
a
there's,
a
pretty
big
backlog
that
probably
needs
to
get
cleaned
up,
so
hopefully
that'll
be
clean,
er
in
the
next
week
or
two
and
good
idea
to
pull
from
there
but
yeah.
D
As
always,
we
try
to
also,
as
you
can
see
like
structure
a
little
bit
of
what
our
next
steps
are
into
issues
that
are
digestible
and
identify
them
for
new
people.
So
yeah,
all
all
help
is
welcome.
Pull
request.
Reviews
are
really
useful.
Documentation
updates
are
really
useful,
really
small
things
that
are
pretty
common.
It's
a
great
way
to
start
in
the
project,
so
yeah
glad
to
have
you
both.
D
Thank
you
cool.
I
think
with
that
we'll
ask
about
user
stories.
Does
anybody
use
the
project
josh
is
on
the
call.
I
might
put
you
on
the
spot
in
the
past
week
or
two
in
some
cool
and
interesting
ways,
maybe
into
measuring
some
sort
of
water,
remote
sensing
device.
B
B
Although
I
was
thinking-
and
I
might
continue
on
this
path-
that
so
this
I'm
referring
to
mqtt
interesting
history
involved,
former
use
for
telemetry
than
then
kind
of
generalized
beyond
telemetry,
so
there's
a
spark
plug
protocol
that
is
new
newish
in
the
last
three
four
years.
B
That
is
kind
of
just
what
we
need
if
you
want
to
send
telemetry
over
a
low
bandwidth
link
using
all
the
things
that
made
mqtt
what
it
was
or
what
it
is.
So
I
got
excited
and
I
I
went
and
used
that
I
have
a
go.
I
have
a
oh
tell
collector
receiver,
it's
a
very
prototype
e,
but
it
does
convert
hotel.
B
It
does
convert
the
mqtt
spark
plug
payload
into
hotel
and
then
sends
it
to
lightstep,
which
I
was
able
to
make
happen.
Have
you
had
a
few
kind
of
like
glitches
here
and
there
that
I'm
I'm
sorting
out
before
I
share
this
one
more
widely?
But
yes,
it
was
exciting
and
I
did
imagine
at
least
maybe
in
the
future.
B
I
could
write
an
stk
exporter
that
would
send
over
mqtt
using
this
same
code
basically,
but
it
would
take
the
the
three
four
loops
that
I
just
showed
you
earlier
and
it
would
output
this
different
payload
and
then
it
would
go
through
and
one
of
the
open
source
mqtt
clients.
Basically,
once
I
had
done
all
that,
I
learned
that
they
are
in
progress
of
updating
the
specification
to
solve.
D
B
D
Well,
cool
anybody
else
have
some
cool,
interesting
uses
or
any
uses.
D
F
Hotel
go
but
there's
a
new
project.
That's
spinning
up!
That's
looking
to
to
get
into
cncf
as
an
incubating
project
called
open
feature
which
is
looking
to
model
itself
as
doing
for
feature
flags.
What
open
telemetry
is
done
for
telemetry
and
including
integration
with
the
open,
telemetry
semantic
conventions
for
conveying
feature
flag
decisions
via
traces,
and
things
like
that.
F
So
it
was
pointed
out
to
me
recently
by
someone
who's
working
on
that,
and
I
thought
that
was
very
cool
and
I
know
it's
it'll
overlap
with
a
lot
of
what
people
are
doing
in
terms
of
getting
visibility
into
how
their
applications
perform
and
knowing
which
feature
sets.
We're
actually
selected
is
kind
of
important
for
that.
D
Yeah,
that's
really
cool.
I've
definitely
seen
two
different
limitations
at
two
different
companies
and
yeah
they're.
So
similar
you
just
wonder:
why
isn't
this
open
source?
That's
really
cool.
B
I
was
going
to
add
that
I've
discovered
a
really
nice
code
base
written,
go
it's
this
mqt
mqtt
server
that
I
was
using,
and
I
found
this
sort
of
like
loan
contributor,
had
written
a
server
and
then
a
few
people
started
using
it.
So
I
was
one
of
the
new
people
to
to
go
and
start
using
it
and
found
it
needed
a
little
bit
of
observability
help
for
in
the
sort
of
sort
of
first
pass.
I
took
was
to
do
an
audit
of
error
handling
and
follow
existing
style.
B
It
created
a
handler
for
your
errors,
so
you
can
see
a
little
bit
more
observability
into
connection
failures,
which
I
was
actually
having
during
that
moment
in
time
and
I'm
tempted
to
go
start
putting
spans
in
there
and
of
course,
I'm
reminded
that,
there's
this
giant
debate
going
on
in
hotel
about
how
to
instrument
that's
observing
message,
passing
system,
and
so
I'm
left
thinking
that
there's
a
potentially
interesting
prototype
for
hotel
go
plus
messaging
server
integration
just
to
show
what
does
it
look
like
when
you
want
to
instrument
a
messaging
server,
because
this
is
like
400
700
lines
of
code?
B
It's
a
really
nice
code
base,
linked
from
my
my
thing
that
you
might
have
found
on
twitter
or
on
go
hotel,
go
slack
anyway.
D
Yeah
cool
I'll
have
to
check
it
out.
I
didn't
actually
look
at
the
server,
but
that's
a
good
suggestion
appreciate
it
cool
so
we're
running
up
to
the
I
don't
know
what
they
say
in
england
bottom,
maybe
top
of
the
hour,
and
we
should
probably
end
it
here,
but
yeah
thanks.
Everyone
for
joining
we'll
see
you
all
next
week
same
place
same
time
or
asynchronously
on
slack
or
in
issues,
but
yeah
thanks
for
everyone.
Bye.