►
From YouTube: 2023-03-15 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
Yeah
sorry
Jack
too
I
still
haven't
had
a
chance
to
comment
on
your
event,
usage,
PR,
yet
issue.
B
B
Well,
Trask
isn't
here
today
or
not
Trask
tigrant,
so
I
can
share
my
screen
and
just
kind
of
guide
us
along.
B
So
the
link
that
I
posted
is
from
a
comment
by
Trask
Trask
is
asking
about
a
specific
part
of
the
of
the
logs
readme,
where
we
talk
about
Legacy
compatibility
for
Trace
context,
and
this
essentially
says
that
if
you're,
if
you
want
to
include
Trace
context
in
in
a
log
pattern,
you
know
and
you're,
not
using
the
log,
API
or
SDK,
to
emit
those
logs
over
over
otlp
that
you
should
include
the
trace
contacts
using
these
inventions.
B
Trace
underscore
ID
span
underscore
ID
and
Trace
underscore
flags,
and
you
know
the
point
that
he
brings
up
is
that
the
underscore
casing
of
that
is
not
the
same
as
what's
used
in
in
ECS
elastic
common
schema
and
there's
a
there
in
case
folks
aren't
aware:
there's
a
proposal
right
now
to
merge
ECS
into
open
Telemetry,
and
so
the
question
is
essentially
should
we
align
with
ECS
on
this
before
we
Mark
the
document
as
stable
I
think
that
this
could
be
a
good
idea,
but
I
also
don't
think
that
this
is
actually
relevant
to
the
the
main
things
that
we
want
to
stabilize,
which
is
you
know
the
logs,
Bridge,
API
and
SDK,
so
I
wouldn't
want
to
block
or
gate
stability
based
on
coming
up
with
the
decision
of
these
I.
B
Think
I
would
be
in
favor
of
taking
this
Trace
contact
Section
and
in
moving
it
to
somewhere
else.
It
kind
of
seems
like
a
semantic
conventions
of
sorts,
but
you
know
it's
it's
it's
not
entirely
like
the
other
semantic
conventions
that
we
have,
because
it
doesn't
really
say
how
to
represent
data.
You
know
in
the
otlp
format,
so
it's
kind
of
different
in
that
respect.
B
C
So,
apologies
for
possibly
not
understanding
the
background
here,
but
I
thought
that
Trace
ID,
you
know
the
the
mixed
case
with
no
underscore.
That
was
what
was
actually
specified
in
the
logs
data
model.
So
I'm
not
sure
I
understand
what
the
difference
and
the
distinction
here
between.
B
So
the
Legacy
the
Legacy
situation
is
referring
to
is.
B
It
is
referring
to
a
case
when
you're
not
able
to
translate
your
logs
into
you
know
when
they're
emitted
from
The
Source
in
an
application
you're
not
able
to
translate
those
to
the
otlp
representation,
you
continue
to
just
log
them
out
to
the
console
or
to
files
in
in
you
know
whatever
Legacy
format
you're
using
and
so
in
those
cases
it's
you
know,
you
still
have
Trace
contacts
that
may
be
available,
because
you
know
the
open,
Telemetry,
Trace,
API
and
SDK
are
being
used,
but
you
know
you
you're
not
able
to
actually
translate
them
to
the
the
open,
Telemetry
representation,
and
so
you
know
the
the
details
in
the
log
data
model
where
we
say
Trace,
ID
yep
these
these
aren't
actually
relevant.
B
So
this
this
you
know
describes
the
fields
on
the
log
record
Proto.
So
you
know
this
is
essentially
the
data
model
for
log
records
when
they're
translated
to
the
open,
Telemetry
format.
But
you
know
this
Legacy
situation.
They
never
make
it
to
the
the
new
format
they're.
Just
you
know,
regular
old
logs
on
the
console.
C
So,
and-
and
forgive
me
again
if
this
is
not
an
appropriate
place
to
ask
this
question,
but
if
we
are,
if
we
have
we're,
let's
say,
for
example,
we're
using
log
for
J2
we're
using
a
a
the
the
the
I,
the
ability
to
change
it
and
specify
you
know
with
using
the
class
path,
you
can
specify
the
Json
format
and
what
we
were
doing
was
we
were
trying
to
match
the
logs
the
the
Otep
logs
data
model
and
emit
that
Json
format.
B
So
that
it'll
it'll
be
pretty
difficult
for
you
to
actually
have
a
properly
encoded.
B
You
know:
Json
object
that
you
know
represents
the
data
model
perfectly,
so
you
know
just
to
give
you
an
example
of
what
that
would
look
like.
So
if
you
actually
want
to
have
a
log
record
that
is
encoded
in
you
know,
otlp
in
its
Json
encoding,
the
what
that
would
kind
of
look
like
is:
let's
go
to
the
protocol.
Let's
go
to
the
file
exporter,
so
this
document
describes
like
if
you
want
to
encode
metrics,
logs
or
traces
in
the
otlp,
Json
representation
and
just
like
print
them
out
to
your
console.
B
B
I
think
it'll
be
pretty
difficult
for
you
to
replicate
this.
You
know
just
using
the
the
log4j
Json,
the
the
Json
appender
I
think,
is
what
it's
called
and
so
yeah
like
what
you're.
Essentially,
doing
is,
if
we
go
back
to
the
logs,
read
me
in
this
Legacy
section
down
here.
This
is
saying:
like
hey,
you
just
have
a
you're
encoding,
your
logs
in
some
sort
of
Json
representation,
where
you
specify
the
key
value
pairs.
It's
not
the
open
telemetry.
B
You
know
Json
encoding
of
the
of
the
logs
protocol
buffers
it's
just
something
else
that
you've
come
up
with.
If
you
do
that,
then
this
this
section
of
the
document
says
that
you
should
encode
Trace,
ID
and
span
ID.
You
know
like
this
with
the
the
snake
case,
format,
okay,
and
that
we
don't
really
say
anything
about
the
other
fields
in
the
log
data
model.
In
terms
of
casing.
C
B
Well,
so
it
doesn't
sound
like
anybody
has
any
strong
opinions
about
where
this
Trace
contacts
and
Legacy
formats
portion
of
the
document
should
live
and
whether
it
should
be
part
of
stability,
I'll
open
an
issue
and
propose
that
we
move
it.
So
we
can
have
the
discussion
offline.