►
From YouTube: 2022-10-12 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
B
B
Related
so
I
guess
many
of
you
saw
the
pr
that
I
posted
there
I
wanted
to
discuss
it
and
to
summarize
I
think
the
idea
is
the
following:
the
the
word,
the
term
event
is,
is
very
overloaded
or
it's
unlikely
that
we're
going
to
to
agree
exactly
what
it
means
and
and
people
don't
agree,
and
so
what
I'm
trying
to
do
here
is
that
as
much
as
possible
with
we,
we
avoid
using
the
generic
term
event
and
instead
we
we
do
the
following:
we,
we
are
open
Telemetry
right,
so
we
Define
something
that
is
called
open,
Telemetry
event,
and
our
definition
is
that
it
is,
is
a
it's
a
log
record
that
has
a
specific
shape
right,
the
one
that
has
the
event
domain
and
the
event
name,
and
then
we
have
recommendations
around
okay.
B
So
how
do
you
use
the
open
Telemetry
event?
When
do
you
use
it
when
you
don't
use
it?
What
do
you
do
when
you,
when
you
have
a
generic
event
that
originates
somewhere
else?
Is
it
an
open,
Telemetry
event,
or
is
it
not
so
essentially
I
try
to
address
that
with
an
FAQ
there?
B
B
I'd
like
to
understand
whether
you
think
it's
a
good
idea
as
a
generally
to
approach
it
like
this,
like
to
introduce
the
notion
of
capital
letter,
open,
Telemetry
event
and
then
and
then
Center,
the
I
guess
use
it
as
as
the
reference
point
for
for
all
the
other
questions
that
arise
around
the
events.
C
I'm
a
fan
of
the
approach
I
like
the
pr
that
you
put
out
there
I
think
the
FAQ
section
in
particular
helped
make
things
clear,
I
think
there's
a
few
things
to
work
out,
but
generally
I'm
aligned.
D
E
B
Thanks
Dan,
you
see
a
thumbs
up
from
David
as
well.
Okay,
that's
good!
So
I
guess
yeah!
Definitely,
let's,
let's
make
the
FAQ
more
clear.
I
mean
sure
we
can
discuss
the
details,
I'm
happy
to
to
just
as
necessary
and
I
see.
There
are
suggestions
already
on
the
pr,
so
we
can
definitely
work
it
out.
Okay,
that's
that's
good
I!
Don't
know!
If
does
anybody
is?
Is
there
anyone
who
thinks
it's
a
bad
idea?
Let's
say
right
what
I
proposed?
Let's
maybe
try
to
do
that.
F
I
think
generally
I'm
on
board.
With
you
know,
events
as
being
I
think
was
it
Jack
said
schematized
log
entries
or
something
like
that
right,
they're,
they're
log
entries
that
you
can
trust
something
about
the
structure
of
based
on
some
identifying
attributes,
but
I
think
I
have
the
same
question
that
Dimitri
has
about
this.
This
fact
where
it
says
that
open
Telemetry
events
are
produced
using
over
Telemetry
events
API
and
whether
that's
actually
a
restriction.
We
need
to
keep
okay.
B
So
I
think
open
Telemetry
events
are
typically
produced
using
open,
Telemetry
events
API,
but
if
you
have
a
data
source
that
that
produces
something
that
looks
that
you
can
call
it
an
open
Telemetry
event,
then
it
is
an
open
language
event
right.
It
has
if
it
has
all
the
all
the
characteristics
of
an
opportunity,
email
event,
then,
yes,
it
can
be
an
optical
achievement.
I
mean
I
I,
don't
know
how
helpful
this
definition
is.
B
I,
just
don't
want
to
completely
rule
out
I,
don't
want
to
say
that
strictly
only
events
that
we
produce
using
open,
Telemetry
events
API,
are
the
true
open,
Telemetry
events
right
I,
don't
just
don't
want
to
block
everybody
else
from
from
producing
something
that
is
really
compliant
with
our
understanding
with
the
notion
of
what
an
open
pregnancy
event
is.
Maybe
someone
goes
and
writes
their
own
logging
library
right,
it's
more
of
their
own
SDK
to
create
events
or
I,
don't
know
log
engaging
or
something
else.
B
F
I
think
we're
aligned
on
that.
My
concern
is
that
this
language
seems
to
say
the
opposite
of
that,
though,
it
seems
to
say
that
you
produce
open
three
events
through
the
open,
Telemetry
API
and
if
you're
not
you're,
not
an
open,
Telemetry
event
and
I.
Think
that
was
the
discussion
we
were
having
the
last
week
or
the
week
before
regarding
the
the
kubernetes
events
being
generated
out
of
a
receiver
and
The
Collector,
the
that
isn't
using
the
open,
Telemetry
API,
but
is
just
constructing
P
data
that
has
the
appropriate
shape.
I
mean
I.
F
B
B
So
it
kind
of
is
implied
that
you
can
find
something
that
exists
elsewhere
and
map
it
to
an
open,
Telemetry
then,
and
then
it
becomes
an
open,
Telemetry
event,
so
maybe
whatever
the
wording
is
with
with
that
that
contradicts
with
what
we
were
saying
is
the
right
thing.
So,
let's
fix
that
that
part
of
the
wording.
B
Concepts
yeah
yeah-
that
was
my
intent,
but
but
what
Anthony
is
saying:
I
guess
somewhere
else,
I'm
I'm,
not
clear
about
that.
I
guess.
A
Yeah
I
I
remember
seeing
that
too
that
you
mentioned,
maybe
in
one
of
the
comments
that
the
events
are
created
with
the
events
API
I.
B
Guess
I
have
that
as
well,
but
I
probably
should
say
that
it
is
not
the
only
way
to
create
I.
Guess.
That's!
That's
why
right!
Okay!
So
let
me
see
the
line
that
Anthony
posted
there
yeah,
okay,
so
yeah
I!
Guess
it's
too
too
excluding
I!
Guess
here
right.
It
says
it
sounds
like
it's
only
using
events
API,
and
that
is
not.
That
is
not
the
internet.
So
maybe
we
need
to
rework
this
okay.
D
You
also
said
to
grant
that
we
like
the
condition
which
we
should
consider
whether
we
can
take
another
like
third-party
event
as
an
open
parameter
event
is
that
it
should
like
be
able
to
continue.
We
can
categorize
it
as
an
open
time
driven
so
like
this.
If
there
are
some
characteristics
that
we
need
to
probably
call
out
explicitly
and
to
make
sure
that,
like
this
mapping
from
Sir
patio,
events
is
possible
or
like
desired
I,
don't
know
like
reading
the
whole
dog.
It's
a
bit
unclear
to
me.
B
D
I
don't
know
like,
for
example,
if
third
party,
like
stores,
provides
some
kind
of
events
that
we
can
patch,
for
example,
of
the
time
to
collector
the
essential
events
or
practice.
Events
I,
don't
think
there
are
there
are
even
logs.
There
are
actual
events,
so
is:
is
that
enough
to
Define
them
as
a
and
open
Telemetry
events,
just
because
they
are
called
events
and
some
other
context?
D
I,
don't
know
so
this.
This
part
of
the
bit
unclear
yeah.
B
So
one
one
of
the
FAQs
there
is
that
if
it's
called
events,
that's
absolutely
not
enough
as
a
reason
right
to
to
map
them
to
an
open
Plenty,
then
the
reason
I
called
that
out
is
because
the
the
term
is
so
overloaded.
People
use
it
in
so
many
different
ways:
I'd
rather
ignore
it.
We
heck
we
we
all,
we
we
even
call
it
the
metrics
data
points
in
our
own
specification
events.
Sometimes
if
you
look
at
the
metrics
spec,
we
call
them
events.
I
mean
those.
Those
are
different
depends.
B
Those
are
not
the
indents
that
you
would
so
people
are
not
going
to
agree.
I
guess.
The
point
I'm
trying
to
make
is
that
everybody
has
a
different
definition
of
what
an
event
means
and
instead
of
trying
to
argue
with
people
about
their
definition,
I'm
saying,
let's,
let's
not
argue,
let's
forget
the
term
our
term.
What
we
Define
is
called
open,
Telemetry
events
right,
that's
a
New
Concept
we
introduce
it,
we
Define
what
it
means,
and
let's
work
on
that.
Let's,
let's
work
on
the
precise
definition
of
that
and
then
have
guidelines
around
okay
I.
B
Have
this
data
I
found
it
somewhere?
Is
it
an
open,
Telemetry
event
can
I
call
it
an
open
elements?
Event.
Let's
work
on
the
definition
of
that
on
rules
for
doing
that
right
on
guidelines
on
that,
maybe
we
can
discuss
the
kubernetes
events
here.
I,
don't
know
right
so
yeah,
it's
been
a
bit
unclear
to
me,
but
it's
maybe
good
example
to
have
a
a
discussion.
A
About
yeah
I
think
whatever
we
pick
I
think
it's
important
to
document
whether
that
source
is
emitting
events
or
general
log
records
yeah,
because
that
sets
the
expectations
for
the
backends
to
process
them
accordingly,
yeah.
F
F
It
may
not
be
a
capital
E
Event,
but
trying
to
use
a
general
term
as
a
term
of
art
seems
like
it
might
be,
causing
us
more
trouble
than
it's
worth
here.
If
we
can
come
up
with
a
more
specific
term,
you
know
something
like
schematized
log
records
or
something
that
makes
it
clear
that
this
is
a
log
record
that
has
specific
properties.
A
Right
but
but
isn't
the
lock
record
generic
enough
that
it
will
eventually
be
the
same
as
event
10
years
from
now.
A
F
B
B
What
what
to
record
there
like
like
this,
really
as
as
little
restrictions
as
possible,
as
opposed
to
that
the
open
Telemetry
events
or
whatever
new
name
we
decide
for
those,
has
additional
restrictions
right,
so
you
have
to
have
the
domain
and
you
have
to
have
a
name
at
least
so
that
is
the
primary
difference.
The
the
log
record
is
the
the
basic
data
model,
which
allows
us
to
record
X
data
that
is
found
externally
elsewhere,
and
also
data.
B
That
open
Telemetry
believes
is
the
right
way
to
to
record
events
or
whatever
we
give
name
we
give
to
those
right.
So
the
log
record
is
a
supersettle
all
of
the
the
kinds
of
the
events
we
could
record
metric
events,
even
if
we
wanted
to
right,
as
as
log
records
we
don't
there's
no
need
to,
but
we
could,
if,
if
we
wanted
to
so
it's
as
generic
as
possible
as
flexible
as
possible,
with
as
little
restrictions
as
possible,
the
log
record,
the
open,
Telemetry
event
is
not
like
that.
B
A
B
A
E
G
E
I,
don't
know
it
was
a
number
of
months
ago
and
I
posed
a
question
about
live
records
and
I.
Don't
know
if
this
helps
other
people's
minds,
but
the
way
that
I've
been
thinking
about
events
is
I.
Agree.
I,
think
that
we're
kind
of
caught
up
on
on
words
here.
The
thing
that
I
posed
a
number
of
months
ago
was
that
log
records
are
this
convenient
thing
to
create
your
own
custom
Telemetry
signals
right,
so
we're
talking
about
like
metrics
and
spans
and
like
what?
What
makes
what
makes
metrics
special?
E
What
makes
band
special
as
as
a
thing
aren't
those
events
too.
Well,
we
call
those
things
signals
and
so
and
we
we
have
specification
around
what
those
things
are.
There's
a
lot
of
structure.
F
E
A
lot
of
Labor
has
been
put
into
what
those
things
are
and
I
would
I
guess
expect
that
as
an
individual
is
coming
up
with
what
we're
currently
calling
an
event
right
that
they
would
put
in
that
labor
of
defining
what
this
new
signal
is.
So
if
we're
talking
about
kubernetes
or
if
we're
talking
about
client-side
monitoring
like
right,
there's
going
to
be
a
lot
of
a
lot
of
Labor
to
Define
what
that
is.
E
So
it
seems
like
there's
some
sort
of
a
a
bar
that
you
need
to
to
reach
to
to
Really.
Justify
this
thing.
Is
this
thing's
special,
this
thing's
a
new
signal
effectively,
but
I
just
happen
to
be
using
this.
This
generic
data
model
the
log
record
to
deliver
it.
H
I
think
it
might
make
some
sense
to
actually
anchor
some
of
this
too,
like
I,
think
kubernetes
events
are
actually
a
really
good
example
of
something
that's
highly
structured,
very
consistent.
You
know
when
we've
got
a
container
changing
state
or
a
pod,
changing
state
that
gives
us
a
solid
event.
I
think
it's
also
really
interesting
in
that
the
naming
in
the
the
kubernetes
events
doesn't
match
the
naming
that
we've
chosen
so
I
think
actually
going
through
and
mapping
what
a
kubernetes
event
looks
like
as
an
open,
Telemetry
event
could
be
a
illustrative
exercise.
H
D
H
Sorry
I
was
just
going
to
say
it
seems
a
lot
like
what
tigrin
did
at
the
very
start
of
the
the
log
Sig
and
kind
of
mapping
out
the
the
log
record
structure.
To
you
know
a
bunch
of
different
blogging.
Library
representations,
sorry
go
ahead,
Dimitri.
D
I
just
want
to
add
that
the
only
thing
that
my
only
concern
about
like
is
specifically
is
speaking
about
kubernetes,
the
only
my
concern
about
putting
comprehensive
events
into
local
records
and
not
saying
like
this
is
actual
open.
Telemetry
events
is
because
of
what
kubernetes
has
lost
as
well,
and
it
has
to
advance
so
I
believe
it
just
makes
sense
to
map
them
to
whatever
we
have
for
events
in
open
Telemetry
instead
of
using
blocks
so
that
that
was
my
ideal
cancer
I.
H
I
totally
agree
and
I
think
to
kind
of
roll
with
this
a
little
bit
like
what
I
would
expect
to
do
with
an
with
a
kubernetes
event
like
taking
a
look
at
you
know,
specifically,
you
know
pod
lifetime
events
right,
so
it
you
we
get
get
that
it's
pending.
Then
we
get
that
it's
you
know
it's
starting
and
it
gets
to
go
because
it's
ready,
that's
just
the
state.
Changing
those
events
are
going
to
have
a
very
consistent
body
right
and
so
what
we're?
H
What
we're
looking
for
in
terms
of
an
open,
Telemetry
event
is
that
we
can
partition
it.
We
can
say
that
this
is
a
domain
of
kubernetes
and
the
name
is
pod
status.
I,
don't
know
what
what
it,
what
it's
actually
called
right
and
then
the
entire
kubernetes
the
way
I'm
envisioning
it
the
way
the
you
know,
the
actual
kubernetes
event
then
goes
in
as
the
body.
H
So
the
you
know
the
category
and
the
name
give
us
the
ability
to
predict
what
the
the
structure
is
going
to
be,
and
that
to
me
is
the
the
that's.
What
I'm
understanding
is
the
essence
of
an
event?
Is
that
if,
if
these
two
things
match,
then
I
know
what
to
expect
in
the
body,
whereas
you
know
like
a
structured
log
event,
you
know
that
could
be
anything.
B
So
you
see
how
this
is
so,
if
we
do
that,
let's
say
if
we
do
the
mapping
of
the
the
event
data
that
is
produced
by
kubernetes
cluster
into
open,
Telemetry
events,
then
that's
our
definition
of
what
kubernetes
events
are
right.
It's
not
kubernetes
definition.
We
decide,
we
make
a
decision
of
what
the
the
domain
the
value
is
going
to
be
and
what
the
name
value
is
going
to
be.
It's
our
decision.
So
essentially
it's
our
thinking.
We
are,
we
are
we're
creating
a
new
data
source.
B
The
name
of
the
data
source
is
kubernetes
events
receiver
in
the
collector.
It's
essentially
an
open,
Telemetry
data
source.
Yes,
it
is
pulling
the
data
from
kubernetes,
but
it's
not
it's
not
the
original
kubernetes
event
in
a
sense
right.
You
may
encapsulate
the
the
original
kubernetes
events
data
as
a
payload
as
an
attribute
value
or
even
as
the
body,
but
it's
then
our
decision.
B
H
Well,
I
mean
I,
guess:
I
I've
been
presuming
that
the
name
and
the
category
or
the
the
yeah,
the
those
are
kind
of
envelope
attributes.
So
those
give
us
partition
values
that
you
know
we
can
process
all
of
these
things
the
same
even
within
that,
though,
you
know,
because
I
don't
think
we
want
to
get
into
the
business
of
like
remapping
all
of
the
kubernetes
events,
yeah,
okay,
I,
don't
think
we
can
do
that.
I.
Think
what
we're
trying
to
do
is
we're.
H
You
know
giving
you
know
any
given
company
any
given
group
an
ability
to
be
able
to
say
hey
these
things
are
going
to
remain
largely
consistent
and
even
there,
like
you
know,
kubernetes
events
are
probably
going
to
change
as
as
kubernetes
changes,
but
you
know
that's
going
to
be
on
the
processor
to
figure
out
like.
Is
this
a
version
one,
or
is
this
a
version
15.?
H
You
know,
I,
don't
think
we
want
to
get
into
that
level
of
detail.
We
just
want
to
be
able
to
create
an
envelope
that
can
kind
of
be.
You
know,
partitioned.
B
Yeah
I
think
it's
fine.
We
we
create
open,
Telemetry
events
which
reference
or
which
envelope
the
the
kubernetes
events.
I
mean.
Probably
yeah
sounds
good
to
me.
We
choose
the
domain,
we
call
it
Ka
test
and
we
choose
the
event
name.
It's
probably
even
a
composite.
We
we
concatenate
some
of
the
values
we
we
have
in
the
original
data
and
that
becomes
the
event
name.
B
That's
I
mean
I'm.
Okay.
With
that
approach,
the
the
reason
I
was
opposed
to
to
to
going
forward
immediately
with
that
was
that
I
I
felt
that
we're
kind
of
defaulting
to
this
fit
to
this
approach,
right
that
everything
that
we
see
becomes
an
open,
Telemetry
event
and
I'm,
not
sure
that's
the
right
approach.
Should
we
do
that?
Like
I,
see
a
log
record
in
a
file,
then
let
me
turn
it
into
a
into
a
file
into
an
open,
Telemetry
event.
Why
not
I
can
do
that
as
well
from
the
online
domain?
B
Is
the
file
and
the
event
name
is
whatever
right
or
an
entry
or
something
like
that.
I
think.
That's
a
that's
a
bit
slippery
slope.
I
want
to
avoid
that
right.
So
I
want
to
make
sure
that,
if
we're,
if
we're
observing
some
raw
data
from
somewhere,
we
do
not
necessarily
have
to
try
to
shoehorn
it
into
an
open,
Telemetry
event.
In
this
particular
case.
Maybe
it's
a
good
idea
and
I'm
hearing
arguments
in
favor
of
doing
that.
B
F
F
Having
having
a
more
discreet
name
can
be
advantageous,
because
there
are
certainly
schools
of
thought
that
they
think
that
all
log
records
are
events.
All
metric
observations
are
events
and
thus,
of
course,
everything's
an
event,
whereas
not
all
like
law
records
are
schematize
records.
If
you
know
for
lack
of
a
better
word,
yeah.
D
We
can
probably
just
Define
how
we
map
external
events
to
open
Telemetry,
explicitly
like,
for
example,
we
have
kubernetes.
We
we
put
in
the
specification
how
what
we
put
and
then
like
event,
domain
and
event
name,
and
if
it's
there,
we
have
like
agreement,
how
we
envelope
the
comprises
events,
if
you
want
to
add
something
else,
we
do.
We
do
another.
D
B
C
What
about
the
Event
Source
events
from
not
ecosystem
that
Mike
and
Alan
were
talking
about
previously,
that
I
think
they're,
a
particularly
good
example,
because
sometimes
they
look
highly
structured
like
the
events
that
were
a
planetary
event
for
but
other
times
they
look
more
like
traditional
application
logs,
and
so
they
might
be
a
good
like,
like
a
counter
case
to
say
you
know,
maybe
in
this
case
we
even
despite
the
name
event
in
the
Event
Source
Events.
C
B
G
You
can
instrument
your
code
using
it
I
think
it
rides
on
things
built
into
windows,
so
you
can
emit
it.
You
know
in
other
languages,
I
think
the
system
itself
emits
in
that
format,
but
we're
just
kind
of
looking
at
the
dot
net
API
for.
G
E
E
So
when
you're
in
debugging
mode,
there's
events
that
fire
to
indicate
when
a
garbage
collection
took
place
or
when
memory
was
allocated
or
something,
and
you
can
see
that,
like
in
a
little
graph
within
the
IDE
itself,
I
think
it's
all
built
upon
a
similar
foundation,
and
so
in
that
context
right
it
very
much
feels
like
something
different
than
a
log
record,
at
least
certainly.
B
G
So
this
is
another
side
of
the
same
coin.
This
isn't
the.net
API,
but
I
think
this
is
the
same
fundamental
model
that
like
goes
on
in
Windows
etw.
Is
this
crazy
thing
in
Windows
where
it
gives
you
these,
like
kernel
pages,
so
the
applications
can
log
to
these
different
pages
independently
on
their
own
threads
you're,
just
dumping
into
memory?
It's
super
efficient
to
write
them,
which
is
also
why
they're
so
highly
structured,
because
the
system
has
to
reason
out
what
to
do
with
them.
G
And
then
you
have
these
listeners
that
are
not
in
process
they're,
just
listening
to
these
windows
Pages
or
something,
and
then
they
can
all
get
different
copies
and
do
whatever
they
want
with
them.
So
there's
tools
like
perfume,
you
know,
there's
the
event
log
itself.
We
have
some
open
Telemetry
exporters
that
listen
to
etw,
so
we
can
do
log
and
Metric
I,
think
all
of
them
actually
and
traces
where
we
just
dump
into
etw.
So
you
get
this
really
efficient,
non-blocking
high
throughput
from
the
process,
and
then
some
agent
listens.
That's
like
disconnected!
E
And
you
mentioned
perfume
perfume
is
kind
of
like
the
the
tool
that
everybody
talks
about
in
terms
of
consuming
these
etw
events,
Event
Source,
so
the
c-sharp
API
for
writing
events
via
event
source
is
also
consumable
by
Perfume.
So
you
could
fire
up
a
perfuse
session
and
be
consuming
etw
events
from
like,
say,
the.net
runtime,
indicating
things
like
GC
and
so
on,
and
then
also
in
line
C
Event
Source
records
that
you've
written
from
your
application.
For
example,
if
you've
subscribed
to
both
sources
when
running.
G
My
kind
of
thinking
on
this
is
we
sort
of
need
like
a
mission
statement.
We
have
to
Define
what
an
event
is
in
a
sentence
or
two.
If
that
definition
is
an
open,
Telemetry
event
is
just
a
special
type
of
log
record,
with
structure
or
a
strongly
typed
log
record.
If
that's
the
definition,
then
I
think
these
cases,
like
the
Event
Source,
the
etw,
makes
sense
to
be
represented
as
a
hotel
event.
G
If
we
go
a
different
direction
and
we
say
events
are
just
these
specific
things
that
you
must
admit
through
this
API,
then
I
would
say
we
would
not
include
them.
So
to
me,
it
all
kind
of
hinges
on
that
top
level.
Definition
how
we
describe
it,
then
we
can
decide
what
fits
in
there
and
what
doesn't,
if
that
makes
sense,.
C
I
think
that
makes
sense,
but
you
know
I
and
I.
Don't
understand
Event
Source!
Well
enough
to
answer
this
question,
but
I
I
think
I
remember
from
prior
discussions
that
in
some
cases,
event
sources
can
be
cleanly
mapped
to
the
notion
of
an
open,
Telemetry
event
where
they
have
a
domain
in
a
name
that
identifies
the
structure.
But
in
other
cases
they
can't
be
neatly
mapped
and
the
the
name
and
domain
doesn't
neatly
identify
as
structure.
C
And
so
what
do
you
do
in
cases
where
a
particular
Telemetry
source
is
sometimes
looks
like
an
open,
Telemetry
notion
of
event,
and
sometimes
it
doesn't.
G
Let
me
post
a
link,
so
there's
there's
two
logging
libraries
we're
looking
at
in.net,
there's
Event,
Source
and
there's
ilogger
I.
Think
ilogger
is
more
that
case
or
sometimes
you
can
have
strong
typing
like
an
ID
and
a
name
most
of
the
time
you
don't
and
it's
just
structured
Logs
with
no
sort
of
identification.
G
E
One
example
that
we
talked
about
in
Prior
conversation
was
that
we
in
fact
use
Event
Source
as
our
logging
mechanism
for
open
telemetry.net.
So
like
concrete
example
like
the
rotlp
exporter,
if
it
you
know,
fails
to
export
for
some
reason,
you
know
we
might
emit
a
log
and
we
use
Event
Source
for
that,
and
it
is
a
highly
structured.
E
You
know,
I'll
put
events
and
like
air
quotes
here.
It
is
a
highly
structured
event
because
it's
like
we,
we
log
out
a
message,
but
then
we
also
have
like
metadata.
That
goes
along
with
that
message.
Like
you
know
the
the
inputs
to
the
the
export
attempt.
C
C
G
Yeah
two
things:
so
you
have
the
Event
Source
name.
That
would
be
like
otlp
exporter.
That
would
be
like
a
domain
and
then
each
individual
event
that
submitted
has
an
ID
numeric
and
a
name
which
is
like
the
method
name
of
the
in
the
class.
The
method
that
you're
calling
like
failed,
Explorer,
Start
Explorer.
You
know
invalid
span,
whatever
you
want
to
call
it,
so
you
could
in
theory,
map
it
to
an
event.
G
You
just
take
the
Event
Source
name
as
a
domain
and
then
the
individual
event
name
has
the
event
name,
and
then
it
gives
you
from
there.
You
have
like
a
body.
You
know
like
a
message,
a
message
template
and
then
you
have
optional
attributes.
Basically,
you
don't
have
to
have
them.
You
can
just
have
an
event
with
a
plain
string,
but
you
can
also
put
you
know
whatever
you
want
into.
It
typically
use
primitive
strings
and
ends
and
stuff
like
that,
but
you
could
probably
pass
a
complex
type
I'm,
not
totally
sure
about
that.
C
C
In
that
example,
the
method
is
equivalent
to
the
open,
Telemetry
event
name
and
one
particular
method
could
emit
multiple
log
statements
that
are
for
unrelated
things
and
that
don't
share
the
same
schema
right.
No,
no
here.
E
Bring
a
picture
to
words,
so
this
is
this
is
the
otlp
exporter
for.net,
and
this
is
our
Event
Source
it
it
drives
from
this
thing
called
Event
Source
for
the
all
everything
that
the
otlp
exporter
logs
uses
this
class,
and
there
are
discrete
events
that
are
effectively
methods
that
are
implemented
as
methods
failed
to
reach
the
collector.
You
know,
and
then
the
attributes
effectively
right
would
be
like
well,
what
was
the
URI
that
you
would
attempted
to
connect.
C
C
C
B
C
B
D
B
So
I
guess
in
this
in
this.
In
this
particular
case,
you
probably
There's
no
practical
reason
to
do
that
right.
The
old
TLP
exporter
failed
to
do
something.
You
probably
don't
want
to
generate
another
old
PLP
event
as
a
result
of
that
another
field
record.
As
a
result
of
that,
that's
that's
pointless,
I
guess!
But
if
you
had
some
other
Library
which
uses
this
event
source
for
its
logging
purposes,
then
that
you
maybe
would
want
to
to
bridge
to
open
telemetries
or
TLP
exporter,
somehow
right
using
the
the
notion
of
what
we
call
an
appender.
B
B
Yes,
yeah
some
from
some
other
completely,
not
related
to
an
implementation
of
open,
Telemetry
SDK.
You
have
an
application
which
uses
the
Event
Source
in
the
same
way
that
that
Allen
was
showing
here
and
that
I
think
that
that
Maps
nicely
right.
You
have
the
event
names
as
the
measured
names
you
have
the
domain,
which
is
whatever
you
choose
as
a
domain
name.
Maybe
it's
your
application
name
and
I
think
that
fits
in
that
case.
C
Yeah,
maybe
the
event
name
would
have
to
be
fully
qualified
in
some
way,
so
some
concatenation
of
the
class
name
and
Method
name
so
that
they
don't.
You
know
when
methods,
two
methods
with
the
same
name,
emit
events
from
different
classes
that
represent
different
things.
There's
not
collusions,
but.
E
E
Actually
decorated
with
an
Event
Source
this
annotation
here
this
is
the
this
is
what
I
think
would
map
to
the
event.domain.
That's
what
yeah
Mike's
been
talking
about?
Okay,.
C
Yeah
Alan,
you
said
you,
you
said
you
didn't
feel
quite
right.
Something
didn't
feel
quite
right
about
mapping
these
to
open,
Telemetry
events,
I
I
read
in
between
the
lines.
Maybe
you
feel
that
way
because
of
the
the
high
frequency
of
these,
then
the
low
level
of
them-
and
you
know,
stop
me
if
you
feel
so
otherwise,
but
God.
C
Well,
I
just
to
complete
the
thought,
but,
like
you
know,
there's
other
events
that
I
think
the
client
instrumentation
group
is
planning
on
capturing.
Like
click
has
been
suggested
as
as
a
particular,
you
know,
category
of
events
and
those
will
happen
with
really
really
high
frequency,
and
you
know
if
we
wanted
to
capture
other
types
of
browser.
Events
like
like
scrolling
events
or
something
like
that
or
zoom
in
and
zoom
out,
events
I
think
those
would
be
reasonable
to
capture
and
they
happen
at
high
frequencies.
C
So
if
part
of
your
trepidation
is
like
of
these
low-level
method,
invocations,
then
I
I
think
they're
a
good
fit
for
open
Telemetry
events.
E
Well,
yeah
frequency
is
an
interesting
thing,
but
that's
not
I,
don't
feel
like
that's
really.
What
was
bugging
me.
My
thoughts
are
evolving
here,
so
I
I
think
that
I
think,
maybe
you
know
we
talk
about
like
how
the
reason
why
we're
doing
these
events
is
that
it's
it's
important
to
be
able
to
process
Telemetry
differently,
because
this
is
special
somehow,
and
so
maybe
that's
that's.
E
C
Yeah
just
thinking
out
loud
here,
so
vendors
are
going
to
do
all
sorts
of
different
things
with
the
open,
Telemetry
log
records
they
receive,
they
might
siphon
off
individual
log
records
that
match
certain
criteria
for
special
processing,
I.
Think
what
we've
been
suggesting
is
that
event
domain
and
event
name.
The
presence
of
those
attributes
suggests
that
the
vendor
or
backend
might
process
those
specialty,
but
I
don't
think
it
necessitates
special
processing
I
think
it
leaves
the
door
open
to
it.
F
Yeah,
conversely,
I
don't
think
those
need
to
be
the
only
attributes
that
can
be
used
to
identify
records
that
might
be
subject
to
special
or
additional
processing.
I
think
any
record
that
you
can
identify
using
some
attributes
of
it
that
are
known
beforehand,
that
it.
The
rest
of
it
then
follows
a
schema
or
can
be
processed
in
a
particular
way
could
be
an
event.
F
I
think
we're
saying
here
that
domain
and
name
or
the
two
attributes
that
we're
calling
out
as
things
that
we
have
an
API
for
that
will
help
generate
them
and
that,
if
you
follow
those
other
people
will
know
that
they
should
be
treated
or
should
be
able
to
be
treated
in
this
manner.
Even
if
they
don't
necessarily
have
the
schema
to
do
further
processing.
They
can
know
that
this
is
a
thing
that
might
be
intended
to
be
treated
in
that
manner.
C
Right
right,
yeah.
To
give
an
example
of
that
exceptions,
we
we
add
those
semantic
conventions
to
add
the
exception,
attributes
to
log
records,
so
a
vendor
could
interpret
log
records
that
have
the
exception
attributes
and
do
something
special
with
them.
B
And
not
just
schema
right,
the
vendors
may
choose
to
to
implement
a
UI
which
which
which
which
anticipates
the
presence
of
the
event
domain
somehow
and
groups
the
events
that
belong
to
one
domain
in
some
way
in
the
UI
right.
So
somehow,
if
I
know
these
are
kubernetes
events,
I
may
show
them
in
in
a
particular
page
or
a
section
of
the
UI
and
put
a
kubernetes
icon
next
to
them.
B
Something
like
that
right,
so
maybe
I,
knowing
that
what
what
I
expect
to
receive
from
open,
Telemetry
I
can
then
maybe
adjust
the
behavior
of
the
back
end
according
to
that
somehow
not
not
necessarily
because
I
I
I'm
going
to
interpret
the
shape
of
the
event
in
a
special
way,
although
maybe
I
can,
but
just
be
just
by
looking
at
the
values
of
the
event
domain.
Even
maybe
that's
that's!
That's!
That's!
That's
also
an
interesting
thing
to
do
to
have
a
UI
that
that
that
gives
you
a
nicer
user
experience.
Somehow.
B
But
again,
you're
right,
you
don't
have
to
look
at
the
the
event
domain
or
the
event
name
in
any
way,
but
also
you
can
make,
maybe
maybe
even
routing
decisions.
You
decide
that
I
don't
know.
For
some
reason.
All
of
the
kubernetes
events
have
to
be
stored
somewhere
else
or
the
browser
events
have
to
go
somewhere
else.
You
want
them
to
be
archived
for,
for
a
long
retain
for
a
longer
period
of
time.
E
B
E
Way
in
this
concrete
example
of
why
my
mind
was
a
little
stock
was
with
Event
Source
like
if
I
was
running
open,
telemetry.net
and
I
was
also
you
know,
using
some
logging
framework
of
my
choice
to
to,
for
my
own
purposes,
for
my
own
applications
purposes,
but
also
you
know,
of
course,
using
open
telemetry.net
I'm,
also,
maybe
getting
the
logs
from
open
telemetry.net
itself.
E
You
know
for
troubleshooting.
I
might
want
that
workflow
to
just
see,
like
my
all,
my
logs
from
all
my
sources,
but
then
I
guess.
If
some
of
these
things
were,
you
know
open,
Telemetry
events
that
would
enable
the
back
end,
though,
in.
E
To
you
know,
do
some
other
experience,
maybe
as
needed
or.
B
E
C
C
B
D
A
B
A
Come
back,
I
I
want
to
talk
about,
you
know
keeping
the
domain
in
the
instrumentation
scope.
It's
I
know
I'm
going
back
on
this.
A
We
because
it's
something
we
agreed
on
and
it's
part
of
the
specification
already,
but
thinking
again,
I
feel
it
was
not
a
good
idea
to
keep
it
there,
because
in
in
all
the
discussions
so
far,
we
have
always
said
that
you
know
folks
should
look
at
both
the
attributes,
the
domain
and
name
to
consider
it
as
an
event
and-
and
one
of
them
is
at
the
scope
level.
One
is
at
the
signal
level.
A
So
so
the
back
ends.
It's
not
sufficient
to
just
look
at
the
scope
and
say
everything
contained
inside.
You
know
you
you
send
it.
You
know
one
way
they
have
to
look
at
the
individual
log
records
to
see
whether
it
contains
the
name
attribute
and
only
then
make
a
decision.
So
to
me
it
is
more
natural
for
to
think
of
them
together
and
it's
nicer
if
they
are
at
one
place.
A
It's
simpler
complexity,
Wise
It's,
simpler
if
they're
in
one
place
for
for
both
communication
documentation
and
as
well
as
you
know,
from
a
logical
perspective
to
so
the
one
reason
we
had
it
in
the
scope.
One
reason
I
I
said
to
myself
that
since
the
there
was
some
text
in
the
scope
documentation
in
the
scope
or
depth
about
attributes
that
they,
they
will
naturally
flow
into
the
signals
too.
A
A
So
in
with
with
that
text,
I
had
taken
away
that
the
attributes
at
the
scope
will
also
be
naturally
present
like
for
the
backends
can
treat
it
as
being
present
at
the
signal
level
also
and
from
an
API
ergonomics.
It
makes
sense
to
specify
the
domain
once
and
then,
as
you
create
events
for
the
domain,
you
you
don't
specify
the
domain
and
again
and
again,
but
so
and
so
in.
A
In
short,
I
I
feel
we
should
move
the
domain
back
into
the
log
record
and
and
then
keep
them
together.
B
A
The
batch
processing
is
anyway
tricky
today,
because
just
one
attribute
is
not
any
sufficient.
Anyways.
B
No,
it
ends
up
in
the
attributes
of
the
of
the
scope.
The
scope
is
is
a
message
in
otlp:
it's
a
it's
a
different
message:
the
scope
contains
multiple
log
records,
so
the
event
domain
that
we
that
we
specify
the
in
the
API
call
where
you
obtain
the
logger
will
end
up
as
an
attribute
of
the
scope
on
the
on
the
wire.
B
G
A
I
I
think
we
can
keep
the
API
the
same,
but
describe
where
the
domain
goes
to.
We
could
just
change
that
language
in
this
pick.
B
But
again
we
lose
the
ability
for
more
efficient,
batch
processing
there
right.
If,
if
your
decision
is
based
only
on
the
scope
either
the
name
of
the
scope
or
the
event
domain,
then
then
you
can
do
that.
That
decision
once
for
the
entire
batch
of
log
records
in
the.
A
School,
actually,
the
the
original
trigger
for
for
this
was
the
definition
of
an
event.
A
So
I
have
a
PR
as
well
to
provide
some
of
these
clarifications
and
there
I
defined
an
event
as
a
log
record
containing
these
two
attributes.
Whereas
in
your
definition
you
mentioned,
an
event
has
is
a
is:
is
a
has
a
name
in
The,
Log
record
and
a
domain
in
the
scope,
so
it
just
makes
it
complex
for
for
somebody
to
understand
that.
B
So
I
just
want
to
remind
the
use
cases
why
we
wanted
it
to
be
in
the
scope
why
the
efficient
processing
was
even
even
a
topic.
We
had
this
profiling
events
that
people
intended
to
to
maybe
record
as
log
records,
and
we
had
the
entity
events
in
The
Collector.
Both
of
these
are
actually
what
was
Alan
referring
to.
They
are
essentially
new
kinds
of
signals
that
don't
have
their
own
first
class
representation
in
open
Telemetry
and
we
represent
them
as
generic
log
records,
but
they
are
essentially
their
own
class
of
of
data
right.
B
So
you,
you
probably
want
it
to
be
processed
by
maybe
a
different
backend,
so
kind
of
that's
where,
where
the
efficient
processing
is
coming
from
you're
receiving
this
whole
stream
of
log
records,
but
some
of
those
a
subset
of
those
belongs
to
a
different
place
right.
So
you
can
route
them
efficiently
by
looking
just
at
a
single
attribute,
just
just
at
the
Domain
instead
of
processing
the
the
the
logarithms
individually.
To
do
that,
you
certainly
can
do
that,
but
it's
less
less
efficient,
so
I
don't
know.
B
If
we
now
think
that
these
are
not
the
use
cases
that
we
care
about-
and
we
want
to
support
with
with
a
open,
Telemetry
events,
if
that's
the
case,
then
I
can
agree
with
you.
Let's
put
it
in
a
log
record,
but
we
need
to
be
explicit
that
we're
this
is
these
are
not
the
use
cases
we
care
about.
A
That
is
one
more
way,
but
I
I
think
it
was
shut
down
in
the
past.
But
let
me
bring
it
up
again,
which
is
you
keep
the
domain
in
the
scope
but
set
the
I
basically
leave
it
open
to
the
back
ends
to
our
or
any
consumers
that
you
know
that
these
all
the
scope
attributes
can
be.
You
know,
naturally
considered
at
the
signal
level
also.
A
And
they
can
be
overwritten
if
they're
present
in
the
signal
too,.
B
You're
saying
the
log
record
inherits
all
of
the
scope,
attributes
essentially
yeah,
which
which
I'm
not
sure
about
also.
B
Because
that
that
we
we
say
that
it
means
that
there's
no
way
to
record
the
attributes
which
describe
the
scope
itself,
not
the
log
records
if
I
want
to
say
something
about
the
scope,
I
can't
anymore
right,
somehow,
I
I,
don't
know
the
scope
has
a
name
and
version
today.
What,
if
I,
want
to
record
more
information
about
the
scope
and
that
semantically
is
actually
about
the
scope,
not
about
the
contained
log
records,
the
log
records
that
are
emitted
from
this
scope?