►
From YouTube: 2022-10-27 meeting
Description
Instrumentation: Messaging
A
C
D
E
B
B
A
E
E
Cool,
so
this
is
the
agenda.
We
don't
have
anything,
but
we
can
keep
going
over
the
pull
requesters.
Actually,
oh
I'm,
not
sure,
okay,
so
we
can
keep
going
cover.
The
pull
request
is
attributes
unless
your
folks
want
to
add
something
to
that
gender.
A
E
Discussed
last
time,
so
I
would
have
done
I
removed
any
Clarity
on
where
to
put
this
attributes
on
so
I,
don't
have
any
prescription
on
links
or
suspense
just
to
stay
away
from
controversial
topic
for
now
and
yeah
I
analyst
a
couple
changes
in
the
changes
to
yeah
another
thing:
I've
done,
I
removed,
messaging
URL
I
think
we
discussed
it
over
the
meeting
last
time
and
I
also
renamed
send
operation
to
publish,
because
we
now
have
some
conflict.
E
We
said
that
we
have
like
we
used
term
publish
in
the
beginning
of
the
stack,
and
then
we
call
this
operation
stand.
E
Yeah
but
I
guess
we
can
now
go
through
it
offline
and
maybe
we
can
focus
on
the
discussion.
Singapore
requests
so
I
can
have
open
there.
E
Okay,
so
I
think
there
was
an
interesting
conversation.
E
Right
so
the
thing
we
wanted
to
talk
about
last
time
is
a
system
and
MPP
and
GMS
right.
E
You
can
have
more
than
one
system
on
the
spend.
B
B
Very
symmetrical
to
a
database,
but
also
you
have
like
a
system
and
then
a
possible
orm
top
of
the
of
the
driver
right
and
then
people
get
into
this
conflicts
of
what
should
go
into
the
system
if
it's
the
orm
name
or
the
or
the
like,
I,
don't
know
like
MySQL,
right
and
and
there's
no
like
a
clear
answer.
What
to
do
I
think
in
a
database
they
request,
the
driver
name
will
be
used
for
the
system
and
and
not
like
the
the
wrapper.
Does
it
does
it
make
sense.
E
B
More
systems,
and
then
you
have
like
the
like
the
driver
itself,
like
the
the
thing
that
you
actually
use
right
so
I
think
it's
confusing
both
for
database
and
both
for
messaging
and
then
I.
Think
open
Telemetry
in
general
should
be
more
descriptive
about
what
to
do
in
these
cases
and
what
are
your
thoughts.
E
I
think
we
should
allow
to
have
a
different
sets
of
things
right.
So,
for
example,
if
I'm
in
we
have
a
system
called
service
bus,
it
supports
so
it
works
over
ampp
right.
So
if
there
is
some
attributes,
for
example,
it's
I
know
some
some
MTP
specific
thing.
What
is
it
Anyway
I
want
to
have
this
attribute
in
amqp,
namespace,
right
and
I
also
want
my
specific
service
bus
things
in
service
bus
namespace.
E
But
then
the
question
is:
how
do
we
say
that
there
are
two
systems
that
do
we
even
need
to
things
like
JMS
or
amqp?
They
are
well
known,
said.
The
Hat
should
be
a
check
and
thank
you
the
early
like
an
abstraction,
either
backhand
knows
that
service
bus
implements
the
MPP
and
apply
some
additional
semantics
right
or
it
it
needs
to
know
it
should
to
Telemetry
and
then
system
becomes
an
array
or
something.
B
B
So
I
think
that,
like
we
should
be
consistent
like
if
we
decided
system
is
like
the
low
level
like
the
driver,
the
actual
networking
protocol
or
whatever
that
is
like
that,
the
bottom
one.
Then
we
should
be
consistent
across
messaging
systems
and
databases
and
maybe
come
up
with
a
different
attribute
to
describe
like
the
obstruction
above
it
like
JMS
or
I,
know.
Ruby
has
a
lot
of
wrappers
around
messaging
systems
and
databases.
The
orms.
E
Yeah
the
question
is,
but
let's
let's
try
to
understand
what
would
be
the
use
of
it
just
to
have
some
quality,
so
it
will
be
the
back
ends
who
apply
some
specific
experience
right
for
to
visualize
specific
system
and
they
need
to
know
if
it
works
with
MPP
right.
Maybe
there
is
a
specific
experience
for
interview,
maybe
there's
a
specific
experience
for
a
certain
system.
B
D
Oh,
this
is
a
gym
like
maybe
quickly
finding
things
that
apply
to
JMS
or
the
underlying
protocol.
Amtp
I
think
is
also
another.
You
know
valid
reason
to
have
both
on
these
two
things,
like
I
I,
feel
fairly
opinionated,
that
we
should
allow
kind
of
messaging.jms.whatever
and
messaging.amkp
Dot
whatever
in
the
same
Trace.
D
B
Like
maybe
for
now,
we
can
just
assume
that
the
system
is
like
not
the
JMS,
it's
like
the
actual,
the
mqp
like
the
actual
system
and
remember
that
we
have
to
to
do
it
in
the
future.
One
day.
D
D
I
I
have
one
idea:
I
just
don't
know
if
it's
too
tailored
to
this
example.
If
I
don't
know
if
it's
generic
enough,
but
JMS
is
a
standard.
Api
and
amqp
is
a
protocol
right
and
so
I
wonder
if
we
have
the
concept
of
what
is
the
API
and
what
is
the
protocol?
So
maybe
it's
messaging.api
and
message
dot
protocol
are
two
separate
things
and
then
those
are
two
namespaces
that
you
can
put
into
messaging
dot,
API
dot,
whatever
messaging.protocol
that
whatever
I
just
don't
know.
If
that's
too
tailored
to
this
example
or
not.
E
I
actually,
like
your
comment,
it's
a
really
useful
idea
that
MPP
is
a
protocol
and
then
at
least
an
upper
and
Telemetry
world.
We
put
protocol
level
things
along
with
anything
right.
So,
for
example,
we
have
net
peer
name
or
something.
So
since
it's
just
different
concepts,
we
can
we
can,
or
somebody
can
create
an
additional
list
of
him,
keep
a
specific
protocol
of
things
right
and
then
you
can
combine
spans.
E
You
can
combine
attributes
from
ampp,
along
with
spans
from
messaging
spec,
but
amqp.
It's
the
again.
It's
the
protocol
level
concern,
and
in
this
fact
we
are
I
think
we
have
stated
somewhere
that
we
are
not
tackling
the
protocol
level
just
yet
and
still
we
can
combine
system
specific,
gaining
mqp
and
then
for
GMS.
E
E
D
E
Should
not
even
being
the
messaging
namespace,
it
probably
should
be
just
the
root
name
space
for
the
protocol,
or
maybe
it
should
be
messaging.d
mqp.
So
what
I'm
suggesting
that
amqp?
We
put
it
aside.
It's
not
the
system
right,
so
it's
okay
to
combine
MPP
attributes
with
anything.
Then
they
can
exist
on
their
own.
If
somebody
needs
to
like
I,
don't
know,
use
a
skull
level
and
keep
it
quiet.
There
could
be
an
instrumentation
for
mpb
Library.
E
E
D
I
think
I
think
I
agree
with
your
JMS
Kafka
example
where
but
amqp
I
think
is
a
messaging
system.
It's
just
that
you
can
have
like
GMS
is
like
an
adapter
of
that
sits
on
top
of
various
messaging
systems
right.
It's
like
it
adapts
a
standard
API
to
an
underlying
system
or
provider.
So
I
like,
for
example,
if
you're
using
a
cupid
API,
which
is
a
faithful
representation
of
everything
in
the
MPP
protocol.
In
you
know,
in
a
specific
API,
the
cupid
API,
then
I
think
in
that
case
the
system
to
me
is
clearly
amqp.
D
It's
just
when
you
have
this
adapter,
that's
on
top
of
you
know
an
a
system
like,
and
then
you
have
things
that
are
specific
to
that.
You
know
well
the
JMS
specific
stuff
I,
just
that's
where
I'm
just
not
clear
how
to
handle
it,
but
I
I,
because
I
think
amqp
and
Kafka
are
peers
in
that
regard.
Right
you
can
Implement
I,
don't
know
for
sure,
but
I'm
we've
mentioned
it
I'm,
assuming
that
there's
some
JMS
implementation
that
uses
Kafka
as
a
provider
and
there's
also
a
you
know:
JMS.
D
It
has
a
there's,
an
AP
provider
and
there's
many
other
providers,
so
it's
just
when
you
have
an
abstraction
or
an
adapter
on
top
of
a
system.
How
do
we
handle
that
I?
Wonder
I
think
it
should
be
the
same
for
Kafka
and
ankp,
and
you
know
any
other
provider
for
GMS
should
be
a
similar
strategy
for
all
of
them.
E
Yeah,
it's
just
the
same,
but
let's
first
clarify
the
hit
QP
part,
so
I
can
use
Cupid
apis
directly.
But
imagine
I
have
a
messaging
system
on
top
of
HTTP
and
there
are
plenty
of
them.
B
B
So
it
can
use
like
a
ready,
so
rub
it
or
it
supports
a
few
beacons,
and
then
you
can
just
send
them
a
message
and
it
gets
sent.
And
then
you
read
it
on
the
other
side
and
you
don't
know
what
backend
is
involved
so
I
think
there's
no
point
to
it.
Just
to
add
another
example
to
this
discussion.
E
Yeah
and
I
think
there
are
others.
There
is
a
thing
called
massive
Transit
in.net
any
service
mesh
that
does
messaging,
for
you
is
an
example
of
such
a
system
right,
but
the
question
is
where
instrumentation
is
done?
If
it's
done
in
underlying
library
right,
then
you
can
have
concrete
system
examples.
If
it's
done
in
abstraction,
then
you
can
have
an
abstraction
spread,
maybe
with
just
a
generic
attributes.
It's
an
interesting
question
how
to
merge
this
two.
But
let's
keep
it
aside.
D
Yeah
I
yeah,
that
that
is
a
problem
and
I
do
think,
though
amp
is
very
much
like
just
like
Kafka
right,
it's
a
it's
a
way
of
doing
messaging
and
then
it's
just
possible
to
adapt
it
to
some
other
API
like
JMS
like
it's,
it's
just
a
it's
one,
messaging
I
I
think
it
isn't
very
much
a
messaging
system.
Mkp.
E
E
Said
that
that
name
suggests
that
it's
it's
a
protocol
right
and
you
can
you
you
need
to
have
additional
semantics
on
top
of
it.
So
it's
yeah
it
clarifies
something
but
instrumentation
for
mqp.
D
And
sources
and
destinations
within
that
broker
like
but
things
like
it
like
just
imagine,
I've
written
an
application
using
Cupid
right
so
I'm,
an
amqp
native
application.
D
There's
it
almost
feels
like
well,
if
we
relegate
ampp
out
of
the
messaging
space
altogether
into
something
equivalent
of
you
know,
net
dot,
something
that
there
there's
no
messaging
right.
There's
no
messaging
instrumentation,
like
I,
think
that
there's
most
like
sources
and
destinations
and
so
on
all
the
things
we're
talking
about
for
do
have
Concepts
expressed
in
amtp,
so
I
think
amdp
can
express
a
lot
of
these
things
and
I.
You
know
I
I
appreciate
that
it
is
labeled
a
protocol,
but
but
I
don't
think
that
necessarily
means
it's
not
like.
D
It
also
said
it's
a
message
queuing
protocol
right,
it's!
It
is
very
much
about
messaging
and
has
a
lot
of
these
messaging
Concepts
formalized
in
it.
E
So
if
you're
saying
yeah
correct
me
from
wrong
that
assuming
someone
implements
their
own
I,
don't
know
wrapper
around
just
pure
amqp
and
use
this
as
it
as
a
messaging
system
without
SDK
right,
it
just
communicates
to
the
broker
that
supports
MPP.
E
D
I
think
a
lot
of
so
I
think
what
we
have
is
for
a
lot
of
messaging
systems
like
Kafka
I,
don't
know,
I'm
not
going
to
come
up
the
long
list
here,
I
guess,
but
you
know
that
they
have
both.
They
have
everything
kind
of
expressed.
There
is
a
they
provide,
an
API
that
uses
a
native
protocol
to
communicate
with
an
existing
broker.
Amkp
is
something
a
little
more
generic
where
the
broker
you
know
is
the
details
of
all
the
broker.
Behavior
are
not
really
specified.
D
It's
just
saying
how
do
I
get
something
to
the
broker,
but
I
think
it's
still
a
messaging
system.
You
know
I,
definitely
think
of
it.
You
know
our
product
has
an
implementation
of
ampp
as
well
as
mqtt.
Mtt
is
also
another
very
something
very
similar
to
amqp
it
it.
It
specifies
a
little
bit
more
Behavior,
which
is
nice,
but
you
know
what
I
think
I
think
these
things
very
much
are
messaging
systems.
D
You
know
we
I
like
in
our
product,
it's
very
much
a
peer
of
Our
Own,
Native
protocol,
it
you
know,
there's
just
a
a
little
bit
that
we
impose
like
we
say.
If
you
want
to
publish
a
cure
or
a
topic,
we
have
ways
of
specifying
that
in
amqp,
but
it
uses
amp
Concepts
to
express
that
it's
just
you
know.
D
Basically,
the
format
of
certain
fields
and
annotations
is
specif
is,
is
clarified
right
to
use
it
with
our
product
and
and
that's
what
generally
happens,
but
so
I
think
aimkey
has
most
of
the
tools
to
be
its
own
system.
There
seems
to
be
a
little
bit
of
structure
imposed
to
actually
use
it
right.
I
I
I
to
sum
it
up:
I
think
it
is
a
messaging
system
and
it's
just
it's
awkward,
because
it's
kind
of
in
the
middle,
it's
it's
not
TCP
or
HTTP.
D
It's
definitely
more
message
oriented
than
that
and
I
I
do
think
that
a
lot
of
as
I
said
a
lot
of
things
that
we
talk
about
in
terms
of
a
source
and
a
destination
and
the
things
that
we
think
of
as
messaging
concepts
are
definitely
in
amqp
right,
so
I
think
ampp
can
can
fill.
You
know
the
need
of
what
we're
doing
here
and
so
I
I,
think,
yeah
and
so
back
to
the
point.
I
started
earlier.
D
That
proprietary
systems
like
Kafka
and
and
ours
and
a
lot
of
others,
you
know
we
have
a
broker
protocol
and
API,
and
in
that
case,
where
there's
one
sort
of
entity
that
provides
all
things,
it's
very
clear.
What
the
system
is?
It's
Kafka
right,
you
know,
and
in
the
case
where
you've
got
generic
apis,
where
maybe
something
proprietary
underneath
implements
it.
It's
it's
more
of
a
gray
area
and
the
case
of
amqp,
where
it's
kind
of
only
the
piece
in
the
middle.
That's
totally
common.
D
It's
a
little
less
clear
what
the
system
is
like
if
a
if
a
active
mq
broker
receives
an
ampp
message
from
the
broker's
point
of
view
as
a
amqp
system
or
the
active
mq
system
and
on
the
but
but
at
the
same
time
I
do
think
that
there
are
amqp
apis
which,
if
it's
pretty
much
a
faithful
representation
of
the
mqb
protocol,
that
API
is
going
to
say.
Well,
my
system
is
ampp,
so
I,
don't
know,
I
I,
think
ATP
is
a
system
and
it
when
there
are
abstractions
on
top
of
systems.
D
That's
where
we
just
have
to
say
how
do
we
express
that?
Is
it
you
know,
is
there
a
do?
We
increase
the
conscious
of
a
system
adapter
or
system
abstraction
or
something
that
is
a
layer
on
top
of,
or
do
we
not
bother
specifying
that
and
it's
just
allowed
to
appear
as
a
messaging.jms
in
a
Trace.
E
So
it
sounds
like
yeah,
so
let
me
just
a
quick
summary,
so
we
should
expect
so
we
consider
nqp
is
one
of
the
possible
obstructions
right
and
possible
systems,
and
then
we
can
have
as
many
abstractions
as
exist
in
the
industry.
We
don't
even
know
how
many
right,
so
it
could
totally
possible
to
have
GMS
and
name
QP
and
service
bus
to
another
system
that
supports
the
most
in
the
one
span.
And
yes,
the
question
is
how
to
specify
it.
E
Why
we
want
to
specify
it
unless
Amir
you
have
implemented
something
on
aspect
on
you,
you
can
share
what
exactly
you
want
to
light
up
and
I
will
step
in
a
second.
So
my
proposal
here
is
to
just
not
specified
until
we
have
a
understanding
how
it
can
be
used
and
for
now
to
keep
this
open
enough
to
for
it
to
evolve
in
the
future.
D
Sure,
yeah
I'm,
fine
with
that
and
and
we're
not
limited
to
only
putting
messaging.system
attributes
right-
is
that
that
another
decision
we're
coming
to
here
like
because
if
the
most
concrete
thing
I
know
is
ampp
but
I
also
know
about
JMS
am
I
allowed
to
put
messaging.jms
and
messaging.amkp
stuff
for
the
same
Trace.
Even
though
the
system
is
ampp.
E
So
if
my
single
instrumentation-
and
they
know
about
the
mqp
and
JMS
at
the
same
time-
GMS
well,
it's
interesting.
What's
more
specific
right,
we
don't
know,
but
assuming
it's
GMS,
it's
closer
to
the
user
API.
E
So
probably
it
should
be
GMS,
but
then
anyway,
instrumentation
needs
to
pick
one
of
them
and
put
in
the
system,
and
then
the
question
is
so
what
we
have
in
the
stack
currently
that
this
namespace
must
match
the
system.
This
is
a
hard
requirement.
We
need
to
relax.
B
So
so
what
I
think
about
is
like
I
need
an
algorithm
like
a
way
if
I
get
a
custom
spend
which
I
know
nothing
about
like
how
do
I
get
this
set
of
attributes
and
make
sense
out
of
them.
So
if
I
know
that
the
the
rules
like
I
always
go
to
messaging
systems,
I
see
some
text
there
and
then
I.
Look
in
all
the
articles
for
messaging
Dot
and
the
text
I
found
in
system
and
I
get
like
a
set
of
attributes
and
I
know
what
they
mean.
B
D
Does
it
help
if
messaging
system
would
be
an
array
where
perhaps
it's
ordered
where
the
first
item
is
the
kind
of
highest
level
thing
JMS?
In
this
example,
that's
the
closest
to
the
user,
and
then
you
know
if
it's
on
top
of
a
protocol,
a
second
element
in
the
array
could
be
the
protocol
that's
on
top
of
and
that
it
allow
would
that
does
that
make?
Does
that
address
any
of
your
concerns,
or
so.
B
I
think
if
we
know
the
just
two
layers
like
system
and
the
obstruction
on
top
of
it,
so
I
think
it
will
be
more
comfortable
instead
of
having
an
array
just
to
have
two
attributes
like
one
that
describes
the
system
and
another
one
that
describes
the
obstruction
and
then
have
like
a
set
of
attributes
for
each
one.
I'm,
not
sure
we
can
cover
all
cases,
but
it
for
sure
be
so
much
easier
for
beacons
and
uis
and
whatever
process
that
needs
to
to
get
this
data
and
extract
the
things
out
of
it.
D
Makes
that
makes
sense
to
me.
I
was
just
going
to
say
that
you
may
end
up
in
a
situation
where
you
can
only
make
one
of
those
two
required.
Is
that
like
okay,
like
that,
because
you
might
like,
if,
let's
just
say
we
in
our
example
of
JMS
over
antp,
that
the
system
is,
we
could
debate
this?
But
let's
just
say:
for
now
the
system
is
JMS
and
maybe
we
call
it
I
don't
know.
Protocol
is
amtp.
D
Let's
say
you
might
know
the
system
JMS
in
a
certain
case
right,
like
you,
your
generator
trace
your
JMS
Auto
information.
So
they
put
system
equals
JMS
somewhere
else.
Let's
say
I
know
we're
not
covering
Brokers,
but
you
know
we
have
to
think
about
them
a
little
bit.
So
a
broker
gets
the
message
and
it
receives
an
amtp
message.
So
it
doesn't
know
necessarily
if
this
is
a
JMS
message.
D
Is
it
going
to
be
okay
that
so
I
think
what
if
we
go
down
that
path,
I
think
we
have
to
open
the
door
to
the
possibility
that
only
one
of
the
two
is
required.
Does
that.
A
B
Understand
I
think
like
there
are
so
many
Concepts
and
we
try
to
like
come
up
with
a
spec
that
the
like
captures
everything
and
always
walks
correctly,
but
I
I
support,
like
maybe
we
say
like
the
system.
We
it
doesn't
have
to
be
like
a
real
system.
It
can
be
a
protocol,
it
can
be
a
it
can
be
like
an
abstract,
Library
name,
I,
don't
know,
but
but
it
all
it's
always
there,
and
if
we
want
to
specify
other
things
then
well
do
we
put
them.
E
I
really
miss
one
part:
I
understand
how
it
can
be
useful
to
know
which,
which
attributes
to
expect
I
can
try.
Okay,
Miss
English,
like
previous
experience,
so
in
my
was
the
like
the
backhands
I
played
with.
They
have
very
little
customization
per
specific
systems.
Right
then,
at
the
best
they
show
some
icon
and
attributes.
It's
just
a
blob
of
things
somewhere
on
the
side.
People
can
look
into,
or
maybe
query
with
right.
E
B
Yes,
so
so
I'm
doing
a
lot
of
work
on
like
a
processing
like
random
spins
that
come
from
a
lot
of
places,
and
sometimes
you
get
like
attributes
like
a
set
of
attributes
and
like
it's.
It's
really
how
to
make
sense
out
of
them
like
I,
want
to
show
them
in
the
UI
I
want
to
I
want
them
to
be
shown
nicely
like
if
something
is
is
like
group
them
in
in
a
way
that
makes
sense
to
users
and
currently
what
I'm
doing
is
I
have
a
lot
of
these.
A
E
B
Let
me
see
we
have
like
a
demo,
but
anyway,
I
can
search
for
it
soon,
but.
E
E
D
I
think
we
I
think
keeping
it
a
little
bit.
Vague
is
probably
the
right
call
at
this
point:
I
just
I'm,
not
sure
exactly
what
we're
suggesting.
Maybe
if
that's
could
have
cleaned
up,
we
could
Circle
back
to
it
next
time
and
just
you
know
see
if
we
agree
with
what
we
ended
up
with,
but
but
yeah
I
agree
with
keeping
it
a
little
open
right
now
and.
D
A
B
I
can
show
you
an
example
what
I
mean
if,
if
you
want
like
you,.
A
B
So
this
is
an
example
of
like
a
very
simple
details:
window
for
a
Karen
Spence,
so
I
press
on
the
span
and
I
have
this
guitar
window
and
if
I
go
to
attributes,
so
what
we
do
we
collapse
them
according
to
like
the
first
text
in
the
attribute
name,
so
it's
easier
for
user
than
to
navigate.
So
you
can
open
messaging
and
see
like
all
the
messaging
attributes,
but
this
is
like
very
general,
no
matter
what
spam
we
get.
B
We
can
show
this
window
because
we
have
like
a
very
strict
rules
on
how
to
build
this
this
categories,
but
we
also
have
this
this
main
window.
This
message
window.
We
chose
like
a
more
in-depth
details
about
about
the
span.
So,
for
example,
here
we
have
the
topic
and
the
action,
but
for
some
messaging
systems
we
have
like
a
lot
of
data.
B
They
produce
a
lot
of
data,
so
they
have
like
a
lot
of
custom
attributes
and
some
other
information
which
we
want
to
show
and
the
the
issue
is
that
if
I
know
nothing
about
these
attributes,
then
all
I
can
do
is
just
enumerate
them
right.
I
can
only
show
okay.
This
attribute
equals
this
this
out
of
it
equals
something
else.
I
I
know
nothing
about
the
content
of
these
attributes
right.
So
what
I'm?
Looking
and
also
this
is
like
a
Kafka
spam,
but
we
do
have
some
cases
where
we
say
like.
B
If
it's
a
rabbit
spend,
then
we
we
don't
show
like
a
general
window.
We
show
like
a
customized
window
for
rabbit
where
we
take
the
data,
like
we
say:
okay,
these
attributes
we're
showing
we
show
them
like
this,
and
these
are
two
to
show
them
some
other
way,
and
then
we
have
this
window
full
of
like
meaningful
data
that
users
like,
and
then
we
have
a
lot
of
code
that
builds
these
custom.
These
custom
components
in
the
UI
and
and
I
don't
like
to
do
this
job
I
want
like
walls.
B
E
Can
I
just
ask
a
few
questions?
I
I
understand
your
imagination,
I'm
just
trying
to
get
different
here.
So
you
say
when
I'm
dealing
with
rabbit,
I
I
know
it's
rabbit.
B
Yeah,
like
currently
I
worked
with
a
lot
of
examples
like
I
do
get.
We
do
get
the
expense
from
things
that
are
not
open.
Telemetry
they're,
like
I,
don't
know
some
other
apms
that
that
can
be
translated
to
open
telemetry
and
then
like
the
attributes.
They
don't
even
start
with
messaging
dot.
Something
they're
just
like
texts
that
that
we
have
to
map
by
hand,
but
even
for
open
Telemetry.
What
I
seen
is
that
the
instrumentations
they
don't
like
they
just
come
up
with
the
things
that
they
need
right.
B
But
you
don't
know
how
to
call
this
attribute
right
because
there's
no
guidelines,
so
people
come
up
with
like
names
and
and
those
like
a
zoo
of
names,
so
many
variants
and
and
then
we
get
this
data
and
we
want
to
show
it
in
the
UI,
because
it's
important
and
people
need
it
and
love
it
and
use
it.
But
we
have
no
rules
how
to
to
understand
what
it
means.
So
what
I'm
looking
for
is
like.
Oh
it's
like.
B
If,
if
this
data
is,
is
relevant
to
the
specific
system,
then
then
feel
free
to
to
come
up
with
whatever
attribute
name
you
want,
but
at
least
have
started
with
a
messaging
Dot,
mqp,
and
then
I
can
write
some
automated
process
to
to
take
some
random
attribute
to
know
things
about
it,
that
even
if
it's
not
in
the
specification
I
can
at
least
like
get
Clues
what
it
means
like.
Where
does
it
go
like
things
like
that.
E
B
You,
yes,
so
so,
for
example,
this
message
window
like
the
best
I
can
do
now
without
any
knowledge.
Is
that
just
to
enumerate
all
the
attributes
that
starts
with
messaging
dot?
Something
right,
but
if
I
know
that,
like
no
matter
what
span
it
is,
I
can
look
for
messaging,
Dot
and
then
the
system
name.
Then
I
have
some
useful
information
which
I
can
use
to
to
structure
this
window
in
a
more
useful
way.
B
Right
and
I
can
show
you
another
example.
Here
we
have
like
filters
right,
so
we
have
many
filters
so
and,
and
we
create
them
like
we
try
to
to
give
the
meaningful
values
here.
So
so
it's
currently
very
hard
because
all
we
know
that
that
we
can
use
this
like
messaging
dot
system
right.
A
B
E
Okay,
okay,
so
then
let
me
ask
you
this
question
assuming
to
have
an
attribute,
so
basically
what
you're
seeing
record
so
for
the
last
piece
and
the
namespace
right,
the
this
name
space
and
the
segments
of
it
could
describe
you.
You
want
to
put
a
world
in
which
this
namespace
describes
you
what
it
this
attribute
refers
to
right.
E
B
E
Is
yeah
that
the
question
is
what
how
much
structure
you
need?
Assuming
we
have
a
system
and
we
have
all
attributes
and
the
span
like
messaging
dot,
Kafka
and
messaging.gms
on
the
same
span
system
matches
Kafka.
B
Yeah,
so
if
the
system,
a
message,
Kafka,
then
I
know
automatically
to
look
for
a
messaging.kafka.style
and
I
know
what
they
mean,
but
if
I
have
messaging
dot,
JMS
and
I,
don't
know
what
this
JMS
means.
Then
then
I,
don't
really
like
I
can
know
that
this
is
a
group
of
attributes
that
are
somehow
related
because
they're
in
the
same
namespace
but
I,
don't
know
what
his
name
space
is
right
because
JMS
is
is
like
today's
jml
tomorrow
I
get
to
spend
the
sales
instead
of
JMS.
It
says
something
else:
I
can't
understand.
A
E
Then
the
goal
here
is
that
you
want
like
assuming
the
the
stupid
case
right,
we
add
GMS
and
you
Amir
and
all
the
back
end
developers
in
the
world
would
go
and
see.
Okay,
they
had
the
GMS
extension.
Let
me
go
and
implement
it,
and
now
I
can
have
I
know
what
GMS
is
right,
and
this
involves
some
work,
and
this
is
what
you're
trying
to
avoid
right.
B
Yeah
yeah,
and
currently
we
have.
We
have
like
a
these
if
statements
that
says
for
this
to
this
and
for
if
this
text
is
here,
then
do
some
other
thing
and
for
because
we
don't
have
this
knowledge
yeah.
B
E
B
E
Yeah
I
see
it's
just
what
the
Earth's
saying
is,
basically
that
there
is
enough
structure
in
the
name
space
that
you
can
yeah
so
that
you
can
do
something
Advanced
on
top
of
it.
Let
me
play
a
devil
advocate
for
one
more.
Second,
assuming
you
split
the
namespace
into
segments
right
and
then
now
it
starts
with
messaging,
and
then
you
have
a
number
of
segments,
and
then
you
have
the
attribute
name.
So
the
first
one
tells
you
it's
messaging.
E
B
Yes,
so
it
could
like
I,
could
do
all
sorts
of
heuristics
to
try
to
understand
things
automatically,
but
I
think
it
would
be
amazing
not
only
for
me
for
everyone
if
respect
stated
in
a
way
that
the
instrumentation
implementers,
if
they
want
to
add
something,
then
they
get
like
rules
on
how
to
to
to
namespace
it.
B
Yeah
like
like,
if
you
now
want
to
to
implement
an
instrumentation
for
something
new
and
you
you
see
this
piece
of
data
and
you
know
that
it's
useful,
but
you
go
to
the
specification
and
it
doesn't
tell
you
like
what
the
attribute
name
should
be
right.
So
you
you
come
up
with
something
you
one
person
might
put
it
in
messaging
Dot
and
then
like
a
phone
and
someone
else
might
use
a
messaging
dot
a
rabbit.fu
and
someone
else
might
use
it
in
messaging,
Dot
message:
dot,
full
I,
don't
know
like
people.
E
B
D
Like
I
think,
if
I'm
understanding
you
know
what
you're
saying
in
here
like
things
like
messaging
dot,
source
and
messaging
dot
destination,
are
kind
of
those
concepts
are
good
for
what
you
need,
because
they're
part
of
the
core
spec.
You
know
that
their
namespace,
you
know
it
can
be
in
it
and
that's
good.
The
it's
the
more
sort
of
optional
ones
like
amqp,
Kafka
JMS,
where
it'd
be
nice
to
have
something
in
the
stack
that
sort
of
tells
you
what
function
JMS
serves
or
what
you
know
like.
D
If
you
said,
if,
for
example,
we
decided
to
have
messaging
dot
system
equals
ampp
and
messaging
dot,
I,
don't
know
you
know
abstraction
equals
JMS
and
we
had
those
two
attributes,
and
then
that
told
you
that
okay,
there
could
be
JMS
and
amqp
namespaces
in
this
message
and
that
that
means
they're
the
messaging
system,
and
that
means
they're.
The
messaging
abstraction,
like
that.
That's
kind
of
the
best
outcome
from
your
point.
B
D
E
But
I
wonder
imagine
so
we
have
a
span
with
Kafka
attributes
and
attend
GMS
attributes
in
it.
Would
it
help
you
if
there
is
an
extra
attribute
that
tells
okay?
You
should
expect
both
Kafka
and
GMS
like
the
right
handful
attributes
in
it
anyway,
and
you
can
just
go
by.
B
So
how
do
I
know
currently
to
vital
Kafka,
because
I
looking
the
messaging
system
and
I
see
the
text
Kafka
and
then
I
know
to
put
it
in
in
this
graph
right.
So
I
want
like
if
we're
saying
that
we
want
to
add
the
JMS,
namespace
and
I
need
to
know
like
if
it's
if
it
means
something
meaningful
or
is
it
just
like
a
text
that
the
user
added
and
it
doesn't
tell
me
anything.
E
Yeah,
so
imagine
you're,
you
have
a
list
of
attributes
for
this
fan
right,
it's
a
very
small
waist
and
then
you
Group
by
the
first
two
segments
messaging
dot
block
right
and
as
an
outcome.
You
get
messaging
that
message.
You
know
it's
generic,
you
get
messaging
the
destination,
it's
generic
messaging.source,
it's
generic!
You
get
also
the
messaging.kafka
and
messaging.jms
yeah.
E
B
E
They
don't
like
you,
you
should
trust
your
users
to
populate
it
right
and
nothing
will
protect
you
from
users
putting
random
stuff
into
spans,
but
you
know
to
show
cough
cards.
There's
GMS,
slash
two,
because
user
gave
you
the
three
namespaces.
D
Yeah
but
I
do
think,
though,
that
one
of
the
in
this
messaging
spec
itself
I'm
assuming
we
don't
want
to
go
down
the
path
specifying
all
of
the
JMS
specific
attributes
all
of
the
Kafka
specifications.
We
don't
even
want
to
say
that
these
things
exist
just
that,
because
I
think
we
want
those
things
managed
by
their
own
separate
specifications
and
so
I
think
what
we
want
in
this
spec
is
to
say:
messaging.system
equals
blah,
and
that
implies.
D
B
Exactly
and
I
just
want
to
add
I'm
doing
a
lot
of
reviews
for
the
contrib
people
in
an
old
and
people.
They
add
custom
attributes
and
we
can't
stop
them
like
we
can
tell
them.
We
can't
edit,
because
because
it's
not
in
a
spec,
because
it
doesn't
make
sense
people
they
do
it
all
the
time
right
and,
and
they
just
come
up
with
an
attribute
and
there's
nothing
I
can
do
about
it.
I
can
like
okay.
B
This
is
that
what
you
want
go
for
it,
but
if
there's
rules
in
the
specification
that
says
if
these
attributes
relates
to
Kafka,
this
is
the
namespace
where
it
should
go
and
if
it
relates
to
something
else.
This
is
how
you
build
your
custom,
attribute
name
in
a
way
that
is
structured
for
for
the
backends
to
consume.
Then
then
I
can
in
the
review.
I
can
tell
them
okay,
you
added
this
attribute
name,
but
it
doesn't
comply
to
the
spec.
I
know
it's
not.
B
D
I
just
think
if
we
want
to
allow
multiple
namespaces
one
for
the
system
and
maybe
and
I
use
the
term
adaptation,
I'm
sort
of
making
it
up
like
or
abstraction
right
JMS
is
an
abstraction
for
some
underlying
messaging
system.
If
we
had
messaging
dot,
abstraction
and
messaging.system
I
think
that
gives
Amir
what
he's
looking
for
the
tricky
part
with
that
is
well
I,
don't
know
if
there's
a
problem
or
not.
If
we
just
say
we
insist
that
you
include
one
of
these
two
things
like
the
one
of
these.
Two
things
is
required.
D
A
Has
a
problem
of
its
own,
but
it's
a
it's
a
good
idea.
D
D
A
E
Yeah
sure
it's
just
my
only
worry
about
it
that
we
are
recorded
and
we
will
be
on
YouTube,
I.
Think.
B
B
My
question
is
about
a
database
as
amount
of
conventions.
Wait
a
minute
or
show
my
screen
again.
A
A
B
C
B
E
E
Yeah,
so
here
there
should
be
a
computer
name.
There
is
a
a
section
below
maybe
the
note
or
maybe
the
whole
section
yeah
so
go
scroll
down.
There
is
a
net
net
peer
attribute
somewhere.
It's
the
heading.
B
E
A
B
Source
name
of
the
remote
service
right,
so
I
can't
populate
it
with
the
IP
other
site.
Yeah.
E
So
there
is
a
link
here.
Sometimes
hostname
is
only
available
to
instrumentation
as
a
string
which
may
contain
DNS
name
or
IP
address,
and
that
grenade
should
be
set
to
the
available
known
post
name
right.
So
basically,
if
you
don't
know,
then
use
it
like.
If
you
don't
know
what
it
is,
use
that
pure
name,
it's
like
the
best
known
remote
destination,
without
specifying
it
further
so.
B
E
So
if
you
user
gave
you
an
IP
address,
I,
don't
know
a
type
right.
You
know
the
type
of
this
thing
is
AP
address
or
yes,
you
got
it
from
the
socket
level,
then
put
it
on
the
sock
address.
If
you
don't
know
what
it
is
put
it
on
that
premium,
if
you
know
it's
a
logical
name
put
it
on
that.
For
me.
B
Okay,
okay,
cool
thanks!
You
want
this
right,
yep,
I'm,
cool,
amazing!
That's
what
I
needed!
Thank
you.
Yeah.