►
From YouTube: 2023-03-01 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
C
A
I
think
yes,
let's,
let's
put
together
like
we
discussed
right
already,
let's
put
together
a
couple
slides,
let's
see
if
we
can
present
it's
on
Tuesday
on
Tuesday
I'm,
still
here,
I'm
leaving
on
Wednesday
so
yeah.
Let's
maybe
try
to
do
that
back
on
Monday.
We
also
have
maintainers
making
kind
I,
don't
know
if
we're
ready
by
then
maybe
we
can
also
present
there.
A
A
This
is
what
it
looks
like
and
we
are
planning
to
declare
that
stable
and
we
also
have
prototypes
in
three
languages
and
here's
an
example
of
a
prototype,
and
then
maybe
we
show
the
the
Java
prototype
with
some
code,
samples
and
stuff
like
that
right.
So
we
go
into
more
more
details
of
what
the
prototypes
are
doing
and
we
also
show
the
details
of
the
API
there.
C
A
C
I
can
we'll
chat,
offline,
I
suppose,
but
you
know,
if
you
don't
beat
me
to
it:
I'll
create
the
the
scaffolding
for
a
presentation
and
start
to
put
together
a
kind
of
a
really
trimmed
down
example.
I
know
back
in
the
in
the
issue
you
you
requested
examples
of
the
usage
in
Python
and
net
and
Java
and
I
sent
over
basically
some
test
code,
I'll
kind
of
extract
that
out
to
like
a
standalone
application
that
demonstrates
the
usage,
something.
C
C
C
I
think
it
would
be
useful
for
us
to
elaborate
on
the
specific
characteristics
of
the
of
events,
one
one
they
are
more
advantageous
than
the
other
signals
and
when
the
you
know
using
the
event,
API
is
more
appropriate
than
just
using
your
existing
log
framework
like
log4j
or
log
back
and
I
also
wanted
to
put
I
also
put
together.
Some
some
use
cases
for
events
that
I
thought
are
appropriate.
C
A
I
think
that's
a
good
idea.
I'll
read
the
details.
I
didn't
see
the
issue
that
you
created,
I'll
read
it,
but
I
think
it's
a
it's
a
very
good
idea.
We
probably
also
should
be
looking
for
for
some
input
outside
this
thing
as
well
right,
if
we
can,
it
would
help
as
well
like
us,
maybe
ask
more
broadly
for
the
in
the
specsig
or
maybe
maintainer
seek
for
thoughts
on
what
what
other
use
cases
that
we
haven't,
thought
of
in
this
group
may
exist
for
events
or
events
may
be
more
suitable.
B
Yeah,
probably
tagging
the
people
who
responded
to
your
PR
tigrant
about.
Should
we
get
rid
of
the
events
API
like
I'm
thinking,
you
know
John
Watson,
and
there
are
several
of
us
in
that
one
tagging
on
this,
so
I've
had
a
quick
read
through
it.
Jack
and
I
agree
with
most
of
it,
there's
probably
a
couple
of
things.
That
is
missing.
It's
still
from
my
point
of
view.
It's
still
very
much.
B
C
B
C
Know:
I'd
love
it
if
I'd
love
it.
If
you
could
like
elaborate
on
how
you
think
of
events
when
you
think
events
are
more
appropriate
than
you
know,
using
logs
or
just
you
know,
regular
plane
logs
and
if
you
could
like
add
some
of
the
use
cases
that
you're
thinking
of
maybe
I
know
you're
kind
of
coming
at
it
from
a
ram
and
Quan
instrumentation
perspective.
C
You
know,
even
if
you
could
just
enumerate
some
of
the
most
some
of
the
the
highest
value
use
cases
from
that
domain.
I
think
it'd
be
good
because
it's
still
a
bit
abstract
for
me
what
what
specific
events
would
be
emitted
in
client
instrumentation?
You
know
I've
heard
a
few
things
floated
around,
but.
B
Yeah
so
I
just
pasted
our
spreadsheet
that
we've
gone
through
to
Define
for
at
least
for
browser
events
where
we've
got
the
the
open,
Telemetry
proposed
names
versus
all
the
other
names
used
by
all
the
other
contributors
with
the
different
vendors.
So
these
are
the
most
common
ones
for
a
browser:
they're,
not
they're,
not
the
only
ones.
When
you're
monitoring,
you
know
how
a
user
is
using
it.
Your
a
web
page.
B
C
I
do
have
one
so
I
I
haven't
fully.
You
know
digested
that
that
response
yet,
but
one
thing
that
I've
noticed
is
kind
of
a
recurring.
You
know
point
of
conversation
is
this
idea
of
like
size,
size
constraints,
Over,
The,
Wire,
yeah
and
I
I,
don't
know
exactly
how
to
solve
that,
but
I
think
I
think
we're
kind
of
conflating
issues.
A
C
They're
related,
but
it's
like
you
know,
there's
so
many
problems
to
solve
with
respect
to
the
payload
size
ones
that
I've
heard
are
like.
You
know
that
clients
have
problems,
sending
and
maintaining
multiple
connections
to
an
otlp
receiver,
and
so
we
need
a
way
to
combine
metrics
logs
and
traces
into
a
a
single
request,
and
you
know
this
type
of
thing
where
there's
there's,
there's
lack
of
compression
support
for
this
type
of
telemetry
data
that
we're
sending
up
and
I
I.
C
B
But
it's
still
a
case
of
you
know,
depending
how
you
model
the
data
is
a
direct
effect
of
the
the
size
of
the
data
on
The
Wire,
so
yeah
yeah
for
in
a
browser
runtime.
It
is
a
huge
concern
and
like
one
of
the
other
ones,
I've
gotten
there
is
a
smart
TVs.
We
use
a
couple
of
our
internal
sdks
on
Smart
TVs
and
we
have
to
like
prune
it
down
severely
because
it's
it's
even
us
more
stricter
runtime
than
a
browser,
but
to
effective
a
small
JavaScript
runtime.
A
B
Yeah
and-
and
it
is
worth
looking
into
you
know-
the
biggest
issue
is
like
during
that
page
shutdown.
That's
when
we
we
get
hit
with
all
these
restrictions
from
browsers,
especially
modern
ones,
older
ones.
We
used
to
just
do
an
xh
synchronous,
xhr
and
block
page
navigation
until
we
offload
everything,
but
we
can't
do
that
in
modern,
browsers
anymore.
C
I
think
we
just
need
to
find
a
way
to
to
to
decouple
those
conversations
to
some
extent
they're
related,
but
you
know
it's
without
addressing
it.
It
seems
like
every
conversation
could
kind
of
boil
down
to
payload
size
and
I.
Don't
think
that
you
know
we'll
have
we'll
be
spending
our
time
wisely.
If,
in
every
data
model
in
conversation
it
comes
down
to
payload
size,
Over,
The,
Wire,
yeah,.
B
I
know
for
for
Microsoft
application
insights
we
effectively
have
you
know
we
always
send
the
the
data
in
the
same
manner,
which
effective
as
a
structured
log
but
depending
on
the
the
type
we
then
Hive
it
off
into,
like
you
know,
logs
specific
events
that
we've
identified,
you
know
custom
events
to
users
identified
Etc,
so
that's
sort
of
the
angle
where
I'm
coming
from
that
and
that
we
want
to
be
able
to
Define
and
say
okay.
This
is
this
is
an
event.
C
B
C
B
C
C
B
A
C
A
The
part
I'm
not
quite
sure
about,
should
we
should
we
for
every
log
record
do
that
it's
an
increasing
payload
size
which
and
I
mean
probably
can
be
useful,
but
vast
majority
of
cases.
People
will
not
be
using
it.
So
it's
unclear
right.
Why
are
we
doing
that
for
every
log
record?
Should
it
be
an
opt-in
option.
C
Yeah
like
something
that
came
to
mind
when
you
said
that
was
that
the
trace
SDK
has
this
notion
of
a
configurable
ID
generator
and
the
ID
generators
generate
your
Trace
ID
and
span
ID,
and
what?
If
there
is
a
similar
concept
for
the
log
SDK,
where
you
could
provide
a
configurable
record,
ID
generator
yeah.
C
Do
yeah
it
could
be
right
and
we
you
know
that
would
that'd
be.
That
might
be
a
good
thing
to
include
right.
So
right
now,
all
the
other
signals
or
the
trace
only
has
batch
and
simple
processor.
It
would
be
good
to
have
more
kind
of
built-in
processors
that
do
other
useful
things
within
the
ecosystem,
so
generating
and
appending
an
ID
is
a
useful
thing,
foreign
for
it.
You
know,
use
the
use.
The
extension
point,
the
processor
rather
than
having
you.
A
A
I
think
we
can
do
that.
We
can
say
that
the
log
record
ID
or
is
it
the
uid
uid
Maybe
populated
to
be
as
the
case
using
the
processor,
something
like
that
right
so
that
it's
clear
it's
I
mean
it
already
says
it's
optional
and
optional
I
believe
it's
the
the
new
term,
for
it
is
opt-in
right
or
they
were
changing
that,
but
from
optional
to
opt-in
and
opt-in
is
I,
think
what
we
should
do.
C
Well,
I,
don't
want
to
I
guess,
maybe
then
we
should
consider
merging
this
as
is
or
maybe
with,
like
you
know,
adding
a
little
bit
of
language
to
say
that
you
know
you
should
consider
generating
this
with
a
processor
but
I.
Don't
you
know
if
we
do
want
to
add
a
built-in
processor
to
the
SDK
I,
don't
think
that
it's
necessary
to
Define
this
processor
before
stabilizing,
and
so
you
know,
I
think
it
might
be
good
to
wait
on
that
piece.