►
From YouTube: 2023-01-23 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
B
A
Sorry,
I
missed
the
past
few
meetings.
My
I
had
like
a
never-ending
streak
of
car
problems
and
guess
guess:
what's
super
fun,
it's
snowing
here.
So
do
you
know
what
happened
yesterday.
B
A
A
Anyway,
2023
everyone's
safe,
don't
worry,
it
was.
It
was
like
one
of
those.
You
know
someone
stop
and
slide
yeah.
They
like
slid
right
into
us.
I
have
a
little
cut
in
my
bumper,
but
it
was
I
was
like
oh
God.
If
I
have
another
car
issue
where
I'm
gonna
like
have
to
skip
Monday
again,
that's
gonna
suck,
it's
been
like
three
in
a
row.
It's.
A
Yeah
every
other
like
Monday,
it's
a
problem:
oh
that's,
cool
yeah!
We
had
that
cold
snap,
I
hope
everyone
survived
the
cold
snap.
We
lost
a
battery.
That
was
why
I
was
out
last
week.
Car
wouldn't
start
had
to
go,
get
it
towed
anyway,
I'm,
not
sharing
anybody.
Let's,
let's
get
this
document
shared.
We've
got
a
lot
to
talk
about
here
we
go.
A
A
D
Oh
sorry,
I
was
trying
to
amuse
myself,
so
it's
a
small
device
that
that
you
you
put
on
the
wall,
clock
and
connect
to
your
car
battery.
It
helps
to
monitor
the
voltage
job
and
if
the
warranty
jobs
a
lot,
it
will
help
to
recharge
the
battery.
So
essentially
it's
like
driving
your
tire
to
recharge
your
battery.
Every
few
weeks.
A
C
A
Yeah
I
am
I,
I
thought
I
wasn't
far
north
enough.
That
I
would
have
to
deal
with
the
block
heaters.
That's
like
a
Michigan
thing
right,
I'm
in
Pittsburgh
we're
we're
like
well
south
of
Lake
Erie
anyway.
Here
we
go.
Let's
can
you
guys
see?
My
screen
is
actually
showing
you
yeah,
yes,
okay,
I,
just
wasn't
zoomed
into
the
right
spot,
cool,
so
I
think
the
most
important
thing
to
talk
about
today
is
yay
on
Friday.
A
The
ability
to
make
metric
semantic
conventions
in
yaml
was
finally
unblocked.
The
tool
now
supports
metric
yaml
and
that
version
of
the
tool
is
released.
So
we
have
a
bunch
of
tasks
here
to
go
through
and
just
Mass
update,
metric
semantic
conventions
with
yaml
and
I.
Think
as
we
do
so
we're
going
to
find
conflicts,
we're
going
to
find
differences,
we're
going
to
find
issues,
but
it's
like
the
number
one
thing
I
want
to
do
before
we
declare
metrics
for
HTTP
semantic
convention.
Stable
is
get
them
into
yaml
format.
A
For
so
we
can
make
sure
that
we
can
do
code
gen,
so
we
can
make
sure
that
we
have
documentation
and
consistency
between
things
or
intentional
inconsistency,
as
opposed
to
unintentional
inconsistency
right.
So
this
way
we
will
know
and
it'll
be
clear
in
the
yaml
that
yes,
I
decided
not
to
put
this
in
the
common
area.
A
So
with
that
I
think,
there's
there's
a
lot
of
tasks
around
table
generation
that
we
need
to
outline,
but
I
was
gonna.
Wait
till
we
get
to
the
HTTP
semantic
convention
bit
first,
because
I
think
we
want
to
Target
those
so
I
just
want
to
call
and
highlight
that.
E
Quick
before
we
move
on
or
are
there
any
details
or
documents
on
what
has
changed
in
that
semantic
convention
generator
so
that
those
of
us
who
are
generating
from
it?
You
know
what
we
need
to
update.
We've
noticed
that
when
that
changes,
it
sometimes
causes
us
issues
in
our
generation
process
that
we
have
to
adapt
to,
and
we
don't
get
communication
about
it.
A
So
the
important
thing
here
is:
am
I
I'm,
not
sure.
What's
that
the
pr
describes
what
was
changed
but
I
think
the
most
important
thing
is
the
this
only
effects
right
now,
the
spec
we
I,
don't
think
it
has
the
code
generation
for
the
metric
semantic
inventions.
I
think
we
need
to
add
those
in
on
a
per
language
basis.
The
the
primary
goal
of
merging
this
and
getting
this
in
was
a
we
will
have
yaml
for
metrics,
so
we
can
unblock
the
generation
of
code
and
then
B.
A
We
can
start
updating
the
specification
to
get
the
metric
semantic
conventions
into
the
yaml.
So
then,
when
we
do
Cogen
we're
doing
it
on
real
things,
so
the
only
thing
that
to
pay
attention
to
or
the
primary
thing
to
pay
attention
to
is
actually
the
yaml
files
that
were
created
I,
believe
so,
if
you
look
at
here,
I
think
I
just
want
to
make
sure
there
may
have
been
one
before
this.
That
adds
a
few
things.
A
No,
it
is
in
this
one
in
the
semantic
convention
schema
you'll,
see
and
in
the
readme
it'll
kind
of
describe
a
little
bit
about
how
to
do.
Metrics
and
Metric
name
groups
and.
A
I
think
that's
it
for
docs
is
basically
there's
a
new
metric
group
in
metric
name
group
that
you
can
use
right.
A
And
if
you
look
I
think
there
is
input
and
expected
where's
the
animal
here
it
is.
The
definition
of
the
yaml,
unfortunately,
is
still
in
test
data,
so
I
think
there's
some
to
Do's
around
documentation
stuff.
But
this
is
the
goal.
Is
that
the
yaml
exists?
The
tool
can
interact
with
it.
You
can
go
build
your
code,
gen.
A
Does
it
so
in
terms
of
again
since
I
don't
know
exactly
all
the
Cogen
and
paths
that
you
take.
I
assume
we're
not
even
at
the
point
where
your
post
Cogen
stuff
would
run.
Is
that
correct.
E
E
But
we
we've
got
tasks
going
right
now,
I
think
to
generate
the
117
conventions,
so
we'll
make
sure
to
or
I'll
ask
people
to
make
sure
that
they're
using
the
latest
generator
and
report
back.
If
we
experience
any
issues.
A
Yeah,
what's
the
shape
of
those
kind
of
problems,
because
maybe
we
can
fix
that
too.
E
Structure
of
the
the
context,
that's
candid
to
the
template
has
changed
so
things
we
were
using
are
either
in
a
different
place
or
gone.
I
can
dig
up
the
changes
that
the
PRS
that
we
made
to
deal
with
those
and
play
with
them.
A
Okay,
I
see
interesting
I'm,
trying
to
figure
out,
maybe
there's
a
detection
in
thing
we
can
make.
We
have
so
like,
like
yeah
I,
said
and
I,
don't
know
if
I
pronounced
your
name
right.
This
shouldn't
change
you,
because
it's
mostly
around
structure
of
metrics
generation,
so
it's
possible
that
it
would
have
made
an
alteration
to
trace
I
think
there
could
be
an
alteration
and
Trace
from
this
version.
A
Timestamp
though,
but
nominally
everything
that
was
added
here
would
be
common
attributes
and
unless
you're
synthesizing
those
common
attributes,
it
shouldn't
actually
have
affected
Cogen.
A
Okay,
cool
all
right,
so
the
next
thing
is:
we
have
a
semantic
convention
concerned
around
scope,
attributes
and
names
facing.
A
So
what
this
is
is
we
added
scope,
attributes
right
and
there's
motivation
behind
the
Otep
and
there's
this
notion
of
instrumentation
scope,
short
name,
there's
an
open
question
here
around
whether
we
should
allow
instrumentation
scope
to
kind
of
prefix
semantic
conventions,
so,
for
example,
for
HTTP
semantic
conventions
should
we
have
requiring
instrumentation
scope
of
HTTP
that
has
a
short
name
of
HTTP
and
then
metrics
and
and
spans
and
traces,
don't
need
to
say
HTTP,
because
instrumentation
scope
would
kind
of
append
to
it.
That
was
like
one
of
the
intentions
of
instrumentation
scope.
A
If
we
say
that
we
want
to
go
that
route,
I
think
there's
some
work
to
do
with
some
spec
and
SDK
stuff.
So
I
really
want
us
to
be
very
intentional
about
like
how
we
want
to
use
scope
and
what
what
it
means.
B
D
A
Separate
yeah,
so
you
could
have
oh
sorry,
my
cat
wants
attention
and
at
every
time
I
have
a
meeting.
So
you
would
you'd
have
the
library
name
which
would
be
like
you
know:
Java
HTTP,
cement,
convention
version,
Foo
or
you
know,
Java
spring
web
MVC,
whatever
instrumentation
and
then
you'd
have
a
short
name
which
says
http,
I
think
actually
I
misread
the
the
pr
it's
oh,
my
God
get
out
of
here.
A
The
the
the
actual
question
is:
should
we
have
the
scope
name
and
the
HTTP
cemented
conventions
and
match
and
have
a
semantic
convention
that
requires
that,
so,
when
I
instrument
for
HTTP
I
would
need
to
have
a
scope
that
says
here
are
the
HTTP
things
that
come
out
right
and
then
all
of
my
HP
semantic
conventions
are
in
that
same
instrumentation
scope
or
instrumentation
Library.
C
F
Yeah
we
we
always
ran
away
from
this
traditionally
in
open
tracing
and
open
Telemetry,
because
we
were
skeptical
about
the
idea
that
a
single
instrumentation
package
would
only
produce
one
kind
of
semantic
convention,
for
example,
even
with
HTTP.
You
also
have
like
Network
conventions
and
other
things
in
there,
and
so
we
don't
we
it's
just
like
it
always
seemed
a
little
overfitted,
though
it
also
always
seemed
very
useful
if
you
just
had
like
a
span
type
or
something,
but
we've
we
just
we've,
never
done
it.
For
that
reason,.
B
F
A
I
I
think
the
I
always
use
the
word
ontology
there
and
people
can
yell
at
me
and
say
that's
wrong,
but
it's
basically
like
you
have
you
have
a
flexible
notion
of
types,
so
it's
or
how
about?
We
call
it
structural
typing
we're
we're
in
a
structural
typing
world,
not
a
static
typing
world
and
I,
don't
want
to
be
Java
1.4,
that's
all
I'm,
saying
so.
A
I
think
I
think
I
I
totally
buy
that
logic
of
let's
continue
with
structural
typing
and
let's
continue
doing
our
best
to
annotate.
What's
expected
here
with
semantic
conventions
right
like
here
when
you
see
HTTP,
you
should
see
these
sets
of
things,
but
you
might
also
see
the
network
things
yeah,
that's
fair
and
that's
more
of
a
kind
of
you
know.
I
am
multiple
things.
At
the
same
time,.
F
F
F
Always
been
a
little
nervous
to
say
we're
just
gonna
slap,
a
single
type
onto
these
things
and
say
everything
has
to
conform
to
that.
B
F
The
the
other
thing
we
didn't
do
that
I
have
like
some
regrets
about
that.
That
would
I
think
solve
this
issue
because
it
seems,
like
part
of
the
issue,
is
really
just
trying
to
save
space
in
a
way
or
make
things
convenient
and
that's
nested
attributes,
and
the
main
reason
for
that
was
all
of
pretty
much.
F
All
of
the
tracing
systems
at
the
time
did
not
support
nested
attributes
on
the
back
end,
since
that's
kind
of
like
the
origins
of
this
project,
we
didn't
have
nested
attributes,
I
kind
of
feel
like
that
would
actually
be
the
thing
that
would
make
life
easier
for
people.
If
you
could
just
have
all
the
HTTP
attributes
just
nested
under
the
HTTP
namespace,
then
we
wouldn't
be
worrying
about
this
stuff
anymore,
but
we
didn't.
G
Oh
yes,
I
I
just
opened
the
issue
and
then
I
I
noticed
that
it
wasn't
me
that
opened
it
last
year.
So
when
I,
when
I
opened
it,
it
was
because
we
were
doing
the
or
trying
to
get
the
scope
short
name
down
and
I
noticed
that
there
was
like
there's.
No,
there
was
no
attributes
for
a
scope,
so
there
was
no
semantic
and
vegetable.
G
There
was
no
emo
file
for
scope,
attributes
and
when
I,
when
I,
like
the
motive
for
the
issue,
was
that
we
could
create
emo
files
for
defining
attributes.
G
That
would
stay
on
the
scope
so,
for
example,
the
shortening
it
was
one
one
thing,
and
then
it
also,
for
example,
if
there
is
a
attributes
that
are
not
like
scope
related
like
Global
scope
or
just,
for
example,
trace,
and
then
it
would
I
also
proposed
a
way
that
you
could
have
the
ammos
in
a
way
that
can
also
generate
the
the
tables
for
the
scope
attributes,
but
just
for
spans
for
traces,
but
I
didn't
consider
any
name
spacing
or
anything
like
just
having
HTTP
on
the
scope
and
then
the
rest
just
follows
it.
G
It
was
just
just
a
way
of
defining
conventions
for
scope
attributes,
because
today
we
don't
have
anything.
We
just
have
no
name
inversion
but
yeah
like,
and
there
was
this.
There
was
the
shortening
that
we
wanted
to
add,
but
we
then
we
decided
to
not
have
as
an
attribute
and
has
it
as
a
as
a
feud
like
we
have
today
I
think
and
then
the
the
notion
of
scope
attributes
was
just
like
dropped.
Nobody
talked
about
it
anymore,.
A
It's
almost
like,
we
still
have
to
ask
if
we
need
it
so
right
inventions,
don't
use
it.
That's
that
makes
me
more
nervous
about
them.
Let
me
have
your
hand
raised.
H
Yes,
so
one
thing
it
can
address
is
that
we
currently
each
semantic
convention
needs
to
Define
at
least
one
required
attribute
to
signify
what
it
is
and
the
scope
can
solve
this
problem
and
if
they
include
both
database
and
HTTP,
it
can
say:
okay,
I'm
database
treat
me
as
database
I
will
best
when
I
visualize
this
database,
and
it
will
also
make
it
easier
and
more
explicit
to
create
semantic
conventions
and
the
concern
about
multiple
types.
I
mean
it's,
it's
optional
right,
it
shouldn't
be
required.
H
Then
something
can
say:
okay,
I'm,
nothing
tricky,
as
whatever.
F
Yeah
I
I
can
totally
see
this
as
as
being
useful,
but
I
don't
know
that
you
can
remove
the
the
I
think
that
the
reason
this
was
brought
up
in
this
conversation
originally
was
like.
Can
we
remove
the
the
dot
name,
spaces
and
the
attribute
names
and
it
it
feels
to
me
like
this.
This
might
be
like
a
useful
thing,
but
it's
if
what
you're
trying
to
do
is
change,
how
we
name
attributes
I,
don't
I,
don't
see
any
of
this
stuff.
Getting
us
out
of
For,
Better
or
Worse.
F
Having
like
gone
with,
you
know,
single
string
names
with
dotted
name
spaces
seems.
A
A
A
Call
it
two
things
so
hard
to
say:
like
do
some
sort
of
hierarchy
like
I,
think
what
suggested
here
was
the
heterogeneous,
arrays
and
attribute
values
right
where
we
could
literally
make
a
label
called
HTTP
and
underneath
it
have
the
values,
be
key
value
pairs,
no
matter
what
someone
has
to
unwind
that
stack
and
so
there's
going
to
be
work
on
exporters.
A
If
we
go
with
that
convention,
and
so
that's
like
working
in
SDK,
what
lamilla
was
was
suggesting
there
I
like,
however,
theoretically
theoretically,
when
I
make
an
instrumentation
scope,
I
give
it
a
schema.
Url
that
schema
URL
tells
me
what
type
of
conventions
to
expect.
So
now
the
question
is
you
know
how
do
I
say
this
span?
A
Is
an
HTTP
span,
I,
don't
think
adding
an
instrumentation
scope
attribute
actually
removes
the
need
for
a
required
attribute
on
the
HTTP
span,
because
a
particular
instrumentation
scope
could
generate
many
types
of
spans.
It
doesn't
need
to
only
make
HTTP
spans,
and
so
we
don't
actually
have
a
mapping
from
like
the
scope
to
the
span.
So
I
I,
like
where
you're
going
with
that
I
wish
that
that
were
true
I.
Just
don't
think
it
would
actually
work
out.
A
A
I'm
curious
what
people
think
like
do
we
need
to
take
so
do
we
need
to
basically
ask
the
H3
semantic
convention
group
what
scope
attributes
would
be
or
do
we
think
that
we're
they're
just
we?
We
can't
come
up
with
a
use
case
right
now,
where
we
need
to
lean
into
them.
B
A
A
So
from
my
my
standpoint,
you
know
like
I,
wanted
to
ask
the
question
here
and
have
us
kind
of
think
through
it,
but
I
don't
think
we
need
a
lot
from
scope,
but
I
did
want
to
like
evaluate
it.
First
before
just
saying
blanketly
like
we
probably
don't
need
to
do
a
lot
with
scope.
I
think
metrics
is
where
we
have
to
do
a
lot
of
work.
F
F
Could
you
put
things
other
things
in
there
like
GitHub
repo
or
you
know
if
this
kind
of
library
has
different
flavors
or
you
know,
builds
or
something
various
things
like
that,
the
that
that's
that's
where
I've
seen
people
potentially
want
to
leverage
scope
attributes,
but
not
for
describing
the
not
for
describing
the
data
being
emitted
by
it,
but
describing
the
library
itself
in
more
detail
and
I
also
don't
think
it
would
block
anything
we're
doing
I
feel,
like
anything.
F
A
Think
the
the
utility
there
isn't
super
high
or
like
need
semantic
convention
work.
The
context,
attributes
I,
think
are
super
interesting,
super
useful,
absolutely
needed
for
a
hotel
and
we'll
have
to
look
at
them
as
they
as
they
show
up.
Okay
time
box,
wise
I
blew
this
out
of
the
water
apologies,
but
I
think
for
now
what
we'll
say?
I
might
mark
this
as
non-blocking
now
for
semantic
convention
stability,
so
we'll
take
an
offer
blocking
list.
A
Yeah
I
think
you
might
have
already
added
scope,
attribute
support
to
build
tools,
or
at
least
I
saw
a
PR
around
it.
So
I
think
even
the
original
PR
itself
might
already
be
answered,
but
we'll
put
that
topic
down
for
now.
Sorry.
A
A
Great
I'm
going
to
time
box
the
next,
the
next
discussion
to
only
10
minutes,
so
we
have
time
for
the
rest
too,
so
HTTP
semantic
conventions,
I
wanted
to
call
it
a
few
of
my
thoughts
around.
Let's
get
this
thing
marked
stable,
so
I
think
primarily
what
I
want
to
do
is
now
that
we
have
the
ability
to
have
metrics
in
yaml
to
take
the
the
metric
HTTP
semantic
inventions
and
get
them
into
yaml.
A
We
can
do
them
one
at
a
time.
We
can
split
this
off,
I,
don't
care
who
does
the
work
I'm
happy
to
help
actually,
but
I
want
to
get
them
into
metric
GMO,
because
this
will
implicitly
tell
us
what's
shared
and
then,
if
we
want
to
make
explicit
decisions
to
have
things
diverge
in
consistency?
That's
okay,
like
that's!
That's
still,
a
discussion
to
have
I
just
want
to
make
sure
that
we
are
knowingly
doing
it
and
that
it
fits
within
the
tools.
A
The
one
thing
I
want
to
call
out
is
before
we
marketing
stable
I
would
like
to
have
everything
in
yaml
so
that
we
can
do
Cogen,
so
we
can
do
automatic
documentation
and
because
the
yaml
will
be
the
the
kind
of
codified
version
of
what
we
consider
stability
and
how
we
Define
migrations
right.
So
we
need
it
in
yaml
and
then
we're
also
going
to
have
the
schema
URL
to
talk
about
how
we
do
migrations
going
forward.
So
we
have
full
control,
Fair.
A
Okay,
with
that
I
had
two
issues
that
I
thought
we
could
talk
about
now
if
they
make
sense
to
talk
about
again,
I'm
looking
to
http
semcon
folk,
who
are
here
to
kind
of
enlighten
me.
Maybe
these
aren't
the
best
two
issues
again
I'm,
not
as
involved
in
the
details,
but
first
off
I
wanted
to
talk
about
whether
or
not
all
metrics
are
required
or
if
we
need
the
ability
to
Mark
some
as
optional
and
some
is
required
and
if
you
feel
like
you
have
that
ability
today.
B
A
Yes,
yeah
so
think
think
of
it
like
if
I'm
producing,
if
I'm
saying
that
I'm
HTTP
semconf
compatible
right
here
are
the
metrics
you
have
to
produce,
and
here
are
optional
ones
that
you
can
produce,
but
the
way
I
heard
I
think
it
was
James
described
this
at
some
point
was
a
you:
have
a
t-shaped
API
right,
where
we
have
the
required
components
that
we
consider
core
observability
needs
like
this
is,
if
you
think
about
it
from
an
end
user
standpoint,
if
I
don't
have
these
metrics
I
can't
do
good,
alerting
right,
I
can't
do
great
monitoring
and
I
have
trouble
diagnosing
right
and
I,
and
then
my
it
puts
questions
on
like
you
know
the
the
actual
quality
of
the
instrumentation.
A
Do
we
want
to
distinguish
like
you
must
to
produce
this
to
consider
yourself?
Hp
semconf,
so
at
a
bare
minimum
I
say
your
HP
semconf
I
make
a
default
set
of
alerts
and
dashboards
and
they
should
always
work,
and
they
should
give
me
that
minimum
layer
of
observability
that
that's
useful
for
http
option.
Number
two
is
we
just
say:
here's
what
could
be
produced
and
people
can
just
produce
whatever
they
want
right.
That's
option
number
two
option.
Number
three
is
we
could
say
everything
that
we
have
is
required
and
always
required.
A
And
I'm
biased
at
Google.
We
have
this
notion
of
golden
signals
from
our
SRE
book
of
like
here
the
things
you
need
to
measure
and
guess
what
duration
is
one
of
the
big
ones
request
counts,
the
other,
the
other
one
of
like
how
many,
how
many
errors
are
coming
in
and
how
many
errors
are
going
out.
A
B
Well,
you
can
get
that
from
duration
yeah!
Well,
that
that's
something
to
discuss
maybe
later,
but
I
was
kind
of
curious
about
that
errors,
because
you
can
get
it
from
duration.
B
A
bucket
there's,
a
dimension
that
you
could
split
across,
though
it's
not
as
convenient
just
having
a
individual
errors
that
is
then
split
across
dimensions.
A
But
again,
that's
actually
fine
like
because
again
it's
it's
does.
If
we're
going
to
Define
required
I
think
it
should
be
bare
minimum
and
support
the
use
case
of
what
we
consider
good
observability.
So
if
you
can
say
like
here's,
how
you
split
this
histogram,
this
is
the
only
thing
we
need.
It
gives
you
all
the
observability
you
need
great.
Then
we
can
mark
the
other
things
optional
as
like
add-on
value
right
or
it
might
make
it
easier.
A
H
Someone
else
yeah,
there
is
one
thing
that
can
be
related,
that
if
we
are
somehow
reusing
attributes,
we
need
to
make
sure
that
we
all
destroysing
attributes
that
are
needed
for
required.
Metrics
are
also
required.
H
A
Yeah,
that's
that's
actually
a
great
Point,
so
the
we
do
have
a
bit
of
a
dichotomy
of
like
trace
and
metrics,
especially
here
for
things
like
latency
like
hdb
duration
is
probably
one
of
the
most
useful
metrics
you
can
get.
Http
latency
with
exemplars
and
also
sending
traces
for
debugging
is
useful.
However,
I
could
get
everything
I
need
with
just
traces.
A
A
Did
you
make
it
a
requirement
that
metrics
must
be
calculated
from
traces
or
just
specific
types
of
metrics
should
be
calculated
similarly
to
traces
right,
I,
don't
know
if
I
would
say
that
that
should
be
a
requirement,
but
for
these
metrics
we're
talking
about
specifically
I
can
see
how
that
could
be.
H
Yeah
I
think
in
addition
to
the
metric
calculation
from
traces.
The
other
case
we
have
in
Java,
for
example,
is
where
instrumentation
API
creates
both
signals
right
and
then
we
would
need
to
have
those
attributes
populated
without
even
knowing
how
the
signals
will
be
produced.
B
So
I
think
if
the
metric
is
essentially
corresponding
to
a
span
such
as
client
duration,
then
we
want
at
the
any
required
metric
attributes
to
be
required
on
the
span.
H
F
I
Do
we
have
any
kind
of
graphical
viewer
for
this
when
I
say
graphical
I
mean
like
the
computer
science
concept
of
a
graph
data
structure,
not
like
visual
just
thinking
about
this,
like
you
know,
as
we
try
to
link
stuff
in
semantic
conventions
to
what
I'm
guessing
is
gonna,
be
the
metadata.eml
and
all
the
contrib
stuff,
et
cetera,
Etc
like
that,
might
be
useful
to
like,
actually
see
I've.
Seen
like
a
data
dictionary
request
too
and
I'm,
like
you
know,
after,
like
realizing,
we
might
need
this
for
the
dependency
closure
problem.
I
That
is
that
we
were
just
talking
about
there.
It
might
be
useful
to
like
write
like
some
kind
of
like
graph
representation
of
our
metrics,
because
it
seems
like
it'd
be
used
in
a
couple
places
now
anyway,
just
bit
on.
I
Yeah
sorry,
yeah
okay,
so
we
were
just
talking
about
like
how
required
attributes
must
be
like
figured
out.
I
guess
I
could
say,
like
standardized
solidified,
for
what
are
determined
to
be
required
metrics.
My
phrasing
of
that
would
be
like
okay,
so
we
have
like
many
receivers
that
might
be
able
to
implement
a
given
name,
an
identifier.
You
know
which
is
a
metric,
and
you
know
that
it'll
be
either
optional
or
not
optional.
I
So,
in
order
to
like
actually
see
what
that
looks
like
it
would
be
useful
for
me
as
a
developer
to
go
out
and
like
actually
do
that
task,
or
even
just
figure
out
what
the
scope
of
that
task
is.
If
we
could
have
like
some
simple,
like
parsing
tool
that
would
combine
the
various
metadata
yeah
or
like
wherever
we're
going
to
eventually
have
these
things
living
in
with
the
otel
spec
ref.
To
my
understanding,
right
now,
if
I
were
to
do
that,
I
would
have
to
by
hand
cross
reference
a
bunch
of
EML
files.
I
Maybe
there
has
been
some
new
changes
that
I
didn't
see
going
on
the
build
tools.
I
know
we
have
recently
launched
that
anyway,.
F
I
I
think
I
get
what
you're
saying
the
way
we
currently
write
these
semantic
conventions
out
in
yaml,
because
you
have
like
pricing
metrics
logs,
and
it's
like
these,
like
vertical
columns,
as
opposed
to
saying
we
have
HTTP
and
here
are
like
all
the
HTTP
attributes
and
maybe
like
a
flag
for
which
ones
are
required.
It
also
like
a
flag
for
like
which
ones
go
on
our
like
default.
You
know
how
do
you
compose
your
default
like
metric
dimensions
and
stuff
like
that?
Yeah.
I
And
and
like
going
back
to
Josh's
comment
about
like
ontology,
the
idea
of
like
all
these
metrics
identifiers
out
there,
they
exist
with
some
sort
of
form
of
relation
to
each
other.
But
right
now,
that's
like
kind
of
implicitly
encoded
and
we
don't
have
like
an
explicit
way
to
like
actually
walk
that.
What
I
would
call
a
virtual
graph
like
that
graph
exists
conceptually,
but
it
doesn't
exist
in
code.
A
What
we
just
added
for
yaml,
is
you're
going
to
have
a
yaml
file
where
you
put
common
metrics
and
then
you're
gonna
reuse.
Those
when
you
define
your
spans
when
you
define
your
metrics
and
it's
going
to
reference
the
common
and
pull
in
kind
of
like
an
inheritance
thing.
It's
not
the
same
as
a
graph,
but
it
is
something
we
could
actually
use
directly
with
Cogen
and
such.
I
When
I
say
graph,
I
mean
like
we're
conceptual
but
I,
I
kind
of
if
I'm
not
communicating
this
clearly
I
can
take
some
time
on
the
side.
I,
don't
we
are
time
boxing
this
and
I
don't
want
to
take
up
too
much
of
our
time
here,
but
that's
yeah.
A
Yeah
we're
over
our
time
box,
but
I
think
the
thing
you're
going
after
sounds
like
it
will
be
useful
it
just
let's
flush
out
what
it
looks
like.
So
we
can
have
a
more
yeah
but
I
think
I.
Think
I
like
where
it's
going,
okay,
so
to
wrap
up
just.
J
I
have
a
quick
bit
to
that
like
by
having
the
graph.
It
means
you
could
have
as
part
of
the
generated.
C
I
That's
exactly
where
I
was
going.
We
actually
have
an
open
backlog
item
in
our
working
group
for
coming
up
with
a
data
dictionary
that
was
open
in
2020
and
internally
at
my
team
and
my
company,
we're
talking
about
like
some
desirable
feature
as
well.
So
anyway,.
A
So
in
terms
of
required
versus
optional,
let's
stick
with:
let's
stick
with
this
notion
that,
like
some
things
can
be
required,
some
things
can
be
optional
and
go
down
that
path.
I
saw
lamilla
has
to
drop.
So
if
someone
could
bring
her
up
to
speed
on
that
for
the
HTTP,
semconf
that'd
be
ideal.
A
So,
let's
let's
go
with
that
and
with
the
things
I
do
want
to
for
HTTP
7
conf.
We
can
follow
up
on
chat.
We
need
to
update
metric
semantic
convention
stabilities
to
use
the
new
yaml
and
Metric
Cogen.
If
we
want
to
fragment
out
tasks
there
and
assign
it
to
people
I'd
love,
if
we
could
do
that,
if
you
need
me
to
take
on
anything
ping,
me
I'm
going
to
assume,
though,
that
the
HP
semcon
kind
of
owns,
that
is,
that
fair,
okay,
good
good
I,
see
Trask
naughty.
A
Pending
discussions
about
it,
well,
let's
walk
into
that,
since
we
want
to
save
time
for
it:
okay,
cool,
there's
a
few
other.
If
you
look
at
some
kind
of
blockers,
I
don't
know
if
we've
had
a
chance
to
go
through
those
in
the
semconf
group,
but
there's
there's
a
few
interesting
things
of
like
host
versus
server
and
junk
like
that.
Just
please
take
a
look.
I
only
pulled
in
two
for
discussion,
but
I'm
glad
we've
spent
time
on
this.
This
was
a
very
useful
discussion.
B
Awesome
yeah,
so
we
had
discussed
this
at
two
weeks
ago
in
this
meeting
of
you
know
splitting
out
a
subgroup
from
this
group
to
focus
on
HTTP,
getting
HTTP
metrics
I
mean
HTTP
semantic
conventions
to
stability
following
Ted's
new
process
doc,
and
so
we
thought
that
you
know
it
seemed
worth
you
know
going
for
it
using
you
know.
Right
now
we
would
say
we're
in
state
there's
the
three
stages:
three
quarters
of
Ted's
process.
B
The
first
quarter
probably
will
be
very
shortcut
short,
but
we
are
technically
in
that
first
quarter
stage
where
we're
putting
the
working
group
together,
we
did.
We
do
have
two
TC
members
signed
up,
thank
you
Riley
and
Josh,
and
we
have
two
domain
experts
so
far,
lidmilla
and
Dennis
and
so
sort
of
my
thought
is,
you
know,
it'd
be
great
to
meet.
B
You
know,
do
the
do
the
follow
the
I,
like
part
of
the
part
of
the
process
that
I
liked
for
the
stage
two
was
the
multiple
meetings
a
week
like
at
least
I.
Think
at
least
two
meetings
a
week
to
really
you
know
and
I
was
actually
thinking
like.
B
You
know
30
minute
meetings
more
as
just
like
more
like
checkpoints,
make
sure
that
you
know
we're
coordinating,
make
sure
that
people
are
assigned
to
tasks,
make
sure
that
we
know
what
we
should
be
working
on
next
and
then
coordinating
obviously
with
this
group.
I
think
the
first
task
would
be
for
this
group
would
be
to
sort
of
would
be
to
look
over.
I
mean
it's
pretty
much
labeled
Josh
has
labeled
everything
already
of
things
blocking
hdp
semantic
stability,
so
we
would
create
a
separate.
B
A
I
I,
like
it
I,
think,
to
the
extent
that
we
identify
there
is
say
an
over
General
issue
in
the
spec
or
lack
of
definition
of
what
stable
means.
This
group
should
be
focused
on
that
and
make
sure
that
we're
making
progress
and
then,
to
the
extent
that
we
have
to
you,
know
ironically
I,
think
the
discussions
are
intertwined
right
now,
like
our
discussion
on
scope
was
basically
do.
We
need
scope,
semantic
convention,
stability
to
have
any
semantic
convention
stability,
but
we
really
just
talked
about
HTTP
and
like
are
inferring
from
that.
A
A
B
B
Just
briefly,
though,
do
we
have
anyone
who
is
in
Europe
or
Asia
Pacific
like
as
far
as
optimizing
time,
zone,
options
and
I
know,
I
was
going
to
check?
Probably
nobody.
Obviously,
nobody
from
Asia
Pacific
here
at
this
time
are
gonna
check
with
James,
because
I
know
he
was
he.
He
may
be
interested.
B
Do
do
we
think
it
would
be
worth
alternating
times
if
we're
meeting
twice
a
week,
or
will
that
not
I
mean
I'm
a
little
worried
about
not
having
the
same
consistent
set
of
people
at
the
meetings.
A
B
B
So
I'll
put
out
a
doodle
in
the
in
this
channel,
I
mean
in
our
the
semcom
slack
Channel
and
for
scheduling
meeting
times
and
see
if
we
can
start
next
week,
if
possible,.
B
And
definitely
yeah
yeah.
Oh
yes,
I
will
post
the
time
the
doodle
on
the
issue
and
if
you
are
interested
in
being
you
know,
HTTP
representing
HTTP
expert.
B
A
Yeah
I
think
I
forget
the
approval
process
for
these
project
issues,
but
I
think
I
think
between
Riley
and
I.
Since
we're
both
there,
we
can
Market
approved
to
make
the
board
right
Riley.
A
G
K
Just
a
quick
question
about
the
overall
stability
process
and
the
the
way
how
we
want
to
make
bring
HTTP
the
stability
in
specific.
So
like
is
it
something
that
we
want
to
have
some
verifications
or
or
it
will
be
just
a
document
I
mean
do
we
want
to
do
not
only
prototypes
but
actual
implementation
to
three
different
sdks
for
different
languages,
or
it
just
will
be
the
specification
that
we
consider
stable
and
only
after
that
point
we
want
to
bring
bring
all
the
efforts
to
actually
implements
which
opinion
folks
have
here.
Yeah.
A
Yeah
I
I
could
take
this
or
Trask.
You
can
take
it
if
you
want,
but
we
have
implementation
already
for
HTTP
instrumentation.
We
definitely
have
it
in
Java.
We
have
it
in
many
languages,
as
we
Define
the
specification,
a
a
implementation
supposed
to
follow.
If
you
look
at
the
issue,
traffic
has
linked
there's
a
phase
three,
where
it's
people
doing
implementation,
if
you're,
also
asking
about
verification
of
like
I,
would
like
to
test
to
make
sure
that
the
signals
abide
by
the
semantic
convention.
A
That
is
work
that
we
want
to
get
to
as
part
of
this
working
group.
One
of
the
reasons
why
we're
pushing
for
all
stable
semantic
conventions
to
be
in
yaml
is
it
doesn't
matter
that
it's
yaml
because
again
I
think
I
hate
ammo?
Personally,
it's
just
yet
another
config
language
that
just
annoys
everybody
yay
config,
but
it
works
and
the
key
is
everyone
uses
it
and
B
we
can
code
gen
from
it.
A
So
the
idea
being
that
with
the
blocker
to
stability,
is
the
ability
for
us
to
create
the
verification
tool,
but
the
verification
tool
can
come
later
because
we
don't
want
to
block
everyone
for
like
a
magical,
you
know
perfect
world.
We
want
to
just
like
make
sure
that
we
can
get
there
eventually.
So
if
you
are
interested
in
working
on
a
verification
tool
where
like
I,
can
you
can
look
at
that
yaml
file,
look
at
dumped,
otlp
files
and
say:
does
this
match
the
yaml
that
is
I
I?
Think
it's
on
our
project.
A
Charter,
we
haven't
scoped
the
work.
We
don't
have
anyone
who
has
time
to
work
on
it
right
now,
but
it's
definitely
in
the
roadmap
and
it's
something
we'd
love
to
have.
So,
if
you're
interested
in
working
on
that
absolutely
like,
we
can
talk
more
later
and
like
flush
that
out
and
get
that
going.
I
think
everybody
would
love
to
have
that
tool.
We
don't
have
a
lot
of
time
to
build
it
just
yet,
but
we're
trying
to
enable
it
if
that
makes
sense,
that's
the
current
goal.
K
Yeah
definitely
thank
for
clarification,
but
at
least
like
we
want
to
put
this
everything
that
we
consider
stable
to
that
yaml.
So
later
we
can
come
with
any
kind
of
clarification
tool,
but
at
least
all
the
things
that
we
have
in
a
spec
should
be
also
kind
of
reflected
in
that
demo.
Is
it
correct
exactly.
A
Exactly
and
the
other
thing
about
a
verification
tool,
we're
mitigating
verification
via
code
gen,
so
because
everything's
in
the
yaml
and
we're
focused
on
Cogen
nominally
the
code,
gen
means
it's
less
likely
that
you
violate
the
semantic
conventions
because
you're
using
automatically
generated
code
from
the
yaml,
which
is
another
reason
why
that's
lower
priority.
But
it's
still
something
that
we
want
right.
So
so
again
we're
all
in
on
the
yaml
and
then
eventually.
We
hope
that
the
tooling
can
can
really
really
make
this
seamless
and
dead.
Simple.
J
All
right
folks
I
have
a
bit
different
questions
about
metrics,
so
you
you
mentioned
that
we
will
have
this
notion
of
required
and
optional
metrics
and
in
semantic
conventions,
I'm
working
on
open,
Telemetry
collector,
when
we
have
like
this
active
scrape
and
from
all
different
sources
for
the
metrics,
and
we
also
have
notion
of
optional
and
default
managers
there,
which
can
be
enabled
disabled
by
the
user,
and
also
we
introduce
a
notion
of
default,
optional
attributes
so,
for
example,
CPU
per
core
core
as
an
attribute
right,
and
we
want
to
make
it
optional.
J
So
user
can
re-aggregate
the
data
right
right
on
the
source,
so
they,
for
example,
want
to
have
CPU
metric
piercore
as
an
attribute
they
enable
it
by,
but
by
default,
not
disabled
and
in
semantic
convention.
All
attributes
are
like
there's
no
notion
of
optional
or
like
default
attributes,
so
I'm
curious.
J
A
A
I
think
I
think
we
absolutely
want
that.
I
think
that
was
part
of
that
one
major
discussion
on
scope,
attributes
and
then
around
the
whether
or
not
we
need
optional
default,
metrics
I
think
it's
the
same
for
attributes
so
yeah.
If
you
want
like
at
this
point,
I
think
it's
clear
enough
that
if
anyone
wants
to
take
the
time
to
make
sure
we'd
have
optional
and
default
clearly
documented
everywhere,
I'll
put
a
caveat
that
the
notion
of
optional
default
should
be
per
signal.
A
J
A
And
I
think
we
need
to
account
for
that
and
that
there's
this
weird
inheritance
thing
that
you
use
in
yaml
that
might
allow
us
to
specify
that,
but
that
would
be
worth
investing
in.
So
if,
if
you
want
it,
if
that's
an
area
that
you're
passionate
about
and
want
to
go,
invest
and
like
make
that
possible,
you
want
to
look
in
open,
Telemetry,
slash,
build
tools,
look
at
the
same
comp
generator
and
the
ammo
there
and
start
working
on
that
that'd
be
beautiful.
Okay,.
A
Absolutely
yeah
and
there's
I
think
there's
no
less
than
two
or
three
bugs
open
with
that
same
feature:
request
phrase
in
various
ways:
I'll
see
if
I
can
collect
them
all
and
unify
them
for
you.
But
okay,
if,
like
that's
I,
think
it's
clear
and
again
I
don't
want
to
speak
out
of
turn
everyone
in
this
meeting.
If
anyone
disagrees,
please
raise
your
hand
but
I
think
that's.
We
all
yeah.
A
Yeah
and
yeah
yeah
says
it
should
be
possible
with
current
time
tools.
I'm
pretty
sure.
It's
possible
yeah
and
just
remember
that
when
you
look
at
the
same
conf
right
like
the
the
optional
default,
will
probably
be
on
the
span
itself
or
on
the
metric
itself,
not
in
the
shared
space.
So.
A
Cool
anything
else
before
we
call
it
I
want
to
give
everyone
a
heads
up
that
we
had
a
bunch
of
discussions
in
December
around
what
metric
stability
means
around
like
things
that
will
be
included
in
metric
stability.
A
We
have
this
notion
of
telemetry
stability
document
that
I
haven't
gone
through
and
made
PRS
to
I
got
really
really
really
really
swamped
early
January
with
a
whole
ton
of
crap
that
I
still
plan
to
push
out
so
I'm
hoping
by
next
week.
You
will
see
a
slew
of
PRS,
or
maybe
one
giant
one,
probably
one
giant
one
of
here's.
What
metric
stability
means
I
expect
this
to
get
nitpicked
to
hell.
I
expect
lots
and
lots
and
lots
of
back
and
forth.
Please
folks
from
this
group
comment
approve
Etc
same
for
resource
attributes.
A
Yeah
we're
gonna
have
to
do
that
for
resource
attributes.
Yeah
I,
agree
cool
all
right
anyway,
good
to
see
everybody,
sorry
I
missed
last
time
and
looking
forward
to
continue
working
here,
let's
get
HTTP
out.
Thank
you.