►
From YouTube: 2022-10-19 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
C
All
right,
let's
start
I
see
we
have
prms
in
the
agenda.
Allen
Zone
here,
yeah
you're
here.
E
Yep,
hello,
yeah,
I
plopped
this
on
the
agenda.
I,
don't
regularly
attend
this
meeting
so
I.
Maybe
I'll
have
spoken
about
this
in
the
past,
so
maybe
it's
just
me
getting
up
to
speed,
but
I
had
a
question
as
we
were.
You
know,
I
attended
last
week's
say
again:
we
predominantly
talked
about
the
events,
API
and
and
so
on,
question
is
there
any?
E
Has
there
been
any
conversation
about
advancing
towards
a
stable
log,
API,
mainly
in
support
of
like
third-party
libraries
and
so
on,
because
I
feel,
like
the
the
logger
API
is,
is
pretty
solid?
In
that
respect,
I
mean
it
seems
like
Java
and
both.net
and
Java
have
vetted
it
to
some
degree
and
I'm
wondering
if,
like
there's
been
a
conversation
about
like
kind
of
like
breaking
apart,
the
events
part
of
the
conversation
into
like
more
of
an
experimental
thing
and
like
advancing
the
logger
API
independently
from
that.
C
With
where
we
are
with
the
with
the
events,
discussion
I'm
a
bit
reluctant
on
on
doing
anything
like
that,
because
I
feel
like
if
we
change
name
names
of
things,
it
may
somehow
impact
the
loading
API
as
well,
so
I'd
be
a
bit
I,
don't
know
I'm,
not
sure
I
mean
I
understand.
What
we
want
to
do
will
be
great
if
we
could
do
that.
C
Make
portions
of
the
work
that
we
did
stable
now,
but
before
I,
would
prefer
that
at
least
we
settle
this
event
thing
right
with
this
decide
what
what
it
looks
like
and
and
after
that
I
think
it's
it's
valid
to
exercise
the
the
idea
of
stabilizing
the
logging
portion
of
it.
I,
don't
know,
that's
my
thinking,
I,
don't
know.
Somebody
has
a
different
opinion.
D
Foreign-
let's
play
that
out
a
bit,
so
we
we
come
to
some
conclusion
about
events,
either
naming
or
just
how
they
appear
in
the
API,
but
that
part
is
still
going
to
be
I,
guess
less
stable
and
more
controversial
than
the
the
log
ofender
API
part
of
it
and
the
you
know
the
basic
components
of
the
SDK
and
so
like
I.
Suppose
we
suppose
we
answer
that
question
tigran!
D
You
know
it's
still
going
to
be
an
experimental
mode.
Is
it
at
what
point
is
that
is
that
no
longer
a
blocker
to
stabilizing.
C
So
yeah,
when,
when
we
when
we
when
we
are
certain
that
the
the
proposed
structure
of
the
of
the
of
the
apis
right,
we
said
there
is
a
logger
through
which
you
can
make
log
records
and
events
right.
Are
we
certain
about
that?
If
what
is
it
if
it's
wrong
right?
It's
what?
If
events
are
going
to
be
emitted
not
through
the
logger
but
through
something
completely
different,
because
they
are
very
different,
and
in
that
case
the
the
whole
structure
falls
apart.
We
don't
need
that
anymore,
that,
like
we,
we
have
a
diagram
there.
C
Let's
say
so
he's
a
logger.
He
is
a
log
log
record
emitter
is
is
an
event
emitter.
If
that's
not
the
case
anymore,
then
maybe
the
design
of
the
logo
is
different.
Now,
because
that's
that's
pointless
to
have
that
design
right
anymore,
yeah,
that's
what
my
worry
is
right,
at
least
structurally,
let's,
let's
kind
of
be
be
certain
to
some
degree
about
what
we're
doing
here
in
in
any
case,
I
would
be
very
reluctant
with
going
to
stable,
maybe
to
better
but
not
stable,
right
with
with
the
with
the
apis
of
the
logger.
C
D
C
C
We
we
designed
the
logger
in
a
way
that
it
suits
for
emitting
both
log
records
and
events.
What,
if
that's
not?
What
knows,
what
was
not
a
requirement?
Would
we
design
the
logo
the
same
way?
Maybe
no,
if
that's
removed
from
the
picture,
if
there
is
no
events
that
we
need
to
take
into
account,
then
maybe
we
do
it
in
a
different
way.
I,
don't
know,
maybe
you're
right.
Maybe
it
doesn't
influence
it,
but
I
I
can't
answer
that
right
now,
immediately
right,
I
don't
know.
F
It
feels
to
me
like,
if
events
are
defined
as
being
just
log
records
that
have
particular
Fields
with
particular
meaning.
We
should
be
able
to
define
the
log
record
API
in
a
vacuum,
not
consider
events
at
all
and
then
bring
them
on
top,
because
that
API
should
be
syntactic
sugar
over
the
log
record
APN.
Yes,.
C
That's
one
of
the
options
you're
saying
it's
a
different
obstruction
level.
Essentially
it's
built
on
top
of
the
log
records,
but
that's
not
how
we
we
designed
it
right
now,
it's
it
kind
of
it
sits
as
a
neighbor,
it's
kind
of
as
a
sibling
thing
at
the
moment.
If
you
look
at
the
API,
it
starts
with
an
entry
point
with
a
logger.
C
You
obtain
a
logger
and
then
there
are
two
sibling
apis
from
that
where
you
can
emit
either
log
records
or
events
when
we
have
the
siblings
and
you
remove
one
of
those
and
this
one
remains
kind
of
the
only
I,
don't
know
child.
Of
that
thing.
It's
the
design
is
no
longer
so
sound
to
me.
I,
don't
know!
Why
is
it?
Why
is
there
a
thing
like
that
anymore?
C
And
also,
precisely
with
what
you
said,
Anthony,
if,
if
the
design
of
the
events
is
going
to
be
that
it,
it
is
not
a
sibling
anymore,
but
it
uses
somehow
it's
built
on
top
of
the
logger
or
log
records.
Maybe
building
on
top
means
something
else
for
what
what
whatever
is
the
foundation
for
that
now
right,
so
maybe
the
foundation
is
going
to
be
different.
You
you
may
be
the
what
you're
building
on
top
of
is
something
that
is
you're
going
to
extract
from
the
logo
or
something
like
that.
E
C
We
had
that
different
design.
Actually,
initially,
we
didn't
have
events
and
we
had
a
different
design,
and
this
design
is
different
from
that
Bond,
because
we
now
have
events.
We
did
a
redesign
precisely
because
we
brought
the
events
into
the
picture.
If
you
remove
them,
does
the
new
design
still
make
sense
or
or
no
I
don't
know?
Thank
you.
D
Yeah,
the
two
use
cases
for
the
introduction
of
the
API
were
to
have
a
a
log,
appender
API,
one
that
catered
to
log
appenders
for
producing
log
records
and
then
one
for
events.
Those
were
the
two
main
use
cases
and
I
guess.
The
point
is:
if
events
go
away,
do
you
still
want?
Can
you
still
justify
the
existence
of
a
standalone
API
for
only
the
log,
append
or
use
case?
D
C
So
yeah
I
think
we
we
have
to
wait
as
much
as
I
would
want
to
move
forward
with
the
logger
portion.
I
think
we
we
can't
I
mean
I,
don't
have
the
confidence
that
we're
able
to
so
I
think
we
should
funnel,
maybe
our
energy
into
figuring
out.
What
do
we
do
with
the
events.
C
Okay,
let's
move
to
the
next
one.
Some
coach!
You
want
to
talk
about
the
scope,
attributes,
I,
believe
right.
A
So
you
have
a
PR
that
is
saying
that
this
scope
attributes
should
only
be
specified
at
the
build
time,
so
I'm
wondering
what
its
impact
is
on
the
event.domain
that
is
currently
at
the
instrumentation
scope
level
and
in
the
last
week's
call,
we
also
discussed
the
possibility
of
keeping
the
event.domain,
as
you
know,
in
the
log
record.
A
So
so
should
we
like
if
this
PR
gets
merged,
then
I
guess
it
breaks
the
the
logs
the
events
API
and
and
therefore
we
will
have
to
make
changes
to
it.
So
is
that
the
change
we
want
to
make
where
we
keep
the
interface
just
the
specification
would
say
that
instead
of
the
logger,
you
know
the
logger
provider
would
still
take
the
event.domain
as
a
parameter
to
give
your
logger,
except
that
the
logger
will
not
put
that
domain
on
the
scope,
but
it
will
attach
to
the
individual
property.
C
C
That
said,
in
that
new
PR
that
I
proposed
the
alternate
one
that
is
called
categorized
logs,
there
I
made
that
proposal
based
on
our
previous
last
week's
discussion
and
suggested
that
we
do
move
the
event
domain
to
the
to
the
log
record.
So
maybe
that's
the
right
thing
to
do.
I
don't
know,
but
it
doesn't
necessarily
were
not
necessarily
forced
to
do
that.
C
A
Be
but
I
think
the
current
semantic
convention
says
it's
an
enum
with
custom
values
allowed
so.
C
F
F
A
No
I'm
I
was
only
wondering
if
that's
something
it's
very
hard
to
validate
right,
that
whether
it
was
specified
at
build
time
or
it
was
pulled
from
some
variable
that
runtime,
how
do
you,
how
do
you
validate?
How
do
you
verify
that.
F
H
C
Yes,
that's
the
proposal,
so
maybe
that's
a
wrong
proposal,
but
I
wanted
to
make
it
explicitly
there
right.
If
we
believe
that's
wrong,
then
we
have
two
choices.
One
is
we
say:
no,
the
event
attribute.
Sorry.
The
scope
attributes
can
be
specified
at
one
time,
so
the
scope
is
not
solely
a
build
time
concept
or
we
say
that
here
sure
you
can
have
a
runtime
in
the
kind
of
a
value
that
is
defined
at
runtime
for
the
event
domain,
and
in
that
case
we
don't
put
it
in
the
scope.
C
We
put
it
in
the
log
record,
I'm
fine,
with
the
with
the
with
putting
it
on
the
log
record.
I,
don't
think
it's
the
right
approach
to
say
that
the
scope
is
is
allowed
to
represent
runtime
entities.
I
think
that's
that
contradicts
to
every
past
discussion
that
we
had
at
open
Telemetry
at
large,
but
I
saw
that
in
some
places
some
people
expect
that
it
should
be
possible
to
record
the
runtime
values.
C
G
So
maybe
it's
a
wording
thing
because
I
think
your
runtime
values
are
talking
about
about
the
things
that
will
be
different
for
the
same
piece
of
code.
That's
running
right,
so
process,
ID
session
IDs,
as
opposed
to
what
I'm
talking
about
is
it's
okay,
so
yeah.
When
the
application
is
constructed,
the
value
will
always
be
the
same.
But
when
you
go
to
fetch
the
event,
emitter
you'd
say:
I'm
I
want
my
event
limited
for
Microsoft
or
for
Azure
or
for
Splunk
or
whatever
of.
C
Course
so
that's
that's.
That's
essentially
a
hard-coded
string
in
your
source
code
somewhere.
F
I've
been
thinking
about
this,
and
some
of
the
questions
that
came
up
about
you
know
build
time
not
being
applicable
to
some
languages,
and
things
like
that.
I
wonder
if
static
might
be
a
better
term
for
that,
like
yeah.
E
F
C
The
the
thing
with
the
static
is
that
it's
not
tied
to
the
source
code
in
any
way
and
the
current
definition
of
the
scope
is
tied
to
the
source
code.
It
says
in
unit
of
code,
if
you
say
only
static,
then
a
value
that
you
read
from
a
config
file
also
works
if
you're
config
file
is
static,
for
example,
do
we
allow
that
this
specifically
exclude
that
kind
of
usage
as
well,
because
once
you
start
doing
that,
your
config
file
is
probably
mutable?
You
can
also
change
it.
C
You
can
no
longer
make
the
assumptions
that
you
are
able
to
make
today
about
the
school
right.
You
have
a
scope,
it's
tied
to
the
unit
of
code
to
the
source
code.
Specifically,
it
describes
the
place
in
the
source
code.
It
doesn't
describe
what
happens
with
the
application
when
it
runs
when
it's
deployed.
It's
not
a
deployment
configuration
thing:
it's
not
a
runtime
thing:
it's
not
tied
to
the
lifetime
of
the
process
in
any
way
it's
tied
to
the
lifetime
of
the
source
code.
I
think
the
distinction
is
important
here.
C
Okay,
yeah
I
think
we
have
a
bigger
elephant
in
the
room,
the
event
thing.
So,
let's,
let's,
let's
continue
to
what
was
the
next
one.
What
is
the
roadmap
for
log
receivers,
fire
log
receiver
pending
issues?
This
is
more
like
a
question
for
The
Collector
sync.
C
So
this
this
thing
is
is
working
on
the
apis.
As
the
case
classification
of
the
log
I,
don't
know.
If,
then,
maybe
you
have
any
sort
of
answer
to
that
yeah.
I
I'll
keep
this
quick
I
think
that
the
file
log
receiver
can
probably
move
to
Beta
I'll
double
check
that
there
are
no
critical
issues
that
would
threaten
the
stability
of
the
configuration
or
the
behavior,
but
I.
Don't
I.
Don't
think
that
there
are
and
I
know
that
it's
had
a
lot
of
usage
by
a
lot
of
different
customers.
E
I
E
I
So
the
The
Operators
I
I,
think
are
also
ready
for
beta
I.
Think
pretty
much
all
of
the
parsers
and
Transformers
have
been
used
sufficiently
to
Warrant
that
as
far
as
porting
it
to
another
thing,
we
we
have
the
plan
as
I
understand.
It
is
to
basically
re-implement
the
same
capabilities
in
the
transform
processor,
so
this
will
just
be
a
different
implementation
and
then
that
would
allow
us
to
ingest
logs
and
then
just
process
them
and
in
Native
Hotel
format.
E
So
if
it
will
be
replaced
by
transfer
processor
should
be
considered
possible.
Duplication
of
the
operators
in
that
case,
so,
like
log
receivers,
only
provides
on
Raw
data.
I
I,
don't
think
you
would.
We
would
necessarily
need
to
deprecate
The,
Operators
and
I.
Think
some
users
would
probably
prefer
to
use
those
for
processing
logs
at
the
source
where
they're
ingested,
instead
of
pass
later
in
the
pipeline.
But
yeah
I
mean
I.
Think
if
we,
if
we
move
too
stable
before
getting
that
far
with
the
transform
processor
and
assessing
whether
that's
a
full
replacement
or
not,
then
then
I,
you
know
I
think
we
would
just
commit
to
supporting
them
to
the
V2.
C
Related
to
this
I
think
you
were
not
in
the
collector
segmenting
today.
Then
there
was
a
proposal
for
a
metrics
we've
seen
her.
That
also
has
a
notion
of
operators
which
I
think
overlaps
to
some
degree,
with
the
notion
of
operators
for
the
follow-up
receiver
that
we
have
so
there
is,
there
may
be
a
need
to
figure
out
what
do
we
do
there?
We,
if
we
accept
that
as
a
metric
receiver
there,
but
anyway
I
guess
guys.
Maybe
that's
that's
a
collective
discussion.
Let's
try
to
to
move
it
to
the
collector's
thing.
C
D
D
I,
don't
want
to
focus
on
that
too
much,
but
you
know
just
to
summarize,
the
proposal
is
to
keep
the
name
open,
Telemetry
event,
so
that
everybody
knows
what
an
event
is,
but
to
change
the
names
of
the
attributes,
event,
domain
and
event
name
because
those
are
potentially
confusing
or
ambiguous
around
what
the
semantics
of
those
things
are.
So
just
improve
the
the
names
of
the
attributes
to
provide
more
clarity
around
what
those
actually
mean,
and
so
that
users
would
have
better
intuition
about
what
to
do
with
those
fields.
D
D
Schema
URL,
so
schema
URL
is,
let's
see.
Skimmer
URL
is
attached
to
this
scope
and
would
it
be
any
different.
C
If
we
allow
the
derived
schemas,
you
probably
remember
that
proposal
where
you
not
only
have
a
single
open,
Telemetry
schema,
but
you
can
derive
from
it
and
extend
it
so
that
you
can
have
some
additional
attributes
defined.
On
top
of
that,
then
that
gives
you
the
domain
right.
Isn't
it
the
domain?
I
mean
the
the
open,
Telemetry
domains
and
another
non-op
complementary
domains.
C
Non-Open
Telemetry
domains
can
be
represented
by
schema
URLs
that
are
coming
from
elsewhere.
They
are
not
open,
Telemetry
urls,
but
conceptually
is
it
different,
because
the
schema
URL
describes
the
schema
of
the
things
that
are
under
the
scope.
That's
that's
the
proposal
that
you're
you're,
that's
what
you're
describing
the
domain
essentially
describes.
The
log
record
schema
right.
That's
that
is
it
what
you're
suggesting.
D
But
schema
skimmy,
URL,
I,
guess
the
the
one
difference
is
and
maybe
I'm
not
sure.
Maybe
you
can
clear
this
up
for
me,
so
we
would
we'd
have
one
schema
URL,
let's
say
the
schema.
Your
url
refers
to
or
points
to
the
schema
for
open
Telemetry.
Like
events
which
are
you
know,
we
have
some
that
are
documented,
like
mobile
or
browser
events,
but
then
within
within
each
of
those
domains.
You
have
a
bunch
of
distinct
types
of
events,
so
you
have
like
clicks
or
like
page
loads
and
things
like
that.
C
D
C
What's
the
purpose,
my
understanding
is
that
it
defines
the
shape
shapes
of
all
events
that
are
defined
within
that
particular
domain
right
collectively,
because
why
I'm
saying
collectively,
because
it
doesn't
matter
which
of
the
which-
which
ones
of
those
types
that
we're
talking
about
there
are
many.
They
are
different.
They
differ
by
their
names
and
they
differ
by
their
schemas,
but
collectively
that
their
their
shape
is
defined
by
the
domain
right.
The
domain
says
what
what
are
the
shapes
of
all
of
those
things,
but
that's
exactly
what
the
schema
URL
does
today
right.
C
D
C
So
if
we
were
to
allow
multiple
URLs
that
still
refer
to
open
Telemetry
semantic
conventions
but
reflect
the
additional
Nuance
of
it
being,
let's
say,
kubernetes
events,
then
you
would
get
the
exact
same
functionality
that
you're
going
for
here
with
a
schema
domain.
I.
Think
so
that's
my
understanding.
D
Yeah
and
then
just
to
complete
the
thought,
though
so
the
event
name
or
schema
name,
would
point
to
a
particular
type
of
thing
within
that
that
broader
schema,
which.
C
Yeah,
whether
it's
an
event
name
or
or
the
schema,
a
schema
name,
doesn't
sound
very
nice
to
me,
or
maybe
anyway,
yeah,
that's
the
yes.
We
we
obviously
need
that
second
parameter,
but
the
question
is:
do
you
need
that
second
parameter
to
be
to
be
standardized?
C
C
B
C
B
C
B
C
First
thing
this:
this
goes
back
to
the
to
the
name
field
that
we
originally
had
in
the
the
log
record
which
we
removed
because
we
weren't
sure.
So
if
we
do
that,
that's
I
think
that's
exactly
the
same
thing
that
we
had
in
the
name.
That's
the
name
and
domain
becomes
a
schema
URL,
and
now
we
don't
need
anything
else
really,
because
because
you
have
everything
that
you
wanted
to
record
here,
domain
is
is
in
the
schema
URL,
it's
the
it's
part
of
the
schema
URL
essentially,
and
the
the
name
I
mean
yeah.
C
C
C
It
is
a
New
Concept
and
the
reason
I
think
it
is
a
New.
Concept
is
because
we
say
that
there
is
a
very
large
world
of
log
records
and
events
out
there
that
you
want
to
map,
probably
somehow
to
open
Telemetry.
You
want
to
represent
all
sorts
of
things
as
open,
Telemetry
log
records,
and
it's
it's
a
much
bigger
and
essentially
uncontrollable
world.
We
don't
control
that
world
all
right
so,
but
we
we
need
to
bring
it
somehow
and
and
I
call
it
the
domain.
Kubernetes
events,
for
example,
we
don't
Define
the
kubernetes
events.
C
They
exist
without
our
definitions
right,
but
we
want
to
represent
them
as
open
Telemetry
log
records
and
their
representation
is,
is
separated
from
every
other
event.
Definition
by
by
recording
that
particular
attribute.
If
you
say
that
yeah
schema,
name
or
event
domain
equals
kubernetes.
That's
the
indication
that
this
is
a
kubernetes
event,
but.
B
If
we
had
this
concept
from
the
get-go,
is
that
essentially,
where
we
would
be
putting
we
use
like
Dot
kind
of
dotted
name
spacing
yeah
and
the
top
level
is
like
kind
of
essentially
the
domain
right,
like
HTTP
or
redis
or
or
messaging.
C
I
guess
possibly
it's.
H
Events,
one
of
the
the
differences
there
is
that
we
might
have
overlapping
domains.
We
don't
have
a
central
repository
of
all
of
the
event
definitions.
Okay,
so
we
we.
You
know
we
can't
have
like
a
universal
hierarchy
of
events,
because
you
know
people
are
just
going
to
be
making
stuff
up,
and
that
would
be
my
one.
My
one
reservation
with
using
the
schema
URL
in
place
of
the
domain
is
that
presumably
we
want
a
URL
to
actually
be
a
URL.
That
goes.
H
B
I
I
also
think
you
want
you
don't
want
to.
This
is
useful
information,
I
think
for
back
ends,
like
independent
of,
like
the
schema
and
other
things
like
being
able
to
look
that
up
like
you,
want
to
be
able
to
to
index
events
right,
but
you
don't
want
to
be
comparing
events
that
have
the
same
names
that
are
in
different
domains.
D
To
use
your
analogy
of
the
event
name
being
a
like
a
primary
key,
so
I,
I,
I
I,
didn't
think
that
was
quite
correct.
I
think
that
that
you
actually
have
a
composite
key,
which.
C
C
B
Mean
we
do
this
with,
like?
Usually
we
make
a
composite
with
for
tracing
it's
like
service,
name
plus
band
name,
because
it.
E
B
G
So
the
domain
was
going
to
be
the
namespace
I
haven't
read
the
the
full
thing
before
that
so
where's
the
schema
live
at
what
level
is
it
on
each
individual
log
record
or
is
it
that
the
effect
of
the
the
transport
has
that
as
a
header
or
something
so.
D
G
D
G
D
G
Got
it
okay,
so
that
would
work
because
the
other
option
is
you,
take
it
even
further
and
say
the
the
schema
URL
defines
the
name
as
well
as
opposed
to
having
a
name
which
is
an
index
into
the
schema.
D
Yeah
I'm
still
I'm
still
stuck
a
bit
on
what
David
was
suggesting
or
I
guess
I
agree
with
what
David
was
suggesting,
so
the
schema
URL
today
we
pointed
to
one
schema
URL
for
all
of
open,
Telemetry,
and
so
that
doesn't
actually
allow
us
to
disambiguate
between.
You
know,
potential.
C
They
have
to
be
different.
We
go
with
my
proposal.
They
have
to
be
different,
but
David's
objection
is
very
valid.
They
have
to.
They
are
URLs
that
they
are
defined
as
URLs.
Today
they
have
to
be
downloadable
which
forces
you,
when
you're
defining
a
domain
to
actually
make
it
hosted
somewhere.
It
has
to
be
downloadable
that
may
be
a
too
high
bar
right.
I,
don't
know
if
you
want
to
define
a
domain.
Maybe
that's
too
much
so
kind
of
yeah
could.
C
We
would
have
to
modify
the
notion
that
they
are
Uris,
but
then,
in
that
case
they
serve
a
purpose
particular
purpose
that
they,
the
schemas,
that
they
are
downloadable,
because
we
want
to
download
them
to
see.
What's
the
content
of
the
schema,
we
want
to
use
the
Transformations
defining
them.
If
we
remove
that
property-
and
we
say
they
are
your
eyes-
we
lose
that
ability
or
somehow
we.
We
now
have
two
different
classes
of
schemas.
Some
are
downloadable
and
applicable
for
transformation
purposes.
Some
others
are
not
anymore
and
I.
Don't
think.
G
C
G
G
H
When
we,
when
we
started
talking
about
the
the
URLs
too,
we're
also
talking
about
externally
defined
events,
so
things
like
Cloud
events,
that
you
know
we
we're
not
going
to
pull
into
open
Telemetry
we're
not
going
to
pull
the
definitions
into
open
Telemetry,
but
maybe
we
still
want
to
be
able
to
operate
on
those
schemas.
C
Okay,
can
we
maybe
talk
about
that
that
controversial
proposal
that
I
made
does
anybody
think,
but
it's
a
good
idea
to
instead
of
calling
it
an
event,
call
it
something:
I
I,
wonder
something
very
different
right.
That's
that's!
That
was
the
idea.
It's
not
an
event
at
all.
It's
something
very
different.
C
G
I
guess
from
the
rum
perspective,
we're
looking
at
an
event,
so
we're
looking
at
defining
an
event
and
where
that
event
happens,
to
be
transported,
whether
it's
a
log
event
or
a
it's
transformed
into
a
span
event.
As
far
as
we're
concerned,
we're
defining
an
event.
G
G
It's
keeping
it
similar
because
the
the
whole
there
there's
a
path
we
could
be
on
here.
Where
we're
saying:
okay.
Well,
we
Define
an
event.
An
event
could
be
sent
with
a
span
or
event
could
be
sent
on
its
own,
or
we
say
at
some
point
in
the
future,
even
though
we
have
the
span
event,
maybe
that,
under
the
covers,
depending
on
your
instrumentation
Etc,
sends
out
a
logo
bin.
G
A
C
The
confusion
was
around
always
an
event
right
if,
if
we
all
agree
on
what
is
an
event
in
particular
how
Okay
so
the
problem
is
that
there
is
an
external
definition
of
an
event,
there
are
many
of
those,
let's,
let's
for
a
minute,
assume
that
they
they
are
the
same
okay
right.
Somebody
says
what
an
event
is,
and
we
agree,
but
we
have
another
definition
of
invented
or
conflammatory,
which
is
different
from
that.
That
common
understanding
of
what
an
event
is
right,
because
we
say
open,
telemetry's
event
is
something
that
has
this
particular
attributes.
C
A
Different,
why
I
like
in
the
spam
events
when,
when
it
was
named
events
in
Span,
the
definition
is
not
different
from
what
we
have
here.
F
C
A
particular
kind
of
an
event
right:
it
has
a
specific
name
that
we
defined.
It's
called
a
spun
event
here
before
my
my
first
PR,
that
suggested
to
name
it
an
open,
Telemetry
event
with
a
capital
e
H.
We
didn't
even
have
a
specific
name
for
it.
We
were
using
the
generic
term
event,
not
in
a
generic
sense
right.
I,
don't
think!
That's
that's
a
very
good
idea,
because
we're
going
to
confuse
people
who
don't
know
what
is
what
is
an
open,
Telemetry
event
and
it's
not
exactly
the
same
thing
as
a
generic
definition.
C
Maybe
that's
fine
I
mean
maybe
that's
enough.
It's
enough
that
we
we
always
keep
calling
it
an
open,
Telemetry
event
right,
never
call
it
just
an
event.
Maybe
that's
good
enough.
Maybe
we
always
refer
it
with
a
capital
E
everywhere
we
write
it
right.
So
that's
a
special
type
of
event.
That's
our
understanding!
That's
our
definition!
That's
our
complementary
understands
Events!
Maybe
that's
good
enough
that
that
was
proposal.
A
that
I
made
puzzle
B
was
to
stop
referring
it
to
to
to
an
event.
Call
it
something
else
altogether,
I'm,
not
sure
about
either
of
those.
A
I
thought
this
is
more
of
a
standard.
The
context
is
not
clear.
So
maybe
you
know
this
is
a
standalone
event,
but
otherwise
structure,
wise
and
event.
All
in
at
all
of
these
places
to
me
they
they
are
the
same
way.
I'm
failing
to
see
the
difference.
B
We're
not
sporting
events
they're
different
just
for
clarity,
we're
not
is
anyone
I,
it
seems
like
we
we've
come
back
around
to
like
we're
gonna
keep
calling
it
events.
Is
there
anyone
who's
like
actively
pushing
for
for
that
not
to
happen
at
this
point.
B
D
Pushing
for
additional
Clarity
around
the
semantics
of
this
fields
and
the
reason
why
I
think
we
need
additional
Clarity
is
we've
done.
Two
mapping
exercises
we've
tried
to
map
kubernetes
events
and
we've
tried
to
map
events,
from.net's
Event
Source
and
in
both
cases
there
have
been
confusion
about
what
to
put
in
the
event
name,
field
yeah.
So
two
for
two
bad
yeah.
B
Okay,
that
that's
fair
I
just
want,
but
that's
like
a
tighter
scoping
right
of
like
we're
still
calling
we're
calling
these
events.
These
are
open,
Telemetry
events
and
the
next
question
is
how
the
heck
do
we
map
all
the
other
kinds
of
events
relevant
events
to
to
these?
If
we
want
to
record
them
here
and.
B
To
actually
answer
that
second
question:
I
think
it
comes
back
to
this
concept
of
an
index.
This
is
where
it
came
up
in
rum
and
kind
of
what
originated
the
idea
was
the
the
difference
between
an
event
and
a
log
and
open
Telemetry
we
were
thinking
is
that
an
event
are
records
where
you
can
do
comparative
analysis,
in
other
words,
there's
going
to
be
many
instances
of
this,
and
you
want
to
be
doing
some
kind
of
statistical
analysis
or
comparative
analysis
across
those
instances.
B
So
you
need
to
have
some
predefined
field
where
you
put
that
that
index,
which
is
the
the
compound
key
of
like
domain
plus
event,
name
or
schema
name,
and
that's
that's.
What
we
would
like
to
propose
is
like
why
something's
an
event
and
not
a
log,
an
event
you're
doing
you're,
comparing
across
other
instances,
but
not
every
log.
You
record
is:
has
that
quality
right
like
there's
plenty
of
times
where
you
just
log,
you
know
got
here
or
something,
and
it's
not
intended
to
to
be
used
in
that
manner.
B
B
In
other
words,
that's
the
difference
between
an
event
name
and
a
log
message.
A
log
message
shouldn't
be
construed
as
like
an
index
that
you
want
to
spend
Computing
resources
trying
to
compare.
I
I
think
that
that
definition
makes
sense
to
me
and
that's
how
I've
been
thinking
about
this
and
I'm
I
I
think
it's
interesting
that
there's
even
still
a
little
discussion
about
whether
we're
intending
to
model
the
events
in
general
or
put
some
scope
on
it
and
I.
Think
to
me
your
definition.
Ted
is
a
very
general
definition
right
like
so.
What
we
have
here
is
this
is
just
our
best
data
model
for
event.
Modeling
events,
just
like
we
created
a
data
model
as
a
project.
I
B
And
if
we
want
to
map
things
to
our
model,
really,
the
only
rule
is
to
to
try
to
look
at
that
kubernetes
event
or
Cloud
event
and
be
like.
What's
the
what
is
intended
to
be
the
primary
index
here,
if
it
has
one
because
I
feel
like
almost
any
any
kind
of
event
concept,
at
least
in
our
domain,
like
has
something
like
that,
and
you
just
want
to
figure
out
what
that
is
and
and
convert
it
into
the
event
name.
F
Literally
100
agree
with
with
what
Den
just
said.
There,
though,
like
even
even
with
metrics,
we
have
specific
metric
types
that
other
types
of
metrics
generally
have
to
be
transformed
into.
You
have
to
transform
it
specifically
into
a
sum,
and
that
sum
has
to
be
monotonic
or
not,
or
it
has
to
be
transformed
into
a
histogram.
These
are
specific
things
that
have
specific
meanings
here
for
events
generally,
they
don't
other
than
we're
saying
they
should
have
some
way
of
identifying
how
to
process
them,
which
is
a
log
record
right.
F
There's
no
difference
between
a
log
record,
a
structured
log
record
and
an
event
in.
In
that
case,
a
log
record
has
a
bearer
for
information
about
an
event,
so
I
think
we
can
talk
about.
How
do
we
take
events?
Generally,
you
know
in
the
the
small
e
sense
and
turn
them
into
log
records
that
can
be
effectively
processed
by
open
Telemetry,
but
I
I,
don't
know
that
we
need
a
special
concept
of
event,
separate
from
log
record.
B
You
mean
like,
on
the
back
end,
I
I,
think
it's
I
think
that's
the
direction
that
we
went,
though,
which
is
to
say
like
these
are
just
log
records,
but
you
have
specific
attributes
that
you're
going
to
look
for
a
schema
name
and
schema
domain
and
essentially
like
if,
if
you
have,
if
those
attributes
are
present,
then
this
is
an
event
and
if
they're
not
present,
then
it's
just
a
generic
log
record
Anthony.
D
I
think
you're
suggesting
that
you
know
is
there:
do
we
really
need
an
open,
Telemetry
event
with
a
capital
E
can't
everything
just
be
a
regular
log
record,
no
special
fields
that
identify
open,
Telemetry
events
and
the
structure
of
something
the
structure
of
some
log
record
is
identified
by
some
combination
of
its
attribute
key
value
pairs.
So
when
you
know
the
log
record
contains
attributes,
like
exception
DOT
type
and
then
like
a
value,
you
know
that
this
is
like
an
exception.
D
Looking
thing
and
I
think
I
think
the
problem
that
I
have
with
that
versus
having
the
event
domain
and
event
name
is
the
complexity
that
it
could
potentially
pose
to
identify
these
things
so
like
if
the
if
you
need
to
examine
three
or
four
Fields
their
keys
and
values
in
order
to
identify
a
particular
type
of
log
record,
that's
like
a
high
barrier
for
to
entry
versus
the
like,
if
you
just
encode
it
all
in
just
two
fields
that
will
always
be
present
on
all
these
things,
then
the
burden's
much
lower
for
both
people
querying
these.
F
And
I
I
think
for
things
where
we're
defining
the
schema
we
can,
we
can
say
you
will
be
able
to
identify
using
one
or
two
Fields
the
schema
that
you
need
to
use
to
process
this
record,
but
for
for
others,
maybe
that's
not
the
case.
Maybe
there
are
three
or
four
fields
that
have
to
be
used
to
identify
the
unique
combination
of
fields
that
can
be
used
to
process
this,
but
that
doesn't
mean
they're,
not
a
log
record
that
can
be
processed
as
if
it
were
a
lowercase
event.
C
So
what
I'm
hearing
here
is
Anthony
I,
think
you're
saying
we
don't
need
a
special
name
for
it.
We
probably
don't
need
a
special
API
for
it.
We
need
a
semantic
conventions
for
it
right.
We
have
semantic
conventions
that
Define
one
or
two
attributes
which
Define
the
schema.
Fine,
that's
the
endorsed
way
of
generating
log
records
from
our
complementary.
Why
do
we
even
need
a
special
name
for
it
or
a
special
API
to
do
that
right?
It's
it's
completely
possible
to
generate
using
the
generic
logging
API
that
we
we
already
defined.
C
E
B
Just
you,
you
want
to
make
it
convenient
for
end
users,
and
we
are
saying
we
have
an
official
concept.
It's
just
not
its
own
separate
data
stream.
That
was
the
thing
we
we
went
away
from.
We
do.
We
do
want
to
have
a
way
to
communicate.
These
comparative
events
to
backends,
like
Jack,
was
saying
we
don't
want
backends
to
have
to
know
about
every
type
of
event
before
they
do
something
useful
with
them.
B
C
The
the
weekends
don't
care
about
the
API
right,
they're
going
to
depend
on
the
semantic
conventions
to
do
their
thing,
so
the
API
is
you're,
saying
it's
a
convenience,
but
in
its
current
form,
in
the
specification
it
doesn't
look
like
it's
a
convenience.
It's
it's
very
Central
there
right.
It's
very
first
class
citizen
thing
there
in
the
in
the
specification.
Maybe
it
shouldn't,
maybe
we
it
should
be
just
like
what
we
did
with
with
other
semantic
conventions.
Okay,
here's
the
definition
of
endorsed
way
of
recording
events
with
semantic
conventions
you
need
helper.
C
Maybe
we
Define
how
the
helpers
are
named
in
in
the
in
the
particular
language
or
or
the
languages
decide
what
the
helpers
are
to
make.
It
easy
convenient
to
record
those
those
log
records,
but
it's
not
on
the
same
footing
as
let's
say,
creating
any
log
record
or
creating
any
spot
right.
We
don't
need
the
first
class
API
for
that
I.
D
I,
don't
I
I
I
I
would
I
would
be
on
board
for
that.
If
that
was
the
case,
but
I
just
want
to
like
push
back
a
little
bit,
I,
don't
think
it's
if
it
does
feel
like
it's
on
an
equal
footing
with
emitting
log
records.
If
it
does
feel
like
there's
all
this
special
accommodation
for
it,
I
think
it's
just
because
they're
so
limited
API,
surface
area
in
the
log
API
in
general.
D
H
F
H
There's
sorry
go
ahead,
I'm
just
gonna,
say
I
think
there's
a
couple
other
pieces
in
terms
of
like
the
the
mindset,
the
developers
in
when
emitting
events
is
substantially
different
than
when
you
know,
building
a
logger
endpoint.
So
you
know
the
kind
of
the
the
framework
when
you're
doing
something
like
rum,
where
it's
all
events,
it's
not
necessarily
going
to
feel
right
to
do
a
logger
I
think.
F
What
I
was
trying
to
say,
which
is
that?
Maybe
we
should
go
further
with
some
of
these
trigger
syntax
apis
like
I,
don't
know
that
adding
an
API
to
create
an
event
that
just
has
a
schema
and
a
name,
and
then
you
split
in
attributes
like
you
would
a
log
record
is
super
helpful,
because
if
you're
already
setting
attributes,
you
can
set
a
domain
and
a
name,
but
if
you
have
an
API
that
is,
this
is
a
ROM
API.
That's
for
creating
events
around.
F
You
know
the
the
life
cycle
of
a
browser
session,
that's
a
much
more
useful
API
that
offers
better
developer
ergonomics.
It's.
F
C
B
F
B
I
mean
like
we
have
all
these
different
standardized
definitions
for,
like
what
an
HTTP
span
looks
like
and
stuff
like
that,
and
for
a
long
time
we
wanted
to
add.
B
We
wanted
to
add
helpers
that
make
it
easier,
but
I
would
suggest
that
we
still
want
this
API
because
it
actually
mirrors
the
other
apis
that
we
have
right.
We
have.
We
have
a
span
API
where
you
can
create
a
name
and
attributes.
We
have
a
span
event
API,
where
you
can
create
a
name
and
attributes
and
I
think
it
would
be
helpful
to
to
kind
of
just
keep
that
pattern
going
with
these
events.
B
B
H
D
Switch
to
slack
or
the
issues
that
have
been
linked
to
in
the
documents
thanks
everyone
and
we'll
see
you
next
week.