►
From YouTube: 2021-03-11 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).
B
C
E
C
C
If
you
look
at
the
tracing
api
first,
you
see
there
are
three
classes
and
if
you
look
at
each
individual
class
it
tells
you
what
what
members
that
this
class
have
and
all
the
like
methods
provided
by
this
class
and
whether
something
you
must
provide
so
now
look
at
the
matrix
one
and
start
try
to
see
how
I
can
how
I
can
make
progress.
I
notice
it
it's
a
very
long
and
has
a
lot
of
verbal
statement
that
is
not
very
straightforward
for
the
sdk
or
the
api
developers
to
implement.
C
So
when
you
look
at
this,
it's
more
like
giving
you
the
the
concept
and
also
given
we're
trying
to
split
the
work
stream.
So
we
have
data
model
and
api
sdk
and
also
the
premises
one.
So
this
is
my
current
thinking
and
I
send
a
draft
pr
just
try
to
quickly
explain
to
people
what
I'm
thinking
so
I'm
trying
to
have
the
top
level
readme
file
in
the
metrics.
So
we
look
at
that
it.
It
gives
you
the
overview.
C
What's
our
design
goal
like
what
are
we
trying
to
achieve
and
then
how
do
we
look
at
the
api
sdk?
What's
the
functionality
like
we
look
at
the
api,
I
try
to
capture
what
we
discussed
last
week.
The
epi
is
only
doing
two
things
one
is
it
captures
the
raw
measurements
number
two?
Is
it
allows
the
sdk
to
be
injected
at
runtime,
so
that
gives
people
a
step-by-step
approach.
C
They
can
understand
what
we're
doing
here
and
then
I,
I
think,
it'll
be
great
if
we
can
explain
the
top
level
concept
like
the
provider
meter
instrument,
because
those
things
will
apply
to
both
the
api
sdk
and
some
of
the
concepts
like
the
measurements
probably
would
make
sense
for
the
data
model
as
well,
and
then
we
link
to
the
individual
document,
so
my
pro
portal
would
be
I'll
I'll
start
to
migrate.
Some
of
the
concepts
here
to
the
top
level
readme
because
it
applies
to
the
data
model
as
well
and
for
the
api
spec.
C
C
I
want
to
know
if
people
feel
that's
the
right
direction,
if
that's
okay,
I'll
I'll
change,
that
to
a
to
a
like
a
real
pr,
and
I
want-
I
want
people
to
help
out
here
and
ideally
I
want
like
once
I
want
to
start
small
and
once
we
got
this
merged,
I
can
start
to
move
those
concepts
here
and
start
to
change
the
api
spec
to
be
similar
like
the
tracing
and
so
I'll
park
here
and
get
the
feedback.
D
Can
I
can
I
have
a
quick
question
around
the
what
what
you
you
mentioned
about
like
acquiring
a
instrument?
It's
in
the
bottom.
I
guess.
D
Did
this
change
recently
because
because,
as
far
as
I
remember,
it
was
like
getting
an
instrument
was
a
very,
very
lengthy
and
variables
like
process
or
workflow
like
you
needed
to
go
through
like
at
least
like
four
components.
By
the
time
you
got
your
instrument.
C
My
understanding
is,
there
are
four
levels
at
the
top
level.
You
have
a
meter
provider,
then
you
have
the
meter,
and
under
meter
is
more
title.
Libraries
you
have
the
name
and
the
version,
and
then
you
have
instrument
instrument
is
basically
this
is
my
http
latency
and
for
the
instrument.
Every
time
when
you
report
the
data,
the
data
is
called
measurements.
That's
my
understanding.
D
F
C
Yeah,
so
the
api
will
allow
you
to
inject
the
sdk
and
by
default,
if
you
don't
have
the
ick,
the
api
will
just
give
you
a
meter
provider.
You
can
still
get
meter
and
an
instrument,
but
all
the
measurements
you
reported
through
the
instrument
will
get
dropped
on
the
floor.
But,
like
I,
I
think
it's
a
great
question
because
you
can
see
like
jonathan,
I
I
think
he's
the
expert
on
the
matrix
and
he,
if
he
even
got
a
little
bit
confused
on
the
spike.
C
It
just
tell
you
you
need
to
have
this
meter
provider
and
the
meter
provider
should
have
this
gut
meter
function
and
if
you
try
to
get
the
meter
using
the
same
parameter,
it
will
give
you
the
same
thing.
Instead
of
giving
you
error,
you
put
something
invalid,
this
is
what
you
will
have,
so
I
hope
that
separation
will
give
people
a
clear
understanding
and
I'm
happy
to
make
progress
during
this
weekend.
If
we
can
get
this
pr
like
moving
forward
as
soon
as
possible,.
A
Yeah
that
that's
a
good
strategy,
riley
and-
and
we
can
definitely
you
know-
provide
feedback
by
tomorrow-.
C
Yeah
and
and
then
I'm
going
to
clean
up
the
current
matrix
api,
I
think
we're
great.
We
try
to
scope
down
so
I'll.
Try
to
find
a
way.
We
can
preserve
the
history
instead
of
remove
everything
and
then
add
back
and
then,
if
you
look
at
gate,
blame
everything
points
to
write
it.
So
I
want
to
find
out
a
better
way,
but
the
first
step,
I
think,
is
once
we
got
this
pr
merged
I'll
reduce
the
matrix
api
specs.
C
So
we
only
cover
the
synchronous
api
and
let's
use
that
to
figure
out
how
we
can
document
things
and,
of
course,
there's
naming-
and
I
I
think
there
are
a
lot
of
questions
like
jonathan
mentioned,
the
up
down
counter
a
lot
of
things
like
we've,
never
seen
before
in
other
systems.
These
are
a
lot
of
new
concepts.
C
So
we
try
to
make
it
simple
so
for
people
who
come
here
new
without
metrics
background
and
make
sure
they
feel
it's
not
something
requires
a
phd
degree
and
for
people
who
have
matrix
background
there's
a
way
they
can
simply
translate
their
existing
knowledge
like
whether
it's
micrometer
or
like
premises.
They
will
simply
know.
Oh,
this
is
the
micrometer
concept
and
in
open
climate
is
just
ideally.
C
I
want
them
to
be
the
same
name,
but
I
know
we're
trying
to
convert
multiple
systems,
so
it's
impossible,
but
we
try
to
find
the
right
balance
here
and
also
there's
a
consideration.
We're
taking
dependency
on
the
data
model,
so
the
name
or
whatever
thing
we
have
in
the
api
has
to
fully
support
the
data
models.
In
the
end,
we
have
the
like
very
simple
name,
people
who
could
understand,
but
we
can
only
cover
50
of
the
data
model
requirement.
C
That's
not
going
to
work,
so
I
think
we
can
start
to
work
on
the
synchronous
api
just
to
figure
out
how
the
process
should
be
and
also
figure
out
the
name,
and
once
we
have
that,
I
think
the
next
step
is
to
use
the
the
old
tab,
like
146,
the
http
server
scenario,
to
figure
out
the
async
api
and
the
reason
I
think
we
have
to
have
both
the
sync
api
and
async
api
is.
If
we
just
have
the
sync
api
first,
then
we
go
to
the
sdk
spec.
C
Once
we
have
a
perfect
sdk
spec
that
can
cover
all
the
sync
api,
when
we
start
at
async
api,
we
will
realize
no,
the
sdk
part
has
to
be
completely
screwed
up
and
reworked,
because
I
did
some
experiment.
I
I
think
that
that's
my
gut
feeling,
so
I
want
to
get
people's
opinion
here.
Do
you
think
we
can
start
work
on
the
isdk,
just
focusing
on
the
sync
api
and
and
later
adding
asynchronous
api
without
a
dramatic
change?
I
I
don't
think
so.
That's
why
I
have
my
current
profile.
C
Yeah
so
so
my
my
thinking
is,
we
have
to
do
the
same
api
first
and
then
we
have
to
do
the
a-think
api
and
then
we
can.
We
can
do
the
minimum
sdk
to
cover
one
and
two
for
patching
and
some
of
the
like
bonded
thing.
I
think
that
can
be
additive
change,
but
I
don't
believe
if
we
try
to
switch
like
two
and
three:
we
try
to
do
the
minimum
sdk
just
for
sync
api
later
adding
async
api.
I
think
that
won't
work,
that's
my
gut
feeling,
but
I
want
to
get
x-first
feedback
here.
F
C
Okay,
so
so
the
first
step
is:
please
help
me
I'll
turn
this
into
a
real
pr
and
there's
some
concepts.
I
I
think
we
might
struggle.
For
example,
do
we
call
something
aggregator
or
accumulator?
I
think
those
concepts
are
complex
and
I
might
make
mistakes
so
if
it
turned
out
to
be
a
blogger,
I'm
happy
to
just
remove
that,
because
we
can
review
that
later.
That's
the
sdk
topic,
not
api,
so
just
to
get
that
in
shape.
C
C
So
this
will
be
the
old
type
146
grocery
scenario,
which
is
very
simple,
I'll,
just
use
that
to
practice
the
synchronous,
api
document
and
and
and
make
progress,
and
hopefully
we
can
get
the
merge
as
soon
as
possible.
Then
we
can
use
the
http
scenario.
This
is
http
server
to
document
the
api
and
from
the
prototype
part.
I
I
think,
as
long
as
we
can
use
this
like
prototype
api
in
the
code,
see
we
can
make
the
data
and
we
don't
care
about
whether
data
got
dropped
on
the
floor.
C
We
just
send
the
data
nowhere
as
long
as
we
can
describe
the
data
for
these
two
scenarios.
We
know
the
api
part
we
feel
good
and
then
we
check,
with
the
data
model,
work
stream
to
see
if
the
data
we
provided
can
incentivize
the
data
model
requirements.
I
I
think
given
like
the
timeline
is
around
late
march.
There's
a
perfect
alignment
here
and
once
we
see
oh,
the
api
part
is
in
shape.
Then
we
try
to
polish
that
and
meanwhile
we
can
make
progress
on
sdk.
C
Sounds
okay,
okay,
cool
and
for
the
project
tracking.
So
I
start
to
have
this.
C
C
We
don't
we're
still
like
the
open,
ended
thing,
but
by
doing
the
the
prototype
on
the
step
one
and
step
two,
we
should
be
able
to
identify
the
concrete
work
items
and
I'll
need
your
help,
so
we
can
discuss
like
who
should
be
working
on
which
item
and
got
them
assigned
and
start
to
track
them.
I
think,
probably
next
week
this
week
is
just
very
rough.
E
I
have
a
general
question
about
the
like
prs
from
the
the
two
cigs,
so
we
just
looked
at
1533
there's
also
the
1512,
which
is
j
macd's
data
model
document,
is
the
idea
that,
like
one
builds
on
the
other
that
these
these
two
will
tie
in.
B
E
C
Always
george
like
like
trying
to
move
some
of
the
concept,
because
this
concept
will
apply
to
both
the
data
model
and
the
api
sdk.
So
so
I'll
try
to
move
some
of
the
common
concepts
to
the
top
level
readme,
and
then
we
can
decouple
them.
B
I've
definitely
begun
using
those
model,
kind
of
model
instrument
names
as
being
the
ones
that
we
specced
out
a
year
ago,
just
just
to
name
the
concept
of
these
hypothetical
instruments,
not
to
try
to
propose
them
as
being
real
instrument
names.
Since
they've
created
a
lot
of
confusion
for
users,
and
it's
not
a
good
idea
so
that
we
may
end
up
with
counter
histogram,
engage
and
they'll
have
a
mapping
into
those
conceptual
single
purpose,
well-defined
instruments
we
may
yeah.
C
A
Really
there
are
obviously
you
know,
specific
dates
that
we
are
trying
to
target
for
different.
You
know
milestones
or
different
tasks,
right,
yeah
and,
and
so,
like
you
mentioned
the
data
model.
You
know
as
well
as
the
think
async
apis.
So
is
that
something
that
is
easy
to
surface?
You
know
at
a
glance
because
all
right
cool,
so
we
can
just
look.
A
C
In
the
blog
post
for
the
metrics
we
on
people-
here
we
tell
them
the
blog
post
is
just
the
estimation
at
the
time.
The
latest
one
will
be
reflected
here.
So
this
is
the
source
of
truth
and
I'll
make
sure
it's
well
maintained
here
and
I
know
josh
had
the
the
data
model
project
maintained
on
the
spec
repo.
So
that's
fine.
As
long
as
we
have
a
single
place
like
we
don't
have
the
data
model
here,
it's
on
the
spec,
remote
okay.
C
I
can
move
it
there
if
you
want,
I
just
put
it
where
I
had
access
at
the
time.
Yeah.
I
think
up
to
you
as
long
as
we
have
a
single
place,
and
I
think
people
like
working
on
this-
they
know
where
it
is.
We
have
the
clarity.
C
C
If
you
think
it
would
be
great
to
move
here,
I'm
happy
to
do
some
labor
work
just
to
make
it
work,
and
I
I
think
we
we
should
try
to
get
pro
like
get
access
for
you,
because
this
cross,
like
this
cross
spike
and
data
model
protocol
work,
is
very
important
and
we
don't
want
to
stack
on
some.
We
know
you're
not
going
to
take
the
take
the
permission
and
delete
the
report
right,
so
so
why?
Why
would
you
want
to
like
slow
us
down
so
I'll
I'll,
be
supportive
and
I'll?
C
A
C
B
C
B
Okay,
okay,
okay,
okay,
I
I
suspect
that
that
that's
goes
at
least
one
step
and
if
everyone's
comfortable
with
that,
that's
being
enough
we're
good.
I
know
that
from
for
a
real
like
a
real
example
that
I
was
writing
myself,
it
often
that
batch
observer
was
kind
of
important.
I
see
in
golang,
it
was
like
I
did.
My
read:
mem
stats
call,
which
is
pretty
expensive
and
I've
got
seven
different
numbers
now
and
they're
all
async,
and
I
can't
easily
organize
that
without
a
single
callback.
B
C
So
so
here's
my
proposal,
josh,
like
probably
you-
can
try
to
find
a
scenario,
a
minimum
scenario
that
can
capture
that
which
is
not
captured
by
the
old
type
146
and
send
a
small
pr
just
to
just
to
update
146.
So
we
can
cover,
let's
see
like
here.
It
goes
to
http
and
I
do
have
a
scenario
which
is
not
covered
and
we're
getting
merged
and
we'll
try
to
cover
that
in
the
api
design.
Would
that
make
sense
yeah
that.
B
B
F
Here's
here's
the
thing
I'll
say,
though,
that
you
mentioned
like
not
having
to
lock
memory
and
such
I
I
don't
know
how
far
we
can
go
there
and
that's
going
to
be
a
fun.
I
I
think
I
think
it's
a
great
a
great
example
of
a
user
custom.
F
You
know
batch
processing
thing
that
you
want
to
observe
its
behavior
right,
so
someone
has
written
some
kind
of
hue
and
you
want
to
observe
its
behavior.
That's
a
that's!
Probably
one
of
the
hardest
use
cases
I
can
think
of,
because
the
user
will
have
to
do
appropriate
multi-threading
code
for
us
to
async.
Read
it.
F
B
I
wasn't
trying
to
take
away
locking
I
was
just
trying
to
avoid
introducing
locks
that
are
only
necessary
for
the
purposes
of
like
calling
your
gc
stats
once
and
then
letting
the
observer
like
trigger
seven
times,
without
repeating
the
call
of
the
garbage
collection
stats,
which
requires
some
sort
of
lock
conceptually.
I
think
okay,
and
then
I
mean,
of
course,
q
stats
is,
I
feel,
like
that's
one
of
the
more
advanced
use
cases,
but
it's
one
where
there's
this
tension
between
I
can.
B
It's
like
a
counter
at
your
at
your
doorway
that
says
how
many
people
have
entered
a
building
and
how
many
people
have
exited
a
building
and
and
like
I,
I
know,
there's
a
current
number
of
people
in
the
building
and
and
that's
like
the
queue
essentially
and
and
and
when
I
enter
the
building.
I
have
all
these
attributes
which
are
about
me
and
they
might
be
my
my
all
dot
myself.
B
Why
would
you
go
to
the
trouble
of
doing
async
for
stuff
like
that,
instead
of
using
the
synchronous
api,
so
q
length
to
me
is
not
a
great
example
for
async,
since
they're
good
synchronous
use
cases
just
so
I'd
say
that
I'm
not
sure
that
the
up
down
counter
or
the
gauge
that
has
up
down
in
prometheus
has
been
covered
very
well
in
the
use
cases.
B
B
So,
if
we're
going
to
include
async,
we
gotta,
I
think
we
have
to
add
more
use
cases
and
it
might
be
two
different
use
cases.
Yeah.
C
I
I
agree,
so
I
I
I
think,
a
lot
of
folks
who
join
this
like
what
I
observed
is
they
don't
have
a
good
understanding
of
all
the
async
cases.
So
my
suggestion
josh,
like
help
people
to
understand
okay
cover
scenario
in
the
old
house
and
try
to
make
a
as
small,
as
example
as
possible,
just
to
cover
the
core
need.
So
we
make
sure
we
don't
miss
that
during
the
api
design.
B
Okay,
I
can
commit
to
a
pr
on
the
otp
145
or
whatever.
It
is
to
add
some
use
cases
around
async.
C
B
A
Riley,
I
just
had
another
question
on
the
cross
referencing,
some
of
the
common
bugs
or
you
know
which
are
reported
across
reapers.
I
mean
it
doesn't
apply
so
much
on
the
language
apis,
but
specifically
on
the
data
model.
I
do
see
duplication
what's
the
best
way
of
tagging
those
or
you
know
consolidating
them.
C
I'm
I'm
not
sure
I
heard
your
question
because
your
voice
got
caught
in
the
middle.
Probably
my
bad
network.
Do
you.
A
I
can
repeat
again:
I
I
so
in
in
triaging,
through
some
of
the
you
know,
pros
some
of
the
issues
across
repos,
I'm
often
seeing
you
know
the
same
issue
being
reported
in
different
places,
right
and
and
they're
often
related
to
the
data
model,
or
do
something
you
know
such
as
prometheus
or
or
others.
So
you
know
is
it:
how
do
we?
How
do
we
can
we
tag
these
or
label
user
label
that
can
actually
cross
reference?
These.
C
Yeah,
so
so
currently,
I
I
think
I've
seen
a
little
bit
struggle
in
the
open
time
tree
specification
and
in
the
protocol
repo,
because
these
are
two
separate
reports
yeah,
but
within
the
specification.
This
is
what
I
see.
So
there
are
multiple
tags.
C
If
you
look
at
the
matrix
part
I'll
pick
the
experimental
release,
so
we
use
tags
and-
and
this
so
far
has
been
working
well,
I
think
the
only
thing
that
people
are
not
very
happy
is
you
probably
want
to
remove
priority,
because
now
we're
having
milestones,
it
doesn't
make
sense
to
have
two
different
things.
Yeah.
C
The
good
thing
here
is
when
people
go
to
the
specification
they
try
to
open
issue.
We
have
the
issue
templates,
so
it
will
go
to
the
right
place
and
most
likely,
I
see
people
follow
that
they're
not
going
to
make
some
confusion.
The
only
place
I've
seen
is
when
people
create
the
matrix
one,
they
don't
specify
whether
that's
the
api
or
the
data
model.
A
C
But
I
I'm
I'm
doing
a
weekly
charge
on
friday
with,
like
ted
and
other
folks,
so
so
we
take
a
look
at
that
and
we'll
put
that
in
the
proper
place
and
it's
in
the
api.
Then
later
I
realized.
Oh,
it's.
Actually
a
data
model
problem,
I'll
output,
two
tags
on
that
just
to
make
sure
like
both
six
would
care
about
that.
C
Okay,
I
mean
this
is
what
country
we
have
for
the
for
the
duplicated
issue
in
the
open
time
trip
protocol
and
spec.
I
don't
have
a
good
solution.
I
think
most
likely
people
working
on
the
protocol
will
be
more
focusing
on
the
actual,
like
the
grpc,
like
the
wire
format
on
respect
is
more
like
the
general
question.
A
G
A
B
A
C
I
mean
it's,
it's
actually
not
it's
like.
At
that
time.
We
were
trying
to
have
this
recurring
meeting
just
to
push
for
ga,
but
later
we
decided
okay,
we're
going
to
trace
1.0
and
after
trace,
1.0
people
say
oh,
like
let's
celebrate
and
there's
no
point
to
like
just
do
a
weekly
like
like
push
right
and
also
like
the
g8
tag,
those
things
they
like
they
don't
make
sense
today,
so
with
ngo
left
lights
that
I
I
think
we're
trying
to
like
reignite
that.
C
A
C
One
when
I
came
back
from
vacation
this
year,
I
I
joined
that
meeting.
The
first
question
I
have
is
like:
where
are
we
still
trying
to
drive
the
ga,
because
we
are
now
talking
about
stable
and
then
carlos
and
had
commented?
We
don't
know
like
we
need
to
fix
this
problem.
Otherwise
we
don't
know
what
we're
doing
so.
Currently,
we
kind
of
have
the
idea
how
we
should
do
that.
H
Sure
so
I
just
want
to
add
on
top
of
your
steps
earlier,
you
had
step
one
two
three,
but
I
think
there's
a
step
above
that
and
which
I
hear
people
asking
is
that
well,
how
do
you
get
that
first
meter
provider-
and
I
know
that
that's
a
problem
in
the
septa,
in
the
sense
that
I
think
we
probably
want
to
clarify
the
mental
model
that
we
have
for
the
separation
of
the
api
and
sdk,
because
that
I
know
has
confused
me
and
that
has
always
caused
me
problems,
and
that
has-
and
I
you
know,
enter
some
issues
but
right
now
we
do
not
have
a
good
separation
of
api
sdk
that
works
in
all
languages
with
or
without
dependency,
injection
and-
and
that
also
introduces
that
fourth
level,
that
people
alluded
to,
which
also
causes
confusion.
H
C
D
Sorry
go
ahead
so
if,
if
there
is
something
we
can
do
around
around
this,
to
make
it
a
little
bit
more
intuitive
or
simpler,
I
I
would
include
that
too,
because,
like
as
as
far
as
I
remember
when
I,
when
I
did
this
exercise
last
time
to
check
like
how
can
I
get
the
instrument,
the
process,
it
wasn't
just
like
long
to
get
through
an
instrument,
but
the
the
classes
and
the
method
names
were
not
the
best.
B
There's
a
pretty
long
history
of
discussion
about
this,
but
I
don't
think
we
ever
got
very
far
other
than
saying
that
this
is
a
per-language
decision
that
has
to
be
made.
That
kind
of
has
to
pay
attention
to
what's
natural
and
possible
and
in
those
languages.
B
So
I
can
talk
a
lot
about
go
and
how
you
know.
There's
this
idea
of
people
hate
globals
generally
speaking,
and
it
infects
a
lot
of
thinking
around
this
like
it's
automatically
a
bad
idea,
and
I
don't
think
it
is
automatically
a
bad
idea
for
telemetry
libraries,
because
the
whole
point
is
to
get
all
our
signals
in
the
same
place.
B
If
you
don't
want
it,
you
don't
have
to
have
it
and
then
it
leaves
open
dependency,
injection
possibilities
and
yet
we've
said:
there's
going
to
be
a
default
and
then
what
that
looks
like
is
kind
of
a
per
language
question
today,
and
I
write
I
tried,
writing
out
chaps
a
year
ago
about
go
and
what
to
do
and
nobody
liked
it
except
to
go.
We
had
to
do
something,
so
I
just
did
it.
B
You
know
like
there's,
no
otep
or
spec
about
it
and
that's
where
we
are
and
when
I
actually
write
real
code
to
use
that
I
end
up
writing
a
static
variable
in
my
package,
which
is
the
meter
for
a
whole
bunch
of
code
to
use,
and
then
I
end
up
with
one
liners
to
to
declare
instruments
in
various
places.
B
Statically,
because
that's
the
model,
that's
simple,
that
you've
always
had
with
prometheus
and
sd
is
somewhere
I'm
going
to
put
a
piece
of
code
at
the
top
of
my
file,
which
is
my
instrument
and
almost
nobody
else.
Nobody
wants
to
go
the
trouble
of
having
a
struct
with
a
pointer
to
an
instrument
and
to
getting
it
all
declared
in
your
instructor,
which
is
totally
possible,
and
if
you
hate
globals,
you
can
do
that.
D
So
to
to
me,
it's
like
I,
I
only
checked
the
the
java
api
back
in
back
in
january,
and
there
to
me,
like
the
the
the
global
non-global
thing,
did
not
seem
to
be
an
issue
at
all.
But
what
I
saw
is,
for
example,
like
there
is
that
it
is.
It
is
not
in
the
apids
in
the
sdk,
for
example,
that
global
metrics
provider
class.
D
I
would
say
that
it
is
giving
me
a
class
of
global
metrics
or
a
matrix
class,
because
it's
a
matrix
provider,
but
no
it
will
give
you
a
meter
provider
which,
as
far
as
I
remember
like
like
having
a
meter
provider,
I
would
I
would
say
that
it
should
give
me
meters,
but
it
has,
as
far
as
I
remember
like
two
methods,
and
one
of
them
will
give
you
a
meter
instance,
because
it's
a
meter
provider.
G
Oh
jonathan
I'll
just
say
that
name
that
class
is
named
wrong
at
the
moment
it
should
be
global.
Okay,
that's
all
I'm
saying
like
this
could
be
just
just
for
background.
We
had
to
rip
out
everything
metrics
before
we
could
release
1.0
and
we
had
to
do
it
very
quickly.
So
there's
there's
some
detritus
still
left
from
that,
and
I
so
I
please
feel
free
to
put
in
a
pr
to
fix
that
name.
It's
wrong
at
the
moment.
Okay,
cool.
H
I
I
want
to
ask
the
the
group
here
I
mean
I,
I
looked
at
a
bunch
of
the
other
metrics
api
and
what
is
wrong
with
us
just
starting
with
creating
the
counter
up
front,
just
a
simple
new
counter
and
off
we
go,
I
mean.
Is
there
history
behind
why
we
have
two
levels
of
getting
the
the
provider
from
the
sdk
instead
of
just
the
api,
then
having
that
provider
provide
you
a
factory
of
meters.
B
There
are
several
histories
and
one
is
about
the
the
hotel
wide
thing
has
a
provider
concept
that
was
introduced
to
give
you
the
name
of
your
instrumentation
library,
so
that
whole
layer
was
added
just
for
independent
reasons,
and
then
I
think
you're
asking.
Why
should
why
shouldn't
there
be
a
global?
H
F
Anyone
want
to
talk
about
it.
I
I
yeah.
I
want
to
give
like
three
use
cases
that
I
think
kind
of
matter.
One
of
them
is
actually
in
riley's.
F
Document
of
an
api
provider
wants
to
provide
metrics,
and
those
metrics
should
do
absolutely
nothing
unless
somebody
has
implemented
a
pipeline
to
export
them
right,
and
I
need
the
ability
to
configure
that
pipeline
and
do
things
with
it
and
global
kind
of
limits
that
ability
we've
run
into
trouble
with
open
census
around
multi-tenancy,
where
we
actually
want
to
take
some
of
our
instrumentation
and
say
this
instrumentation
is
for
this
user.
This
instrumentation
is
for
that
user
and
they
never
touch
the
same
pipeline
right.
You
literally
can't
do
that
in
open
census.
F
So
that's
one
use
case
I
just
want
to
call
out
of
like.
I
need
the
ability
to
send
things
different
places
we
might
not
care.
Maybe
we
just
get
rid
of
that
use
case
and
say
sorry
do
something
different,
but
that
is
one
of
the
ideas
behind
that.
The
second
thing
I
want
to
call
out
is
this
notion
that
api
and
sdk
are
completely
decoupled
completely
right.
F
The
person
who
writes
the
one
is
not
the
same
person
who
writes
the
other
and
there's
a
lot
of
complications
around
that
and
tying
those
two
together
that
you
could
resolve
with
global
like
josh
is
recommending,
and
I
think
you
could
do
that
relatively
easily
and
that's
the
idea
behind
the
existing
globals
is
as
an
api
provider.
F
Whether
or
not
we
want
this
to
be
explicit
to
the
users,
they
have
to
see
it.
I
don't
know,
that's
that's
a
different
story,
but
that's
the
idea
there
of
you
know.
I
have
this
instrumentation
library
and
I
need
to
instantiate
it
with
somebody
else's
configuration
all
of
this.
You
know
there
are
different
ways
to
solve
that.
That
could
actually
be
completely
solved
with
maybe
filterable
metric.
You
know,
processors
that
happen
in
line,
maybe
that's
more
expensive
to
do.
It's
like
cheaper
to
just
configure
it.
F
You
know
up
front
to
do
the
right
thing
and
go
to
the
right
pipelines,
so
there
could
be
performance
costs
with
going
the
other
route,
but
that's
just
so
you
know
that's
the
second
use
case.
The
third
use
case
I
think
around
this
is
the
d
decoupling
of
the
sdk
completely.
Theoretically.
At
some
point,
I
think
maybe
somebody
wanted
to
provide
their
own
sdk
implementation,
so
I
can
take
a
dependency
on
the
api
and
they
don't
use
the
open
telemetry
version
sdk.
They
use
a
highly
optimized
somebody
else,
rights.
F
Sdk
again,
I
don't
know
if
we
actually
care
about
that
use
case,
but
that's
like
another
reason:
they're
decoupled
right.
You
can
have
a
vendor
specific
sdk
yeah.
The
question.
B
B
You
could
have
the
current
sdk
be
part
of
the
context,
whatever
sdk
you're
using
is
the
one
that
was
installed
somehow
and
that's
another
approach
to
multi-tenancy
versus
the
dependency
injection,
where
you
have
to
keep
your
like
pointers
everywhere
throughout
the
whole
code
and
the
only
other
one
that
you
didn't
mention
josh
is
the
zero
state
like
I
have
a
instrument
that
I'm
creating
and
it's
never
been
used,
but
I
want
to
export
a
zero
or
something
like
that.
I
remember
bogen
raised
that
one
pretty
strongly
a
year
or
so
ago,.
C
Yeah
so
just
I
told
what
josh
mentioned
that
point
three,
the
isdk
scenario.
Actually
I've
seen
a
lot
like
when
people
try
to
do
internal.
They
have
python
application,
calling
into
a
highly
optimized
c
c,
plus
plus
module
doing
the
following
function:
interface,
they
would
say:
hey
in
the
foreign
function,
interface
like
in
the
c
module.
I
don't
have
access
to
the
python
context,
so
in
this
case
I'd
rather
to
use
the
c
plus
plus
sdk,
and
even
in
my
python,
I'm
using
the
python
api
but
the
actual
sdk,
the
c
plus
plus.
C
So
we
might
have
open
telemetry
c,
plus
plus
being
used
in
combination
with
the
python
api
and
coming
back
to
victor's
question.
I
I
think
my
statement
would
be
given.
We
have
the
tracer
provider
model,
which
is
quite
successful
and
well
established.
I
think
there's
no
strong
reason
for
us
to
have
a
very
different
mental
model,
so
I
I
would
just
say
we
want
to
align
with
tracer
provider,
so
we
have
meter
provider
and
we
have
log
provider.
H
And
I'm
not
against
that,
but
I
I
think
to
everyone's
point
is
that
we
we
have
a
on
top
of
just
the
instrument.
It
sounds
like
we
have
a
level
above
it
to
quote
capture
the
instrumentation
to
create
you
know
up
space
for
allowing
different
pipelines
to
be
configured.
So
I
think
that
model
works
with
the
quote:
trace
provider
model,
so
you
can
have
a
trace
provider
model
and
then,
underneath
that
you
could,
you
know,
maybe
attach
an
instrument
to
your
trace
provider
or
some
other
some
means
of
doing
so
right.
B
Prometheus
has
a
register
function,
you
have
to
register
your
instruments
and
it's
so
you
move
it
from
being
a
constructor
statement
to
a
like
static
function
registry,
and
I
I
think
it's
you
know
like
there's-
also
a
global
hiding
there
in
prometheus
there's
also
a
global
hiding
in
open
census,
and
I
looked
at
statsd
and
the
case
there
is
it's
purely
stateless,
so
you
never
needed
to
register
the
instrument
because
you
could
just
in
line
create
a
string.
B
That's
a
new
instrument
right
and
I
that's,
I
think,
that's
one
of
the
reasons
why
I,
as
a
user
came
into
this
originally
a
year
and
a
half
ago
saying
I
just
want
to
write
a
static
like
declaration
and
not
have
to
like
find
my
dependency
injection
to
get
my
meter
right.
So
that's
why
we
ended
up
with
globals,
but
the
alternative
was
just
an
api,
pure
api
level
instrument
concept
that
has
no
binding
to
the
sdk,
and
that's
why
I
mentioned
the
one.
B
The
objections
that
we've
heard,
like
zero
state,
doesn't
really
work.
So
here
we
are
where
we
are,
but
I
think
it
could
have
gone
the
other
way
victor.
I
think
that's
what
you're
saying
so.
I.
H
Maybe
we
should
adopt
that
and
I
don't
think
that
would
also
preclude
us
from
following
riley's.
You
know,
you
know
I
guess
preference
to
maintain
similarity
with
the
trace
provider
and
trace.
H
B
B
So,
just
to
make
sure
I
understand
the
event
model
idea
is
that
we
don't
need
a
global
there's
implicitly
a
global
and
you're
just
going
to
subscribe
to
the
events
that
you
want
and
yeah.
I
haven't
thought
through
how
that
work
works
for
multi-tenancy.
I
think
the
idea
would
be
that
you
must
have
some
sort
of
resource
label
or
some
sort
of
something
that
says
who
you
are
and
then
you're
going
to
tee
off.
Based
on
that
something
that
says
who
you
are
yeah.
Sorry.
F
H
And
I
think
the
the
the
join
point
is
is
the
the
key
aspect
for
me,
whether
we
do
this
model
or
not.
But
how
do
we
join
the
api
to
the
sdk
and
and
I'm
proposing
that
we
join
it
by
either
one
extreme
by
you
know
a
string
name,
that's
one
extreme!
The
sec.
Another
extreme
would
be
well
when
the
sdk
is
initiated.
It
just
needs
to
do
some
kind
of
a
selection
of
which
meters
from
a
global
list
that
it
wants
to
attach
to
and
so
forth.
But
it
feels
like.
G
It
feels
like
that's
muddying
things
up
in
a
way
that
I
don't
like,
though,
which
is
like
at
least
I'm
speaking
from
java,
which
we
have
interfaces
and
there's
no
like
joining
up,
there's
an
implementation
of
an
interface,
which
is
what
the
sdk
provides.
So
there's
not
like.
There's
a
joining
up.
You
have
to
ask
something
to
get
into
get
an
implementation
of
your
interface,
that
something
can
be
the
no
op,
a
no
op
global,
that
something
can
be
an
instance
that
you've
created,
but
there's
not
like
a
joining
up.
There's
an
implementation.
G
H
So
again,
I
I
don't
want
to
prevent
java
from
doing
that
as
well.
All
I'm
suggesting
is
one
scenario,
and
this
is
just
one
of
many
scenarios,
but
one
possibility
is
when
you
create
your
counter,
you
currently
we
name
the
counter.
What
if
we
just
added
a
scope,
a
string,
that's
just
a
scope
name
and
that's
it
and
then
on
the
sdk.
H
When
you
create
your
pipeline
for
the
sdk,
you
just
attach
that
scope
name
now
how
strongly
that
attachment
of
a
scope
string
versus
an
instance.
You
know
that
could
be
debated,
but
that's
just
one
possible
implementation
of
it
if
you
will,
but
but
my
my
point
isn't
to
dictate
how
the
language
should
do
it.
B
I,
like
your,
I,
like
your
rant
there.
Victor
sorry,
actually,
there's
something.
There's
a
couple
topics
here
that
are
hiding
one
is
about
this,
this
idea
of
separation
and
like
whether
we
move
away
from
like
the
ap,
the
interface
that
john
said,
and
I
think
we
have
to
remember-
open
telemetry-
was
really
founded
with
us
like
a
very
strong
guideline
about
doing
that.
So
there
is
definitely
a
like
reason
why
open
telemetry
is
moving
that
way
from
our
founding
principles.
B
About
the
the
other
part
of
your
statement,
victor
about
scope,
I've
tried,
I
always
try
to
avoid
that
word,
because
it
has
a
lot
of
meaning
and
it
it
can
mean
the
right
exactly
the
right
thing,
but
it
has
too
many
other
meanings
and
you
just
connected
it
with
like
the
third
rail.
Unfortunately-
and
I
don't
want
to
like-
take
the
rest
of
the
meeting
but
there's
a
question
with
resources
that
have
are
almost
like
confusingly
left
out
of
the
api,
spec
and-
and
I
think
we're
gonna
end
up
with
the
same
exact
problem.
B
That's
not
part
of
the
sdk
binding,
that's
just
sort
of
like
in
my
code.
I
have
some
attributes
that
describe
what
is
this
instrument
is
so
that
I
can
use
that
those
properties
to
configure
you
know,
selection
and
filtering
and
stuff,
which
is
the
spirit
of
the
tracer
get
tracer,
was
just
to
get
your
instrumentation
name
and
library
version
and
so
on,
but
really
when
you're
in
a
piece
of
code.
You
have
all
this
sort
of
static
information
about
your
instrument
that
that
that
you
could
also
attach
right
there
in
the
instrument.
B
That's
like
prometheus,
called
const
labels,
but
there's
this
notion,
I
think
of
scope.
It's
almost
across
a
hotel,
which
is
to
say
that,
like
when
you're
saying
get
tracer
get
meter,
you
also
just
want
to
say
and
always
use
these
attributes
whenever
you
use
that
tracer
or
that
meter.
That's
a
common
pattern
and
we
don't
have
that
in
the
api
and
because
we
don't
have
that
in
the
api.
B
There's
a
lot
of
confusion
and,
and
we
can't
have
a
scope
concept
and
I
I
actually
wrote
an
otep
like
exactly
a
year
ago
or
or
more
saying
what,
if
we
had
a
resource
scope
concept,
which
would
be
the
idea
that
you
somehow
can
can
do
what
you
just
described,
which
is
build
up
a
scope
that
has
no
binding
to
an
sdk,
but
just
as
an
api,
with
a
set
of
keys
and
values.
And
then
you
can
create
instruments
and
spans
from
those
scopes.
B
We
don't
have
that
and
I'm
afraid
that
asking
for
that
is
like
a
huge
project
and
we've
kept
avoiding
it,
because
no
one
wants
no.
One
really
knows
what
a
resource
is
to
begin
with,
and
if
this
conversation
is
interesting,
we
should
bring
in
more
people
like
tigrin
has
been
focusing
on
what's
a
resource.
I
know,
and
I
need
to
catch
up
with
him
as
well.
H
B
I
know
that
in
the
summer
of
2000,
whatever
19,
I
was
trying
to
find
the
same
and
and
bogdan
talked
me
out
of
it.
I
wish
he
was
here
right
now,
but
I
think
we've
covered
all
the
reasons
why
he
wanted
it.
The
way
it
is.
I
think
I.
G
I
haven't
heard
it
mentioned,
although
I've
also
been
distracted
a
little
bit,
but
you
know
the
one
of
the
primary
goals
of
this
project
is
to
get
people
to
use
our
instrumentation
libraries
apis
in
their
libraries
and
and
people
are
going
to
be
using
those
without
any
implementation
at
all
behind
it,
and
it
needs
to
be
as
ultra
lightweight
as
possible
in
those
circumstances,
because
the
users
of
the
libraries,
if
they're,
not
using
open,
telemetry,
sdk
and
an
exporter,
etc.
G
H
So
so
I
have
this
issue
open,
it's
kind
of
stale.
I
don't
know
how
to
move
it
forward
and
I
don't
know
whether
we
need
to
make
this
a
ongoing
topic.
I
don't
I
don't
know
how
to
you
know
progress
on
it.
H
So
my
my
goal,
at
least
what
I
deem
is,
that
per
riley's
a
conversation
about
step,
one
two
three.
I
was
just
hoping,
maybe
before
that
there's
a
general
step
to
just
and
maybe
not
code
or
maybe
not
necessarily
anything
concrete,
but
just
a
abstraction
of
what
is
the
sdk
api
separation
method.
We
want
to
use.
C
Good
point
so
victor
it
is
here.
If
you
look
at
this
pr,
I've
described
the
api
and
isd
can
put
a
simple
link
to
the
top
level,
open
telemetry
concept.
So
there's
a
top
level
open
telemetry
overview
gives
you
the
idea
of
the
separation
of
api
sdk.
I
think
that's
already
solved
the
problem,
so
you
asked
me
how
to
make
progress
mounts
really
very
simple.
Just
close
that
issue,
we're
done,
but
it's
still
a
continuing
issue
for
me.
It's
all
I'm
saying
it
might
be
an
issue
for
you
and
I'm
happy
to
explain
that.
C
B
And
I
had
this
discussion
actually
there's
a
reason
why
it
doesn't
is
that
you
don't
need
an
instrument
to
create
a
span.
You
just
give
a
span
name
in
this
at
this
on
the
spot
and
there
there
are
actually
issues
saying.
Should
we
have
a
prepared
span
instrument
which
would
be
like
a
span
instrument
essentially,
and
you
would
have
to
declare
it
in
open
telemetry
today
and
you
wouldn't
like
it,
and
but
we
don't
have
that.
I
want
to
ask
jonathan
what
he
thinks
from
micrometer's
perspective
like
what
what's
the
ideal.
D
So
how
micrometer
does
this?
It
has
like
a
a
central
like
class
or
interface
called
the
the
registry,
and
if
you
want
to
get
an
instrument
you
can
get
from
the
registry
in
one
step.
D
Okay,
sorry,
like
yeah,
you
can
get
it
from
the
from
the
from
the
registry
by
just
one
call
that
hey
give
me
a
counter.
Give
me
a
gauge
or
whatever
or
as
what
we.
What
victor
said
you
can.
D
You
can
create
basically
a
new
counter
and
you
can
register
it
to
your
registry,
so
in
micrometer
this
this
registry
is
the
is
the
factory
that,
where
you
can
get
instruments
or
where
you
can
register
your
instruments
and
behind
the
scenes
since,
because
since
this
is
an
interface,
you
can
do
whatever
you
want
like
it
will.
It
will
hide
all
of
those
like
issues
like
from
the
users.
You
can
have
a
registry
which
is
like
which
depends
on
the
knob.
D
What's
that
nope
implementation
or
you
can
have
a
registry
which
depends
on
whatever
sdk
and
you
can
like
get
that
sdk
with
an
spi
or
or
whatever
so
for
micrometer
from
the
user
perspective,
it's
completely
transparent.
They
will
never
know
about,
they
just
need
to
set
up
upfront.
What
do
they
want?
What
kind
of
registry
do
they
want
to
use?
D
If
there
is
no
registry
setup,
then
there
will
be
a
default
one
I
use
or
actually
in
java,
you
need
to.
You
need
to
at
least
like
that
that
hey,
I
want
to
use
the
default.
Okay,
can
I
just
say
a
question.
F
If
you're,
a
library,
so
let's
say
like
spring
itself
right
is,
is
implementing
meters.
What
registry
does
it
use
does?
Does
it
like
expect
the
user
to
provide
one
to
spring
to
get
the
instrumentation?
Is
there
a
global
like?
I
assume
you
have
the
same
kind
of
problem
with
your
registry
since
you
well,
I
looked
at
the
docs
and
it
expects
users
to
instantiate
the
registry
right.
So.
D
So
if
so
the
user
needs
to
like
it
depends
if
you
are
using
spring
boot
or
spring,
because
if
you
are
using
spring
boot,
it
will
create
all
of
these
all
of
these
configs
under
the
hood
for
you,
but
what
it
does
it
basically
like
scan
your
class
pad
and
if
you
are
using
the,
I
don't
know
the
micrometer
parameters
and
and
the
prometheus
class
pass
registry.
The
prometheus
registry
is
on
your
class
path.
D
G
G
D
What
what
you
are
saying
as
a
like
a
library
owner
as
an
instrumenter,
give
me
a
meter
registry,
and
from
that
point
I
don't
care
like.
I
just
need
that
that
simple
interface
and
I
will
get
all
of
the
instruments
from
the
registry
and
it's
an
interface,
so
the
the
instrumenter
will
never
know
what
is
under
the
hood
if
it
is
an
o,
if
it
is
a
whatever.
F
G
H
G
H
So
when
I'm
writing
the
code
for
my
library-
and
I
I
don't
know
who's
going
to
be-
you
know,
I
don't
know
who's
going
to
be
using
my
library
at
that
point
or
whether
they're
going
to
inject
anything.
How
do
I
get
my
first
interface
you?
If
brought
library
you
it
is
given
to
you
on
your
constructor
or
whatever?
H
G
Yeah
and
I
think
that
the
way
that
we've
recommended
at
least
for
open
telemetry
in
java,
which
is
not
micrometer,
is
that,
if
absol,
if,
unless
you
have
extreme
circumstance,
allow
your
users
to
inject
a
implementation
into
you,
but
consider
falling
back
to
the
to
the
global
which
defaults
to
a
no
op
in
extreme
cases
where
you
cannot
guarantee
that
the
user
will
be
able
to
provide
you
one
right.
So.
F
F
That
class
at
some
point
so
like
this
global
thing
is
cool,
but
there's
a
lot
of
languages
where
it's
a
huge
problem,
just
from
an
initialization
standpoint,
where
you're
going
to
force
your
users
to
know
about
initialization
anyway,
which
dependency
injection
kind
of
forces
you
to
solve,
I'm
not
a
fan
of
dependency
injection,
but
I
think
it's
better
than
like
the
other
alternatives
in
this
case.
But
we
should
it's
still
worth
a
discussion,
maybe
not
all
of
this
meeting
next
time.
Maybe
we
should
take
this
offline
yeah.