►
From YouTube: 2022-08-03 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
Okay,
it's
three
minutes
past.
Probably
no
one
else
is
joining
the
event
domain
right,
it's
the
first
one
there.
So
I
posted
what
I
thought
maybe
is
a
possible
approach
to
introduce
the
values
of
the
event
domain.
So
to
summarize,
I'm
trying
to
to
basically
to
reuse
other
name
spacing
concepts
we
have
elsewhere
right
with
the
semantic
convention.
We
do
the
allocation
of
name
spaces
for
semantic
conventions,
so
I'm
trying
to
in
a
sense
piggyback
on
that
right.
So,
instead
of
introducing
a
new
process,
just
just
reuse
it.
A
So
if,
if
you
look
at
the
attribute
requirements,
it
already
says
that
it
always
has
rules
about
how
this
this
namespace
is,
are
part
of
semantic
conventions
how
the
company's
specific
ones
can
be
can
be
introduced.
I
think
this.
This
fits
well
right.
So
if
we
say
that
the
existing
name
spaces
where
they
conceptually
match
the
domain
of
the
event,
we
should
just
use
that,
but
I
think
it
kind
of
it
works
right.
So
kubernetes
we
have
k
as
a
prefix
for
browser
semantic
conventions.
A
We
have
browser
dot,
as
a
prefix,
I
think
seems
to
be
not
too
bad.
In
my
opinion,
and
when
you
have
something
new
to
add,
it
becomes
simultaneously
becomes
also
a
namespace
for
for
semantic
conventions
for
that
particular
domain.
So
you
can
add,
I
don't
know
if
we
want
to
kind
of
also
have
a
single
location
where
we
list
all
the
namespaces
and
all
the
possible
domains.
Maybe
we
can
have
tooling
around
that
that
verifies
it,
but
that's
that
we
can
discuss
if
we
want
to
do
that.
A
B
Right,
yeah,
actually,
I
think,
a
few
months
ago
we
from
the
the
client
instrumentation
said
you
know
we
wanted
to
define
a
resource
attribute
to
indicate
that
hey
this
telemetry
is
coming
from
mobiles
and
we
we
wanted
to
give
a
value
of
device
or
any
attribute.
You
know
if
it
starts
with
device.
We
want
to
consider
it
as
coming
from
mobiles
but
then
anthony
from
aws.
He
had
a
comment
that
we
don't
know.
B
You
know
if,
like
you
know,
this
semantic
convention
only
tells
you
know
one
set
of
things
right.
You
know
we
don't
know
if
others
like
you
know
other
devices
which
are
not
mobile
devices.
You
know
they
won't
be
using
it.
A
So
when
I'm
looking
at
the
existing
cement
interventions
in
the
device
namespace,
they
seem
to
be
all
about
mobile
devices.
Right
from
what
I
see
can
there
be
other
devices
non-mobile
devices
where
which
would
require
maybe
other
semantic
conventions
in
the
same
name
space?
Maybe
I
think
that's
fine
right,
even
in
that
case,
that's
fine.
If,
if
those
other
non-mobile
devices
want
to
emit
events,
they
can
also
use
that
as
event
domain.
B
I
think
the
examples
could
be
that
those
devices
you
know-
maybe
let's
say
on
board
devices
like
the
server
side
which
are
not
coming
from
the
internet.
They
they
are
completely
a
different
domain
like
let's
say
linux
devices.
B
So
so
I
think
the
only
thing
we
may
want
to
do
is
to
define
this
in
the
attribute
naming
spec
that
you
know
the
the
namespaces
are
kind
of
exclusive
to
the
domain.
A
Yeah
also
by
the
way
talking
about
the
devices
on
on
servers
or
stuff,
like
that,
there
is
another
proposal
for
hardware
metrics
which
uses
hw
as
a
prefix.
Okay.
For
for
the
metrics,
I
think
if
we're
talking
about
devices
like
that,
it
likely
is
going
to
be
in
that
particular
base
space,
not
not
in
the
device
name
space
but
more
of
the
the
hardware
bank
space
right:
okay,
okay,
it's
not
accepted,
but
it's
it's
a
proposed
pr.
There
right,
sorry,
yeah.
B
A
You
mean
for
the
device
yeah
for
the
for
the
device
dot.
Semantic
conventions
have
a
description
that
this
this
set
of
attributes
is
about
mobile
devices.
A
Yeah,
I
think
that's
fine,
either
way.
I
think
I
would
like
to
go
with
with
this
approach
right,
where,
instead
of
inventing
one
more
additional
way
of
introducing
a
set
of
unique
values,
we
already
have
one
right.
The
name
spaces
are
essentially
a
set
of
unique
values
for
which
we
have.
We
have
a
process
essentially
right,
it's
part
of
the
specification,
so
it's
guaranteed
to
be
kind
of
it's
kind
of
regulated.
A
It's
that
we
know
how
you
introduce
new
values
there
right,
you
submit
a
pr
which
introduces
the
semantic
convention,
so
I
think
we
can
just
just
make
the
event
domains
essentially
part
of
this
same
process
instead
of
inventing
a
new
new
one.
So
I
I
try
to
minimize
the
amount
of
new
new
processes,
new
concept
that
we
introduce
here.
We
essentially
say
that
the
event
domain
is
the
same
thing
as
the
namespace.
That's
it.
B
But
it's
it's
a
loose
binding
right
as
in
it's
not
a
compulsion
to
use
the
namespaces
like
we,
we
don't
know
right
in
the
future.
There
could
be
events
within
a
certain
domain,
but
within
a
certain
namespace,
but
you
know
they
belong
to
different
domains.
Are
typically
business
constructs
right.
I
think
the.
A
A
Can
there
be
a
future
one
that
doesn't
fit
it?
Maybe
yeah
possibly,
and
there
is
no
it's
fine.
We
can
adjust
the
rule
as
soon
as
we're,
not
breaking
the
semantic
conventions,
existing
ones
themselves,
it's
okay
to
adjust
the
rule
and
say
that,
yes,
this
is
another
domain
name,
but
it
does
not
have
an
equivalent
namespace.
For
example,
I
think
that's
okay,
okay,.
A
A
Yes,
cloud
providers.
I
think
they
have
their
own
top
level
name
spaces,
yeah,
yeah,.
C
A
A
D
A
D
Well,
I'm
not
I'm
not
sure
about
that.
Actually,
so
I
think
you
know
making
it
a
required
parameter
when
you
get
the
logger,
I'm
not
sure
that
that
that
fits
well
with
this
notion
that
we
have
where
a
logger
can
produce
yeah.
A
Okay,
I
guess
it's
kind
of
half
an
event,
truly
half
defined
event.
Okay,
yeah
I
mean
it's
fine.
I
I
don't
see
a
problem
with
that.
That's
okay!
We
say
that
if
you
want
to
emit
an
event,
make
sure
you
specify
a
valid
domain.
If
you
don't
know
what
to
specify
use,
your
company
name
use
your
application
name
or
whatever
right
you
use
the
other
one
of
the
other
rules
which
which
we
already
have
that's.
Okay.
I
I
think
it's
fine.
D
And
I
was
thinking
of
it
from
the
perspective
of
other
semantic
inventions.
We
have,
for
example,
the
http
semantic
conventions,
and
so
I
think
there's
some
required
attributes
on
there,
like,
I
think
http
method
is
absolutely
required
and
then
I
think
the
span
kind
has
to
be
server
for
http
server
spans
right,
and
so,
if
you
violate
those
rules
of
the
semantic
inventions,
then
this
fan
doesn't
represent
a
span
to
an
http
server.
D
So
I'm
thinking
of
events
in
a
similar
way
like
you,
can
still
produce
data
that
doesn't
have
an
event
domain,
but
like
systems,
I
don't
think
should
be
obligated
to
recognize
it
as
an
event.
Yeah.
B
Well,
I
think
we
can
make
it
a
requirement
for
the
implementations
to
if,
if
they
are
explicitly
creating
an
event
from
the
logger,
you
know
they
can
validate
that
both
the
fields
are
present.
Both
the
attributes
are
present.
A
So
you're
saying
it
should
not
be
a
required
parameter
for
obtaining
a
logger,
but
as
soon
as
you
try
to
emit
events
using
that
logger,
if
the
event
domain
is
missing,
you
just
fail
immediately
and
you're,
saying
yeah
the
event
domain
must
be
specified.
I
think
yeah
we
can
do
that
and
it
will
have
high
visibility.
So
it's
not
a
kind
of
a
surprising,
obscure
behavior.
D
And
we
do
something
similar
in
metrics,
where
we
have
naming
convention
rules
for
instrument
names
and
so
you're
only
allowed
to
use
certain
allowable
characters
in
instrument
names.
And
you
know,
if
you
violate
those,
you
can't
create
an
instrument:
yeah,
okay,
yeah.
A
B
And
and
if
anybody
is
using
them,
while
producing
logs.
B
Cases
you
know
that
people
had
in
mind
when
this
was.
I
think.
A
We
can
dig
some
examples,
but
to
me
it's
it's
fairly
obvious
that
there
are
data
sources
where
you
will
see
this
happening
really.
So
it's
it's
not
going
to
be
possible
to
represent
the
data
that
is
coming
from
some
some
external
sources,
maybe
not
produced
by
open
telemetry,
but
from
some
other
external
sources
they
will
likely
have
more
more
more
more
nesting,
more
more
more
complex
data
structures.
We
can
dig
some
some
some
examples
if
that
is
necessary,
are
you
so
why?
Why
are
you
asking?
B
E
Big
justification:
there
are
a
bunch
of
lugging
libraries
that
allow
objects,
like
you
know,
zap
bunion
in
javascript
mdc,
and
I
think
that
one's
log4j
I'll
allow
you
to
to
put
objects
which
in
turn
have
nesting
okay.
So
we
need
some
way
of
being
able
to
represent
that.
A
E
A
So
I
think
that's
that's
a
strong
justification.
You
may
receive
that
data
from
from
the
library,
so
you
have
to
do
something
about
it
right,
okay
and
the
ideally,
you
should
preserve
you
shouldn't,
try
to
flatten
or
do
something
like
that.
So
that's
that's!
That's
a
very
strong
reason.
I
don't
think
we
need
any
other
reason.
A
A
B
Yeah,
so
where
I'm
going
with
this
is
that,
if
there
are,
there
are
two
options
you
know
either
keep
the
map
support,
nested
structure
support
only
to
logs
are
extended
to
in
other
signals
as
well.
The
advantage
with
other
signals
is
extending
to
other
signals
is
that
the
implementation
becomes
simpler,
it's
common,
but
I
think
there
isn't
a
strong
motivation
outside
of
these
two
use
cases
that
we
have.
A
Yeah,
the
problem
is
that
there
isn't
a
use
case
for
for
non-log
data
types.
We
we
can't
actually
show
that
demonstrate
that
there
is
a
strong
need
for
nested
attributes
for
metrics
and
and
and
spans
right,
especially
for
metrics.
It's
probably
metrics
yeah
ridiculous,
but
for
spawns.
Maybe
I
guess
you
could
come
up
with
some
some
examples,
but
we
don't
have
existing.
I
guess
no.
B
There
is,
there
is
yeah
there
is
there
aren't
many,
but
there
is
let's
say:
http
headers,
request,
headers
and
responses
yeah.
B
That
that
is
one
and
the
use
case
that
we
have,
and
in
fact
it
today
it
is
only
for
the
so
basically
the
performance
data
performance
timing,
data
for
api
calls
made
from
the
browser
the
browser
provides.
A
set
of
you
know,
name
value
pairs,
saying
you
know,
dns
lookup,
you
know
took
this
time,
so
so
the
different
timing,
information.
B
You
know
the
browser
provides,
and
there
was
a
an
issue
to
asking
how
to
represent
similar
information
even
for
back
end
spans,
like
the
spans
created
by
the
backend
applications,
something
to
indicate
how
many
retries
the
client
made.
B
How
much
time
the
dns
resolution
take
took
so
things
things
like
those.
So
if
we
get
this
support,
it
will
be
helpful
not
just
for
the
client
instrumentation,
but
you
know
in
general
as
well,
but
the
use
cases
are
a
hand.
You
know
just
a
few,
not
not
many.
C
B
C
Data
yeah,
which
we
need
for
for
events,
but
you
know
considering
like
ajax
one
like
fetch,
currently
spans
an
attribute
on
there,
which
was
the
custom
data
which
was
nested,
would
be
useful.
C
As
opposed
to
creating
a
span
event
for
which
still
a
span
event
has
attributes
which
are
still
span,
attributes
and
that's
the
same
problem
at
the
very
minimum
span
span
event
attributes.
It
would
be
ideal
to
have
those
as
nested,
but
there
are
a
bunch
of
issues
open.
I
think
tigran's,
aware
of
them
all
trying
to
get
this
through
and
I'm
hitting
them
with
my
spec
clarification
as
well.
E
Yeah
I
wanted
to
share
suffer.net
for
logs
and
events
same
situation.
There.
Some
logging
frameworks
only
support
structure,
key
values,
other
support,
complex
types,
so
we're
also
investigating
like
how
we
can
support
that.
What
I
wanted
to
bring
up
for
spans
is
there's
one
exporter.
I
want
to
say
it's
zipkin,
where
it
says
like
nested
attributes
have
to
be
like
json,
so
we
have
some
weird
code
depending
on
our
exporter,
we'll
either
just
dump
a
two
string
of
anything.
That's
not
you
know
a
primitive
for
zipkin
we
do
json.
C
Yeah,
that's
that's
already
partially
defined
in
the
attributes,
definition
where
it
says.
If
it's
not
a
native
one,
it
talks
about
being,
it
should
be
jason,
and
I
elaborated
that
and
just
sort
of
said.
This
should
be
some
strategy
that
exporters
should
do,
should
use
and
the
zipkin
that
you
know
if
they're
saying
it
should
be
jason
their
strategy
is,
it
should
be
jason.
So
the
exporter,
I
think,
is
the
correct
place
that
any
flattening
should
occur.
E
C
Yeah,
I
have
to
support
them
for
with
javascript
for
both
app
insights
and
run
ds
for
that.
A
E
A
A
The
community
that
this
is
a
good
thing
to
do
for
traces,
then
it
still
remains.
Definitely,
I
believe
for
for
logs
for
events
and
then
then
then
it's
different
right
for
logs
and
events,
which
is
not
ideal,
but
then
it
is
what
it
is.
Yeah.
C
My
basic
approach,
which
I
tried
to
do,
is
one
big
pr
was:
let's
get
it
defined
for
logs
specifically
for
events
for
logs
and
then
let's
try
the
push
to
unify
span,
events
and
log
events,
which
means
span
event
attributes
we
want
nested
support.
At
least
that
was
the
approach
I
was
going
to
try
and
take
to
try
and
get
there,
but
I
think
it's
a
long
pole
to
get
there.
D
Do
you
think
that
we
would
you
know
part
of
this
conversation
has
been
that
it's
not
clear
that
a
lot
of
vendors
support
complex
attribute
types?
D
A
D
C
A
Right,
but
I
I
wouldn't
want
to
do
that-
I
kind
of
I
think
why
why
why
lose
you
lose
some
data
by
doing
that,
right
right?
Why
do
that?
Why,
when
we
don't
have
to
when
we
already
support
this
in
the
data
model,
we
support
it
in
the
protocol,
probably
most
or
or
the
vast
majority
of
backends
also
know
that
logging
can
be
complex
and
it
so
I
I
wouldn't,
for
the
sake
of
being
just
for
the
sake
of
being
consistent
with
traces.
I
wouldn't
want
to
do
this
to
the
law.
Yeah.
D
And
and
I
prefer
to
support
complex
attribute
types
as
well.
I
don't
like
the
idea
of
having
you
know
mixed
support
amongst
the
signals,
so
like
complex
types
for
logs
and
non
complex
types
for
metrics.
D
You
know
one
because
of
the
like
the
inconsistency,
so
the
the
cognitive
burden
of
users
to
to
have
to
be
aware
that
you
know
for
for
some
signals.
You
have
complex
types,
other
signals
you
don't
and
then,
on
the
implementation
side
as
well.
In
java,
we
have
an
app.
We
have
a
signal,
agnostic,
attributes,
representation,
and
so
it
would
be
challenging
to
be
able
to.
You
know,
have
a
version
of
that
for
for
logging
that
was
different
than
for
trace
and
metrics,
and
so
I
think
my
ideal
situation
is
to
support
complex
types.
A
A
That
probably
should
solve
it
right,
because
people
just
just
don't
want
to
see
this
becoming
the
normal
right
when,
when,
when
we
start
introducing
given
semantic
conventions
with
with
such
nesting
and
then
the
backhands
who
don't
handle
it
well,
are
at
a
disadvantage,
if
all
of
the
semantic
conventions
that
open
telemetry
defines
avoid
doing
that,
then
I
think
it's
fine
right
if
internal,
if
your
internal
implementation
in
java
allows
nested
attributes,
but
none
of
the
the
actual
semantic
conventions
use
it.
That's
okay,
right!
A
It
allows
you
to
simplify
your
code
without
complicating
the
life
of
the
vendors,
because
they
never
really
see
at
least
standard
emitted.
Telemetry
open,
telemetry
defined
telemetry
never
actually
uses
such
attributes.
If
some
weird
unknown
data
source
emits
it
okay,
so
b
right,
the
data
model
allows
it.
There
is
a
defined
way
to
to
flatten
it
deal
with
it.
I
mean
it's
not
end
of
the
world
right.
D
Yeah,
I
I
agree
with
that
and
just
as
you
were
talking,
something
occurred
to
me
that
it's
pretty
easy
for
vendors
to
have,
you
know,
be
able
to
ingest
this
data
in
in
a
really
naive
way.
So
you
know
you
have
this
complex
attribute
type.
You
don't
even
have
to
define
a
flattening
scheme.
You
can
just
serialize
it
into
json
into
like
a
json
map,
and
then
you
know
at
least
the
data
is
accessible
to
users,
even
if
it's
not
structured
in
a
way
where
you
can
decompose
and
query
on
it.
A
They
have
to
do
something
anyway,
because
you
receive
otlp.
You
have
to
be
ready
that
there
may
be
nesting
there
that
if
you
have
to
write
that
case
right,
you
need
to
do
something
about
it.
Maybe
they
ignore
it
today.
I
don't
know
that
they
return
an
error,
but
it's
not
terribly
complicated.
To
just
do
something
simple
about
it.
Just
just
do
the
json,
as
you
say,
or
just
to
flatten
it
using
some
of
the
rules
that
we
introduced.
A
I
mean
it's
doable
and
not
not
a
very
difficult
thing
to
do
right,
yeah,
so
probably
that
that
may
be
an
option
right
prohibiting
semantic
conventions
or
but
allow
it
in
the
data
model
it's
already
allowed
in
the
in
the
protocol
for
traces
and
metrics.
It's
the
same
definition
so
just
just
make
it
also
allow
it
for
sdk
implementations.
Essentially,
do
we
need
to
modify
the
api,
maybe
in
the
future,
but
we
don't
even
have
to
do
it
right
now.
We
don't
need
to
touch
the
tracing
and
metrics
api
today.
C
Yeah
so
far,
there's
not
a
lot
of
traction
on
the
spec
apart
from
push
back,
define
it
as
not
supported.
If
you
look
back
at
the
original
versions,
it
tried
to
encompass
all
this.
The
current
one
I'm
trying
not
to
slam
the
door
shut
effectively.
D
Just
that
you
know,
whenever
I
see
this
issue
pop
up,
I
have
to
re-remember
the
use
cases,
and
you
know
the
discussion
here
today
was
useful,
because
you
know
the
the
the
fact
that
the
logging
frameworks
pass
complex
types
as
is,
and
it's
our
job
to
to
map
those
into
the
open,
telemetry
log
data
model,
it
kind
of
it.
D
It's
it's
a
really
strong
use
case,
for
I
really
strongly
suggest
that
we
should
support
complex
attribute
types
instead
of
trying
to
do
some
sort
of
flattening
exercise
so
like,
if,
if
we
can
just
remind
folks
in
the
community
of
that
really
strongly
and
then
also
bring
up
the
the
situation
that
I
hadn't
thought
of
before
santosh,
that
you
brought
up
about
the
http
headers
so
that
you
know
that's
that's
a
good
use
case
for
spans
as
well.
You
know,
maybe
that
will
help,
make
it
more
clear.
Just
like
reinforcing
the
use
cases.
B
Yeah-
and
I
did
not
understand
when
you
said
that
we
don't
need
to
change
the
api,
so
it's
kind
of
implicit
right
like
api.
A
I
mean
the
tracing
and
metrics
api.
We
don't
have
to
it's
so
the
fact
that
it
is
allowed
in
the
in
the
protocol
the
fact
that
it
is
allowed
in
the
data
model
and
that
the
implementations
internally
allow
it
right
doesn't
also
force
you
at
the
same
time
to
change
the
api
or
it
it
essentially
is
going
to
be
a
new
set
of
apis
right
where
the
attribute
definition
is
slightly
different.
A
So
it's
work
that
I
don't
know
doesn't
need
to
happen.
Maybe
maybe
not
right
away.
I
mean
for
tracing
api
right
when
you
create
a
span.
There
needs
to
be
a
way
to
supply
this
new
kind
of
the
attribute
where
nesting
is
allowing
the
the
network,
maybe
is
necessary
in
the
future,
but
not
right
away
right.
If,
if
we
say
that
semantic
conventions
should
never
have
a
definition
like
that,
then
what's
the
need
right?
Why
do
people
need
an
even
api
to
create
data
like
that?
A
Not
not
from
open
telemetry
api,
you
can't,
but
maybe
from
some
other
data
sources.
The
collector
does
a
conversion
reads
from
some
other
protocol
format,
which
allows
nesting
or
read
through
data
from
somewhere
else,
where
the
nesting
is
possible
and
converts
it
to
otlp.
And
now
you
have
nesting
on
the
wire
right.
B
Well,
that
doesn't
help
us
as
in
like
we,
we
do
have
use
cases
where
that's
required,
even
for
spams
or
at
least
span
events
as.
A
B
We
put
this
all
in
a
tip,
including
examples.
C
B
Yeah,
I
think
that
that
pr
doesn't
talk
much
about
you
know
the
rest
of
the
stuff.
It
only
talks
about
the
changes
to
the
spec.
C
Yeah,
I
I
have
mentioned
the
reference
in
there
about
the
implementation
complexity
between
log
attributes
and
span
attributes,
and
you
know
I
know
in
javascript,
there's
already
it's
already
the
concept
of
a
span
attribute,
which
is
now
just
an
alias
for
attributes.
So
once
we
start
implementing
it,
sdks
are
going
to
have
this
problem
and
I
I
would
really
really
like
to
avoid
yet
another
type.
B
Yeah,
but
for
re
reviewers,
looking
at
your
pr,
I
think
they
probably
don't
have
the
full
context
that
we
here
are
talking.
C
Yeah
like
originally,
I
hadn't
had
the
context
in
there
because
I
I
said
I'm
trying
to
partially
fix
some
of
the
issues
as
described
in
376.
But
if
you
look
back
at
almonds
original
comments
effectively,
he
suggested
they
should
be
two
completely
separate
prs.
C
B
Yeah
and-
and
that
is
why
I
think
a
notep
with
full
background
and
context
would
be
helpful
to
you
know,
get
them
on
the
same
page
and
then
the
parts
would
flow
through
smoothly.
B
Okay,
I'll
I'll
connect
with
you
offline,
we
can
work
together
on
that.