►
From YouTube: 2023-01-19 meeting
Description
Instrumentation: Messaging
A
C
D
A
E
I
guess
we
can
go
through
it.
I
don't
see
anything
else.
Unless
you
guys
I
looked
at
the
board
that
we
had
last
week,
but
I
didn't
see
any
changes
in
the
issues
that
we
talked
about.
A
See
my
my
screen:
yes,
yes,
okay,
so
this
document
is
a
walk
in
Focus
I've
been
working
on
it
for
a
lot
of
time,
and
it's
not
done
yet,
but
it's
very
close
to
being
done.
I
did
some
iterations
with
some
people
asking
for
feedback
and
did
some
improvements,
but
showed
us
a
lot
of
more
room
for
improvements
or
things
that
they
are
missing
and
basically
it
captures
what
we
talked
about
in
the
Sig
for
the
last
year.
I
think,
like
a
lot
of
issues
that
we
discussed
and
how
to
address
them.
A
A
This
is,
of
course,
important,
because
we
want
to
extract
the
messages
out
of
the
spam.
We
want
to
be
able
to
enumerate
all
the
relevant
messages
from
Arbiter
expense,
so
we
need
to
be
able
to
know
how
to
do
it
and
the
next
one
is
giving
an
arbitrary
span
having
a
deterministic
algorithm
to
be
able
to
extract
the
specific
messages
that
it
recorded
So.
A
These
are
things
that
users
need,
and
so,
if
we
have
an
arbitrary
span
like
if
the
user
is
looking
for
something
and
it
can't
find
it,
we
need
a
way
to
be
able
to
record
that
things
are
missing
like
for,
for
example,
we
have
a
Kafka
with
a
thousandth
message,
a
batch
of
thousand
message,
but
we
only
recorded.
Then
we
need
to
be
able
to
to
to
tell
that.
This
is
the
the
case.
A
So
if
we
can't
find
the
message
we
know
why,
so
we
need
a
way
in
the
spec
to
to
be
able
to
do
it
and,
and
then
the
next
one
is.
If
we
see
a
span-
and
we
see
a
message
on
this
spin,
we
need
a
way
to
be
able
to
somehow
Traverse
the
trace.
So
when
query
the
database
to
see
other
spends
that
they
also
have
this
exact
message
instance.
So
if
we
follow
a
specific
message,
we
need
to
be
able
to
tell
this
is
where
it
was
sent.
A
These
are
the
places
that
consumed
it.
This
is
where
it
was
settled.
This
is
what
it
was
processed
but
being
able
to
take
a
single
message
and
trace
it
all
over
and
and
the
the
six
requirement
that
I
wrote
is
that,
for
which
message
we
should
be
able
to
have
like
a
clear
algorithm
on
how
to
extract
attributes
that
relate
only
to
this
message
like
because
the
span
and
the
links
the
recorder,
several
attributes.
But
how
do
we
know
all
the
attributes
for
a
given
message.
C
A
So
every
metrics,
like
the
pages
above
I,
describe
each
and
and
requirement
and
why
it's
needed
and
who
needs
it.
Basically,
there's
a
list
of
things
that
I
want
to
suggest
some
changes
to
the
specification,
and
these
are
my
justifications.
These
are
the
the
things
that
I
want
to
to
to
show
that
they
hold
and
you
will
understand
later,
but
let's
just
browse
the
fast
over
there.
So
first
of
all,
any
suggestion
should
be
something
that
is
feasible
for
instrumentation
to
collect
and
by
feasible
I
mean
it's
efficient.
A
It's
idiomatic,
it's
simple,
it's
readable
and
it's
maintainable.
So
if
we
ask
for
instrumentation
Autos
to
collect
something,
but
they
are
not
able
to
collect
it
and
now
it's
missing,
we
have
to
be
able
to
help
for
these
situations.
The
second
one
is
what
happened
if,
for
some
reason,
the
data
is
not
recorded.
We
all
know
that
the
Things
are
Written
in
the
spec
but
they're.
A
A
C
A
Any
tray
structure,
or
we
depend
on
a
specific
Trace
structure
to
give
value,
and
the
next
one
is
to
make
sure
that
if
we
have
ambient
context,
then
it
can
be
captured
and
then
puzzled
and
what
what
will
happen
if
we
don't
have
correlation
context
like
if
the
producer
is
not
instrumented,
if
the
correlation
context
is
lost
or
cannot
be
recorded
or
the
protocol
does
not
support
propagating
it.
So
how
will
everything
look
in
the
absence
of
correlation
context?
A
I
want
to
suggest
to
examine
like
what
will
happen
in
the
future.
If
we
want
to
change
the
trade
structure,
then
things
might
break
so
each
each
proposal
should
be
like
is
less
dependent
as
it
can
on
three
structure,
and
this
way,
if
we
change
it
in
the
future,
we
break
less
than
things.
A
The
next
one
is
our
easy
to
mentally,
follow
and
understand,
because
sometimes
users,
they
don't
understand
all
the
specifications
and
all
the
rules
and
all
the
reasoning.
They
just
see
a
span
with
a
list
of
attributes
and
they
read
these
attributes
and
they
don't
know
a
lot
about
it
and
it
has
to
make
sense
to
them
and
be
mentally
consistent
and
mentally
understandable,
and
next
one
is
how
many
permutations
and
branches
exist,
because
we
know
some
rules
they
have
like
such
a
complex
tree.
A
It
can
be
either
this
way
or
this
way
or
this
way
it
can
be
there
or
there.
It
gets
very
complex,
very
easily
and
I
think
we
need
to
strive
for
Simple
Solutions
that
have
less
permutations
and
less
complexity
and
the
next
one
is
how
many
exceptions
out.
So
we
know
that
we
talk
a
lot
about
our
dreams,
but
the
reality
is
very
different.
A
So
we
have
to
record
data
that
will
give
them
to
the
answers
to
common
questions
and
the
next
one
is
how
many
hops
need
to
be
followed
to
extract
relevant
insights.
So
if
we
need
to
follow
a
lot
of
things
or
if
we
have
a
span,
we
need
to
jump
to
his
parent
with
to
his
children
to
understand
what's
going
on,
then
it's
not
a
good
quality.
We
need
to
avoid
it
if
possible.
A
A
A
Users
end
users:
they
see
some
data
as
noise
and
they
don't
want
to
collect
it
and
also
because
of
costs,
because
users
don't
want
to
pay
for
a
lot
of
spends
if
they
don't
give
them
a
lot
of
value.
So
we
need
solutions
that
are
flexible
to
these
metrics
and
the
last
one
is
how
well
it
fits
existing
Telemetry
span
model
and
Concepts,
because
if.
C
A
A
Yeah,
so
this
is
the
list,
and
this
is
just
the
summary,
and
here
above
I
have
a
few
pages
where
I
describe
exactly
each
one
of
them
who
needs
it.
And
why-
and
my
goal
is
that
what
I
want
to
achieve
in
this
document
is
I
want
to
achieve
the
semantics
and
algorithms
to
be
able
to
do
all
of
these
things
that
are
written
here,
and
for
each
of
these.
F
A
A
Of
course
we
cannot
satisfy
all
of
them
because
some
of
them
Collide
and
some
of
them
are
don't
just
know
with
the
solutions
we
have
to
to
make
compromises
and
I
think
there
are
a
lot
of
ways
to
do
it,
and
we,
these
are
my
justifications
to
why
I
chose
some
things
over
the
others.
But
of
course
it's
all
open
for
a
discussion
if
there
are
other
options
that
a
little
better.
F
D
That's
a
couple
of
thoughts,
it's
awesome,
but
what
you're
talking
about
it's
so
far,
it's
been
not
messaging
specific
right.
It's
just
a
general
semantic
convention,
evaluation
process
right
and.
A
D
I
mean
the
the
this
part:
yes,
but
all
the
evaluation
of
proposed
changes.
So
let
me
finish
my
thought
and
then
our
hope
it
will
be
more
clear
what
I
mean.
So
there
is
the
separate
process
on
stabilization
right,
so
our
generals
of
semantic
conventions
that
is
common
and
many
of
these
requirements,
implicitly
come
there
I'm
going
to
share
the
spec
that
created
in
case
you
didn't
see.
So
there
there
is
the
process.
Is
it's
different?
D
Remember
correctly
the
following
to
come
up
with
the
spec
who
will
Circle
within
ourselves
and
say
if
it's
good
and
then
I
think
it
tell.
The
process
currently
mentions
that
okay,
we
should
stabilize
Spike
and
then
implementation
starts,
but
I
think
we
discussed
like
different
problems
with
it.
So
my
vision
that
okay,
we
come
up
with
the
spare
spec
with
freeze
it
then,
at
implementation
time
we
find
a
lot
of
maybe
small
problems,
maybe
some
big
problems.
D
We
beat
the
rate
back
on
the
spec
to
resolve
them
and
I
think
it's
awesome
to
have
back-end
feedback.
My
point
is
that
we
probably
don't
need
to
formalize
it
this
well,
because
we
will
have
people
like
you
Amir
who
implement
it
then
come
back
with
the
feedback
and
say:
okay,
this
part
doesn't
work
because
back-end
implementation
is
unreasonable
or
users
are
confused.
Totally
was
this
thing
so
I
mean?
A
This
list
is
kind
of
a
summary
of
what
we
we've
been
discussing,
like
at
least
from
my
point
of
view,
but
I
hope.
We
can
agree
that
on
on
this
things
and
I
also
think
that
if
we
suggest
something
to
the
specification,
it
could
be
really
valuable
to
to
summarize
why
we
choose,
we
choose
it
over
other
options,.
A
Like
then,
and
then
having
a
list
with
all
the
reasoning
can
be
useful
in
the
future
or
to
get
it
merged.
D
Yeah
totally
I
agree
I'm,
just
saying
that
this
released
on
your
approach.
It's
awesome,
it's
just
something
that
goes
beyond
messages
pack
and
my
my
only
point
was
we.
We
don't
really
need
to
focus
this
much
on
it.
Maybe
we
can
focus
on
Delta
messaging
conventions,
and
this
I
expect
quality
evaluation
process.
I
I'm,
just
suggesting
you
to
move
it
to
the
journal,
semantic
conventions,
for
example,
because
it
will
affect
any
other
semantic
convention.
In
the
same
way,
we
cannot
do
the
messaging
specific
process,
it's
just
a
suggestion
and
it's
all
good
yeah.
A
I'm
good,
it's
a
good
point
like
for
me.
It
was
just
easy
to
write
it
like
this
in
the
document,
because
it
traces
my
thoughts
this
way,
but
it's
a
Google
doc
and
we
can
think
of
how
to
split
it
and
like
we
don't
have
to
copy
paste
it
into
a
something
formal
like
an
issue
or
NPR.
We
can
just
discuss
it
and
then
do
what
we
think
is
right.
A
D
Awesome
yeah
and
the
other
point
was
maybe
I
understand
that
you
wanted
to
structure
search
like
self-contained
document.
But
do
you
feel
it's
like?
There
is
a
lot
of
Delta
changes
to
what
we
have
now
or
it's
just
some
specific
things
that
we
can
focus
on.
A
So
I
think
like
how
to
use
links
and
where
to
use
links
and
the
semantic
of
links.
Are
there
not
very
well
described
in
the
current
specification
right,
because
it's
mostly
via
examples
and
like
very
little
text
yeah?
A
What
I
want
to
suggest
with
this
document
is
to
formalize
the
like
everything
related
to
links,
so
we
will
have
two
benefits.
One
is
instrumentation
Autos.
They
will
have
clear
the
rules
to
follow.
So
it's
not,
nothing
is
ambiguous.
You
know
exactly
what
to
do,
so.
We
don't
have
all
these
variations
of
different
instrumentations
that
the
code
thinks
in
different
ways,
and
this
is
the
first
one
and
the
second
one
is
for
backends
and
the
processors
that
needs
to
ingest
this
data
and
extract
the
value
from
it.
A
They
need
to
follow
something
that
is
deterministically
and
and
they're
consistent
and
simple,
so
it
will
give
a
lot
of
value
there.
So
I
think
regarding
everything
regarding
links
can
be
improved
in
the
specification,
so
these
things
can
be
achieved
once
everything
is
according
to
the
semantic
conventions.
D
A
Yeah
I,
don't
think
we
need
discussion,
I
I
think,
maybe
those
those
more
things
that
there
could
be
at
the
deal
and
also
be
very
happy
if
to
hear
that
you
support
it
and
agree
with
it.
So
I
can
we
can
discuss
if
to
open
other
apps
or
open
PL
to
the
spec
and
start
pushing
it.
So
if
I
know
that
the
Sig
is
in
agreement
about
it,
then
it's
much
easier
and
if
we
want
to
do
changes,
then
we
can
discuss
them
and
yeah.
A
So
we
it's
not
yet
completed
it's
almost
completed
and
if
you
want
to
read
it
and
give
comments
go
ahead
and
then,
if
you
want
to
wait
until
it's
finished
and
ready
for
review,
we
can
do
it.
Then
there's
a
lot
of
text
and
I
really
described
a
lot
of
details
because
I
wanted
to
document
them
and
I
want,
even
for
myself
not
to
forget
all
the
reasons
and
all
the
requirements
and
yeah.
So
that's.
B
It
so
one
point
of
feedback:
I
had
is
I,
I
I
agree
that
there's
a
lot
of
text
and
it
feels
like
some
of
the
the
the
changes
that
you're
hoping
to
see
out
of
this
are
kind
of
lost
in
in
the
details
a
little
bit
so
like
it's
not
just
reviewing
this
document,
it's
not
obvious
to
me
what
specific
changes
you
are
proposing
it.
It's
not
clear
what
I
mean
there
there's
a
lot
of
like
analysis,
but
it's
not
clear
what
the
changes
are.
E
A
So
like
and
all
the
the
beginning
is
just
any
defining
things
and
describing
things
that
I
want
to
to
base
on
the
lateral
sections,
but
then
I
have
this
section
which
I
call
spec,
and
this
is
the
actual
text
that
I
want
to
suggest
to
introduce
to
the
spec.
So
it
all
goes
down
to
just
a
couple
of
bar
graphs
that
I
want
to
introduce,
but
there's
a
lot
of
reasons
why
they
were
chosen,
and
this
document
basically
captures
those
reasons.
A
So
I'm
not
sure
if,
if
it
should
go
into
a
the
speaker
for
sure
it
should
not
go
like
all
this
text
and
then
I
don't
know
about
the
note
app,
but
maybe
like
a
blog
post,
that
we
can
put
it
in
a
blog
post
and
people
can
read
it
if
they
want
to
learn
more
about
why
we
did
things
in
one
way
or
one
or
the
other.
Currently
it's
just
staying
a
Google
doc.
D
A
Yes,
so
there's
a
couple
of
parts
of
changes
like
six
changes
that
I
want
to
suggest
so
the
the
first
two.
These
are
the
ones
that
I
wrote
that
were
quite
simple
and
they're
simple,
because
I
want
them
to
be
simple,
because
let's
make
them
very
easy
and
non-breakable,
and
then
there
will
be
the
part
of
the
links
of
discussing
all
the
ways
that
links
can
be
used.
So
we
know
that
there's
a
few
permutation.
It
depends
on
if
it's
best
or
single
message,
and
then
we
can
store
things
on
the
link.
A
A
This
will
be
I,
guess
a
Delta
like
a
meaningful
Delta,
and
this
first
part
is
just
like
I
wrote
a
lot
of
the
components
in
our
backend
the
process
spends,
and
when
you
do
it,
you
must
have
like
rules
that
tell
you,
okay,
this
Span
iterating
in
one
way
and
this
penetrating
in
another
way-
and
this
was
even
though
they
are
very
simple-
they
really
help
back-ends
to
to
do
these
tasks
and
they
formalize
it.
A
D
And
what
is
like
for
each
specific
thing?
What
is
that
you
want
to
see
in
this
fact?
That's
not
there
yet
right
so
I
understand
why
you
need
messaging
system
attribute
but
like
what
is
it
out
of
your
requirements
that
is
already
satisfied
and
what
not,
and
if
there
is
something
not
satisfied,
what
is
the
proposed
change?
D
So
if
you
can
highlight
maybe
specific
sentences
or
specific
requirements
or
somehow
summarize
what
what
is
missing
and
let
us
start
there
and
we
can
discuss
these
things
here
and
discuss
suggestions
and,
like
the
the
explanation,
it's
not
subject
of
the
semantic
conventions
where
we
are
here
mostly
on
the
same
page,
for
the
reasons,
and
why
and
everything
right,
do
you
see
what
I'm
saying.
A
Yeah
I
understand
so
I
graded,
the
first
two
suggestions
or
quite
a
small
and
trivial
though
those
are
not
a
lot
of.
He
doesn't
introduce
something
big
to
the
spec,
but
there
is
the
power
of
the
links.
I
have
some
drafts
here
below
that
are
not
yet
they
organized
correctly,
but
there
is
some
actual
suggestions
on
like
everything
we
talked
about
the.
How
do
we
record
a
batch
of
messages
into
links?
What
are
the
attributes
that
needs
to
be
there?
C
A
A
Cool
so
actually,
next
week,
I
will
be
on
vacation.
So
in
two
weeks
we
can
do
it
and
yeah.
D
A
B
I
see
yeah
I
think
it's
a
great
document.
It
has
a
lot
of
detail
and
it's
just
like
ludmil
is
saying
it's.
It's
not
clear
to
me
what
the
the
Delta
you're
you're
you're,
trying
to
do
here.
It
I
I
think
that
there's
definitely
a
lot
there
that
can
go
into
the
spec,
but
one
of
the
things
that
I'm
particularly
interested
in
is,
is
around
the
the
span,
links
and
I
think
that
We've
had
a
lot
of
discussions
around
this,
but
I
feel
like.
B
There
are
definitely
some
scenarios
where
I
think
you've
mentioned
this
in
the
doc
in
your
document
of
how
having
a
parent-child
relationship
would
be
better
to
prioritize
over
the
span,
links
that
we
currently
have
in
the
spec
and
I
agree
with
that.
A
B
Okay,
emila:
do
you
know
where
Johannes
is
he.
D
B
Because
I
would
definitely
be
interested
in
hearing
his
feedback
on
amir's
document
as
well,
but.
D
Yeah
so
then
I'll
ping
Johannes
once
he'll
be
back,
and
hopefully
he
will
have
a
chance
to
read
the
document
before
our
next
talk
about
it.
In
two
weeks.
E
I
I
also
think
it's
very
good
I'll
try
to
take
some
time
to
read
it
as
well.
I
put
it
some
notes.
Why
why
all
the
guys
and
the
girls
were
talking
about
yeah
I,
also
think
that,
because
we
did
some
changes
recently
right,
so
load
Billa
worked
on
the
attributes
and
on
other
things,
and
also
there's
this
old
tab
from
Johannes.
E
So
it
would
be
good
if,
if
the
document
already
considers
in
like
leave
the
things
that
are
already
done
out-
and
maybe
just
put
a
too
long
didn't
read
at
the
at
the
beginning,
with
the
exact
changes
or
some
something
like
that,
so
then
we
we
probably
can
give
you
more
or
people
can
give
you
more
feedback
and
and
maybe
speed
up
the
the
discussions.
B
What
I
guess
another
feedback
I
would
give
is,
it
seems
like
there's
a
lot
of
at
least
several
different
active
several
different
individuals
actively
working
on
various
changes
within
the
messaging
Sig
and
I
feel
like
there's
a
fair
bit
of
overlap
between
them,
such
that.
If,
if
you're,
trying
to
batch
everything
into
one
document
change
or
one
one
Otep
or
one
thing
to
review,
it
makes
it
hard
to
kind
of
resolve
some
of
the
overlap.
B
So
if,
if
there
are
parts
of
your
document
that
are
are
potentially
unrelated
or
not
not
intrinsically
linked
together,
I
I
would
suggest
trying
to
split
it
out
as
like
separate
proposals.
So
like,
for
example,
attribute
changes.
I,
don't
think,
are
necessarily
linked
to
span
links
versus
parent
child
changes.
B
A
A
B
I
mean
I
think
it's
fine
having
a
document
to
kind
of
discuss
the
overall
changes,
but
when
actually
trying
to
implement
or
integrate
I
I
strongly
encourage,
try
to
to
decouple
as
much
as
possible.
E
All
right,
I
think
Santosh
is
here
now.
So
if
you
want
to
go
through
your
item
in
the
agenda,
yeah.
F
Yeah
so
yeah
I
I'm
part
of
the
log
Sig.
We
have
been
discussing
the
event
specification
and
we
came
across
Cloud
events
and
you
know
we
wanted
to
I
mean
we
felt
you
know,
there's
some
overlap,
you
know
and
we
don't
fully
understand.
Cloud
events
so
I
reached
out
to
the
cloud
events,
team
and
Jesse
Manning
who's
on
the
call
I
think
he
asked
me
to
you
know
come
here
because
he
joins.
You
know
this
meeting,
so
Jesse
I
think
I.
F
Basically,
the
open,
Telemetry
event
specification
is
meant,
you
know
for
creating
events
meant
for
you
know
Telemetry
purposes,
and
it's
not
super
clear
to
you
know.
As
in
the
log
Sig,
you
know
what
is
even
the
intent
of
cloud
events.
F
G
Foreign
yeah,
so
Cloud
events
is
seeks
to
establish
a
standard
way
of
creating
metadata.
You
know,
increasingly,
what
we
see
is
events,
particularly
moving
between
organizations
within
a
single
Enterprise
or
also
between
Enterprises,
so
you
can
think
of
it
as
a
you
know
how
we
have
sync
apis
right
now.
You
know
you
expose
out
your
async
kpi
to
a
external
partner.
They
call
your
your
rest,
API,
you
get
a
response
back.
G
A
lot
of
people
see
that
moving
towards
an
async
world
as
well,
where
you
know,
if
there's
a
stock
order,
if
there's
you
know
a
change
in
the
weather
forecast,
rather
than
having
to
constantly
pull
for
those
things,
we
push
out
events
to
to
Partners
who
are
interested
in
them.
The
challenge
is
that
a
lot
of
times,
those
events
that
are
pushed
out
don't
have
a
lot
of
context,
disassociated
with
them
like
if
you're
making
a
sync
call.
You
know
why
you're
asking
for
that
particular
piece
of
information
with
an
event.
G
It
arrives,
sort
of
un
unrequested
on
on
your
doorstep,
and
you
kind
of
have
to
figure
out
what
you
what
you
want
to
do
with
it.
So
it's
hard
I
think
cloud
events
is
providing
a
standard
way
of
giving
of
providing
metadata
about
a
particular
event,
so
that
the
receiver
of
the
events
can
understand
why
it
arrived
on
their
doorstep
and
and
hopefully
be
able
to
do.
You
know
process
it
in
a
more
logical
kind
of
way.
G
So
it's
hearts,
and
also
a
big
part
of
this-
is
you
know,
as
we
sort
of
evolve
through
different
messaging
Technologies,
there's
a
chance
that
it
could
move
from
Kafka
to
IBM
mq.
It
can
move
over
to
Solace
who
I
work
for
you
know,
move
over
to
activemq
and
then
every
step
along
the
way
that
metadata
needs
to
be
moved.
G
You
need
to
understand
sort
of
what
the
original
intent
of
that
particular
event
was
and
so
Cloud
events
its
heart
is
about
creating
standard
ways
to
standard
metadata,
to
attach
to
events
and
also,
as
it
travels
along
a
wire.
How
is
that
preserved
across
different
messaging
Technologies
so
that
if
we
create
an
event
in
mq
and
eventually
we
consume
it
off
of
Kafka?
How
do
we
ensure
that
that
metadata
stays
with
the
event
itself.
F
Could
you
give
me
an
example
of
the
metadata
in
in
the
case
of
let's
say,
the
weather
update.
G
Yeah
yeah,
so
the
weather
update,
so
there's
actually
only
four
sort
of
mandatory
Fields
associated
with
a
cloud
event.
There
is
a
sort
of
a
grid,
so
there's
an
ID,
then
there's
sort
of
an
event
source
which
yeah,
who
created
that
oh
man,
I'm
gonna,
forget
it.
C
G
Right
right,
and
so
that
means
so
when
you
that
that's
the
standard
sort
of
the
metadata
associated
with
it.
F
Okay
and
when
you
said
there
is
there's
it's
not
as
event
format,
you
know
what
does
that
mean
so
I'm
looking
at.
Let
me
share
my
screen.
F
So
Doug
commented
this
in
in
my
issue
to
Cloud
events.
It
says
that
it's
best
to
not
think
of
C
as
as
an
event
format,
but
so
what
does
that
mean?.
G
It's
meant
to
be
additive
to
what's
right
there,
not
a
replacement
yeah,
so
I
don't
really
know
what
Doug
is
talking
about
that,
but
I
definitely
agree
it's
not
it's
about
how
to
expose
existing
event
data.
You
know
sort
of
like
PID.
You
know
the
source
of
it
in
a
common
location
that
that's
the
part,
I
understand
and
agree
with
so
you're,
exposing
sort
of
the
ID,
the
type
The
Source
in
a
very
prescribed
place
in
very
specific
wire
for
wire
protocols.
So
you
know
that
this
is
a
cloud
event.
G
Compliance
message
in
IBM,
mq,
you're
gonna,
have
a
very
specific
header
that
shows
you
that
information.
If
it's
over
in
Kafka
you're
gonna,
have
a
cough,
a
Kafka,
Heather
or
Kafka.
You
know
value
that
shows
you
that
information.
You
can
rely
that
on
that
information
being
there
in
the
in
the
exact
in
that
exact
place.
So.
F
Okay,
so
would
it
be
correct
if
I
say
that,
since
you
mentioned
you
know,
this
is
typically
meant
for
exposing
events
from
one
system
to
an
in
a
completely
different
system
which
is
following
a
different
set
of
you
know,
standards
for
representing
the
events.
You
know
you
provide,
you
know
a
standard
to
you
know
to
to
expose
the
metadata,
and
in
so
for
open,
Telemetry
events.
F
It
is
applicable
only
when
we
font
somebody,
you
know
in
a
completely
different,
like
we
are
exposing
this
in
a
standard
format
today
defined
by
the
open,
Telemetry
spec,
but
in
future,
if,
if
required,
for
a
completely
different
system
to
consume
these
events,
we
will
need
to
have
a
mapping
to
turn
hotel
events
into
Cloud
events.
Would
that
all
that's
required
so.
G
I
I
agree
again
with
Doug
in
that
you
know
we're
defining
I,
think
open,
Telemetry
sort
of
properties
within
this
within
this
and
with
a
with
an
open
Telemetry
like
you,
want
to
have
various
different
attributes
and
feel
free
for
others
to
to
chime
in
on
this
open,
Telemetry
we're
talking
about
a
lot
of
different
attributes,
that's
associated
with
open
Telemetry
span
and
then
there's
some
that
have
to
be
carried
along
with
the
the
event
itself,
like
the
span
ID
the
trace
ID.
G
If
you're
gonna,
you
know
intelligently,
Produce,
open,
Telemetry
information,
you
need
to
have
that
information
attached
to
a
and
attached
to
a
message,
but
having
you
know
what
you
need
to
actually
have
that
attached
to
the
message
on
the
wire
line.
Open
Telemetry
has
sorry
Cloud
events
has
deferred
to
open
Telemetry
on
on.
On
that,
like
what?
What
do?
G
We
include
on
the
on
the
wire
to
to
enable
open,
Telemetry
and
then
like
doc,
says
additive
to
that
is
the
meta
information
that
cloud
events
that
you
would
need
for
cloud
events,
so
I
I
would
say
that
they're
separate
concerns
that
you're
going
to
have.
If
you
want
to
have
a
cloud
event,
that's
great
Define,
the
the
four
fields
and
you
have
a
cloud
event
if
you
want
to
enable
a
message
to
be
intelligently.
G
Traced
using
open
Telemetry
include
the
the
information
that
you
need
for
open,
Telemetry,
presumably
like
the
span
ID
and
the
trace
ID.
Maybe
some
other
sort
of
attributes,
but
I,
don't
see
a
lot
of
overlap
actually
between
CE
and
otel,
and
the
need
for
a
mapping
between
those
two.
F
Okay,
yeah
that
that's
what
I
feel
like
to
so
yes,
sir
validation.
E
I
yeah
I
I
just
wanted
to
to
make
sure
that
I'm
falling
because
I'm
a
little
bit
lost
so
I
was
why
we
were
talking.
I
was
trying
to
skim
the
the
issue,
so
the
involvement
at
the
the
the
the
messaging
seek
has
been
with
a
cloud
event.
I
was
more
more
involved,
I
think,
and
it
was
what
Jesse
was
saying.
E
Is
that
so
Cloud
events
is
just
Cloud
events
right,
but
it's
it's
used
in
in
in
in
applications
to
to
propagate
things
and
so
on,
and
there
was
a
need-
or
there
was
already
some
extension
in
in
Cloud
events
that
contained
these
two
two
Fields
the
trace,
ID
and
cnid,
and
what
the
group
was
test
or
or
we
got
involved
and
worked
on.
E
It
was
that
there
was
no
specification
or
semantic
conventions
for
how
a
trace
should
look
like
when
your
your
system
is
using
Cloud
events,
so,
for
example,
if
you're,
if
your
system
is
using
communicating
through
Cloud
events,
how
how
do
you
expect
a
trades
to
look
like
in
the
group?
So,
as
in
this
group
here
we
worked
to
Define
semantic
conventions
for
creating
spans.
That
model,
for
example,
Cloud
events
so
and
now
we're
doing
the
same
for
messaging
systems.
E
So
things
like
like
I
sent
like
a
producer,
sends
a
message:
is
it
a
parent
and
child
relationship?
This
is
do
we
do
we
have
it.
We
added
a
link
and
things
like
that.
So
we
we
worked
on
modeling,
the
the
trace
structure
and,
and
as
part
of
this,
of
course
like
which
span
attributes
a
cloud
event
span
would
have
so.
For
example,
we
had
the
cloud
event
ID
the
cloud
event
type
as
fan
attributes
and
things
like
that.
E
But
the
group
is
not
related
to
like
hotel
events
or
or
if
hotel
events
should
reuse,
Cloud
events
and
things
like
that,
which
is
we
worked
more
or
less
on
on
modeling
a
trace
structure
for
applications
that
would
use
that
use
cloud
event
and
there's
a
experimental
document
that
is
experimental
semantic
on
which
for
cloud
events,
you
can
can
go,
go
there
as
well
and
check
it
out,
but
that
that
is
that
is
pretty
much
it
and
it
may
change
or
we
might
merge
it
together
with
the
messaging
that
we
are
working
in
messaging,
semantic
methods
we're
working
on
because
they
overlap.
E
Usually,
for
example,
when
you
have
a
system,
that's
using
Cloud
events.
Cloud
events
can
be
propagated
with
messaging
systems
like
rabbitmq
or
whatever
it's
just
a
payload
right.
So
that
would
so
the
code
comments
that
we
have
now
for
parliaments
might
get
merged
into
the
same,
because
it
would
be
considered
as
a
message
as
well,
not
sure
if
that
was
helpful,.
F
Yeah
yeah,
it
is
definitely
so.
Are
you
saying
that
if
anybody
wants
the
spans
to
be
exported
in
the
in
you
know
to
a
cloud
event
destination
to
to
to
a
consumer
who's,
expecting
data
in
a
cloud
event
format,
then
you
are
your:
are
you
know
defining
the
conventions?
Is
it
exactly.
E
Yeah
so,
for
example,
people
that
write
instrumentation
or
people
that
write,
for
example,
Cloud
events
as
the
sdks,
so,
for
example,
I
worked
in
the
goal
SDK,
for
example,
I.
E
When
you
send
call
events,
the
SDK
creates
a
like
a
producers
fan
and
then
the
receiver
knows
how
to
to
read
the
things
from
the
spin
and
continue
the
trace
and
it
to
The
Container
as
a
parent
to
The
Container
as
a
as
a
child
through
the
container
there's
a
link,
and
things
like
that,
so
the
convex
that
we
wrote
tells
you
like,
tells
someone
writing
instrumentation
or,
for
example,
writing
Cloud
event,
sdks
how
how
a
trace
should
look
like,
for
example,
in
an
application,
I'll
I'll
link
here
the
I'll
also
put
in
the
document
the
document
for
the
current
conveys
that
we
have,
and
hopefully
that
also
can
help
clarify
because
there's
some
diagrams
as
well.
F
Okay,
yeah
I
think
what
I'm
not
fully
following
is
like
who,
who
are
the
consumers
today?
You
know
that
are
expecting
this
pants
in
in
the
cloud
event,
format.
F
Are
the
consumers
like
today,
open
Telemetry
Hotel
protocol,
you
know,
is
meant
for
the
Telemetry
backends
right.
C
F
E
No,
no,
no
so
the
the
RR
conventions
are
just
for
telling
instrumentation
how
to
model
span
so
like
which
which
attributes
I
spent
will
have
does.
E
Does
this
attribute
model
like
a
producer
operation,
a
consumer
operation,
but
those
are
all
spans
and
they
will
be
turned
into
spans
into
otop
message
and
then
back
as
you
think,
just
ingest
like
we're
not
model
anything
that
will
that
open
time
will
use
or
we
will
send
as
Cloud
event
data
and
that's
not
what
we're
doing
we're
just
defining
how,
for
example,
let's
say:
I
have
an
application
that
has
a
producing
a
consumer
and
both
of
us
decide
that
we'll
use
Cloud
events
as
the
as
the
data
to
transport
the
data
right.
E
E
Other
way,
but
this
will
be
all
spans:
no,
there
will
be
no
Cloud
event,
and
it
is
just
because
the
applications
use
called
event
and
we
wanted
to
have
a.
F
Okay,
all
right
so
I
think
then,
in
that
case,
at
this
point
it
doesn't
look
like
there
is
much
to
do
for
us
when
defining
the
open,
Telemetry
event
specification,
except
for
maybe
like
Doug,
says
in
feature.
If
we
ever
want
to
turn
hotel
events
into
Cloud
events.
How
do
we,
you
know
Define
a
mapping?
F
Think
I
joined
this
meeting
only
to
talk
to
Jesse.
E
E
F
F
Okay,
I
think
I
have
some
info.
Let
me
go
back
and
think
about
it,
but
I'm
good
for
now.
Yeah.
Thank
you
for
the
info.
Nice.
E
To
meet
you,
man
yeah
what
we
are
almost
at
the
end:
I
guess
that
is
it
then
I'll
see
you
all
next
week.