►
From YouTube: 2022-04-06 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
C
Yeah,
firstly,
thanks
for
reviewing
the
document
yesterday,
so
I
I
think
from
the
last
meeting
my
takeaway
was
that
you
know
we
did
not
want
to
introduce
a
public
facing
api
for
logs,
but
from
your
comments
it
feels
like
you're
open.
So
I
I
wanted
to
let
you
know
that
I'm
not
so
familiar
with
the
logging
aspects
in
dogs
aspects.
I
only
come
from
the
event
side
from
the
transit
telemetry.
A
A
I
guess
we're
not
hearing
objections
so
which
is
a
good
thing
as
for
someone
else
helping
with
the
logging
api,
since
you
you
will
not
be
able,
then
I
guess
yeah
we'll
need
to
find
that
person.
Whoever
has
the
the
ability,
I'm
not
sure
I
can
do
it
right
now,
but
maybe
if,
if
this
is
not
originally
needed
right
now,
maybe
I
can
find
some
time
a
bit
later
unless
anybody
has
the
time
to
do
it
right
now.
I
don't
know.
C
Is
it
possible
to
maybe
at
least
decide
on
the
entry
point
for
for
the
api
and
and
then
I
could
define
methods
for
you,
know
the
events
aspects
and
then
for
the
logs
aspect.
I
think
you
mentioned
that
you
know
there
might
be
more
or
maybe
you
know
I
could
take
a
first
cut
and
and
and
then
you
you
could
review
and
see
whether
that
addresses
that
I
think
my
hesitation
comes
from
the
fact
that
the
existing
logs
apis
are
very
simple.
Luckily
you
just
say:
lockdown
deeper.
C
Can
you
provide
a
you
know
a
message
and
the
interpolation
arguments
right,
whereas
I
think
the
api
interface
I
have
seen
you
know
here
are
the
builder
type
interfaces
where
interface,
where
you
have
a
separate
method
for
setting
each
field?
A
So
when
trying
to
design
this,
I
would
approach
this
with
a
strong
bias
for
consistency
with
the
tracer
api.
One
possible
approach
here
is
literally
take
the
tracer
apis
trip
it
off.
Whatever
is
like
very
specific
things
like
links
or
nested
events,
and
all
that
stuff
eliminate
spawn
specific
things
and
just
turn
the
spawn
into
a
log
record.
So
you
remove
one
of
the
timestamps
right.
You
you
get
one
timestamp
or
we
actually
have
two
as
well
in
logs,
but
they
are
named
differently
anyway.
A
Remove
those
tracing
specific
things
like
like
the
kind
of
the
spawn,
keep
the
attributes
right,
remove
the
links
and
all
that
stuff
and
try
to
model
around
that
right.
I
don't
know
if
that
will
look
nice
as
a
logging
api,
but
it
will
look
consistent.
A
C
D
I
think
when
you
one
thing
I'll
note
is
you
might,
I
would
suggest,
when
designing
it,
just
concentrate
more
on
the
information
that
needs
to
be
present
like
what
fields
are
required.
What
are
optional?
D
Are
we
going
to
have
a
couple
different,
convenient
methods,
for
example
like
with
an
event
you
always
want
to
have
a
name.
You
don't
have
a
severity
level,
potentially
with
the
log.
You
know
you
have
a
log
message.
D
E
And
I
think
another
way
to
look
at
it
too,
is
that
you
we've
had
a
lot
of
people
expressing
that
we
don't
really
want
log4j
sort
of
api
that
we
would
rather
integrate
with
log4j,
and
so,
if
you
look
at
it
in
terms
of
if
we
were
building
an
integration
with
log4j,
where
you
know
now,
we've
got
their
structure
of
whatever
an
event
is,
and
we
want
to
build
ours.
E
What's
the
api
that
would
help
us
with
that,
and
it
seems
like
it
looks
a
lot
like
this,
so
not
necessarily
like
the
end-to-end
users
api,
but
the
api
for
the
person
who's
implementing
the
log
library.
D
Okay,
yeah,
and
for
for
what
it's
worth
I'll
also
say
like.
I
think
it
might
be
worth
it
to
to
design
these
apis,
but
also,
at
the
same
time,
it's
fine
for
a
particular
language
like
java,
for
example,
to
say,
our
implementation
of
this
api
is
log
for
j,
and
you
use
slog4j
this
way
or
something
like
that.
D
But
I
do
think
it
would
be
helpful
to
define
it
because
most
languages
are
not
like
java
and
don't
have
like
a
strong
overriding
winner
when
it
comes
to
like
a
logging
library,
essentially
so,
but
having
something
that
just
defines
how
we're
supposed
to
use
these
things
across
the
different
languages
would
probably
help
maintainers
a
lot,
even
if
they
are
choosing
to
use
some
built-in
thing.
A
Yeah,
definitely,
I
guess
come
approach
this
from
the
perspective
of
the
usage
right.
How
are
they
going
to
be
used?
You
have
one
specific
use
case.
You
want
to
call
this
from
from
the
client
side
instrumentation,
but
that's
just
one
use
case
right,
there's
probably
other
use
cases
and
what
what
do
the
calls
look
like
in
those
cases
right?
A
How
do
you
want
the
anyway?
Are
they?
Are
they
going
to
be
ergonomic
to
call?
What
does
that
api?
How
does
that
api
help
achieve
the
particular
goal
in
that?
In
that
use
case,
I
think
it's
going
to
be
iterations
like
it's.
It's
apis
are
hard.
It's
it's
not
going
to
be
quick
and
easy
to
come
up
with
something
yeah.
So
it's
it's
going
to
be
some
some
long
process.
I
would
expect
that.
C
Yeah,
unfortunately,
this
means
that
the
timelines
for
client
instrumentation
is
going
to
go
longer,
because
this
is
the
only
fundamental
data
model
for
for
a
lot
of
things
there.
So
this
is
kind
of
blocking
development
there.
So
yeah,
that's
only
you
know,
side
of
going
slow.
C
Okay,
I'll
give
it
a
shot,
then
one
between
tracing
api
and
the
metrics
api.
I
found
the
matrix
api
to
be.
You
know
more
simpler
for
for
the
logs
use
case.
I
don't
know
what
you
think.
Basically
in
the
in
the
metrics,
you
would
directly
say
open,
telemetry,
dot,
metric
builder
and
then
start
building
a
metric
and
and
then
maybe
and
then
just
say,
emit
and
then
be
done
with
it.
A
D
As
as
part
of
this,
or
like
a
related
effort
that
I
also
don't
think
will
be
very
complicated,
it
would
be
helpful
to
define
how
to
translate,
span
events
into
events,
log
events
essentially,
and,
and
vice
versa.
How
do
you
translate
log
events
into
span
events?
D
C
All
right,
so
that's
on
this
topic.
I
have
one
more
in
a
smaller
topic.
I
think
ted
and
I
we
were
talking
in
another
meeting
earlier
today
and
my
screen.
C
I
think
you
know
we
you
know
in
here.
You
know
I
use
this
attribute
name
as
browser.even.name,
so
the
question
came
up.
Why
not
even
dot
name
and
I
think,
based
on
our
last
meeting
here,
I
I
I'm
not
100
clear.
I
understood
then,
but
I
got
a
feeling
that
it
might
be
easier
to
get.
You
know
agreement
if
we
use
you
know,
domain
specific
attribute
name
rather
than
you
know,
even
dot
name,
which
is
which
has
a
wider
scope.
C
So
could
you
explain
once
again
your
opinion
on
having
an
attribute
called
event.name.
A
C
Events
right,
the
dom
events,
several
yeah,
several
possible
events
is
one
of
them.
C
C
Would
be
an
error
occurred?
You
know,
since
the
logic
logging
is
not
so
common
to
ship
from
the
browser
side,
you
know
you
would
only
ship
just
the
errors,
so
you
would
generate
an
error.
A
So
when,
when
an
error
happens,
what
do
you
call?
What
what
would
the
name
be?
Would
you
call
it
an
error
literally
or
how
do
you
make
sure
that
the
potential
values
of
what
you
come
up
with
don't
conflict
with
some
other
possible
event,
names
that
you
would
be
maybe
populating
from
the
let's
say,
a
javascript
event
yeah?
How
do
you
define
the
namespace
of
possible
events
right.
C
So,
are
you
saying
that
if,
if
we
have
clear
documentation
on
you
know,
these
are
the
values
like
you
want.
A
To
call
it,
you
want
to
call
it
a
name
right,
so
let's
say
I
have
a
click
event
in
javascript,
so
the
button
was
clicked
or
something
happened
and
the
name
of
that
event
is
click
right,
so
I
can
have
browser.event.name
equals
click
and
you're.
Also
saying
that,
maybe
you
want
to
record
errors
in
the
same
way
and
the
name
of
that
would
be
an
error.
I
guess
right.
A
So
how
do
you
ensure
that
the
names
that
you
borrow
some
from
somewhere
else,
like
the
javascript
event,
names
and
ones
that
you
come
up
with,
and
maybe
that
that
the
whoever
is
the
caller
of
ad
browser
event
function,
may
be
assigned
arbitrarily
invents
the
names?
How
do
you
make
sure
that
they
are
unique
right?
They
don't
they,
they
don't
have
an
actual
meaning
somewhere
else
right,
and
why
are
we
separating
this
per
per
domain
per
vertical?
A
If
you
will
is
also
to
kind
of
limit
the
in,
in
a
sense
the
blast
radius
here
right,
so
how
much
you
can
contaminate
some
other
areas
is
limited
by
this
right.
It's
essentially
you're
not
going
to
cause
problems
for
the
mobile
area,
even
if
you
have
some
some
sort
of
a
trouble
here
with
conflicting
names
for
the
browser
events.
D
But
that
that
creates
problems
on
the
flip
side,
which
is
you
can't
build
a
back
end
for
processing
events
in
a
generic
way?
It
would
be
sort
of
like
if
we
didn't
have
a
span
name
and
instead
we
had
like
http
http.span.name
and
you
know
db.span.name,
and
it
you
get
an
explosion
on
on
that
end.
So
that's
that's.
That's
the
flip
side.
C
I
I
think
at
least
for
us.
We
definitely
need
to
segregate
logs
and
events.
The
the
processing
is
different.
Processing
pipelines
are
different
for.
D
I
think
it
might
be
okay
to
have
you
know
like
an
event.type
field,
or
something
like
that.
I
guess
I
guess
I'm
just
suggesting
that
we
regularize
the
names
of
these
fields
and
put
the
the
information
that's
varying
like
that
is
as
value
somewhere
rather
than
then
stick
it
stick
it
in
the
name,
space.
C
We
taken
to
address
both,
I
think
you
know
we
could
even
have
a
semantic
convention
on
the
you
know:
values
prefix,
so
the
attribute
name
could
be
even
dot
name,
but
the
value
should
always
have
the
domain
prefix.
So
if
the
vertical
prefix,
so
all
he
went
from
browser
world
would
have
you
know,
browser.
browser.click
and
from
the
desktop
world
it
would
say
desktop
or
something.
A
D
That's
that's
totally
valid.
I
guess
I
just
for
me
like
an
important
requirement
is
that
these
be
extensible
systems.
You
know
like
it
should
be
possible
that
you,
you
don't
want
a
system
where,
in
order
to
extend
your
ability
to
process
and
to
extend
the
kind
of
events
that
exist,
you
you
would
have
to
like
go
teach
your
back
end
to
look
at
look
at
different
fields
or
something
like
that.
D
If
that
makes
sense,
that's
it
would
be
great
if
it
was
extensible
in
a
way
that
that
kept
the
the
place
where
a
more
generic
event
processing
system
would
want
to
look.
You
know
kind
of
like
the
same
spot,.
A
I
don't
have
a
strong
opinion
here.
To
be
honest,
it's
hard
to
tell
unless
you
see
the
specific
definitions,
okay
and
the
semantic
conventions
of
what
are
the
names
of
the
attributes
and
what
are
the
the
expected
values
for
those
well
yeah.
So
I
I
have
a
question
when
you're
saying
you
you
you
want,
you
don't
want,
I
guess
the
ability
for
the
back
end
to
process
these
various
types
of
events
in
a
uniform
way.
How
would
you
use
that,
like
you,
have
browser
events
and
you
have
ebpf
events?
C
Processing
yeah,
if
you
want
to,
if
you
want
to
count
the
events
of
a
given
type,
you
would
pass
it
through.
D
The
the
big
difference
between
an
event
and
a
log
for
me
is
that
events
you're
saying
are
repeated
and
you're
going
to
be
looking
at
them
in
aggregate
in
some
way
like
they're
designed
to
be
looking
at
in
aggregate,
whereas
logs
you
might
want
to
look
at
logs
in
aggregate.
But
actually
every
log
has
like
a
message
field.
There's
something
like
kind
of
unique
about
that
particular
log.
D
That's
also
important,
whereas
with
events
they're
more
strongly
oriented
towards
looking
at
them
in
aggregate
in
some
way,
just
just
like
tracing
data
and
spans,
and
so
you
end
up
building
various
kinds
of
like
indexes
and
ways
of
looking
at
that.
But
it's
still
helpful
to
have
kind
of
like
a
default
primary
index
that
such
a
system
would
use.
A
Hard
time
kind
of
understanding
that
that
argument,
like
you're
saying
events,
are
aggregate
log
records.
Are
you
look
at
them
individually,
like?
What
do
you
do
with
the
profiling
events?
The
profiling
we
have?
I
think
we
have
a
profiling
implementation
where
the
individual
profiles
taken
are
taken
and
they
are
represented.
As
log
records,
which
I
mean,
I
could
argue
that
you
can
also
call
them
events,
profiling,
events
right,
that's
that's
what
they
are.
D
I
think
it's
a
gray
area,
it's
just
it's
a
question
of
I.
I
think
I
think
it's
very
muddy.
I
don't
think
there's
actually
like
a
a
great
way
to
make
a
real,
strong
distinction
between
a
log
and
an
event,
but
it's
more
that
I
think
it
would
be
helpful
to
have
for
things
that
are
intended
to
be
used
in
this
manner.
The
manner
that
we
want
to
be
using
these
event,
events
we're
admitting
where,
yes,
we
want
to
show
them
on
a
timeline.
D
If
we're
like
reconstructing
a
chain
of
events,
you
know
having
them
contextualize
with
spans,
and
things
is
really
helpful,
but
then
we
also
want
to
look
at
them
in
aggregate,
and
if
you
want
to
build
a
generic
system
for
looking
at
events
in
aggregate,
you
want
to
have
a
generic
primary
index
for
what
it's
worth.
This
is
how
spans
work
in
open
telemetry,
and
while
we
do
theoretically
have
all
of
these
same
problems
of
like
naming
collisions
for
spans.
D
In
practice
it
hasn't
come
up
is
a
huge
problem
that
doesn't
mean
we
shouldn't
like.
Do
the
work
to
figure
out
how
to
disaggregate
this
stuff,
but.
F
D
D
Well,
but
that's
pretty
limited,
though
right,
it's
like
client
server
internal
and
we
tend
to
use
things
like
feature
detection.
Essentially
right
like
is
there?
Are
there
http
fields
on
this?
Are
there
there
are
other
fields
that
we
care
about?
D
That's
been
kind
of
like
the
line
we've
taken
so
far
is
that
the
kind
of
span
it
is
is
based
on
what
class
of
conventions
are
attached
to
it,
and
I
guess
my
suggestion
is
just
to
to
continue
with
that
model
for
events
they
these,
don't
they
don't
seem
to
be
so
different
from
spans
and
how
we're
dealing
with
spans.
D
You
know
spans
themselves
are
basically
an
event,
but
they
also
like
provide
some
context
for
other
things
that
are
happening,
but
in
many
many
ways
the
way
back-end
systems
deal
with
fans
is
effectively
an
event.
So.
D
A
D
D
That
is
like
the
way
you
want
to
index
your
stuff,
but
it
is
like
helpful,
really
helpful
for
tracing
systems
to
just
have
that
baseline,
that
they
can
build,
build
off
of,
and
just
I
don't
know
just
in
in
in
the
name
of
like
keeping
consistent
like
that's
for
better
or
worse.
A
A
D
Yeah
and
it's
true,
we
never
address
the
issue
of
like
you
might
have
naming
collisions
across
different
domains
and
in
practice
that
hasn't
come
up.
Maybe
that
could
be
possibly
because
just
in
the
world
of
tracing
like
what
you
end
up
naming
spans,
there
just
doesn't
end
up
being
like
a
huge
overlap
across
domains
and
maybe
there's
the
potential
for
there
being
more
of
an
overlap.
C
Here,
in
a
way,
that's
confusing
it's
domain
agnostic
right
in
tracing
sp
in
the
span
world.
I
I
don't
know
why
the
domains
matter.
It's
it's
a
api
call
and
the
api
has.
You
know,
operation
name,
whereas
events
is
more
in
a
slightly
higher
level
construct.
A
Yeah
you
just
put
it
in
fans,
you
have
do
you
have
a
lot
more
information
typically
provided
in
the
attributes,
so
the
name
is
not
that
important,
really
you're,
not
relying
on
the
name
alone,
to
figure
out
what
is
it
that
this
span
is
describing
too.
So
if
we
approach
the
events
the
same
way,
if
we-
and
I
think
that's
the
expectation
that
you
would
have
fully
structured
attributes
there-
that
describe.
B
A
Is
happening
there,
how
it
is
happening?
Who
did
what
right
then?
Actually,
yes,
there's
a
lot
less
load
on
the
meaning
of
the
name
itself.
Name
would
be
in
that
case
more
like
something
descriptive,
something
that
is
useful
for
the
humans,
maybe
maybe
not
even
that
important
anymore
for
the
machines
right,
so
where
the
uniqueness
and
clarity
of
the
semantics
is
important.
D
F
D
F
A
D
And
and
we're
definitely
part
of
the
the
client
instrumentation
working
group,
part
of
the
work
on
that
group's
plate
is
to
define
all
of
the
semantic
conventions
for
for
all
of
this
stuff.
So
so
that's
that's
definitely
on
the
table.
D
We're
not
going
to
just
say
we
have
events
now
you
know
we
need
to
to
go
in
and
define
how
browser
events
and
ui
events
and,
like
all
of
the
the
standard
events
that
get
emitted
from
all
these
different
client
systems,
and
so
I
think
the
end
result
will
look
kind
of
like
what
we've
done
already
in
the
tracing
tracing
world.
A
Think
the
important
question
here
to
answer
is:
do
we
expect
that
the
event
name
or
the
more
specialized
attribute,
whether
it's
browser
event
name
or
something
like
that
defines
the
shape
of
the
rest
of
the
attributes,
or
it
does
not
right
if
there
is
an
expectation
that
it
does,
then
there
is
a
lot
more
responsibility
here
on
this
attribute?
If
it
doesn't,
then
it
works
similarly
to
the
span
name.
D
Yeah,
I
would
argue
for
this
second,
that
if
you're
trying
to
determine
the
type
of
the
event
like
you,
don't
just
have
a
type
floating
out
in
space.
Generally
speaking,
it's
like
if
it's
like
you
know
a
type
of
event.
That
means
it
has
a
set
of
attributes
on
it
that
make
it
that
type
of
event
like
like
there's
no
event
out
there.
I
think
that
just
is
literally
just
like
a
name
and
and
nothing
else.
D
D
Oh
but
yeah,
I
was
just
I
think,
going
where,
where
you're
going,
which
is
like
the
the
way
a
back
end,
identifies
events
that
it
cares
about.
Is
it's
looking
for
required
attributes
for
for
different
different
types
of
events?
D
A
F
Yeah
so
so
a
background,
that's
trying
to
you
know,
filter
off,
or
you
know,
browser
events
and
do
special
processing
on
them
would
look
for
the
presence
of
those
specific
attributes
defined
in
the.
D
D
I
think
in
the
case
of
these
events,
though,
like
that
name
field
is
always
going
to
there's
always
going
to
be
a
good
name
to
pick,
or
at
least
a
reasonable
name,
that
both
has
like
a
reasonable
cardinality
and
is
like
descriptive
enough
that
if
human
looked
at
it,
it
would
be
fine,
but
I
should
also
point
out
in
terms
of
funneling
this
stuff
off
a
big
way
this
stuff
is
going
to
get
funneled
off.
D
Is
that
you
know
this
data
is
all
coming
from
a
browser
or
a
mobile
client
like
all
of,
at
least
in
the
case
of
client-side
events.
All
of
this
that's
like
a
huge
amount
of
data.
That's
gonna,
possibly
all
go
into
like
a
specialized
system
and
in
those
cases
you
don't
really
need
to
be
sniffing.
The
attributes
there's
some
kind
of
gateway
sitting
on
the
public
internet
where
all
of
that
information
is
getting
ingested.
D
That
is
totally
separate
from
where
all
of
your
server-side
information
is
coming
in.
So
there's
it's
also
feasible
when
you're
building
a
pipeline
that
you
don't
have
to
do
any
sniffing
at
all.
You
know
this
stuff
is
coming
it's
coming
from
a
client,
because
it's
it's
coming
through
that
public
congestion
point
and
you
can
just
send
all
of
that
information
off
potentially
too
to
to
a
back
end
that
can
then
drop
stuff.
It
doesn't
care
about
or
do
whatever
it
does,.
F
D
A
D
Maybe
yeah
I
mean,
I
think
I
think
if
you
gave
application
developers
like
a
better
api,
then
they
might
be
more
thoughtful
about
what
what
they're
doing
with
it.
But
I
still
think
at
the
end
of
the
day,
you're
gonna
have
just
like
printf
equivalent
logs
here
and
there
in
application
code
like
that,
like
that'll,
never
fully
die.
It's
not
that
every
thing
you
want
to
record
is
definitely
going
to
have
like
an
event
name
classifier
potentially,
but
but
I
think
people
would
probably
think
more
about
how
they
structured
their
stuff.
D
E
F
What
do
you
imagine
a
backend
would
do
if
the
name
field
is
present,
but
there's
no
attributes
that
qualify,
that
for
as
like
a
browser
event
or
any
specific
class,
you
think
it
just
falls
through
into
like.
You
know
the
default
case
and
gets
treated
like
the
rest
of
the
logs.
Where
you
know
name
is,
is
not
present.
A
D
D
They
will
start
providing
utility
to
their
users
just
kind
of
this
in
a
utility
that
I
think
is
very
similar
to
how
how
tracing
systems
work,
where
like
user
invents,
some
some
event,
name
or
event
type
and
then
so
it's
just
like
the
event
name
is
like
fubar
and
then
they
can
go
into
their
back
end
and
they're
like
I
want
to
start
aggregating
fubar
in
some
way,
and
I
think
you
know,
as
time
goes
on
systems
that
ingest
logs
will
start
providing
more
more
tools
around
letting
you
look
at
that
stuff
in
aggregate.
D
A
Maybe
so
in
this
situation,
you-
probably
maybe
you
want
to
be
able
to
split
these
data
streams
in
some
way
route
them
to
different
places
so
that
you
can
process
them
differently,
maybe
show
them
differently.
For
that,
I
think
we
probably
want
to
have
the
notion
of
the
scope
attributes.
I
I
posted
this
earlier,
but
I
want
to
emphasize
this.
This
is
an
easier
way
to
to
solve
that
particular
problem.
A
Instead
of
unpacking
all
the
payload
and
looking
at
each
individual
event
or
log
record,
and
then
it's
indeed
all
of
its
attributes
to
figure
out
what
is
it?
Is
it
a
browser
event?
Instead
of
that,
I
think
we
need
to
have
a
more
efficient
way
of
looking
at
a
bunch
of
events
and
saying
these
all
belong
to
browser
events.
These
are
all
browser
events.
This
goes
to
to
that
particular
place
of
my
processing
pipeline,
and
these
all
are
profiling.
Events
and
the
rest.
I
don't
know
what
this
is.
These
are
just
just
logs
store
them.
A
D
A
Questions
right,
I
see
events.
I
want
to
understand
what
kind
of
events
these
are
from
the
perspective
of
where
they
go.
I
need
to
make
a
routing
decision,
and
once
I
make
that
routing
decision
within
that
particular
vertical,
I
want
okay.
This
look
like
they
are
browser
events,
but
what
kind
of
browser
event
this
is
right.
Are
these
clicks?
This
is
a
click.
Maybe
it
has
a
position.
It's
an
x
and
y.
A
We
have
that
envelope
already
we
have.
This
notion
of
the
scope
exists,
it's
in
the
protocol.
We
have
that
in
the
api,
but
there
is
no
use
way
of
just
to
to
provide
user
defined
attributes
with
that.
So
this
proposal
adds
just
that
right
to
the
scope
and
you
can
tag
them
in
a
specific
way
and
then
everything
emitted
from
that
scope
becomes
part
of
that.
It's
a
these
are
all
browser
events
right.
You
meet
it
from
there
using
that
particular
emitter.
A
They
are
all
browser
events
and-
and
it
works
nicely,
if
you
think
of
it
from
the
code
based
perspective
like
what
it
would
look
like
in
the
code.
It's
it's
exactly
how
you
would
want
it
to
do.
You're
not
going
to
be
mixing
different
event,
emitters
for
different
purposes.
You
get
one
you
give
it
a
name.
You
give
it
an
attribute
which
says
all
these.
These
are
all
going
to
be
my
browser
events.
I'm
going
to
emit
my
javascript
events
using
this,
this
scope,
yeah.
C
D
F
Sdk
you
have
like
in
this
idea
of
scope
attributes.
Then
you
know,
I
think,
tigran's
saying
that
scoped
scope
attributes
would
be
immutable,
but
what,
if
you
could
have
a
login
emitter
that
was
scoped
to
the
session
for
image
for
each
session?
You,
you
create
a
new
log
emitter
where
a
session
is
just
one
one
id
you.
D
Yeah
it
gives
us
and
the
the
advantage
here
potentially
is,
if
we're
already
creating
an
api
to
to
build
these
scopes,
then
that
might
mean
we
could
continue
to
not
have
an
api
for
basically
like
resource
scoping
right
because,
like
like,
the
other
problem
we
have
is
like.
D
Resources
have
have
no
api
currently,
so,
even
if,
if
we
want
to
put
the
session
there
and
then
say
like
you
know,
you
can
load
up
new
resources
later
and
now
all
future
batches
of
data
have
this
resource
like
we
don't
have
an
api
for
doing
that,
and
and
adding
that
potentially
opens
up
a
whole
can
of
worms
but
yeah
it
it
might
be.
It
might
be
more
straightforward
to
do
it
with
with
scoped
scoped
instruments.
Yeah.
A
Yeah
so
the
way
scope
works
today
is
you
obtain
a
tracer
or
a
meter,
or
maybe
a
log
emitter
in
the
future
or
an
event
emitter,
and
for
the
lifetime
of
that
object
of
that
emitter,
all
the
attributes
should
be
immutable
and
even
a
lifetime
is
is
defined
in
a
way
that,
during
that
lifetime,
the
session
id
is
not
changing.
Then
you're,
good
right.
You
can
attach
it
to
this
code,
but
you
you
will
have
to
recreate
a
scope
and
obtain
a
new
one.
A
Every
time
you
have
a
new
session
id
if
it
changes,
while
your
application
is
active,
which,
which
can
be
the
case
for
single
page
applications
right.
So
if
you
keep
it
long
enough,
maybe
the
session
id
is
refreshed
or
something
like
that.
D
D
Other
example
right,
like
mobile
mobile
devices,
you
go
to
you,
don't
you
don't
kill
it's
not
like
a
browser
page
where
it
dies
and
gets
refreshed
yeah.
It
goes
to
sleep
and
then
wakes
up
four
hours
later
or
tomorrow,
and
you
need
to
refresh
a
bunch
of
a
bunch
of
this
stuff
and
and
that's
just
like
we
that's
not
a
concept
that
we
have
like.
We
have
thought
about
in
our
apis
at
all.
Basically,
because
it's
it's
less
of
an
issue
on
the
server
side.
D
So
yeah,
I
don't
know
if
we're
making
life
hell
for
people
to
say
they
have
to
regenerate
their
instruments
in
order
to
do
that,
because
you
know
you
kind
of
want
to
create
your
instruments
once
at
the
beginning-
and
you
know,
do
you
want
to
to
just
make
this
a
mutable
thing
in
some
way?
I
don't
know
it's
we've
dodged
it
until
session
id
showed
up
and
there
are
probably
other
resource
attributes
that
that
function.
D
Similarly,
but
again,
it's
definitely
more
on
like
the
mobile
side
like
location-
and
you
know
things
like
that,
but
I
I
think
I
think
we
we
actually
need
to
do
some
prototyping.
D
The
client
instrumentation
sticks
by
the
way
like
willing
to
like
do
the
prototyping
work
around
around
some
of
this
stuff,
but
but
we
should
definitely
think
that,
through
before
we
before,
we
toss
it
into
the.
A
D
Muted
yeah,
it's
it
definitely
complicates
your
sdk.
Like
your
exporting
chain,
you
know
potentially
gets
and.
A
D
And
I
think
I
think
that's
the
thing
we
want
to.
I
think
we
want
to
design
for
is
like.
What's
the
way
we
can
do
it,
that
that
makes
the
instrumentation
like
sane
like
like
we,
I
I
don't.
It
would
be
sad
if
we
got
into
a
situation
where
people
have
to
wrap
their
instrumentation
objects
in
some
kind
of
outer
layer
of
stuff
right
so
that
they
had
can
swap
them
out
under
the
hood
like
if
we
force
everybody
who
uses
our
apis
to
do
that
kind
of
like
they're
yeah
and
then.
A
D
Yeah,
so
that's
that's,
that's.
I
think
we've
actually
done
a
pretty
good
job
with
that.
So
far.
Actually,
but
yeah,
this
the
scope,
stuff,
is
actually
the
the
place
where
we
we
should
make
sure
we
prototype
it
well
before
so.
F
Are
mutable
like
how
would
that
actually
look,
so
you
have
a
log
emitter
or
an
event
emitter
and
you
you
obtain
an
event
emitter
with
the
the
name
and
your
version
and
your
schema
url
and
then
because
scope
attributes
are
going
to
be
mutable.
You,
don't
you
don't
you
don't
set
those
when
you
are
when
you're
obtaining
your
event,
emitter,
you,
you
set
those
when
you're
recording
an
event.
A
F
C
Yeah,
so
the
the
way
I
wrote
it
in
the
sessions
proposal
ted
is,
you
know
there
would
be
a
there
would
be
a
session
context,
you
know
and
there
will
be
processors.
You
know
which
will
you
know
inject
the
session
context
into
the
events
once
they
are
submitted
yep.
C
So,
instead
of
you
know
when
when
that
injection
happens,
you
know
they.
You
know
it
could
go
into
the
into
the
scope.
D
Exactly
right
now,
it's
I
think
that
the
tricky
bit
there
like
yeah
using
context
and
context
propagation,
is
like
a
good
place
to
put
this
stuff,
or
at
least
it
would
work
for
session
id.
It's
just
that
you
with
our
current
implementations.
D
C
Yeah,
so
the
batch
processor
could
do
that
could
do
the
deduplication
yeah,
because
that's
the
last
one
that
you
know.
I
think
in
the
last.
A
D
B
Lot
of
good
points
brought
here,
so
my
topic
is
maybe
more
like
an
observations.
Maybe
let
me
share
my
screen
and
could
tell
you
what
I
was
thinking,
so
it
all
started
that
I
have
seen
this
question
on.
I
think
on
open
telemetric
letter
discussion
by
one
of
the
well
open
telemetry
users
about
the
log
being
emitted
and
there
is
trace
id
and
span
id
here,
but
it's
not
present
when
it
goes
to
the
collector.
So
I
was
like
checking
this
out
and
I
found
okay.
B
This
should
work,
but
the
user
did
not
provide
more
detail.
So
I'm
not
sure
what
was
exactly
happening,
but
then
I
started
thinking
like
that.
I'm
not
sure
what
is
the
current
progress
on
providing
this,
let's
say:
support
for
for
emitting
logs
via
appenders
or
other
things
in
various
instrumentation.
As
the
case,
I
see
that,
for
example,
in
open
telemetry
java
instrumentation,
you
can
specify
logs
exporter
right
now
and
I
think
that
in
the
auto
instrumentation
this
means
that
the
log4j
appender
can
start
exporting
logs
through
otlp
and
yeah.
B
I
think
I'm
curious
if
you,
if
you
maybe
have
more
details
on
what's
the
current
status
of
of
that
or
maybe
if
we
should
bring
some
sort
of
resource
like
some
table
or
or
some
readme.
That
would
provide
some
guidelines
for
for
users
how
to
use
this
capabilities
and
so
on.
F
Yeah,
I
can
provide
a
little
bit
of
detail.
No
table
like
you
mentioned
exists,
but
the
hotel
java
agent,
if
you
install
that
it
will
and
you
enable
log
export
via
otlp,
it
will
collect
logs
from
log
back
or
log4j
route,
those
to
the
open,
telemetry
log,
sdk
and
export
them
over
otlp.
F
You
include
the
there's
a
log
appenders
for
log
for
j
and
for
logback
that
you
can
include
as
a
dependency
from
your
application,
and
then
you
can
configure
a
logging
template
that
references
that
appender
and
if
you
do
that,
then
the
the
logs
will
be
routed
collected
from
your
your
log
framework,
routed
through
the
open,
telemetry
log
sdk
and
wherever
you
decide
to
export
them.
So
it's
available
with
and
without
the
agent.
F
So
I
sort
of
there's
a
there's
an
example
in
for
I
work
for
new,
relic
and
new
relic.
We
have
a
repository
that
contains
some
examples,
but
in
in
one
of
the
examples
demonstrates
that
there
isn't
one
that
is
part
of
the
open,
telemetry
java
instrumentation
project
itself,
but
there
there
probably
should
be.
A
Yeah
that
would
be
great
to
have,
and
if
you
have
one
at
new
relic,
maybe
you
can
just
post
a
link
to
that
in
the
discussion
to
help
this
person
and
it
it.
It
sets
the
the
context
as
well
right,
the
trace
id
and
spam
id.
If
you
use
log4j,
I
suppose
the
trace
id
and
span
id
are
populated.
Are
they.
A
A
Probably
not
not,
I
think
that
we
had
three
languages
with
experimental
implementations
of
the
logging
as
the
case
so
java
python
and
one
more.
B
Yeah,
so
so
so
what
I'm
wondering
is,
if
we
should
follow
with
more
like
sdks
and
and
the
one
I
have
in
mind
is,
is
go
long,
because
that
would
allow
us
to
use
it
in
open,
telemetry
collector,
and
I
think
this
is
something
we're
missing
currently
like
the
ability
to
to
to
configure
the
the
lock
output
from
the
collector.
So
maybe
we
could
use
it
for
on
telemetry
reporting
and
such.
B
All
right,
so
I
would
say
that
my
my
my
curiosity
has
been
filled
like
so
so
thank
you
for
for
for
the
update.
I
think
that
yeah,
the
examples
will
be
awesome
to
have.