►
From YouTube: 2020-11-20 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).
C
A
A
C
B
And
start
in
a
minute
rob:
is
there
anything
you
specifically
wanted
to
talk
about.
E
Christ-
sorry,
I
don't
know
if
I
can
buy
this
laptop.
I
normally
use
the
one
over
there,
but
there's
no
camera
on
that
and
I
thought
I'd
be
polite
and
show
my
face.
So
hopefully
that's
all
working
now,
yep
yeah,
yeah
cool,
so
yeah.
Nothing.
I
want
to
talk
about
explicitly.
I've
come
just
to
show
my
face
and
say
hi
really.
Obviously,
I'm
metrics
focused
at
the
moment.
E
That's
literally
what
I'm
doing
right
now
and
obviously
we
can
talk
about
that
a
little
bit
if
you
want
to,
but.
B
Yeah
I
haven't
looked
at
the
spec
in
forever
and
I'm
trying
to
finally.
C
That
sounds
more
like
a
banging,
not
gun.
B
So
yeah
then
I'll
be
hopping
back
to
metrics,
so
yeah.
Is
there
any
thing
that
you
had
questions
about
so
far
or
is
there.
E
No,
not
really
you
mentioned
0.5,
I
actually
haven't
checked
the
version
of
spec
one.
Now
I
saw
someone
mention
it
earlier
in
gita,
but
again
it's
on
my
other
computer.
E
A
Yeah
I
forgot
to
raise
issues
around
the
like
you
know.
While
I
was
deep
dog
fooding,
I
found
a
couple
of
things
with
the
api
where
I
was
just
like.
Suddenly,
I
had
to
call
into
the
erlang
side
of
things,
and
there
was
also
the
maps
versus
keyword,
lists
thing,
yeah,
where'd,
that
all
land.
B
A
Okay
and
then
the
other,
the
other
one
was
just
that
the
ecto
hookup
no,
actually,
no,
I
think
it
was,
was
trying
to
start
a
span
and
then
immediately
end
it
and
it
couldn't
end
it
without
making
it
current.
B
A
It
was
the
the
elixir
side
of
the
api.
Wasn't
able
to
do
it,
so
I
had
to
call
into
the
erlang
so
yeah
the
small
detail.
If
we're
willing
to
tidy
that
up,
then
that's
not
a
big
change.
Yeah.
B
B
D
B
Let's
see
so
yeah,
the
only
agenda
items
I
had
for
today
were
about
the
I'm.
Definitely
getting
the
next
release
out
very
soon
and
that's
going
to
require
a
number
of
updated
two
integrations
and
like
today
at
work,
someone
they're,
finally
converting
some
stuff
from
open
census
to
open,
telemetry
and
discovered
that
the
phoenix
framework
disintegration
is
not
updated
for
the
latest
api
and
sdk
and
wanted
to
check
if
anybody
ever
working
on
that
garth.
That
looks
like
you
said
you
kind
of
started,
but.
A
Basically,
everything
involved
in
a
normal
phoenix
live
view
app,
so
the
the
phoenix
hookup
the
the
plug
hookup,
if
we're
still
doing
that
the
ecto
hookup
my
own
live
view
stuff,
and
you
know
anything
else
that
gets
in
my
way
really.
But
if
anyone
else
gets
there
first,
please.
B
B
A
If
you've
been
pushing
those
releases
to
hacks
sorry
I
mean
I
shouldn't
use
the
subjective
physically.
Have
you
been
pushing
those
releases
to
hex.
B
A
Right
if
we
can
start
getting
these
release
candidates
into
hex
like
that
having
to
do
that,
those
you
know,
boutique
get
refs
and
having
to
very
carefully
control.
Your
compilation
order
is
a
bit
of
a
mess.
B
Yeah,
oh
well,
the
compilation
order
should
at
least
be
fixed
that
issue
so
yeah.
I
fixed
that
in
the
rebar
three
config
but
yeah
I've
been
wanting
to
get
point
five
out.
B
I
was
waiting
on
a
few
things:
what's
gonna
weight
on
record
exception,
but
I
don't
think
I'm
gonna
wait
so
might
even
release
it
tomorrow,
yeah
there
should
be
there's
nothing
holding
it
up
now,
it's
just
a
matter
of
taking
the
time
and
it's
a
little
tricky,
because
the
api
is
that
weird
monstrosity
of
elixir
and
erlang
together
publishing
the
sdk
is
simple
enough.
B
F
And
what
about
context
propagation?
I
know
that
the
airline
is
a
actor-based
model.
Right,
so
is
it?
Does
it
require
manual
instrumentation
or
you
manage
to
make
it
sort
of
built
in.
B
A
bit
of
both
what
we
do
is
so
there's
the
process
dictionary,
which
is
like
a
it's
like
a
thread
local
in
python,
and
it
allows
us
to
carry
the
context.
B
Behind
the
scenes
within
a
process,
but
when
we
cross
processes,
that's
still
been
an
up
in
the
air
decision.
It's
currently
a
manual.
You
grab
the
current
context
from
the
process
dictionary
and
you
pass
it
through
a
message
or
through
the
function
that
is
spawned,
and
there
is
one
tricky
way,
sequential
tracing
tokens
that
you
can
latch
on
a
context
in
a
message
that
gets
passed
transparently
to
the
to
the
user.
But
it
comes
with
a
lot
of
caveats.
B
I
mean
it's
part
of
earlings
had
its
own
form
of
distributed
tracing
for
like
30
years,
and
it
basically
would
not
allow
the
user
to
continue
to
use
that
for,
like
real-time
debugging.
If
we
latched
on
to
that
some
other
drawbacks
reached
out
to
the
ott
otp
team,
but
haven't
talked
with
them
really
about
it.
Yet
about
whether
or
not
we
should
have
another
option
for
hidden
context,
propagation
between
processes,
but
I
think
it's
probably
gonna.
A
Okay,
yeah
one
thing:
making
a
lot
of
the
integrations
easier.
At
least.
Is
that
excuse
me,
the
the
growing
propagation
of
the
telemetry
project
and
the
the
use
of
the
start,
stop
and
exception
suffixes
on
event
names
so
like,
especially
in
the
I
can't
talk
as
strongly
for
the
erlang
side
of
the
ecosystem,
but
certainly
amongst
all
of
the
elixir
projects.
There's
there's
pretty
widespread
adoption
of
of
telemetry
and
so
other
than
a
few
sort
of
holdouts
like
ecto,
where
they
just
give
you.
A
You
know
one
telemetry
call.
After
the
event,
everybody
else
you've
got
the
the
chance
to
use
the
in-process
tracking.
A
That
tristan
was
talking
about
to
you,
know,
push
and
pop
spans,
and
so
it's
becoming
quite
easy
to
write
integrations
and
even
if
you
don't
want
to
deal
with
the
dependency
management
overhead,
I
mean
there's
a
lot
of
sort
of
vendor
engineering
required,
even
with
open
source
projects
to
take
all
of
these
dependencies.
A
But
increasingly,
the
dependencies
are
very
small
and
you've
got
like
basically
an
entire
project,
which
is
there
just
as
life
support
for
one
module,
and
you
can
pull
the
wings
off
that
module
figure
out
what
it
is
copy
that
one
file
into
your
project
change
it
to
meet
your
local
standards
and
then
just
leave
it
in
place
and
ignore
it
until
the
end
of
time
and
so
yeah.
The
the
integrating
is
becoming
quite
easy.
B
Then
the
content,
because
they
they're
both
within
the
context
together,
so
it
like
the
span
context-
is
in
the
context
and
the
baggage
is
in
the
context.
Oh.
A
B
B
It's
not
exactly
necessary,
but
there's
I've
always
had
some
thoughts
about
being
able
to
do
it
in
I,
I
kind
of
think
it
could
be
useful
doing
it
live
like
adding
information
you
know
about,
because
tracing
in
erlang
is
one
of
its
core
strengths
so
being
able
to
tap
into
that
and
automatically
without
modifying
the
code.
Add
some
spans
or
attributes
is
definitely
possible,
but
I
know
that
new
relic
in
their
tracing
stuff
does
all
kinds
of
stuff.
I
would
if
I
would
not
want
included
in
open
telemetry.
B
But
because
it's
fairly
hacky
of
walking
supervision,
trees
and
stuff,
but
they
do
a
bunch
of
auto
instrumentation
type
stuff
for
theirs,
but
yeah.
We
don't
have
anything
yet,
but
instead
I
don't
know
if
it's
going
to
be
as
useful
or
popular
as
like
in
java,
but
yeah
it's
definitely
a
possibility
because
of
because
we
can
tap
into
anything.
A
I'm
a
big
fan
of
remote
shelling
into
instances
and
using
the
dubig
module
to
hook
up
tracer
functions
to
all
sorts
of
stuff
flying
around
and
some
sometimes
I'll
just
go
for
console
dumps.
But
you
know
equally
I'll
fire
up
some
telemetry
or
or
send
some
traces.
So
I
can
use
my
my
trace
tooling,
to
to
check
out
something.
That's
a
heap
of
fun.
A
No,
I
I
just
I
it
was
kind
of
funny
like
I
I
was
having
such
trouble
understanding
recon,
that
I
I
just
started
using
the
raw
dibb
module,
and
I
I
find
that
easier
now.
I
just
learned
that,
and
that
way
I
don't
have
to
learn
someone
else's
leaky
abstraction
around
it
like
once,
you
learn
to
write
those
those
those
match,
yeah
those
those
little
match.
Specs
are
a
bit
of
a
learning
curve,
but
you
need
to
learn
that
kind
of
stuff
for
ets
anyway.
So
you
know
it
was
about
time.
B
A
B
With
the
sequential
token
sequential
trace
token,
when
it
enters
a
function
right,
it
leaves
the
function.
You
can
only
get.
You
can
get
a
message,
but
it
can't
have
the
sequential
trace
token
so
and
yeah
I've
talked
to
the
ftp
team
about
it,
and
then
I
guess
it
would
be
a
lot
of
work
for
some
reason
to
add
that,
but
but
they're
they're
they're
planning
to
add
the
ability
to
write
those
fine-grain
tracing
stuff
in
erlang
right
now.
B
A
F
A
Bit
disappointing,
I
mean
back
to
yuri's
comment
the
the
the
problem
with
using
dybbic
to
yeah
as
a
routine
way
of
getting
your
your
tracing
done.
A
Is
that
all
your
metrics
is
that
if
anyone
else
comes
along
and
wants
to
use
debugging
for
anything,
the
first
thing
they're
going
to
do
is
clear
all
of
the
traces
and
and
then
it
all
stops,
and
it's
we've
also
had
like
problems
with
the
telemetry
based
integrations,
which
is
that
supervising
starting
them
up
is
a
real
hassle
because,
of
course
the
if
there's
a
if
anything
dies
then
like.
A
If,
if
one
of
the
telemetry
event
handlers
crashes,
then
telemetry
will
remove
all
of
the
all
of
the
handlers
for
the
same
id
and
that's
just
gone
and
there's
there's
no
way
to
get
a
notification
out
of
that,
and
so
whatever
process
you
you
were
supervising
to
get
that
started
up,
is
none
the
wiser
and,
and
it's
just
suddenly
you're
like
hang
on
where's,
my
where's,
my
ecto
telemetry,
so
yeah
there's
an
awful
lot
of
exception,
catching
happening
in
those
those
handlers
to
try
to
make
sure
that
you
know
whatever
happens.
F
Pain,
I
think
my
main
background
for
that
question
was
like
different
languages
deal
differently
with
context
propagation
and
so
in
java,
for
example,
if
you
don't
do
auto
instrumentation,
then
it's
pretty
hard
to
guarantee
that
the
context
propagation
will
be
working
correctly,
because
people
are
always
free
to
create
like
a
new
thread
or
something
like
that
and
if
you're
using
thread
local,
then
you
basically,
you
have
to
have
every
single
concurrency
primitive
to
be
instrumented,
and
so
the
instrumentation
can
do
that,
whereas,
like
explicit
one
can't
and
so
like,
when
I
was
a
tuber,
we
had
always
like
this
issue
with
that
kind
of
type
of
like
breaks
in
the
context
propagation,
and
so
this
is
why
I'm
asking
where
is?
F
I
can
go
because
context.
You
can
also
also
drop
the
context,
but
at
least
it's
sort
of
like
part
of
the
pattern
that
you
pass
the
context
as
an
object
through
the
function
calls.
Then
it's
it's
much
more
straightforward
to
always
have
that,
and
I
would
like
with
erlang,
because
I
just
don't
know
the
language
well
enough.
F
D
B
Out
a
smooth
way
that
wouldn't
have
some
bad
side
effects
to
do
it
automatically,
but
the
nice
thing
is,
I
think,
because
the
spawning
and
messaging
the
processes
is
sometimes
transparent,
but
it's
also
it's
fairly
fairly
defined.
When
it's
being
done,
it's
not
as
a
like
surprising.
If
you
need
to
pass
it,
you
know
where
it's
happening,
so
I
don't
think
it's
as
much
of
a
problem
like
in
I
don't
know
when
I'd
written
go.
I
wouldn't
know
when.
F
B
Was
or
where
they
were,
these
guru
teams
were,
but
in.
F
B
We
have
a
nice
structure
around
it,
so
it's,
I
think,
a
little
more
defined,
but
definitely
would
yeah
prefer
if
there
was
never
the
possibility
that
you
would
lose
context
because
of
the
spine.
Hopefully,.
A
Yeah
in,
in
practice,
most
of
my
usage,
you
know
you
strap
your
integrations
around,
because
it's
just
because
of
the
resolution
I
mean
and
for
for
metrics
and
we'll
get
back
to
rob.
A
We've
got
to
get
back
through
at
some
point
for
metrics
it's
a
different
story,
but
for
tracing
I'm
normally
worried
about
things
that
take
one
ten,
a
hundred
thousand
milliseconds,
and
by
and
large
those
tend
to
be
about
conversations
with
somebody
else
like
and
and
so
and
and
they
they
tend
to
happen
in
particular
modules,
and
so
once
I've
got
my
back
ends
hooked
up
like
because
I
just
because
the
way
these
modules
are
structured,
a
lot
of
them
have
telemetry.
A
Also
a
lot
of
them
have
back
ends,
so
that
can
be
stubbed
out
for
unit
testing
purposes,
and
so
you
whack
your
own
back
end
in
there
and
then
you
can
get
your
integration
happening
before
you
know
it.
You've
got
everything
is
tracing
and
then
it's
by
and
large
everybody's
pretty
good
about,
not
mucking
up
the
call
path
and
the
traces
hook
together
really
really
nicely,
and
all
you
got
to
do
is
look
for
trace
spans.
That
don't
seem
to
have
a
parent
right
like
you
go.
A
Why
is
that
sending
a
new
trace
that
should
be
part
of
an
existing
trace?
And
so,
if
you
just
look
for
those
I've
found
it
very
easy
to
go.
Oh,
it's
sending
a
message:
okay,
I'll
just
hook
up
a
way
to
propagate
the
context
there
or
task.async
is,
is
the
the
big
one
in
the
elixir
community.
Someone
used
tasker
lacing,
so
I
just
wrapped
the
function
pass
the
context
done
and
it
all
turns
out
pretty
straightforward.
B
Yeah
fred
and
I
have
been
talking
about
creating
forking
all
the
behaviors
and
having
behaviors
that
pass
the
context
transparently,
because
since
most
message,
passing
and
spawning
goes
through,
the
the
otp
behaviors,
it's
very
easy
to
just
have
to
plug
it
in
in
certain
spots,
so
sort
of
like
auto
instrumentation.
I
guess
in
java
yeah
we
were
going
to
do
that
for
spawn
fest,
but
just
didn't
get
around
to
it
and
need
to
do
that.
Earlings.
B
Does
that
the
my
framework
for
distributed
virtual
actors
puts
the
current
context
into
any
call
call
or
cast
or
info
to
a
grain,
a
virtual
actor
and
transparently
to
the
user
and
passes
that
along
and
then
puts
it
into
the
current
context?
But.
B
B
E
Well,
not
really
because
it
all
comes
down
to
you
getting
up
to
date
with
the
spec
and
working
out
how
best
to
get
the
erlang
upstate
with
the
spec
we're
actually
limping
through
with
it
now
so,
we've
actually
started
integrating
the
concept
anyway,
but
we
can
do
that
because
we're
not
actually
writing.
Erlang
writing
pure
script.
Obviously
so
you're
writing.
E
And
I
pure
script:
oh,
we
we
write.
B
E
This
isn't
just
academia,
it's
not
just
academia.
No,
no!
We
we
build
disputed
video,
encode
dispute
and
distribution
systems
and
our
primary
language
for
building
the
applications
in
has
been
pure
script
for
the
last
year
and
a
half
or
so.
We've
just
put
our
tools
down
for
a
couple
of
months
to
start
bringing
some
of
our
actual
video
stuff
over
into
pure
script
as
well,
and
that's
where
this
has
come
from
because
we're
going
back,
go
to
the
metrics
and
tracing
again.
How
many
times
do
that
before?
E
Can
we
do
it
better
this
time?
Probably
yes,
let's
go
and
look
at
what
else
is
doing
out.
Oh
look,
opus,
lemon
juice,
you
think.
Oh
look,
okay,
erlang's
a
thing!
Perhaps
you
should
use
that
too
and
so
and
so
forth,
and
that's
what
we
are
here
now,
which
is
learning
all
about
metrics
the
way
they
probably
should
be
done
and
actually
looking
at
a
handheld
systems.
They
are
somewhat
woeful.
Now,
having
learnt
about
some
of
the
things
being
spoken
about
the
other
night.
So
so
that's
that's
where
you
are.
Yes!
E
Writing
your
script.
That's
that's
fine!
So
you
know
the
erlang
is
obviously
quite
out
of
date
and
and
and
if
you
haven't
got
time,
we
do
have
time
and
we're
getting
paid
to
do
this.
So
it's
not
like
we're
like
putting
our
evenings
in
our
company's
happy
to
pay
me
money
to
to
do
the
work
on
openclan
metrics,
so
the
the
the
code
I
can
write
in
peer
scripts
actually
match
something
that
that
works
for
us.
E
And
but
I
think.
F
E
E
Essentially
yeah,
so
we
read
the
spec
and
a
couple
of
times
say
that
paragraph
slightly
ambiguous
to
us
go
and
see
what
the
go
does.
Okay,
it
does
those
things
there,
that's
not
what
the
erlang
does.
The
erlang
probably
should
do
something
similar
to
that.
Okay,
fair
enough.
We
can
do
that.
That's
you
know.
I
reckon
a
day's
effort
would
get
the
lying
into
the
state
where
the
stuff
we
want
to
use
would
work
as
we
needed
it
to
work.
B
E
Well,
as
it
stands,
we
only
care
about.
You
know
two
or
three
of
the
single
instruments
and
a
couple
of
the
async
ones
and
obviously
the
binding
stuff
needs
to
work
properly
as
well,
and
then
that's
that's
pretty
much
all
we
need.
Obviously,
then
we
start
talking
about
baggage
and
the
rest
of
it
too,
and
there's
a
hope
as
a
few
to
do
paragraphs
and
respect
for
those
still,
but
let's
buy
the
buy.
A
A
Side
of
things
the
I
notice
we
can
get
and
we
can
put-
are
there
any
increment
operators
or
accumulate
operators.
B
A
But
yeah
like
maybe
maybe
I
should
be
looking
at
the
I
mean,
because
the
problem
is
that
you
know
I
do
have
some
things
where
I've
got
like
numbers
and
and
so
at
least
in
my
python
code-
I'm
rolling
I'm,
you
know
you
know,
measuring
another
five
milliseconds
and
accumulating
a
value
with
the
total
elapsed
time
doing
that
particular
thing
or
accumulating
the
count
of
of
doing
this
other
thing,
and
then
it
all
ends
up
in
one
event
and
I
dump
it
out,
and
it
kind
of
strikes
me
that
that
was
a
thing
right.
A
Well,
it's
it's
really
handy.
I
mean,
especially
when
you've
got
these.
You
know
in
python,
you've
got
the
you
know
these
chains
of
generators
and,
and
so
you've
got
like
the
yeah
different
functions
and
they're
all
kind
of
closures
around
each
other.
It's
a
bit
weird,
but-
and
you
want
to
independently
gather
up
how
much
time
we
spent
say,
reading
the
image
converting
a
particular
frame
resizing
that
particular
frame.
How
many
frames
was
it?
What
was
the
input
bytes?
A
What
was
the
output
bytes
and
but
I
I
want
them
all
in
one
wide
event
when
it
hits
my
tracing
machinery
and
and
so
I've
been
doing
that
as
part
of
the
way
I
build
events
in
python
and
but
I'm
just
starting
now
to
move
a
lot
of
that
machinery
into
erlang,
and
it
would
be
nice
to
be
able
to
do
the
same
kind
of
thing.
A
E
A
B
B
I
was
only
going
with
so
that's
not
actually
a
difference
from
the
go
implementation,
because
I
just
designed
it
different
is
bound.
Instruments
would
be
actual
variables.
Constructs
that
you
could
pass
around,
but
instruments
were
simply
in
an
eds
table.
B
E
So
I
can,
I
can
talk
about
that
from
a
pure
script
perspective,
which
is,
I
think
there
is
useful
information
because
a
you
don't
want
to
create
the
same
instrument
twice.
You
can't
anywhere
else.
You
did
it's
a
false
operation,
but
the
way
the
reference
stuff
and
go
seems
to
work.
Is
they
like
to
stick
the
references,
the
instruments
onto
their
static
server
or
whatever,
and
then
use
those
to
create
the
binds
bound
instruments
or
use
those
to
create
the
observers
or
so
on
and
so
forth?
E
And
we
kind
of
understand
pure
skip
land
too,
because
if
we
capture
type
information
at
the
point
of
creating
an
instrument,
you
can
use
that
to
when
binding
or
writing
data
to
that
instrument
verify
the
type
of
that
instrument,
and
we
can.
We
can
fake
that
happily
in
in
our
api
on
top
of
the
erlang
stuff,
I
think
it
was
when
it
came
when
it
came
to
writing
the
observer
stuff.
E
We
ran
into
a
roadblock,
and
I
can't
remember
why
that
was
I'm
sure
if
I
looked
at
the
code,
which
is
again
on
the
other
computer,
that
would
would
ring
bells
again,
but
I
I
think
that
we
did
actually
want
that
for
some
other
reason
other
than
just
going.
Oh,
yes,
we'd
like
an
object
because
types,
because
that's.
E
You
know
it's
yeah,
especially
because.
B
I
mean
part
of
it
also
was
like
in
in
open
census.
The
api
was
just
record.
There
was
no
counter
add
gauge,
of
course,
value
record
recorder,
but
now
in
open,
telemetry
there's
the
the
api
is
you
have
a
counter
module
with
an
add
function?
You
have
a
a
value
recorder
module
with
a
record
function,
and
so
in
that
sense
I
was
like
well,
okay,
those.
B
E
I
think
the
the
main
realization
we
had-
and
this
is
just
us
being
doofus-
is
not
reading
the
spec
properly
is
we
didn't
really
understand
instruments
anyway?
Obviously
we
understood
yeah,
you
bind
because
then
you
get
the
things.
You've
got
the
labels
and
then
you
can
add
the
data,
the
labels
here
and
all
that
other
stuff.
What
became
clear
the
other
night
when
I
sat
in
those
talks
is
that
instruments
are
fairly
standard.
Things.
E
Metrics
are
very
standard
things
we
might
have.
An
instrument
called,
for
example,
frame
count
frame
counts
quite
a
good
example
really,
and
we
would
actually
be
writing.
Multiple
label
sets
to
frame
counts
across
that
application,
depending
on
where
you
were,
the
encoder
would
have
a
frame
count.
A
mixer
would
have
a
frame
count,
a
anything
doing
anything
to
a
frame
when
I
have
a
frame
count
and
they
will
all
need
to
either
create
a
frame
count
or
at
least
bind
to
frame
count,
but
then
none
of
them
know
frame
cat.
E
I
just
chat
or
not
so
they're
all
gonna
have
to
call
create
them,
bind
that's
kind
of
silly.
So
actually,
what
I
want
to
do
is
have
friend
count
created
at
the
beginning
by
something
say:
I'm
creating
frame
count
and
you
basically
end
up
creating
most
of
your
instruments
up
front
for
your
application,
and
that
seems
to
actually
not
be
a
terrible
thing.
E
It
seems
to
be
the
right
thing
because
actually
we're
doing
telemetry
here
and
actually
knowing
having
a
standard
type
of
instruments
as
ends
as
it
is
where
everyone
seems
to
converge
and
poof
mad
explodement.
That's
actually
amazing.
A
true
false
is
is:
is
it's
not
an
object?
So
there's
no
there's
no
guide
to
me.
There
saying
hey.
E
Actually
you
want
to
create
this
once
and
then
you
kind
of
wanted
to
to
bind
label
sets
to
it
and
whatever,
even
if
that
the
thing
that
it
returns
doesn't
do
anything
in
our
case
it
would
do
something
good
recovery,
type,
information
or
whatever
and
from
an
api
perspective.
Reading
the
go
made
us
go
whoa.
E
E
Big
thing
for
us:
actually,
when
we
we
read
the
government,
oh
actually,
the
model
we're
trying
to
do
in
in
our
script
is
just
wrong
and
that's
that's
never
going
to
work.
You
actually
you
you,
you
know
you,
you
create
an
instrument,
you've
created
it,
it's
done
it's
pre-referenced
over
here
somewhere
and
then
and
then
and
use
it
to
bind
or
write
directly
or
create
observer
or
whatever
hey
and
observers.
E
There's
a
whole
thing:
there
there's
we're
not
quite
sure
how
to
use
them
properly,
yet.
E
B
That's
really
good
to
know.
That
was
something
that
we
did
in
open
census
as
well,
and
so
I've
been
used
to
it
for
a
long
time,
so
certainly
didn't
document
it
well,
I'm
sure
and
didn't,
and
I
need
to
look
at
the
implementation
again
to
make
sure
yeah.
That
is
clear,
yeah.
It's
not
the
statsd
world
anymore,
where
you
just
throw
metrics
out
some
data
around
yeah
like
yeah
when
we're
talking
about
a
name.
It's
not
like
it's
that's
d!
When
you
use
a
name,
it's
just
that's
the
name
of
the
metric.
F
E
Yeah
and
then
the
key
relation
was
reading
the
spec,
and
it's
saying
you
know
you
create
an
instrument
and
the
instrument
is
there
for
the
lifetime
of
the
sdk
and
you
can't
destroy
it
and
it's
an
explicit
it's
an
explicit
choice
by
the
by
the
specification
so
and
so
forth
I
mean.
Actually
you
know
this
forces
us
down
a
path
where
we
have
to
name
our
instruments
very
carefully
and
think
about.
Do
we
need
a
new
instrument
for
this?
Is
it
or
is
this
something
else?
What
kind
of
instrument
is
this?
E
B
B
E
We're
going
to
be
adopting
in
the
pure
script
stuff
too,
but
obviously
we
encapsulate
type
information
then
too,
because
you
don't
want
like
floats
tyrants
and
so
on
so
forth,
and
you
don't
want
to
try
and
write
a
value
to
a
negative
value
to
a
monotonically,
increasing
counter
and
so
on
and
so
forth,
and
we
can
just
do
that
in
period
land,
which
is
nice.
E
So
there's
a
disconnect
between
the
two
things
which
made
us
come
and
question
everything,
which
is
why
I
went
to
environment.
We
read
everything.
I
say
the
observer
ones
are
interesting
and
obviously
they're
not
really
implemented.
Yet
in
the
erlang
side,
as
far
as
I
can
see,
which
is
maybe
the
spec
has
changed,
but
they're
fairly
big.
E
Stuff
that
we
were
looking
at
typically
because
the
way
our
applications
work
or
the
way
the
workflows
work
with
our
encode
trees
and
such
is,
that
doing
it
individually
per
metric
would
just
performance
wise,
be
just
no.
Basically,
it
wouldn't
work.
We'd
have
to
build
in
a
system
whereby
we
have
to
tell
our
processors.
E
Could
you
please
go
and
write
your
last
value
to
an
ets
over
here
and
then,
when
you're
done,
I'll,
go
and
I'll
I'll
go
and
invoke
the
observer,
so
I
can
go
and
read
them
from
my
ets
and
that's
just
a
silly
way
about
going
things
we
want
is
actually
the
battery
the
batch
observer,
which
comes
in
and
says
I'll
now
go
and
get
all
my
values
and
they'll
go
and
do
this
thing
in
this
way
and
but
defining
those
up
front
gets
interesting
too,
because
again
you
can't
you
can't
callbacks
to
these
things
and
so
and
so
forth.
E
So
there's
again,
quite
a
lot
of
thought
to
be
had
around
that,
but
not
not
in
terms
of
the
spec.
The
spec
itself
is
quite
simple.
Our
own
code
is
interesting
with
respect
to
that,
but
yeah
we'll
need
batch
before
well
too
long.
Really,
but
again
we
can
throw
that
in
it's
not
going
to
be
difficult.
I
do.
E
Way
the
the
ets
table
researched.
Actually,
we
thought
about
our
own
way
of
doing
metrics
and
our
you
know
we
should
have
just
done
this.
This
is.
E
That's
a
lot
more
sensible
than
calling
random
protesters
and
asking
them
for
their
metrics.
You
know
turns
out
when
you've
got
tens
of
thousands
of
processes
going
it's.
It
doesn't
scale
very
well.
B
Yeah
and
I
hope
to
be
able
to
incorporate
counters
from
otp
in
there
at
some
point,
but
they
need
some
updates,
probably
like
they
don't
support,
floats
and
a
number
of
other
issues.
I've
been
talking
to
the
team
about,
but
because
those
will
be
even
more
performant
for
simple
counters,
at
least
and
maybe
even
summaries
can
keep
counts
of
the
histogram
distribution
values
in
a
an
array
of
counters,
but
very
cool.
That
was
very
helpful,
and
this
will
be
good.
I'm
excited
to
work
on
this
again.
E
I'm
going
to
go
and
find
some
camomile
tea
or
something
I
get
quite
hyper
this
time
of
night.
I'm
sure
you
can't
show
you
can't
tell
them.
E
No,
it
says
yeah
well
I'll,
be
I've
been
looking
in
the
metrics
hydro
flips
next,
isn't
it
yeah?
I
was
planning
on
lurking
in
the
background
on
that.