►
From YouTube: 2022-04-13 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
So
the
second
one
is:
we
have
this
new
new
section
logs
section
in
the
specification
compliance
matrix
and
I
think
java
has
completed
it.
I
will
post
a
link
here
in
case
you're
curious
what
is
implemented
and
is
not
implemented,
and
I
ask
the
other
languages.
Python
and
dotnet
also
fill
in
the
matrix.
So
we'll
see
what
exactly
works
so
far
and
what
is
not
yet
implemented.
I
think
it's
good
to
keep
track
of
the
features.
A
I
just
wanted
to
understand
whether
the
recent
changes
he's
making
he
made
to
the
log
collection
library
are
already
propagated
in
using
the
collector
and
whether
it
uncovered
any
issues
and
if
not,
I
think
we
should
probably
move
forward
and
make
the
declaration
of
the
stability
of
the
protocol
well,
unless
anybody
has
any
other
thoughts,
maybe
you
can
comment
on
the
issue
in
that
case
anyway,
so
I'll
skip
that
one
for
now.
Let's
move
to
the
last.
The
third
item
in
the
agenda
guidance,
history
of
log
field,
mapping
formats.
A
What
is
the
question
about
who?
Who
added
it
to
the
agenda.
A
A
B
Hi
yeah,
so
I
just
had
a
question
about
these.
Some
of
the
structure
of
the
fields
for
some
of
these
mappings
so
for
some
context.
I'm
working
on
the
google
cloud,
logging
exporter
and
so
looking
through
some
of
these
fields.
It
looks
like
they
specifically
for,
like
the
google
mappings
recommend,
attribute
names
like
com.google.log
name,
and
I
saw
some
of
them
also
with
like
the
splunk.
B
Htc
follows
that
kind
of
same
pattern
like
com.splunk.source
and
was
talking
about
this
with
our
team,
and
we
were
wondering
if
there
is
any
reason
to
take
this
sort
of
like
java
style
structure
for
company
specific
fields
versus
if
there
would
be
an
aversion
to
changing
these,
to
be
more
like,
like
gcp.log
name,
to
be
kind
of
more
aligned
with
some
of
the
semantic
conventions
from
trace
and
the
other
metrics.
So
just
kind
of
hoping
that
there
could
be
a
little
bit
of
background
on
these.
B
And
if
there's
any
opening
to
change.
A
Those
yeah
yeah,
the
the
attribute
naming,
is
actually
part
of
the
specification
I'll
post.
The
link
here
in
zoom
chat,
if
you
open
that
it
says
that
any
vendor
specific
attributes
should
use
this
reverse
fk
fqdn,
essentially
as
a
prefix
for
the
attribute
names.
A
A
So
in
that
case
he
will
have
more
more
natural
names.
Like
we
do
service
talking
stunts
right,
it's
not
fender
specific,
really,
whether
for
the
cloud
providers
we
should
use
the
entire
full
company
name
or
just
the
cloud
name
abbreviation
is
good
enough.
I
think
it's
a
good
question.
Maybe
we
should
maybe
make
that
proposal
and
yeah-
probably
I
don't
know
it's
hard
to
tell,
but
for
now
the
reason
is
that
it
follows
the
specification
recommendations.
B
Okay,
yeah,
that's
really
helpful.
That's
pretty
much
exactly
what
I
was
looking
for,
so
it
sounds
like
if
I
put
together
maybe
a
proposal
just
for,
like
you
said
the
provider
abbreviations,
and
maybe
I
can
get
some
more
feedback
in
doing
that-
that
it
wouldn't
be
totally
opposed.
A
Yeah,
I
think
it's
reasonable
to
have
shorter
prefixes,
for
I
guess
widely
used
cases
right,
so
I
I
personally
wouldn't
be
opposed
to,
and
I
think,
if
you
look
at
the
semantic
conventions,
there
may
already
be
cases
where
cloud
providers
use
specific
namings,
maybe
not
for
the
attributes,
but
at
least
for
the
values.
So
maybe
just
have
a
look
at
what
exists
there
in
the
semantic
conventions
and
how
the
cloud
provider
specific
attributes
are
made
there
I'm
pretty
certain.
There
is
something
that
is.
B
There
are
that's,
that's
kind
of
what
drew
our
attention
to
it
is
why
I
was
wondering
why
the
logging
mappings
were
different
from
those
semantic
conventions
that
just
use
gcp
and
aws,
and
so
maybe
I'll
get
together.
Yeah.
A
Maybe
open
the
open,
an
issue
there.
We
should
discuss
that
and
maybe
just
make
it
explicit
that
cloud
providers
use
this
other
naming
approach
without
the
they
need
to
have
the
full
company
name
as
a
prefix
cool.
Thank
you.
C
Yeah,
so
this
goes
to
semantic
conventions
as
well,
and
I'm
just
like
mentioning
here
because
I'm
I
wanted
to
like
to
to
to
to
give
like
say
a
transparency
on
that,
but
we
have
semantic
conventions
essentially
on
them
on
two
levels
of
attributes.
We
have
semantic
conventions
for
resource
level
attributes
and,
of
course,
those
are
common
for
locks,
metrics
and
traces
like
each
signal-
and
this
includes
like
useful
information
about
the
cloud
provider
like
what
we've
been
just
discussing
or
about-
let's
say
host's
name
or
maybe,
let's
say
fuzz
or
what?
C
What
not,
but
what
we
also
have
record
level
semantic
conventions
and
those
are
probably
most
advanced
for
traces.
Where
we
have
semantic
conversions
for
database,
we
have
semantic
conventions
for
http
and
etc.
Then
we
have
some
semantic
conventions
for
for
metrics.
Again
we
have
semantic
conventions
for
http
exam,
for
example,
and
the
attributes
largely
match
those
that
are
like
present
for
for
for
logs
for
for
for
traces.
C
But
we
don't
really
have
attribute
related
semantic
conventions
for
logs,
and
I
think
that
in
principle
we
want
to
treat
all
three
signals
in
a
similar
way.
You
know
telemetry.
So
if
there's
like
a
semantic
convention
for
some
attribute
in
tracing,
we
could
anticipate
that
this
is
a
valid
semantic
convention
for
for
metrics
and
for
logs
as
well
for
logs
the
case.
That
is
that,
due
to
the
cardinality
considerations,
some
of
the
attributes
are
like
not
but
welcome,
essentially
in
in
the
metric
attribute.
C
But
this
this
is
not
true
for
logs
and
there
was
an
effort
and
tigran.
I
think
that
you
know
this
one.
This
is
like
in
23
97
about
essentially
making
a
new
structure
from
the
semantic
conventions
that
will
to
take
this
into
account
and
and
the
semantic
conventions
for
for
records
will
be
not
organized
by
the
type
of
the
signal,
but
by
the
category
of
the
of
the
convention
so
like
for,
for
for
database
for
for
sql
and
and
and
things
like
that.
C
So
I
think
that
this
is
so
I'm
bringing
this
up
as
as
a
gap.
I
think
that
for
locks
specification,
that
we
don't
have
those,
and
I
think
that
the
call
to
action
will
be
to
restart
or
continue
the
work
that
that
tetsuo
was
making
on
on
adding
this
making.
This
change
to
how
semantic
conventions
are
like
described
for
for
the
level
attributes.
A
Yeah,
I
totally
agree.
I
think
we
need
to
do
this
for
for
traces
and
logs
the
vast
majority,
if
not
all
of
the
attributes
are
likely
going
to
be
shared.
There
is,
if
you
look
at
the
tracing
and
metrics
attributes,
there
are
some
that
have
differences,
but
it's
the
minority.
I
think
so.
I
completely
agree.
A
We
need
to
have
a
more
more,
I
guess,
uniform
structure
for
defining
the
semantic
conventions
and
then
explicitly
mark
the
differences
as
exceptions
rather
than
the
current
approach
is
to
just
duplicate
things
between
the
signals,
and
I
don't
think
it's
a
good
approach.
I
think
the
only
reason
we
didn't
do
this,
I
don't
think
anybody
was
against.
This-
is
just
that.
We
nobody
actually
took
ownership
and
move
forward
with
it
right.
A
It
requires
to
make
changes
to
the
semantic
conventions
generator
in
particular,
because
it
currently
relies
on
the
existing
directory
structure
and
then
uses
the
yaml
files
as
an
input
to
then
produce
markdowns
human
readable
markdowns.
So
this
needs
to
be
changed
as
well,
but
yeah.
I
completely
agree
with
you
with
with
the
notion
of
that.
This
is
important
to
do.
If
anybody
has
time
and
want
to
take
it
like
and
work
on
this,
it
would
be
great.
A
So
yeah,
I
don't
know
what
I
what
else
I
can
do
other
than
to
upvote
one
more
time,
the
the
issue
that
you
opened
and
maybe
encourage
people
to
if
they
are
interested
to
work
on
this.