►
From YouTube: 2022-09-21 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
B
A
A
C
A
couple
items
in
the
agenda
so
the
first
one
I
added
there.
There
is
a
proposal
from
Google
developers,
I
guess
to
add
a
new
structured
loading
library
to
to
go
I
think
it
was
an
interesting
read
there.
They
they
suggested,
to
be
structured
in
into
components
to
the
front
end
and
the
back
end,
which
which
works
well
for
us
right,
open
flange.
It
could
be
one
of
the
backends,
so
essentially
it's
the
same
model
as
the
appenders
in
log
4G
anyway.
C
I
did
take
a
look
at
the
proposal,
the
interfaces
that
they
are
expecting
to
be
implemented
and
I
prototyped
it
quickly
to
see
what
what
it
would
look
like
if
we
implemented
team,
open
television
go
SDK
and
based
on
that
I
provided
some
some
feedback.
One
interesting
thing
there
was
around
the
context.
How
do
we
deal
with
the
context?
C
There
is
probably
an
opportunity
here
to
to
see
they.
They
actually
support
context
as
one
of
the
parameters
to
the
logging
functions.
Then,
then,
essentially,
we
we
can
support
the
the
correlation,
the
addition
of
Trace
audience
when
I
need
to
log
records
automatically
when
you
use
open,
transfer
I.
Think
that
would
be
really
nice
to
do
so.
Anyway.
C
I
left
a
few
comments,
a
few
thoughts
there
in
my
comment,
if
you
guys,
are
interested
in
going
in
particular-
or
maybe
you
you
want
to
see
the
proposal
there,
I
think
it
would
be
useful,
maybe
to
review
and
if
you
want
to
add
something
from
the
open
calendar
perspective,
feel
free
to
do
that.
Maybe
comment
on
that
on
the
issue
there
on
the
thread:
yeah
I,
don't
know.
If
anybody
already
had
a
chance
to
see
this.
If
you
have
any
thoughts,
foreign.
C
D
The.Net
SDK
and
API
for
the
new
spec
changes.
One
thing
I
don't
see
is
like
specific
mentioning
of
when
you're
logging
an
exception,
I'm
assuming
we're
just
going
to
write
attributes
like
exception.type
exception.message
exception.
Dot
stacktrace
should
I
just
open
a
PR
and
a
spec
with
like
semantic
conventions
in
the
logs
folder.
Have
we
has
anyone
kind
of
thought
through
this
or
I
assume
that's
what
we'll
end
up
doing?
Should
I
just
throw
a
PR.
C
C
C
We
do
have
that
as
a
special
recommendation
for
for
the
traces
spec.
We
have,
how
you
add
an
exception
as
an
event
to
a
Spam,
but
that's
that's
specific
to
spam
events,
and
we
likely
need
to
be
consistent
there
and
do
a
very
similar
thing
for
Standalone
log
records,
but
it
still
needs
to
be
somewhere
in
the
spec.
You
know,
even
if
it's
exactly
the
same
thing,
that
we
do
here.
D
So
what
I
did
is
I
think
for
traits,
as
it's
called
it's.
We
have
like
a
record
exception.
It
might
just
be
a
helper
and.net,
but
it
basically
just
adds
that
event
and
make
sure
it
has
the
right
attributes.
D
So
I
was
just
going
to
do
the
same
for
our
login.
Api
I
would
just
have
an
extension
called
record
exception.
If
you
happen
to
have
the
SDK,
you
can
call
that
if
you're
just
coding
against
API,
it
would
just
be
on
you
to
do
it
correctly,
but
I
think
it
is
a
very
common
scenario.
It
might
be
worth
having
it
just
in
the
API
itself,
but
up
to
you
guys.
C
I'd
say:
let's
start
by
adding
the
semantic
convention
there
and
let's
be
a
bit
more
conservative
about
adding
new
apis.
C
Yeah
I
guess
I,
don't
know
if
there
is
any
other
option
other
than
being
doing
exactly
the
same
thing
as
we
do
work
for
the
span
events.
Is
there
a
reason
why
we
would
want
to
deviate
from
that
like
try
to
be
aligned
with
some
other
standard
I,
don't
know
with
the
elastic
common
schema
or
something
like
that
if
they
have
any
notion
of
recording
exceptions
in
the
logs
foreign.
B
Well,
yeah,
it's
part
of
the
rum
Sig.
We
do
have
the
JavaScript
exceptions
that
we're
going
to
have
to
fire.
We
haven't
got
through
defining
that
yet,
but
we
were
thinking
of
following
the
just
the
general
somatic
conventions
potentially
as
well,
so
that
would
be
a
log
event.
E
Yeah,
you
know,
maybe
we
can
just
take
advantage
of
our
time
together
to
to
work
this
out
a
little
bit,
but
you
know
there's
the
question
of
whether
the
exception
is
just
a
regular
log
record
and
its
components
are
added
as
attributes
on
the
log
record
or
if
it's
an
event
with
a
domain
and
name.
E
If
we
follow
the
convention
of
what
were
happening
in
tracing,
then
it
would
be
it'd
be
an
event,
and
so
you
know
we'd
have
to
give
it
a
name.
I
think
the
name
is
pretty
straightforward,
but
the
the
domain
I
think
is,
is
Up
For
Debate.
D
So
the
apis
I'm,
looking
at
they're,
pretty
similar
to
like
just
a
normal
log
call.
You
know
you
can
add
a
message
and
then
you
just
hand
it
the
exception.
So
what
I'm
going
to
do
is
I'm
just
going
to
write
a
log.
You
know
with
whatever
message
the
user
gave.
They
can
add
their
own
attributes
to
it
if
they
want
and
then
for
the
exception.
I
would
basically
just
decompose
it
into
the
three
attributes.
With
the
semantic
convention.
You
know,
exception.type
exception,
dot,
aim
exceptions
on
stack
if
I
have
to
split
them.
D
E
Yeah
I
agree,
and
you
know,
because
of
the
way
that
the
API
is
designed
right
now,
where
you,
when
you
emit
events,
you
have
to
assign
the
domain
to
the
logger
when
you're
obtaining
it.
It
would
be
a
bit
awkward
if
you
had
to
obtain
a
separate
logger
with
the
exception
domain.
C
E
I'm,
just
assuming
that
you
are
you,
you've
acquired
a
a
logger
and
maybe
it
doesn't
even
have
a
domain
because
you're
just
emitting
regular
log
records-
and
you
decide,
like
an
exception,
happens-
and
you
want
to
you-
want
to
emit
an
event
for
that.
So
you
know
in
that
case
there
would
be
no
domain
assigned
to
your
logger
at
all
correct.
C
You
can
record
you
can
have
a
log
record,
which
has
exception
Dot
attributes,
and
that
would
be
an
exception,
and
that
would
be
a
log
record
that
describes
an
exception
whether
it's
a
media
there's
a
log
record
or
whether
it's
emitted
through
the
events
API,
doesn't
really
make
a
difference
right.
It's
still,
it's
still.
A
log
record
that
represents
represents
an
exception.
C
F
Think
that's
fine.
It
seems
like
you'd.
Probably
do
it
differently,
depending
on
the
context.
So
if
you've
got,
if
you
know,
if
it's
in
a
log
call
where
you're
actually
passing
in
the
exception
as
context,
it
would
just
be
an
attribute,
but
if
you
registered
an
exception
Handler
at
the
top
level
of
your
call
stack,
it
just
catches,
anything
that
happens
to
get
up
to
it,
but
that
seems
like
it
would
definitely
be
an
event.
So
it
seems
like
their
uses,
for
both
cases
yes
could
be
either
I
agree.
F
E
And
furthermore,
right
the
the
trace
API
today,
you
know
it
has
this
idea
of
events
that
you
attach
to
spans,
and
you
know
the
the
one
of
the
main
purposes.
I.
Think
of
adding
the
event
API
for
logs
was
to
you
know,
kind
of
replace
that
in
a
way
or
maybe
not
one
of
the
main
purposes,
but
that
was
that
was
a
thought.
E
Is
that,
like
span
Advance
should
be
able
to
be
use
the
log
API
instead,
and
so,
if
we're
saying
that
an
exception
is
an
event
in
the
span
world,
but
not
an
event
in
the
log
world,
it's
just
not
very
consistent.
F
But
like
I
said,
I
think
it
depends
a
lot
on
the
context
that,
if
the
mean
piece
is
a
log
message
like
you
know,
just
in
in
terms
of
like
hey
I
caught
this,
this
I
wasn't
able
to
connect
to
the
database.
I
know
what
that
means.
I
know
what
to
do
about
it.
I
just
want
to
log
that
this
happened
right
and
then
the
exception
might
be
something
you
would
add
as
context.
So
it
wouldn't
be
the
primary
piece.
F
C
F
Well,
I
I
think
our
our
you
know
what
I'm
saying
is
that
I
think
that
the
existing
system
that
we
have
fits
both
those
use
cases
and
both
those
use
cases
are
valid.
F
So,
in
both
cases
you
know
you
would
have
an
event
with
the
resource
attribute
pair
with
an
exception
attribute-
or
you
would
have
a
log
record
with
an
exception
attribute
like
the
data,
would
look
exactly
the
same.
It
would
be
a
difference
in
whether
you
send
it
through
the
events
you
know
side
of
the
API
or
the
logs
inside
of
the
API
I
think
both
make
sense.
E
F
Absolutely
but
but
that's
kind
of
what
I'm
meaning
is
that
the
the
exception
side
of
that
exception?
Part
of
that
would
still
be
in
the
same
place,
but
you
know
if,
if
you're
looking
at
an
unhandled
exception
yeah
you
would
you
would
register
that
as
an
event,
you
would
go
through
the
events
API
it
would.
You
know
it's
an
event,
but
the
you
know
where
we
would
record
it
and
how
we
would
record
it
in
the
actual
data
structure
would
be
identical.
B
Yeah,
which
I
I
guess
from
the
rum
side
of
things
with
events,
we
are
considering
having
an
event.data
which
would
be
a
nested
attribute
blog.
So,
in
the
case
of
where
you'd
say,
the
event
name
is
exception,
event
data
would
be
potentially
I'll
say
potentially
because
we
haven't
decided
anything
yet
on
this,
where
the
message
the
stack,
trace
and
any
breakdown
stuff,
you
might
have
versus
the
existing
semantic
conventions
that
are
unlocked.
So
we
haven't
just
one
thing.
Potentially
we
haven't
got
to
that
point
before
this
particular
event.
Yet,
yes,.
F
B
F
And
I
know
it's
been
like
a
year
and
a
half
ago
now,
but
we
we
did
go
around
and
around
about
you
know,
exceptions
and
whether
they
should
just
be
a
string
or
whether
they
should
be
a
you
know.
There
should
be
a
data
model
for
it
so
I
mean
I,
guess
it
would
make
some
sense
to
have
the
ability
to
have
either
in
place.
I
don't
know
every.
Maybe
it's
something
we
should.
We
should
talk
about
again.
F
Well,
I'm,
looking
you
know
right
now:
we
don't
have
a.
We
don't
have
a
logs
exception
convention
or
convention
already,
but
you
know
in
the
the
traces
the
stack
trades
is
always
a
string
and
then
yeah
in
some
languages.
It's
really
expensive
to
to
decompose
that
other
languages.
They
they
really
want
to
be
able
to
deal
with
each
frame
individually.
F
So
it
I,
don't
know
if
it
makes
sense
to
have
an
either.
You
know
either
stack
Trace
string
or
list
of
frames.
You
know,
structure
that
yeah.
C
F
C
Okay,
anyway,
let's,
let's
talk
small
for
now,
let's,
let's
file
an
issue
or
a
PR
to
make
sure
we
have
the
conventions
for
the
exceptions
for
Standalone
log
records.
I
think
that
that
should
be
the
first
step.
Let's
start
with
that,.