►
From YouTube: 2022-09-21 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
C
D
A
D
D
So
as
of
now,
meters
are
identified
by
name
version
and
schema
url,
which
is
what
we
are
following
as
so,
we
don't
have
the
attribute,
as
as
one
of
the
identity
in
the
scope,
instrumentation
scope.
D
D
D
D
A
A
A
To
generate
venue,
conversions
and
see
what
is
going
on.
A
D
D
D
D
Probably
we
have
to
update
our
default
buckets
for
the
instagram
and
it
should
not.
They
have
been
discussion,
whether
it's
a
breaking
change
or
not.
It
does
not
look
to
be
a
breaking
page.
Okay,
I
think
I
didn't
this
is
incorrect.
Probably
I
need
to
add
the
correct
bucket
values,
but
it
did.
This
adds
more
even
the
changes
to
add
more
even
even
distribution
of
the
of
the
events
across
these
buckets.
So
the
number
of
buckets
have
been
increased.
It
should
not
be
breaking
change,
ideally
because
the
existing
bucket
range
is
not
updated.
D
Just
the
new
bucket
ranges
have
been
added,
but
anyway
it
should
not
affect
us,
because
we
are
still
into
the
experimental
place
for
matrix.
So
you
want
to
break
the
change.
We
should
be
good.
D
Apart
from
that,
in
the
span
exporter
also,
they
have
a
new
method,
as
we
added
force
flash.
It
was
missing
it
till
now,
but
I
think
over
the
course
of
a
couple
of
months
it
has
been
added
and
we
didn't
yet
implement
that
in
our
trace
implementation.
So
we
have
to
add
this
span.
Exporter
force
flush
as
a
required
method.
D
It
may
not
have
so
we
may
not
have.
We
will
not
have
to
do
any
custom
implementation
for
that.
D
Apart
from
most
probably
the
http
async
upload,
which
we
do
it,
which
we
do
for
otlp,
we
we
do
support
the
concurrent
upload
as
a
you
know,
feature
flag,
so
we
may
have
to
do
some
something
like
this
to
flush
all
the
pending
events,
which
are
which
are
yet
to
be
uploaded,
but
for
all
other
exporters
the
upload
is
synchronous.
So,
as
part
of
the
span
exporter
export
call
dx,
the
actual
export
operation
is
happening
and
that
method
will
return
only
if
the
export
is
successful.
D
D
But
I
just
created
an
issue
for
this
and
probably
to
start
with,
I
think
it's
good
to
add
a
default
method
in
in
the
sdk
default
empty
button,
and
then
we
can
see
ahead
if
all
the
exporters
have
to
do
any
custom
implementation.
For
that.
D
D
We
may
see
this
pr
getting
merged,
but
I'm
I'm,
I
think,
mark
you
did
mention
that
you
had
some
idea
on
how
to
implement
this
in
simplest
places.
I
was
thinking
that
whether
we
should
we
may
not
need
to
support
it
or
just
wanted
to
understand
again.
Are
you
nothing
good.
A
So,
basically,
in
the
in
the
api
itself,
there
is
the
trace
provider
singleton,
which
has
a
setter
and
a
getter,
and
today
everything
is
considered
part
of
the
api,
but
in
in
my
understanding
the
api
should
only
be
about
the
getter.
So
you
get
the
single
turn
to
instrumental
code.
The
setter
is
to
be
used
only
by
the
sdk.
A
So
if
we
move
the
problem
is
that
we
cannot
implement
this
logic
inside
the
api
itself
because
it
needs
it
means
to
do
a
get
environment
and
and
to
do
some
logic.
A
C
A
It's
it's
one
of
those
gray
areas.
A
singleton
is
right
in
the
in
the
middle
between
the
two
was
reacting
with
this
unique
singleton
changes.
D
Okay,
I
think
probably
let
me
let
me
also
see
this
once.
I
think
I
got
your
point
you're
saying
that
if
you
can
move
tracer
provider
into
setter
and
use
the
environment
check
the
environment
wherever
and
then
decide
accordingly,
if
it
is
not
so
if,
if
it
is
disabled,
then
we
don't
need
to
do
any
explicit
set.
Yes,.
C
D
D
D
D
Next
is
more
domain.
Specific
attributes
are
getting
added
in
matrix,
cementing
convention.
We
are
seeing
lots
of
pr
being
raised
honestly,
I'm
not
be
I'm
not
following
all
of
them.
D
That's
something
which
I
think
should
would
be
used
by
the
instrumentation
libraries
who
would
be
generating
the
measurements,
but
this
is
just
just
to
keep
in
keep
a
check
on
that.
What
all
things?
What
all
changes
are
happening
in
the
semantic
convention
for
matrix?
It's
not
yet
stable,
but
I
think
lots
of
domain
specific
stuff
is
already
added.
D
C
D
Yeah,
okay,
on
the
same
I
mean
I
do
plan
for
matrix.
I
do
I
mean
I
just
wanted
to
talk
about
the
performance
stats
for
the
matrix.
D
I
was
going
to
write
some
of
the
benchmark
stuff,
as
I
discussed
in
a
couple
of
meetings
back
just
benchmark
tests
for
the
matrix,
but
the
problem
is
our
benchmark
is
not
very
stable,
very
reliable,
as
of
now
all
the
benchmark
tests,
they
are
running
in
the
ci
system
and
those
are
actually
the
ci
virtual
environment.
D
A
D
D
D
For
us,
which
generates
an
instrumentation
library
which
is
generating
a
matrix,
but
that
matrix
would
be
basically
to
collect
the
cpu
and
the
system
strike
and
the
memory
statistics,
while
the
sdk
is
up,
is
generating
the
that
will
creating
the
matrix
out
of
those
measurements,
and
then
it
is
uploading
those
to
the
injection
system.
So
we
can
use
that
to
calculate
the
performance
stats
for
any
injection
ingestion,
both
for
the
sdk
and
exporter,
depending
on
the
existing
system
which
we
are
using.
D
D
D
A
If
we
have
code
that
generates
a
process
matrix,
would
that
be
into
open,
telemetry,
contrib
cpp
then.
D
Yes,
part
of
adding
it
in
as
part
of
instrumentation.
Here
we
can
do
that
or
I
mean
if,
if
we
really
want
to
do
it,
we
can
also
put
it
in
the
test
directory
in
somewhere
in
text
or
somewhere.
In
examples
I
mean
I
don't
know
I
haven't
thought
where
to
put
as
of
now,
but
at
any
one
of
these
places
we
can
put
it.
D
D
D
D
D
It's
a
new
component
which
would
be
added,
it's
still
not
merged,
but
I
think
it's,
the
pr
is
still
in
review
a
new
component
metric
producer,
which
will
directly
take
the
matrix
from
third
party
component
and
it
will
directly
start
it
can
be
exported
to
the
injection
system.
So
there
won't
be
any
measurements
produced
as
part
of
the
open
elementary
instrumentation
library,
but
it
would
be
from
external
directly.
The
metric
data
would
be
there
from
the
external
systems.
D
D
D
B
So
I
have
the
cmake
part
covered
for
the
latest
version
basil.
It's
I
think
I
have
to
do
the
basal
part
in
another
and
for
windows.
B
C
B
B
C
Yeah,
but
this
packaging
stores
the
latest
one
check
the
ink
to
to
like
yeah
to
that
reaper
right
with
the
package
ripple.
Okay,.
B
D
D
D
B
D
C
A
Just
for
windows
to
clean.
C
C
D
D
D
C
D
D
D
D
D
D
D
D
Locks
for
getting
started
now
we
have
to
handle
this
matrix,
that's
repaired
in
interface.
This
is
something
probably
have
to
look
for:
matrix,
clean
up
hold,
matrix
implementation,
remove
circular
differences,
and
I
I
think
most
of
these
are
from
matrix.
Probably
we
can
go
through
the
matrix
milestone
and
discuss
that
again.
D
D
D
D
These
two,
I
have
to
start
looking
I'll
start
looking
into
these
two
and
just
want
to
remove
that
weak,
weak
pointer
that
circular
dependency
problem
to
change
some
of
the
design
in
the
code.
So
let
me
see
this
clean
up.
It
will
take
afterwards.
Just
before
the
we
are
going
to
release,
we
will
do
this.
D
Recordable
interface
is
just
a
suggestion
if
we
can
do
user
whatever
interface
so
that
we
don't
need
to
copy
or
pass
the
matrix
data
from
the
storage
to
all
all
the
way
to
the
next
to
the
exporters.
D
Observable
guys
yeah,
this
is
something
we
already
discussed
I'll.
Take
it
over
try
to
fix
this
by
this
week.
C
D
So
we
already
discussed
issues
and
switch
on
w
error
in
the
ci.
That's
a
good
point
mark
right.
What
we
have
mentioned.
D
C
B
One
question:
do
you
use
cmake
or
base?
No,
I
use.
A
A
There
is
another
part
also
which
will
be
annoying.
Is
that
when
I
did
the
fix
to
clean
the
warnings,
I
did
local
build
fix
as
much
as
I
could
and
then
submitted
the
patch.
A
But
if
we
certainly
say
running
error
for
everything
that
will
also
include
the
generated
code
by
protobuf
and
this
code
is
not
clean.
So
we
will
have
to
figure
out
in
the
ci
how
to
check
for
warnings
in
the
telemetry
code
and
yet
ignore
the
warnings
from
the
portable
code.
So
that
will
be
annoying.
C
C
C
C
D
A
D
D
C
C
A
If
we
do
a
new
release,
we
should
align
with
the
semantic
conventions
from
the
spec
first.
I
think.