►
From YouTube: 2022-03-30 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).
B
C
So
we
martin-
and
I
you
know
we
are
working
on
the
client-side
telemetry
for
the
mobile
and
browser
monitoring
mobile
applications.
So,
given
that
we
have
decided
to
use
the
log
data
model
to
represent
events
in
in
the
client-side
telemetry,
we
were
wondering
how
to
go
about
the
apis
that
we
could
use
there,
and
I
noticed
that
there
is
no
separate
logging
api
currently
right.
You
know
there
is
some
log
emitter,
that's
available
in
the
sdk,
but
that
is
to
be
used
only
by.
C
You
know
logs
into
the
otlp
model,
but
for
events
I
think
we
will
have
to
expose
some
api
to
the
end
users,
the
developers
and-
and
so
I
was
thinking
you
know,
to
use
the
same
interface
but
but
call
it
an
you
know,
an
event,
emitter
and
and
also
limit
the
and
also
limit
what
all
fields
you
know
we
could
set.
You
know
using
that
api,
because
a
lot
of
fields
are
are
specific
to
logs
like
severity
and
a
few
others.
C
So
the
event
builder,
you
know,
may
have
only
those
options
to
set
fields
that
are
applicable
to
events
which
is
which
is
the
trace
id
and
the
span
id
and
and
and
mostly
just
the
attributes.
C
So
I
wanted
to
get
some
thoughts.
Is.
Is
this
okay
to
go
in
this
direction
or
do
you
have
any
thoughts
comments.
B
By
people
who
implement
appenders
or
whatever
it's
called
for
other
logging
libraries
and
is
not
intended
to
be
end
user
callable.
So
this
is
what
what
you're
proposing
is
is
going
to
be
actually
end
user
callable,
so
something
that
is
the
equivalent
of
our
traces
or
metrics
apis,
but
for
logs
right.
So
it's
going
to
be
open.
Telemetries
logging
lower
logs
api
for
end
users.
I
think
it's
it's
very
useful.
B
It's
going
to
be
very
useful
to
model
this
to
try
to
make
it
consistent
with
the
other
I
mean
it's
obvious,
but
with
the
with
the
traces
or
metrics
apis
where
it's
applicable.
B
I
am
I'm
not
sure
if,
if
you
did
this
exercise
or
no,
if
no,
then
that
it's
worth
going
over
the
the
existing
traces
api
to
see
like
what
does?
How
does
thing
things
work
for
first
plans
and
then
try
to
model
around
that.
B
So
I
guess
maybe
one
of
the
important
questions
to
answer
this
is
do
we
do
we
want
this?
Do
we
need
this
where,
where,
where
is
the
what's
the
situation,
when
you
cannot
use
the
approach
that
we
already
have,
which
is
using
existing
logging,
libraries
with
appenders
that
go
to
to
the
loaning
sdk
and-
and
I
think
that's
the
important
question
right?
If
we
have
a
good
answer
to
that,
then
I
think
yes,
we
can
move
forward
with
this,
and
also
in
some
some
languages.
B
There
is
not
even
a
canonical
single
most
used
logging
library-
even
right,
so
you
probably
do
want
this
in
some
languages
anyway.
So
I
don't
think
anything
prevents
us
from
moving
forward
with
this,
but
essentially
we're
good.
We
need
to
go
through
a
similar
access
exercise,
as
we
did
when
we
were
designing
the
specification
for
the
traces
or
for
spams
the
api
for
traces
or
spans
right.
So
it
probably
can
happen
a
bit
faster
because
we
can
build
on
top
of
that.
B
Try
to
to
reuse
borrow
the
concepts
that
that
already
exist
there
for
spans
and
just
adopt
them
for
for
logs
some.
I
guess
secondary
comments
is,
why
do
we
need
to
call
it
events
and
not
logs
api?
Is
there
are
we
if
we're
making
the
distinction?
If
we
specifically
believe
that
they
are
different,
then
we
need
to
describe
somewhere
how
they
are
different
from
the
end
user's
perspective.
C
Yeah
I
haven't
written
down,
you
know
all
the
details,
so
I
just
wanted
to
you
know,
get
some
initial
thoughts
and
and
if
it
looks
okay
to
go
in
this
direction,
I'll
I'll
write
it
up.
Yeah.
B
To
answer
the
second
question:
you
have
here
the
the
emitter,
the
the
exporting
pipelines
that
we
have
they
are
supposed
to
to
do
botching
per
resource,
and
I
think
they
do
that
for
spans,
and
I
think
they
should
be
doing
this
for
the
logs
as
well.
Right
now,
I
don't
know
the
actual
implementations.
Do
that
or
no,
but
they
are
supposed
to
be
doing
that
right.
So
you're
right,
it's
inefficient
to
export.
C
So
for
spans,
are
you
saying
that
the
batch
exporter
collapses
are?
Do
you.
B
B
You
also
said
one
thing
about
the
events
api.
Let's
assume
it's
different,
some
of
the
fields
that
you
think
that
that
they
are
not
applicable
to
the
events
may
not
be
available
for
setting
like
severity
right.
B
Is
that
the
only
reason
we
believe
events
are
different,
or
there
are
other
reasons
as
well.
Is
it
because
you
have
the
event
name
as
one
of
the
central
concepts
here?
Is
it?
Is
it
the
driving
factor
behind
the
separation
or
because
there
is
many
fields
that
are
not
applicable?
I
mean
those
all.
Those
things
are
optional
right.
You
don't
have
to
set
them
log
record.
B
D
C
Yeah
agreed,
I
think
then,
maybe
whether
you
know
the
logs
side
from
the
log
site.
Do
you
want
to
expose
an
end
user
callable
api?
You
know
if
you
don't
want.
If
you
think
that
could
be
confusing,
then
you
know
we
could
limit
it
to
events
but
yeah.
Otherwise,
maybe
it
could
be
the
same.
B
I
think
we
introduce
sorry
if
we
introduce
the
events
api.
I
think
it's
well,
it's
the
majority
of
the
work
that
we
need
to
do
right.
Why?
Why
not
call
it
logs
api
anyway
right?
What's?
Why
are
we
disguising
it
somehow
trying
to
hide
the
fact
that
we
essentially
have
a
way
for
the
end
user
to
call
some
sort
of
an
api
and
have
log
records
emitted
yeah,
I'm
not
opposed
to
actually
naming
it
logs
api
and
having
our
own
logging
api.
This.
B
B
B
E
I
was
just
gonna
a
couple
couple
things,
so
I
think
on
the
back
end,
we
want
to
be
able
to
distinguish
regular,
regular
logs
from
from
events
and
we're
proposing.
E
Yeah
and
yeah.
So
if
we
had
an
events,
api-
and
you
know
the
the
way
to
distinguish
them-
would
be
by
having
some
semantic
conventions
about
like
what
exactly
defines
an
event
and
so
having
that
event,
api
would
would
take
care
of
it
automatically.
E
So,
like
the
the
end
user
would
not
be
wouldn't,
wouldn't
have
to
worry
about.
Instead
of
like
adding
an
attribute
to
the
list,
they
would,
they
would
just
have
an
api
with
the
name
of
the
event.
That
would
automatically
add
the
attribute
behind
the
scenes.
C
Yeah,
I
think
it's
something
similar
to
what
I
did
here,
where
you
know
there
could
be
an
another
helper.
You
know
api
helper
library,
you
know
where
you
just
say
add
event
in
the
event
name
and
the
bunch
of
attributes
and
then
it
could
set.
D
F
It
really
depends
on
the
context
and
it's
kind
of
a
spectrum,
and
it
depends
on
kind
of
more
how
you
look
at
it
rather
than
than
the
payload
so
making
an
arbitrary
distinction
between
the
two
of
them
is
probably
going
to
put
somebody
put
the
wrong
people
in
or
put
somebody
on
the
wrong
side
of
the
fence,
but
you
know
one
way
or
the
other.
F
The
other
thing
I
just
kind
of
historically
wanted
to
put
up
is
that
we've
gotten
an
awful
lot
of
pushback
and
I
think
rightfully
so
that
we
shouldn't
create
another
slf
or
j,
that
you
know
open,
telemetry,
shouldn't
barge
into
the
java
world
or
whatever
world
and
say,
hey
here's
a
new
logging
framework.
F
F
How
to
distinguish
events
from
logs
and
more
distinguish
this
api
from
a
logging
api,
because
I
think
that
you
know
if
you've
got
a
cloud
service
that
wants
to
send
off
events
as
people
log
in
that's
not
really
a
log,
that's
really
an
event,
and
there
isn't
really
a
great
event
api.
So
if
this
can
send
logs,
but
what
it's
aimed
at
is
events
that
might
be
something
that
would
be
useful
if
that
makes
sense.
F
So
it's
more
of
a
you
know,
to
my
mind
at
least
events
and
logs
are
more
about
the
intent.
Is
this
something
that
I'm
recording
happened,
or
is
this
something
that
you
know
goes
into
some
input
streams
more.
C
I
I
agree
on
the
api
part,
but
I'm
not
very
clear
on
the
distinction
that
it's
not
required.
Can
you
tell
me
more
about
that
because,
on
the
back
end
we
do
want
to
process
events
and
logs.
You
know
differently,
so
it
would
be
good
to
have
some
identifier
to
to
to
classify.
F
Them
well
and
that
that's
kind
of
where
I'm
saying
the
intent
versus
the
payload
right
like
it,
it's
it's
one
of
those
things
that
you
know
when
you
see
it.
Oh,
okay,
this
is
an
event.
You
know
I
want
to
be
able
to
tie
these
together
in
a
certain
way
logs.
I
want
to
be
able
to
put
in
a
big
bucket
and
pull
something
up.
If
I
need
it
right,
so
we
use
them
in
different
ways.
F
But
when
you
actually
look
at
the
payload,
it's
a
little
bit
hard
to
say:
okay,
this
belongs
in
a
log,
and
this
belongs
in
an
event.
At
least:
we've
had
head
discussions
in
the
past
that
you
know.
F
We've
we've
talked
about
okay,
well,
you
know,
name
doesn't
belong
in
in
log
and
it
does
belong
an
event
or
vice
versa,
and
like
all
these
things
that
you
know,
we
find
counter
examples
every
time-
and
you
know
maybe
I'm
I'm
reading
that
wrong,
but
like
trying
to
make
that
a
distinction
is
something
that
we've
kind
of
backed
off
on
a
couple
times.
C
G
I
think
this
is
the
recommended
approach.
Like
we've
all
these
conversations
we've
had
about
logs
versus
events.
This
is
what
we
keep
coming
back
to
is
that
in
general,
attributes
will
be
the
solution
now,
whether
it's
called
event.name
or,
I
think,
more
likely.
What
we've
decided
is,
there's
probably
going
to
be
multiple
different
attributes
for
different
use
cases.
C
So
different
attribute
for
different
situations.
On
that
point,
I
I
want
to
highlight
that
there
will
be
a
resource
that
will
you
know
that
can
identify
the
the
situation.
So
let's
say
you
know
in
the
past
I've
seen
somebody
mentioning
you
know,
call
that
as
a
browser.event.browser.event.
B
Yeah
so
a
couple
of
thoughts
here,
santosh,
I
think
you,
you
can
definitely
propose
a
semantic
convention
called
event
name,
but
the
critical
part
here
is:
are
you
able
to
provide
a
definition
that
that
the
community
can
agree
on
for
what
this
means
right?
What
it
means?
It's
it's!
It's
very
generic
right.
If
you
look
at
it,
so
there
is
going
to
be
a
lot
of
opinions
about
what
it
means.
Can
you
come
up
with
a
definition
that
is
acceptable
for
for
everyone
or
for
most
of
the
parties?
B
That
would
be
the
critical
part.
There
is
a
related
issue
that
I
have
opened
recently
that
was
driven
by
what
you
were
just
discussing.
There
are
certain,
let's
call
them
domains
right
or
business
verticals
which
intend
to
use
logs
or
already
are
using
logs
in
some
form
to
represent
their
data.
B
It
looks
like
what
you
call
an
event
is
maybe
one
of
the
possible
types
of
the
domains,
although
quite
generic,
but
there
are
other
more
more
specific
ones
like
profiling
events
right
profiling
data
that
can
be
represented
as
log
records
or
the
browser
client-side
events
right.
They
are
a
bit
more
narrow
than
just
saying
events
right.
B
B
How
do
we
represent
it
on
the
wire
in
otp
more
efficiently,
and
that
open
issue
is
about
adding
the
notion
of
attributes
on
the
scope
level
so
that
you
can
have
a
bunch
of
log
records
belonging
to
one
scope
and
you
can
record
an
attribute,
maybe
event
dot
name
with
the
scope,
so
that
all
of
the
log
records
under
that
particular
scope
are
are
described
to
belong
to
that
particular
domain
right.
So
that's
an
open
issue.
I
can
post
a
link
to
that.
B
It
doesn't
change
the
semantics
right
of
what
we're
discussing
it's
just
for
more
efficient
processing
of
the
data.
But
the
third
thing
that
I
wanted
to
say
is
that
there
are.
There
are
two
ways
and
I
had
the
pr
that
which
which
didn't
move
forward.
Yet
there
are
two
ways
to
record
the
type
or
the
kind
of
of
the
thing
that
you're
recording.
B
The
the
number
one
way
is
by
recording
an
attribute
of
of
a
specific
generic
name
like
the
event.name,
and
then
the
value
of
this
attribute
defines
the
kind
of
the
of
the
event
right,
so
it
can
be
event,
dot,
name,
let's
say
or
event,
dot
type
right.
Let's
set
aside
the
name,
event.type
equals
profiling
or
event.type
equals
browser.
B
So
that's
by
value.
The
second
approach
is
by
the
presence
of
an
attribute,
so
let's
say
all
profiling.
Events
could
have
profiling
or
event.profiling
equals
true
right,
a
boolean
attribute
or
event.browser
equals
true
or
event.browser
equals
the
name
of
the
event
right
and
there
may
be
different
approaches
here.
So
what?
What
then
was,
I
think
was
was
referring
to
is
to
this
right.
You
do
not
necessarily
need
to
have
a
single
attribute
and
have
all
of
the
community
to
agree
on
the
name
of
this
attribute,
which
is
more
difficult.
B
Rather
you,
you
can
have
all
the
separate
groups
which
which
work
on
the
particular
domains
like
the
profiling
group
or
the
browser
group
that
we
have
they
can
come
up
with
with
an
attribute
name
that
is
applicable
to
their
vertical
only
and
propose
a
semantic
convention
for
that,
so
it
will
be
multiple
attributes.
In
that
case
right,
you
will
probably
use
just
one
per
per
domain,
but
they
will
be
different
attributes,
not
necessarily
one
attribute
name
for
all
of
the
events
that
that
you
are,
you
can
represent.
B
E
Okay,
so
yeah
I
I
would
just
add
to
that
really
quick.
It's
like
we
we've
had
discussions
about
about
different
types
of
events
in
client
side.
So
there's
not
just
like
one
type.
You
know,
there's
not
one
name
space
there
could
be.
You
know
we
could
be
recording
exceptions,
we
could
be
recording
interactions.
You
could
be
recording
different,
many
different
things
and
you
know
so.
E
There
was
we've
had
this
discussion
about
the
concept
of
a
schema
for
four
different
types
of
events
and
like
the
purpose,
so
the
purpose
of
the
event
name
attribute
would
be
that
is
that,
like
you,
can
easily
identify
the
type
of
event,
and
you
can
also
use
it
to
validate
that
that
all
the
attributes
that
describe
that
describe
that
event
are
present
right.
So.
B
Yeah
you're
going
a
step
further
right.
I
guess
it's
a
logical
next
step.
If
you
know
the
kind
of
the
event,
you
probably
expect
that
event
to
have
a
certain
shape
certain
attributes
to
be
present
with
certain
types
of
the
volumes
there.
I
agree.
I
think
that
that
would
be
probably
the
next
step.
We
are
still
we're
not
yet
there
we
probably
need
to
make
a
decision
about.
D
B
Agree
on
the
the
the
representation
thing
about
sorry,
differentiation
thing:
it's
going,
it's
probably
a
bit
premature
to
try
to
solve
the
shape,
shape
thing.
H
So
so
this
is.
This
is
actually
interesting
thing
because
you
have
mentioned,
if
I
recall,
emitting
things
like
stack,
traces
and
others
via
events,
and
I'm
wondering
like
from
from
that
standpoint
like
what
was
the
difference
when
a
log
logging
library
should
be
used
and
when
this
events,
api
should
be
used
by
someone.
Let's
say
working
with
with
open
telemetry.
C
Yeah,
I
think
that
yeah
I
I
agree
there
could
be
some
confusion.
I
think
for
unhandled
exceptions
you
know
is
what
this
was
meant
to
be
so
and
and
also
for
crashes
to
report
application
crashes.
So
you
know,
should
we
use
events
or
are
the
existing
locks
might
be
sufficient
too?
I
I
think.
E
I
think,
if
you're
you're,
going
by
what
what
currently
is
used
for
spams
like
spam
events,
are
used
to
attach
to
spams
like
to
designate
that
there
was
an
error
that
occurred
on
you
know
during
the
span.
So
I
think
that's
what
we're
thinking.
E
H
H
So
it's
like
an
interesting
discussion
like
for
me
like,
what's
what's
really
like
the
difference
between
events
and
and
and
just
regular
locks
and
to
me-
and
this
might
be
not
the
right
answer
like
but
the
way
I
see
it
is
that
the
logs
have
this
like
different
ways
than
can
then
can
be
let's
say
handled,
they
could
be
like
put
to
standard
output
that
that
can
be
like
put
to
some
file,
or,
with
this
let's
say,
new
as
log
link
library,
sdks
with
open
telemetry.
H
Those
could
be
also
sent
through
otlp
and,
I
think,
with
events
events.
This
is
not
really
the
case
like
events
are
intended
for
otlp
really
and
and
putting
them
on
console
would
be
like
a
special
case
rather
than
something
something
normal
or
to
standard
output.
So
I
know,
but
that's
like
one
way,
I'm
looking
at
this
differentiation.
D
Would
be
okay
for
logs
and
events
to
somewhat
overlap
like
if
my
logging
library
could
somehow
be
manipulated
to
create
an
event,
but
we
have
a
specific
event
api
for
when
we,
when
a
user
wants
to
create
an
event.
Is
that
an
okay
thing.
D
B
D
Well,
I'm
not
saying
over
ltlp
like
the
idea,
the
I
think
the
assumption
here
was
everything
went
over
the
otlp
logs
record,
but
I
meant
a
backend
that
receives
these.
If
the
api
is
able
to.
If
the
event
api
is
able
to
create
something
that
looks
like
a
raw,
a
log
to
the
back
ends,
and
vice
versa,
the
log
library
whatever
that
is
whether
it's
log
for
j
or
a
bespoke
logging
api
can
create
event
which
cases
are
okay,
which
cases
aren't.
D
Are
they
all?
Okay.
F
You
know
I,
I
think
they're
all
okay,
I
mean
this.
Is
this
we're
design
we're
designing
a
transport
for
these
things
right?
So
I
I
think
it's
okay
for
you
to
have
two
streams,
one
of
them
that
carries
what
you
consider
a
log
and
one
that
considers
it
carries.
Events
in
your
back
end
process
and
processes
them
totally
differently.
F
D
I
think
I'm
looking
at
the
user-facing
api
and
assuming
that
the
transport
over
otlp
is
already
kind
of
assumed
to
be
set
aside
from,
like
the
aside
from
the
my
new
details
of
like
what
triggers
an
event
being
okay.
D
So
from
a
user's
perspective,
somebody
asked
a
question
along
the
lines
of
like
when,
should
I
use
an
event,
and
my
question
is,
if
I
happen
to
misuse
the
api,
I
guess
the
event
api
to
create
a
log.
How
will
I,
how
will
the
user
know
this.
F
I
think
like,
like
you,
were
saying
that
it
doesn't
necessarily
matter.
You
know
if,
if
this
goes
into
a
log
file
somewhere,
that's
okay,
yeah,
but
internally.
The
way
I
look
at
logs
and
logs
versus
events
is
that
logs
are
a
record
of
something
that
happened.
F
D
How
can
how
will
this
be
misused,
because
any
api
that
we
put
out
there
is
going
to
be
that
way
as
long
as
we
have
a
story
for
it,
I
think
it's
it's
an
acceptable.
F
Point
where
I
like
this,
where
I
think
this
is
really
cool
and
that's
kind
of
where
I'm
trying
to
to
bringing
out
this
distinction
is
that
when
you've
got
a
user
that
logs
in
right,
that's
actually,
you
know
you
can
look
at
it
and
we
have
in
in
the
past,
looked
at
that
as
an
event.
That's
just
something
we
look
at
if
we
really
have
to
and
for
you
know
whatever,
but
it's
it's
becoming
more
and
more
a
event,
something
that
we
might
want
to
respond
to
that.
F
We
want
to
check
okay,
well,
this
guy
got
through.
Is
that
some
something?
So
if
we
want
to
respond
to
it,
we
would
actually
program
that
differently
right
if
it's
a
log,
we'd
use.
You
know
slf
for
j
and
we'd
put
a
log
entry
in,
but
if
it's
an
event,
it
might
be
wrapped
around
your
login
statement,
and
so
when
you
log
in
you
send
an
event,
and
that
has
a
structured
payload
that
we
might
respond
to
in
a
certain
way.
B
Yeah,
I
think
this
this.
This
shows
that
well,
I
have
just
heard
at
least
two
different
ways
to
differentiate
loads
from
low
crackers,
which
are
totally
different
incompatible,
so
we
we
need
one
way
to
do
this
differentiation.
Otherwise,
it's
not
going
to
work
right
for
premek,
it's
the
medium
where
it
is
logged
for
you,
it's
the
immediacy
right.
How?
How
do
we
react
to
that
yeah?
I
don't
know
if
we're
going
to
be
able
to
agree
on
an
actual
definition.
F
And
when
we've
actually
talked
about
it
before
too,
it's
really
falling
apart
when
we
start
talking
about
different
types
of
events,
a
profiling
event
versus
a
cloud
event
versus
you
know
like
each
of
these
events
comes,
carries
with
a
different
bag
and
baggage
and
different
perspective,
and
so
even
different
events.
We
handle
differently.
B
E
B
C
No,
actually
it's
it's
not
just
javascript.
It's
javascript.
B
Okay,
even
even
more,
I
guess
right,
so
why
why
the
existing
ones
cannot
be
used,
show
that
it
is
not
suitable.
It's
not
a
good
fit.
If
you
do
that,
then
the
question
of
whether
to
call
the
new
api,
an
events,
api
or
logging
api,
I
believe,
also
depends
on
whether
we
agree
on
whether
these
are
the
same
thing
or
different
to
me
to
actually
declare
that
they
are
different.
I
want
to
see
that
clear.
The
definition
of
that
difference
right
on
which
we
can
all
agree.
B
I
think
in
this
call
even
we
were
not
able
to
come
to
that
agreement.
If
we
cannot
agree
that
they
are,
there
is
a
clear
definition
of
events
that
are
different
from
the
logs.
Then
I
would
just
aim
to
call
this
a
logging
api
and
record
your
client-side
events
using
the
logging
api.
That's
fine
use
the
semantic
conventions
that
you
propose
for
your
particular
vertical,
for
is
it
the
mobile
events?
Is
it
browser
events?
B
They
may
even
have
different
attributes
right
depending
on
on
the
kind
of
the
client,
so
I'm
guessing
the
event
name
is
not
the
only
thing
that
you
want
to
record.
There
is
going
to
be
a
lot
more
other
other
attributes,
other
semantic
conventions
that
you
may
need.
I
think
we
have
some
already
browser
related,
but
probably
you
you
will
need
more.
If
not
everything
is
there
already
so.
C
I
have
a
question
on
this,
so
I
have
used
java
and
the
logging
library
that
plugin
api
that
I
have
used
is
you
just
say,
log.deepak
and
and
and
and
a
string
followed
by.
You
know
the
variables
that
you
want
to
be
replaced
within
that
string
right.
How
does
that
translate
to
this
log
record?
You
know
all
those
that
finally,
the
string
that's
emitted,
you
know,
does
it
go
in
the
body
or
does
the
template
string
go
in
the
body
and
the
different
parameters
go
as
attributes.
B
C
Okay,
so
so
as
long
as
we
use
the
same
interface
and
just
pass
one
additional
attribute
for
for
the
name,
the
event
name,
we
you're
thinking
that
you
know
it
might.
B
That
should
work
yeah
that
should
work,
but
but
remember
what
I
said
about
the
scope.
B
If,
if
we
go
forward
with
that
proposal,
where
we
record
attributes
at
the
scope
level,
then
when
you're
obtaining
your
log
emitter
at
that
time,
you
are
especially,
you
will
be
specifying
that
additional
attribute
that
you
want
to
be
recorded
for
all
of
the
log
records
that
you
meet
there
you,
you
know
the
purpose
of
the
login
meter
right.
You
will
be
obtaining
one
for
the
purpose
of
emitting
browser
events,
so
when
you're
obtaining
that,
you
will
specify
that
additional
attributes
that
says
these
these
are
these
log
records
emitted
by
this
log.
B
C
Is
that
scope
supported
by
the
common
log
apis.
B
No,
but
you
are
going
to
be
obtaining
the
log
emitter
to
pass
it
to
the
log
offender
right,
that's
how
it
works
today.
I
see.
C
B
B
It's
it's
a
very
early
proposal,
so
I
don't
know
the
details.
Okay
with
me,
may
I
maybe
I
may
be
a
bit
off
here
but
you're
asking
whether
you
should
be
passing
that
attribute
as
yet
another
variable
to
the
to
the
log
dot
info
statement.
H
Yeah,
I
just
want
to
add
that
I
feel
that
adding
semantic
conventions
is
like
easy
and
it's
it's
it's
since
they
are
not
very
controversial
and
make
all
the
sense.
We
just
need
the
right
taxonomy
and
with
the
api.
H
There
are
like
a
lot
of
options
like
either
reusing
the
existing
library,
because
maybe
this
will
work
just
as
we've
been
discussing,
or
maybe
we
want
to
have
like
a
generic
logging
api,
which
I
think
was
not
a
part
of
the
specification
until
now,
because
we've
been
assuming
that
we
use
the
existing
logging
library
like
for
programming
languages
and
just
provide
this
sdk
to
essentially
to
send
it
over
otlp
san
appender
or
such,
and
now
we
will
have
a
like
an
alternative
way
to
to
to
generate
locks,
which
I
feel
would
be
okay
and
then,
like.
G
Yeah,
so
I
just
wanted
to
call
attention
to
these
two
issues
here
on
the
log
collection
library.
So
I
guess
in
the
like
to
put
some
context
on
this
in
the
bigger
picture,
we're
in
my
opinion,
like
80
or
90,
through
sort
of
a
fairly
major
overhaul
of
the
internals
of
the
library
like
what
does
it
mean
like
how,
in
general,
should
you
interact
with
logs,
which
would
be
like
the
default
behaviors?
And
things
like
that
and
to
me
these
are
like
the
remaining
issues.
Basically,
these
are.
G
You
know,
we've
we've
migrated
the
structure
of
attributes
and
resource
from
being
a
flat
string
to
string
map
to
now
being
full,
fully
arbitrary
to
match
the
data
model,
and
now
we've
provided
the
functionality
to
refer
to
fields
at
any
point
so
that
we
can
move
things
around
wherever
we
want.
G
However,
there's
some
nuances
to
like
what
does
it
mean
when
a
user
tries
to
refer
to
attributes
in
general,
and
it
really
like
it
seems
to
make
a
lot
of
sense
in
some
cases
and
make
no
sense
in
other
cases
and
there's
some
words.
A
little
bit
a
little
bit
ambiguous
and
but
maybe
an
argument
can
be
made
one
way
or
the
other.
So
one
of
the
first
issue.
G
There
is
basically
articulating
it's
like
a
super
detailed
analysis,
as
as
I
see
it
of
you
know
exactly
which
cases
does
it
make
sense
and
not
make
sense,
put
some
like
general
rules
and
like
a
sort
of
a
framework
on
it
and
then
proposes
exactly
what
I,
what
I
think
should
change
it's
kind
of
nitty-gritty,
but
would
appreciate
a
couple
more
opinions
on
it,
because
I
think
it's
work
that
at
least
mostly
should
happen,
and
if
you
know,
if
anyone
can,
I
don't
know
either
confirm
or
deny
that
for
me,
that'd
be
really
good.
G
Sorry
yeah
this
one
is
more.
I
I
almost
feel
like
we're
compelled
to
make
at
least
part
of
this
change
with
the
change
to
the
data
model,
because
we've
we've
said
explicitly
in
the
data
model.
Now
that
the
body
should
be
a
string
in
first-party
libraries
and
the
attributes
should
you
know,
is
where
basically
everything
else
goes
and
so
currently,
though,
the
library
when
it
parses
the
body
it
replaces
the
body
with
the
structure
that
it's
built
from
parsing.
So
this
that
right,
there
seems
like
a
violation
of
the
data
model.
G
In
my
opinion,
and
so
that's
like
the
bulk
of
what
that
proposal
is,
and
that's
basically
just
saying
when
we
parse
something
it
should
go
into
the
attributes.
I
think
I
remember
hearing
a
lot
of
agreement
on
that,
but
I
don't
like
see
a
lot.
I
haven't
gotten
a
lot
of.
I
know
some
folks
at
sumo,
thanks
sharminic,
for
showing
that
to
people
but
got
some
buy-in
on
that
from
sumo.
But
I'd
like
to
see
some
more
approvals
and
there's.
G
Like
when
you
parse
the
body
should
it
be
destroyed,
it
used
to
be
implicitly
that
you
would,
because
you
were
replacing
it,
but
now
we
have
to
make
a
decision
should
it
be
destructive
or
not
I'm
proposing
that
it
not
be
destructive,
and
that's
the
only
other
part
of
that.
So
please
just
take
a
look
thumbs
up
comment.
I
appreciate
it.
B
Then,
on
the
the
first
one
4-1-0,
I
think
we're
in
agreement
conceptually
about
about
this
change.
The
only
minor
I
guess
part
that
we
didn't
agree
on
was
with
the
the
where
whether
we
use
camel
case
or
use
lowercase
for
the
other
for
for
the
field
names
right.
B
B
What
do
you
think
about
it?
Is
that,
and
also
is
there
anything
else
that
we
disagree
on
on
this
particular
issue.
G
B
I
may
at
some
point,
but
I
don't
want
to
distract
us
from
this
concrete
discussion
and
go
into
the
theoretical
discussions
about
something
that
may
or
may
not
happen
in
the
future.
That's
why
I
want
to
retract
that
argument
and
I'm
bringing
another
argument.
I'm
saying
the
data
model
in
the
specification
uses
camel
case
for
the
field
names.
A
I
also
want
to
add
something
here:
we
decided
to
move
local
action
library
to
the
open,
telemetry
collector
right
and
as
far
as
I
remember,
we
don't
have
any
camel
case,
syntax
and
open
telemetry
collector.
B
A
Well,
I
believe
it's
all
receivers
that
login
library
provides
using
operators.
Then
correct
me
if
I'm
wrong,
but
I
believe
it's
all.
This
interface
will
be
applicable
in
the
all
of
the
receivers
of
logan
resource
right.
G
B
Dmitry
I
was
asking
something
different.
I
was
saying
you
have
a
good
argument
saying
that
if
we
don't
use
camel
case
elsewhere,
then
we
shouldn't
be
using
here,
which
I
agree
with.
Where
is
it
elsewhere?
That's
what
I
was
asking.
Where
else
do
we
use
lowercase
to
refer
to
the
field
names
in
the
collector.
B
A
B
D
B
Have
a
good
point
mitch:
let's
have
a
look
at
that.
I
I
didn't
have
a
chance
to
look
at
the
other.
The
parser
thing
then
you
mentioned
like
I
can
have
a
look
offline
as
well
inside
because
I
didn't
have
a
chance.
B
G
I
just
wanted
to
make
sure
we're
clear
too,
because
I
I
understood
that
we
had
in
my
the
way
I
had
understood
this
is
that
we
already
made
a
decision
to
use
the
lowercase
versions
and
that
this
discussion
was
about
something
else,
so
those
changes
have
already
been
rolled
into
the
latest
release.
It
hasn't
gone
into
the
collector
yet,
but
it
is
in
the
latest
release
of
the
library.
So
I
think,
fortunately
a
lot
the
collector
was
just
released.
G
Today
we
have
two
weeks
till
the
next
release,
but
we
should
get
this
resolved
enrolled
into
the
next
release,
then
so
that
there's
okay,
there's
not
like
back-to-back
breaking
changes,
yeah.
B
G
Yep
and
then
to
require
that
that
you
must
say
attributes
or
body
your
resource
right,
yeah.
B
G
B
With
that
as
well,
that
is
fine
with
me
as
well.
So
that's,
okay,
I'm
not
looking
for
the
shortcut
syntax
there!
That's
okay!
The
only
I
guess
part
that
I
did
not
yet
agree
with
is
the
the
casing
of
the
name
cases
right.
So
if
you
don't
mind
because,
as
you
said,
we
have
two
weeks-
let's
try
to
figure
it
out
before
we
move
forward
with
this.
A
A
Sorry,
we
cannot
copy
like
value
if
it's
not
the
map
or
something
like
that
to
the
root
of
the
attributes
right.
But
if
I
have
that
use
case,
if
I
have
a
map
in
the
body
and
I
move
to
any
of
the
attributes,
it's
gonna
be
two
different
operators.
After
this
change,
right,
probably
copy
and
flatten,
or
how
this
will
resolve.
A
So
so
the
use
case
I
have
a,
I
have
a
block
with
the
body
as
a
map.
Some
I
just
like
string
to
string
key
value
pairs
and
I
want
to
have
those
pairs
to
be
added
as
attributes
as
like.
G
G
A
B
G
A
Yeah,
I
think
do
operators
would
be
better
than
like
allowing
movie
moving
everything
anything
like
maps,
but
that
doesn't
not
allow
them
to
move
values
to
the
attribute.
That's
can
be
like
error
prone
approach,
so
I
think
your
suggestion
is
is
great,
but
we
need
some
somehow
support
that
use
case
sure
make
sense.
G
B
B
B
Is
this
we
need
to
do
something
I
don't
know
wait
for
something,
or
there
is
some
something
that
may
become
an
issue
at
the
protocol
level,
which
is
not
a
problem
for
the
data
model
which
prevents
us
from
going
stable,
very
hypothetical.
I
don't
know
what
that
can
be,
but
I
just
want
to
give
us
all
a
bit
time.
B
So
the
the
issue
is
all
the
pr
is
open
there.
It's
essentially
changes
nothing
in
the
protobufs,
just
declares
them
stable.
So
please
think
what
what
possibly
we
need
to
do
before
we
can
move
forward
with
this
one.