►
From YouTube: 2022-04-12 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
A
Perfect,
let's
start
and
thank
you
for
joining
okay,
so
yeah
we
have
a
time
box
for
20
minutes
for
metrics.
We
can
probably
leave
that
at
the
end
as
usual.
So
I
guess,
let's
start
with
the
with
the
merging
the
upper
friend
spec
meeting
back
into
this
document.
C
Down
I
was
just
asking
there
were
discussions
if
the
instrumentation
branded
meeting
should
now
be
branded
back
to
just
specification,
and
if,
if
we
were
doing
that,
then
it
would
make
sense
to
merge
it
into
the
same
meeting
notes
document
again.
C
B
A
Okay,
so
let's
postpone
that
decision
on
that
one:
okay,
the
next
one,
the
messaging
semantic
conventions,
one
we
can
use
them
box
of
a
minute
there.
D
Yeah
so
there's
one
item
I
included
here
about
record
level
attribute
semantic
conventions,
so
we
have
this
like
common
space
for
restaurants,
related
semantic
conventions,
but
for
record
level
somatic
conventions.
We
have
a
separate
space
for
trays
and
separate
space
for
metrics
and
separate
space
for
logs,
which
is
almost
empty
right
now
and,
as
a
matter
of
fact,
we
should
consider
that
many
of
the
attributes
should
be
shared
for
for
logs,
metrics
and
traces.
D
So
when
we
have,
for
example,
http
semantic
conventions,
then
we
have
attributes
such
as
I
don't
know:
http
method
or
http,
host
or
scheme
or
status
code,
and
those
are
currently
duplicated
for
for
traces
and
for
metrics,
and
sometimes
it
makes
it
a
little
bit
harder
than
necessary
to
navigate
across
those
semantic
conventions.
Also.
D
I
think
that
some
of
the
semantic
conventions
are
filled
only
for
some
of
the
signal
types
so,
for
example,
with
spans,
we
have
a
database
semantic
conventions
where
we
have
information
about
a
database
system
or
user
or
peer
name
and
etc,
and
this
is
not
even
present
for
metrics,
and
so
what
I'm
thinking
is.
Maybe
we
could
provide
some
space
where
the
common
attributes
for
all
signals
could
be
included
or
maybe
like.
We
need
to
have
some
smarter
way
to
copy
this
data
between
these
spaces
for
traces,
metrics
or
or
logs
or
like
something
else.
D
A
I
think
that
one
interesting
point
is
that
I
mean
you
may
know
what
the
currently
the
real
tools
do:
not
support
generation
of
metrics
right
for
semantic
conventions.
C
Yeah
there
is
a
pr
open,
the
build
tools
report
to
add
metric
support,
but
I
think
the
the
offer
is
on
on
vacation
or
something
at
this
point.
But
eventually
that
should
be
figured
out
and
I
think
for
the
proposal
that
jamaica
made,
we
would
likely
have
to
introduce
a
convention
type
for
common
or
non
or
something
like
that
to
justify
the
attributes
and
then
reference
those
in
the
in
the
tracing
and
in
the
metric
semantic
conventions.
But
it
it
would
look
like
a
good
approach
to
me.
D
Yeah
another
idea
I
had
included
there
was
that
maybe
we
could
have
like
the
single
space
and
a
table
for
each
attribute
if
it's
relevant
to
metrics
to
traces
to
logs,
because
of
because
of
the
cardinality
constraints.
Not
all
of
them
are
relevant
for
metrics,
but
probably
pretty
much.
All
of
them
are
relevant
for
for
logs
as
well
as
well,
the
one
the
one
we
have
for
for
spans
and
yeah.
So
I
think
that
having
a
common
attribute
type
would
make
a
lot
of
sense.
E
I
also
remember,
I
think,
ted
worked
on
something
similar.
I
can
I
put
a
link
to
pr
into
chat
here
and
he
I
think
the
pr
unfortunately
was
abandoned,
but
it
actually
worked
on
basically
reorganizing
the
whole
directory
structure
around
semantic
conventions,
but
that
seems
that
didn't
kind
of
reach
its
hand
and
was
abandoned,
but
I
think
that
ties
in
into
what
what
you're
asking
for
here.
B
On
related
topics,
I
wonder:
what's
your
take
on
a
single
event,
whether
it's
log
or
metric
or
trace,
a
single
event
can
have
multiple
shared
parts
from
from
different
categories
like
a
single
event
could
be
an
rpc
and
database,
so
they
would
have
both
the
attributes
from
database
and
rpc.
B
D
I
think
that
for
logs
and
traces
I
think
that
there's
like
a
really
wide
space
of
the
possible
attributes,
and
if
someone
wants
to
attach
those,
then
why
not
and
our
job
at
the
specification
is
just
to
define
what
they
mean
and
how
this
should
be
interpreted.
I
think.
B
Going
down
this
path,
I
see
exactly
what
we're
we're
doing
so
we're
basically
following
the
path
that
elastic
common
schema
has
already
established
two
years
ago.
The
ecs
folks
shared
their
approach
and
look
at
today
I
can
imagine
in
two
years
it
will
be,
will
be
similar
to
ecs.
A
A
So
if
we
are
okay
with
that,
then
we
can
go
to
the
next
item.
Lyudmila
http,
required
versus
optional
attributes.
F
Yeah
so
last
time
I
introduced
some
change.
I
would
like
to
have
to
narrow
down
the
amount
of
required
to
specify
required
attributes
in
http
specification
and
some
proposal
how
we
can
say
this
is
required.
This
is
optional,
so
thanks
to
grant
for
reviewing
it,
so
I
just
want
to
emphasize
again
that
the
proposal
is
a
valid
thing.
According
to
the
current
specification,
it's
just
a
more
narrow
thing.
More
specific.
F
F
The
other
question
I
have
is
related
to
the
recent
pr
to
mark
all
instrumentations,
unstable
and
the
evolution
of
of
this.
So
I
would
like
to
understand
how
these
two
things
are
related.
Are
we
saying
that
everything
is
unstable
at
this
point
for
the
next
year,
at
least
or
what?
What
does
the
past
here?
A
My
take
on
the
optional
one
is
that
we
don't
really
know,
for
example,
but
tigran
already
mentioned
that
in
the
pr
what
optional
means,
in
my
case,
I
think
it
makes
sense
given
especially
there
were
optional
to
massage
them
and
remove
them
or
rename
them
yeah.
But
I
don't
see
tigre
in
the
call
by
the
way,
so.
F
So
maybe
we
can
take
it
offline.
I
see
I
want
to
understand
what
does
the
pass
forward?
There
is
a
lot
of
work
needed
to
kind
of
make
it
a
real
pr
visit
to
link
change,
and
I
would
like
to
carl,
as
you
mentioned,
you
will
be
looking
into
this.
I
would
like
to
get
your
yay
or
nay
before
I
start
doing
this
work.
A
A
Okay,
in
that
case,
let's
jump
into
metrics
diego
metric
reader
force,
flash.
G
Yes,
so
this
is
a
question
that
I
posted
also
in
the
in
the
channel,
and
I
have
a
reply
from
from
riley.
The
specs
says
that.
G
The
sorry,
the
spec
for
mirror
provider
for
splash
says
that
it
must
invoke
force
flush
on
all
register
metric
readers,
which
I
seems
to
certainly
suggest
that
metric
readers
must
have
a
force
flash
method,
but
in
the
list
of
operations
of
metric
reader
there
is
no
force
flush
as
a
defined.
So
that's
my
question:
what
should
you
do
here.
A
H
G
All
right
I
mean
if
people
don't
have
an
answer
right
now
we
can
take
this
offline
and
there
is
already
a
thread
in
the
open,
telemetry
metrics
slack
channel
so
jack.
If
you
have
more
information
you
can
edit.
There
sounds
good
all
right.