►
From YouTube: 2022-09-28 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
B
B
Okay,
then
we'll
come
back
to
it
if
he
joins.
What's
the
second
item
event,
API
usage,
clarification.
What
is
this
about?
Who
added
it?.
F
And
that
one
so
and
Alan,
West
and
I
are
working
in
the.net,
SDK
and
API
implementing
events,
blogger
provider,
all
the
new
stuff.
So
we
have
a
couple
questions.
We
have
a
couple
logging,
libraries
in.net
that
seem
like
they
support
logs
and
events,
meaning
you
can
emit
a
log
that
has
a
strongly
typed
name,
usually
also
with
like
an
integer
ID,
and
you
also
have
sort
of
a
concept
like
a
domain
you
have
in
one
Library,
it's
called
like
a
category
name
and
the
other.
F
You
have
a
source
name,
so
we've
kind
of
gone
back
and
forth
as
we're
porting
this
code,
which
I
think
technically
they're
like
log
appenders
right.
So
these
are
like
libraries
out
there
we're
shipping
like
Bridges,
so
that
you
can
have
your
existing
code
using
those
libraries
and
it
will
feed
through
oh
hell,
so
we're
trying
to
figure
out
is
for
these
strictly
what
we
call
logging
libraries,
it's
even
unclear.
F
If
there
are
event
libraries
I,
don't
know
we're
not
sure
if
we
should
be
routing
those
event,
names
and
Source
things
through
the
event
API
or
the
log
API,
with
just
different
attributes
that
are
specific
to
those
Frameworks,
so
really
I
think
what
we're
looking
for
is
just
Clarity
on
the
use
cases
for
here's.
When
you
use
events,
here's
when
you
use
logs
events
can
be
logish
or
they're.
Just
for
like
browser
interactions.
B
So
I
think
the
the
idea
was
that
for
appenders,
which
seems
to
be
the
case,
is
that
you
use
the
log
logging
API
right.
It's
the
one
that
police
is
the
least
amount
of
constraints
or
makes
the
least
amount
of
assumptions
of
the
shape
of
your
log
record
and
gives
you
the
complete
flexibility
to
form
the
log
record
in
a
way
that
you
need
it
to
be
formed,
I,
guess
now.
B
The
question
is
how
you
map
the
concepts
from
the
particular
login
Library
into
the
open,
Telemetry
Concepts,
and
whether
you
use
the
particular
semantic
conventions
or
no
I
think
it
needs
to
to
be
considered
specifically
I!
Guess
you,
if
you
can
post
the
the
link,
I
guess
to
the
specific
Library
we
should
probably
be
discussing
the
details
of
that
is
event
domain
semantically.
The
same
thing,
as
is
the
the
category
of
the
logging
library
that
you
use.
If
it
is,
then
you
map
it
to
that
that
thing
right.
B
Attribute
that
you
place
on
a
log
record
or
no
I
wouldn't
use
the
events
API
for
this
because
event,
events
API,
is
that
the
one
that
is
that
that
defines
the
shape
of
the
log
record
in
a
very
specific
way,
which
is
the
open,
telemetries
event
and
and
that
logging
Library
likely
is
not
semantically
generating
an
open,
Telemetry
event
right,
which
is,
which
is
a
more
narrow
definition
of
what
log
record
is
so
probably
stay
away
from
that
when
you're
implementing
a
bridge
just
use
the
the
logging
API
directly.
F
B
F
G
Yeah
I
think
another
part
I,
don't
I'm
not
looking
at
the
specification
right
now,
but
I
think
that
there's
also
room
within
the
specification
for
people
to,
of
course,
Define
their
own
domains,
event,
domains
and
event,
names
and
so
I
think
that
guidance
to
end
users,
too,
would
be
useful
here
when
do
I
create
my
own
event
domain
name
versus
just
log.
This
out
it.
A
G
G
B
B
Yeah
well
yeah,
here's
what
it
says:
if
one
of
them
applies,
then
their
respective
value
must
be
used.
Otherwise
a
custom
value
may
be
used,
so
we
allow
custom
values
which
I
guess
means
that
at
the
end
as
the
end
user,
you
can
make
your
choice
now
whether
you
can
bring
wholesale
another
concept
that
the
category
in
this
case
of
the
library
and
map
it
to
the
event
domain.
B
F
D
F
B
The
guidance
here
should
be
that,
if
you're
defining
your
own
space
of
names
for
the
events,
if
click
is
a
possibility
essentially,
then
it's
a
different
domain.
It
has
to
be
a
different
domain.
Otherwise
it's
going
to
conflict
with
the
event
names
in
some
other
domain
in
browser
domain
right.
So,
if
you're
inventing
your
own
event
names,
then
you
have
to
have
your
own
domain
as
well.
That's
the
idea,
essentially.
F
Yeah
that
totally
makes
sense,
which
then
sends
my
mind
back
to
our
original
discussion,
where
I
had
some
event.
Logging
Library,
like
we
have
one
called
Event
Source
and
you
log
events
and
they
have
names.
So
it
feels
like
we
should
use
the
event
API,
but
I
don't
know
just
it
puts
my
mind
in
a
pretzel
yeah.
B
That's
that's
the
thing
with
a
bridge
right,
you're,
bridging
two
different
worlds.
If
this
world's
defined
Concepts
in
a
way
that
they
match
together
like
there,
is
an
exact
match
between
what
is
called
category
in
World
a
and
what
is
called
event
domain
word
b.
If
that
is
an
exact
match,
you
can
mop
those
if
there
is
no
exact
match.
B
G
G
Advice,
though,
is
good
in
that
I
think
opening
up
an
issue,
maybe
maybe
once
if
we
can
come
up
with
some
kind
of
concrete
patterns
of
use
in
with
these
libraries
that
really
do
feel
like
they
match
open
Telemetry
or
maybe
we
still
have
the
question
of
whether
they
match
open
telemetries
conventions.
G
Then
we
can
bring
that
back
to
the
group
and
we
can
kind
of
dissect
it
together.
C
So
another
thought
that
I
have
is
you
are
talking,
is
there's
a
section
in
the
data
model
that
is
a
set
of
example,
mappings
from
various
other
log
systems
into
the
open,
Telemetry
data
model,
and
maybe
it's
worth
opening
a
PR.
To
add
this
example
that
you're
talking
about
with
you,
know.net's
Event
Source
to
this,
so
that
we
can
have
a
discussion
as
a
group-
and
you
know
you
know
further
our
our
shared
understanding
of
of
what
the
the
field.
B
Yeah
those
those
example
mappings
are
a
result
of
exactly
this
kind
of
an
exercise
we
compared
to
different
worlds,
the
open
Telemetry
world
and
whatever
is
it
that
we're
mapping
to
it,
and
if
we
saw
a
match
we
we
essentially
made
it
a
role
in
the
mapping.
If
there
wasn't
a
match,
then
then,
then
it
became
maybe
a
role
with
with
just
one
column,
saying
that
this
maps
to
a
custom
attribute
of
something
like
that,
so
that
those
mappings
are
exactly
the
result
of
exercises
like
this,
like.
B
B
So
it
may
not
be
as
easy
to
do
right,
because
when
we
did
those
mappings
the
example
mappings
that
was
referring
to,
they
were
between
open
Telemetry
world
and
a
specific
definitions
of
other
logging
like
like
worlds
like
like
syslog,
which
has
a
specification
with
tons
of
documentations
explaining
the
semantics
of
what
the
fields
are
in
case
of
a
logging,
Library
I'm,
guessing
it's
going
to
be
very
sparse,
but
that
that
the
meaning
of
what
a
category
is
like
at
best
you're
going
to
get
maybe
a
line
in
a
documentation
somewhere.
B
G
I
think
that's
fair.
It
too
was
my
inclination
to
treat
these
libraries
not
as
open
Telemetry
events,
but
as
Michael
and
I
have
been
talking
about
this
more
and
more.
A
B
One
other
possibility
is,
if
you're,
not
sure
you
make
this
a
configuration
option
for
the
bridge
right.
The
end
user
makes
the
choice
whether
they
want
to
mop
the
the
category
from
the
library
a
to
an
event
domain
in
open
Telemetry
when
they
are
setting
up
the
breach.
If
they
want
it,
they
get
it.
If
they
don't
want
them,
they
don't
right.
So
if
we
don't
know
ourselves
as
open
Telemetry,
we
give
you
the
tools.
You
make
a
decision.
C
Because
it,
you
know,
based
on
what
you,
what
you
and
and
Macau
were
saying
it
sounds
like
it's
kind
of
situational.
Sometimes
these
Event
Source
events
look
like
log
records
and
sometimes
they
look
more
like
events,
so
you
know
giving
user.
The
choice
might
be
a.
B
F
The
two
we're
looking
at
are
kind
of
the
most
popular
login
libraries
that
Microsoft
ships
as
part
of
kind
of
the
greater
dot
now
runtime
Event
Source
is
kind
of
a
legacy
when
it's
been
around
for
a
long
time.
The
other
one
is
called
ilogger,
that's
a
little
bit
newer
in
the
last
I,
don't
know
four
or
five
years,
there's
a
bunch
of
other
libraries.
You
know
the
third
party
that
we
haven't
really
looked
at
yet
so
there's
a
lot
of
Investigation.
F
We
need
to
do
we
just
kind
of
pick,
the
ones
that
are
already
in
our
code
and
we
started
there
I'm
sure
we'll
have
more
questions
as
we
dig
into
the
other
ones.
Some
of
these
third
parties
we're
not
we're
not
hyper
familiar
with
their
logging
libraries.
You
know
so
we're
just
kind
of
poking
around
and
like
well.
This
thing
kind
of
looks
like
a
domain,
but
I
don't
know,
there's
a
lot
of
a
lot
of
Debian
that
we
need
to
do.
G
And
like
the
Event
Source
One
in
particular,
that
is
the
one
that
has
me
most
questioning
this
because,
like
Michael
said
like
the
Event
Source,
one
is
pretty
Legacy.
So
there's
been
a
a
lot
of
tools
that
have
been
developed
within
the.net
community
that
consume
Event
Source
and
a
lot
of
it
very
a
lot
of
those
tools,
kind
of
feel
like
they're,
using
it
more
an
event,
type
of
way
like.
H
G
Like
waterfall,
like
kind
of
experiences
and
so
on
from
its
from
the
data
that
it
emits
so.
E
Is
that
is
that
the
one
that
like
I
found
just
now
is
that
the
one
that's
called
locking
Event
Source,
which
is
an
awesome
name,
probably
I,
guess
what
I'm
just
poking
I
think
you
know.
Let
me
let
me
just
get
to
the
point.
You
know
if
this
stuff
has
public
surface,
you
know
if
you
guys
just
want
to
drop
a
link
or
two
of
what
you're
looking
at
into
the
notes.
E
I
mean
just
for
the
further
sort
of
Education
of
the
folks
on
the
call,
not
necessarily
to
look
at
right
now,
but
you
know
I'm
now
curious
I
would
like
to
sort
of
would
be
interesting.
If
you
know
the
larger
crowd
here
can
derive.
Some
sort
of
you
know
some
here
to
four
like
esoteric
knowledge
about
the
use
cases.
B
C
Yeah,
so
this
is
just
an
informative
announcement,
so
in
Java
we
landed
a
prototype
log
and
event
API
that
matches
the
the
spec
work
that
Santosh
recently
was
working
on,
so
that
will
be
available
in
the
next
release.
1.19.0
of
java,
which
will
be
you
know
within
the
next
week
to
10
days,
so
give
that
a.
I
I
Are
there
any
other
known
applications
that
will
be
using
it.
C
So
speaking
as
a
a
vendor
now
putting
on
my
vendor
hat
custom,
events
are
really
popular
amongst
our
users,
so
you
know
the
New
Relic
exposes
apis
for
applications
to
collect
custom
events,
and
so
you
know
we're
going
to
be
playing
around
with
that
and
just
seeing
how
that?
How
that
maps
to
our
internal
data
model
and
so
okay,
explorative
work
on
our
side.
C
I
So
this
is
related
to
the
pr
that
Michael
has
where
he
added
semantic
conventions
for
exceptions
in
logs
and
events,
while
going
through
the
pr
I
realized
that
in
his
PR
he
is
not
giving
the
name
exception
to
the
events,
whereas
the
span
events,
you
know
mandate
the
name
of
the
exception
events,
as
exception
I'm,
wondering
if
there
is
any
specific
reason
why
that
was
made
mandatory
in
Span
events,
because
in
his
example
in
in
the
link
that's
mentioned
there,
he
saying
as
an
example,
you
know
ad
user
failure.
I
So
the
event
name
itself
is
is:
is
a
failure
to
add
an
user,
but
it
has
an
exception
attached
to
it,
which
makes
sense,
which
means
that
any
except
any
event
or
any
exception
you
know,
could
have
any
log
or
an
event
could
have
an
exception.
Similarly,
you
know
spans
could
have
an
exception
and
they
could
have
multiple
exceptions
too.
I
I
can't
think
of
a
concrete
example,
but
currently
I
think
it
limits
us
to
have
only
one
exception
to
us.
A
span.
A
B
I
I
I
A
B
C
Well,
events
span,
events
require
a
name,
and
so
you
know,
while
the
attribute
presence
would
identify
that
this
is
an
exception.
You
still
need
to
call
it
something
in
the
state
of
that
world.
B
Well,
I
mean
you
could
call
it
whatever
is
it
that
is
happening
here
and
the
default
could
be
the
exception,
or
something
like
that,
if
you
don't
know
what
to
name
it,
but
it's
unclear
why
you
are
forcing
the
specific
name,
okay,
anyway,
now
this
is.
This
is
still
experimental
as
well
right,
so
maybe
we
get
rid
of
it.
A
I
Yeah,
but
the
idea
is
to
keep
the
span
events
consistent
with
the
Standalone
events
as
much
as
possible,
so
that
in
future,
if
we
end
up
deprecating
span
events,
then
there
is
this
effort
in
in
mapping.
I
A
I
No
I
understand
so
it's
it's
a
loose
thought
so
so
anyway,
I
think
the
idea
is
to
just
you
know,
keep
some
consistency
between
the
two
as
much
as
possible.
C
So
Santosh
we
were
talking
about
this
a
bit
last
week
when
this
idea
of
adding
exception
semantic
conventions
to
logs
was
proposed,
and
you
know
we
were
saying
hey.
Should
we
add
a
new
API
to
record
exceptions
that
essentially
is
syntactic
sugar
to
create
an
event
with
name
exception
and
well.
C
We
could
figure
out
a
domain
later,
but
you
know
one
of
the
things
that
was
brought
up
was
that
an
exception
can
kind
of
happen
in
multiple
contexts,
like
an
exception,
can
be
present
on
an
ordinary
log
record,
in
which
case
you
would
want
to
that's
not
an
event.
It's
just
a
log
record
that
happens
to
have
an
exception
attached
to
it,
and
so
you
still
want
to
structure
that
exception
information
as
attributes
on
that
log
record
and
not
necessarily
create
an
event
out
of
it.
C
But
then
in
other
contexts
like
so
you
know,
the
exception
is
like
an
event
itself
so
like.
If
there's
like
an
uncaught
exception
that
bubbles
all
the
way
up,
that
that
that's
more
or
event
like
and
so
I
I,
don't
think
we
kind
of
came
to
a
conclusion
last
week,
but
that's
kind
of
where
the
discussion
was
heading
was
that
exceptions
can
happen
and
it
can
mean
multiple
things.
Yeah.
I
Yeah
now
I
think
I'm
I'm
only
wondering
if
we
can
remove
this
line,
would
it
be?
Would
it
break
compatibility.
C
Furthermore,
there's
so
exceptions,
recording
exceptions
is
part
of
the
the
trace
API
itself,
and
so
you
know
there's
a
specific
API
outlined
it's
like
a
helper.
C
You
know
for
adding
an
event
to
a
span
that
says
record
exception,
and
it
just
says
to
that:
the
semantics
of
that
APR
to
add
an
event
which
is
conforms
to
the
exception,
semantic
conventions
and
so
I
think,
like
a
lot
of
SDK
implementations,
you
know
they
Implement
that
record
exception
API
as
creating
an
event
whose
name
is
exception
because
these
semantic
conventions
exist.
But
you
know
to
your
point:
it's
a
bit
strange
because
you
know
that's
Behavior,
that's
built
into
these
sdks,
yet
these
semantic
conventions
are
still
experimental.
C
I
Yeah
and
and
now
the
back
ends
that
do
exceptions,
analysis
you
know
they
could
instead
of
looking
at
the
name.
You
know
they
could
look
at,
for
example,
one
of
these
attributes,
let's
say
exception.type
or
stack,
trace
or
one
of.
I
With
the
exception
name,
space
yeah
that
might
be
sufficient.
I
So
so
so
is
it
okay?
If
we
remove
this,
given
that
this
is
experimental,
have
we
done
such
breaking
changes
in
the
past.
C
I
A
I
Yeah
I
think
the
example
here
that
Michael
has
is
something
like
this,
so
it
could
be
the
same
thing.
C
What
if
we
move
this
line,
so
it
currently
lives
in
the
semantic
conventions
for
span
events,
what
if
we
moved
it
to
the
the
API
definition
of
record
exception
so,
like
you
know
whatever,
so
that
makes
it
very
clear
that
when
you
are
implementing
this
record
exception,
like
API,
you.
D
C
Add
it
as
an
event
with
the
name
exception,
but
you
know
that
line
would
no
longer
exist
in
the
semantic
inventions
for
for,
except
for,
for
you
know,
span
events,
and
so
you
know
I
I,
guess
by
by
that
definition
it
would
any
any
event
with
those
attributes
would
be
an
exception
event.
Not
just
events
whose
name
is
exception.
C
I
That
make
sense
so
you're
you're
suggesting
an
override
where
by
default
it
will
be
named
exception,
but
the
API
can
also
provide
a
an
override
method
that
can
accept
an
exception
name.
C
I'm
sort
of
I'm
saying
that
the
I'm
saying
that
from
the
semantic
convention
standpoint
any
span
event
which
has
those
attributes
would
be
considered
an
exception
span
event,
regardless
of
whether
or
not
it
has
the
name.
And
so,
if
you
go
around
this
record
exception
API
and
you
just
manually
add
an
event
and
you
populate
attributes,
like
exception
type,
exception
message
so
on
and
so
forth,
and
that
still
qualifies
as
an
exception
span
event,
even
without
the
name
I'm
and
I'm,
just
I'm,
just
like
I'm.
C
Just
you
know,
spitballing
here,
I'm
not
like
committed
to
this
idea,
I'm
just
trying
to
figure
out
how
we
might
provide
some
consistency.
Okay,.
F
A
A
That
would
be
potentially
complicating
for
some
things.
Like
you
know,
the
the
AWS
x-ray
exporter
and
The
Collector
uses
exception.
Events
on
spans
to
translate
them
to
exceptions
in
the
AWS
SDK
requests
that
it
makes
it
converts
the
Stacked
race
and
identifies
a
cause,
and
things
like
that,
so
that
they
show
up
as
exceptions
in
in
x-ray.
If
those
were
two
different
Telemetry
streams,
I'm,
not
sure
that
would
be
feasible.
C
And
maybe
there's
some
vendors
out
there
that
accept
the
you
know
otlp
spans,
but
don't
accept
otlp
logs,
yet
maybe
they're
like
a
trace,
specific
vendor
and
in
that
case
I
think
they'd
probably
prefer
to
have
all
that
data
in
one
place.
But
you
know
I
think
the
question
that
you're
asking
is
is
kind
of
what
underscores
what
Santos
said
earlier,
where
some
folks
have
suggested
that
perhaps
that,
once
the
the
log
and
event
API
is,
is
complete
and
mature
that
you
know
there
there
might
be
consideration
to
deprecating
span
events.
F
I,
don't
necessarily
have
an
issue
with
the
spam
record
exception
to
me
that
Bitcoin
makes
it's
nice
it's
well
encapsulated.
If
you
want
to
slap
an
exception
on
the
span,
it
has
a
well-defined
event
if
you
needed
to
do
something
kind
of
like
what
I
have
here.
With
this
example
with
the
add
user
failure,
you
could
have
two
events
on
the
span
right.
You
could
have
one
for
the
ad
user
and
then
you
could
have
the
exception.
There's
there's
no
penalty
for
doing
that.
Right.
I
Foreign
I
was
thinking
of
a
concrete
example.
It
may
still
not
be
concrete,
but
think
of
a
a
bad
job
where
it
is
reporting
updates
and
at
each
step
you
know
there
could
be
failures.
H
H
You
know,
you've
got
a
failure
that
you
want
to
flag
on
your
your
span,
but
you
know
what
the
failure
is.
You
just
want
to
have
the
exception.
So
if
that
span,
if
that
Trace
got
dropped,
then
that
you're
fine
with
that,
but
if
you've
got
an
uncaught
exception,
whether
or
not
that's
correlated
with
a
span
with
a
trace,
you
want
to
be
able
to
put
that
up
there.
So
it's
you
know
that
that's
kind
of
the
one
of
the
things
that's
popped
up.
F
H
Yeah
so
so
kind
of
the
idea
is
that,
like
you
know,
if
you're
willing
to
drop
those
events,
if
you
drop
that
Trace,
then
you
would
would
do
that
those
as
a
span
events,
if
that's
something
that
you
want
absolutely
the
event
to
come
out,
you
would
do
that
as
a
an
event.
That's
correlated
with
the
span
does
that,
if
that
makes
sense,.
A
So
the
other
thing
I
wanted
to
talk
about
was
the
idea
that
events
can
be
identified
by
the
set
of
attributes
that
they
have,
rather
than
having
a
name
that
identifies
them.
And
then
you
can
say
what
attributes
you
should
expect,
based
on
that
name
and
I
I'm,
not
so
sure
that
kind
of
duct,
typing
them
or
letting
them
be
implicit,
is
the
right
way
to
go
here.
A
G
H
Well,
isn't
that
kind
of
where
we've
settled
on
the
difference
between
logs
and
events,
that
that
an
event
is
something
that
has
a
concrete
name
and
so
a
concrete
type
and
a
log
event.
You
know
the
the
it
can
match.
Multiple
shapes
right
like
it's
got,
multiple
RNA
RNA
sites
or
whatever
that
like
it
can
be.
You
know
it
can
match
the
the
kubernetes
standards
and
it
can
also
match
web
server
standards
like
so.
H
A
single
log
event
can
be
viewed
in
multiple
contexts
and
same
thing
with
an
event,
but
you
know
event
is
enforced
on
a
certain
type.
C
Yeah
I
think
that
tracks,
and
so,
if
you
follow
that
logic,
then
it
would
not
be
a
good
idea
to
allow
exception
span
events
to
be
named
things
other
than
exception,
because
it
would
kind
of
break
the
the
the
conventions
that
we're
establishing
with
events.
But
you
know
I
think
going
up
a
few
levels
to
bring
it
back
to
santosh's
original
question
of
this
PR
and
adding
these
semantic
inventions
for
for
logs.
C
C
Yet
we
could
later
extend
that
and
add
such
an
event,
but
that
that's
not
what
we're
doing
in
this
PR
or
just
you
know
saying
that
you
know
if
a
log
record
has
exceptional
information
on
it.
This
is
where
it
will
be
contained,
and
you
know
you
have
to
rely
on
the
the
duct
typing
to
detect
whether
that
log
record
is
has
exception.
Information.
C
I
I
I
have
the
next
topic:
I
I'm,
looking
just
for
some
initial
thoughts
and
figure
out
what
approach
to
take.
So
this
is
request
for
a
mechanism
to
export
the
spans
and
events
together,
and
this
is
a
concern
mostly
for
the
rum
agents
which
are
on
the
internet,
mobile
apps
and
the
browser
apps.
I
So
think
of
this
as
a
batching.
You
know
taken
to
the
next
level,
where
you're
not
just
touching
the
individual
spans,
but
also
batching
them,
along
with
the
logs
or
events.
I
So
one
thing
to
notice
here
is
that
this
is
more
helpful
to
the
client,
the
the
internet
agents
that
are
running
on
the
mobile
devices
and
the
browsers,
and
they
won't
be
sending
their
data
through
a
collector
in
in
most
of
the
cases,
there
might
be
some
situations
where
people
would
deploy
collectors,
but
in
most
of
the
cases,
these
agents
send
their
otlp
data
directly
to
the
to
the
back
end,
the
the
vendors
backends.
I
So
so
this
unified
exporter
could
potentially
be
a
custom
solution
where
we
could
just
build
the
unified
exporter
and
then
connect
it
to
our
backends.
But
I'm
wondering
if
this
is
valuable
in
general,.
A
This
feels
to
me
like
solving
it
at
the
wrong
layer
of
abstraction.
This
is
this:
is
a
browser-specific
transport
layer,
kind
of
issue
right
sure,
but
things
that
are
constraining
the
number
of
HTTP
requests.
You
can
make
prayer.
I
Yeah
and
it's
not
just
constraints
on
the
clients,
but
it's
also
a
performance
Improvement
on
the
receivers.
It's
like
it
will
be
half
the
number
of
requests
connections
now.
A
It
might
seriously
complicate
receivers
as
well,
though,
like
if
you
look
at
the
collector
receiver
there
there's
the
otlp
receiver
has
one
component
but
three
separate
handlers
for
each
of
these
streams
and
they
attach
to
different
pipelines.
If
there's
a
single
ingest,
endpoint
I'm,
not
sure
that
it's
easy
for
it
to
differentiate
between
which
pipeline
it
needs
to
send
to.
A
A
I
Yeah
I
think
in
browsers
the
grpc
support
is,
is
is
limited,
so
it's.
D
A
D
Yeah,
so
any
client
that
that
has
a
potential
restriction.
It's
it's
a
combination
of
the
number
of
connections.
It's
led
to
the
amount
of
data
it's
sending
out
and
the
the
CPU
time
involved
in
constructing
the
different
packages.
A
I
think
this
might
be
the
same
sort
of
thing
where,
yes,
we
could
change
the
protocol
in
order
to
get
some
of
these
benefits,
but
we
could
also
look
further
down
the
sack
and,
and
can
we
use
HTTP
2
to
get
these
same
benefits
without
changing
what
we're
doing
and
what
all
of
our
receivers
and
exporters
are
doing
in
all
of
our
sdks.
D
The
gzip
thing
doesn't
work
for
every
platform
because
in
a
browser,
unless
you're
using
the
new
experimental
native
compression,
it's
additional
bytes
and
a
different
additional
CPU
to
play
with
so
yeah.
This
request
from
Centos
is
really
about
you
know.
Can
we
have
a
single
batching
mechanism,
so
you
don't
have
multiple
sets
of
resources
and
timers
and
everything
running
locally.
So
it
is
just
a
single
batching,
Set,
It,
Off
and
I
understand
the
complications
on
the
back
end.
C
So
you
know
obviously
there's
a
lot
of
things
that
would
be
impacted
by
this
type
of
this
type
of
change
to
the
protocol,
and
so
a
lot
of
people
are
going
to
have
opinions
from
folks
that
work
on
the
collector
to
folks
that
work
on
the
sdks
to
vendors
which
implement
the
protocols
that
it
you
know
that
that
accept
this
data.
So
it
has
a
really
it's
really
wide
reaching.
C
As
someone
who
works
on
the
sdks,
I
can
say
that
you
know
this
type
of
thing
would
be
there.
There's
no
there's
no
easy
way
to
implement
this
today.
If
you
wanted
to
go
and
Implement
an
ex
like,
you
know,
even
provide
a
custom
solution
for
like
a
point
use
case.
It
would
be
kind
of
challenging
to
do
this
today
so
that
that's
that's
my
feedback.
C
I
I'm,
definitely
interested
to
hear
what
other
people
have
to
to
say
that
have
that
have
a
stake
in
this,
but
yeah
it
would
be
challenging.
E
So
maybe
this
maybe
I'm
too
naive
here,
but
would
this
not
just
be
a
layer
on
top
of
what
already
exists?
Potentially,
it's
basically
a
pattern:
protocol
of
sorts
that
doesn't
necessarily
need
to
touch
or
change
any
of
the
existing
protocols,
but
gives
a
new
essentially
export
a
receiver
spec
that
can
basically,
you
know,
take
the
various
signals
and
Patch
them
up
in
an
interesting
way,
and
then
it's
optional
to
support.
E
But
if
the
HTTP
solves
the
problem
we
had
in,
like
I
was
thinking
not
quite
going
all
the
way
up
to
that
layer
or
down
to
that
layer
whatever,
like
I,
was
thinking
to
do
it
as
a
sort
of
open,
Telemetry
kind
of
layer
protocol
layer
on
top
of
the
existing
area.
It
might
be
naive,
but
that's
the
only
thing
that
comes
to
mind
anyways
as
far
as
I'm
concerned,
if
HTTP
solves
the
proper
HTTP
2
solves
the
problem
and
is
widely
supported
by
our
clients
that
you
care
about
even
better.
D
Except
we
only
have
fans
today
we
don't
really
have
a
modes
for
a
lot
of
the
platforms.
So
I
guess
mikhail.net,
you
don't
support
logs.
Yet
for
you.
D
D
F
C
Some
other
thread
needs
to
be
like
watching
that
queue
and
on
some
sort
of
interval
pulling
items
off
of
it
aggregating
into
like
a
single
payload
and
sending
over
the
network
so
definitely
possible.
Now
that
I
think
about
it
more
with,
but,
like
you
know,
you
have
to
be
okay
doing
those
kind
of
complicated
steps,
and
you
know
you
can't
do
it
with
otlp.
You
have
to
deal
with
some
sort
of
vendor-specific
protocol.
A
Yeah
yeah,
so
I
I,
know
grpc
is
not
an
option
here,
but
in
in
the
go
SDK
our
exporters
for
otlp
can
be
given
a
grpc
connection.
So
you
could
create
a
grpc
connection
and
share
that
amongst
well
exporters
for
all
of
the
different
signal
types.
They'll
still
end
up
making
distinct
requests.
You
know
send
metrics
Centrics
and
logs,
but
you
would
be
able
to
share
the
same
connection.
A
I
D
Yeah
and
the
browser
case
is
more
constrained
because
you
don't
even
control
the
connection.
All
you
do
is
you
use
the
the
apis
to
say,
send
it
to
this
end
location
and
then
the
browser
takes
care
of
pulling
the
any
connections
that
I
might
have
around
the
protocol.
C
I
Okay,
yeah
I'll
do
some
study
on
HTTP,
2
and
and
then
yeah
great.