►
From YouTube: 2022-04-14 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Good
morning
good
evening,
let's
give
it
maybe
two
more
minutes
and
then
let's
get
started.
B
B
Project
board,
so
what
I
did
here,
I
I
changed
the
settlement
text
that
he
that
we,
according
to
we
discussed
last
times
this
time,
basically
by
extending
it
by
bands.
So
we
can
okay,
saying
that
settlement
can
be
signaled
either
by
spans
or
by
by
events,
and
also
that
it
may
link
to
the
create
spam
for
the
message,
if
that's
possible,
to
create
the
link
and
settle
spence
may
create
a
link
to
the
create
spam.
B
That's
basically
the
summary
there's
more
explanation
up
here.
So
please
have
a
look
at
that.
Maybe
add
comments
to
the
pr
or
just
right
here
in
the
meeting.
If
there's
anything,
you
think
think
that's
missing
here
or
that
doesn't
make
sense
to
you.
A
I'll
do
I'll
do
a
pass
through
on
it
this
week.
B
Awesome
thanks.
One
open
point
we
have
here
still
is
this
process
spam
conventions.
B
I
would
actually
maybe
postpone
or
merge
this
with
the
discussions
that
we
have
with
bogdan,
because
that
somehow
ties
in
with
what
we're
discussing
anyway
with
bogdan
so
with
processbands.
I
think
we
were
agreeing
that
we
make
them
some
somewhat
optional.
B
We
can
require
them
and
it's
still
like,
at
least
for
me,
like
an
open
questions,
a
question,
how
we
are
gonna
kind
of
formulate
or
put
that
in
the
in
in
our
tab,
and
it
is
back
later
on,
but
I
I
thought
it
might
be
beneficial
to
maybe
include
that
in
discussions,
discussions
with
bok
dum
or
discuss
that
after
he
came
to
some
kind
of
agreement
and
conclusion
with
with
bogdan
and
instead
I
will
propose
that
maybe
here
in
progress,
I
put
this
general
attributes
here
that
maybe
we
start
looking
into
that
like
span
naming
and
and
attributes,
because
the
other
things
that
we
see
here
in
progress
basically
settlement-
I
put
it
to
done
so
that
is
if
there
is
any
open
questions
we
can
put
it
back,
but
I
put
it
down
for
now
and
the
things
here,
the
first
one.
B
A
Okay,
I
was
thinking
sorry,
I
was
thinking
if
we,
if
we
have
like
a
clear
way
of
of
or
like
if
we
have,
let's
say
a
story
or
something
that
we
can
use
to
tell
to
to
to
to
explain
to
bogdan,
because
I
feel
that
sometimes
in
the
in
the
last
time
where
we
tried
to
explain
to
him
was,
it
was
like
too
many
details,
and
maybe
we
were
like
going
going
like.
A
Maybe
we
were
saying
the
same
things,
but
I
I
thought
that
both
sides
were
trying
to
try
to
say
the
same
thing,
but
none
of
us
got
got
any
conclusion
or
or
we're
just
I
don't
know
like.
Maybe
maybe
we
can
just
try
to
to
formulate
our
our
scenarios
in
a
way
that
that
is
clear,
because
probably
we'll
have
to
present
this
at
the
dc
meeting
or
something
right
at
some
point,
or
I
don't
know
if,
if
if
we
will
but.
B
Yeah,
I
mean
my
my
hope
is
actually
that,
when
bogdan
kind
of
done
kind
of
understands
what
we're
doing
here
with
us,
that
is,
okay,
that
we
are
fine
on
the
tc
side,
because
we
bought.
A
B
So
if
he
basically
says
okay
explained
it
to
me
understands
it
makes
sense,
I
think
it
would
basically
spare
us
or
it
would
make
it
unnecessary
for
us
to
kind
of
present
it
again.
B
But
the
point
you
make
is
a
good
one
and
I
I
think
it's
just
a
a
challenge,
because
I
mean
we
discussed
about
this
now
for
almost
half
a
year
and
it's
a
challenge
kind
of
to
summarize
and.
A
B
It
to
to
somebody
else-
and
I
I
also
thought
about
how
to
best
explain
this
to
bogdan
and
to
think
maybe
what
we
make
clear
to
him.
What
you
should
make
clear
to
him
today
is
that
we
have
these
two
main
scenarios
that
we
talked
about
in
the
very
beginning.
This
one
scenario
where
you
want
to
see
everything
in
your
traces,
including
the
meteor
instrumentation.
B
B
I
think
we
didn't
manage
to
make
that
hundred
percent
clear
to
him
last
time,
because
we
were
talking
about
this
north
star
kind
of
for
this
goal,
idea
that
we
have
everything,
instrumented
and
kind
of
we
see
the
complete
traces
flowing
through,
but
actually
I
think
for
many
cases.
This
is
not
desired
like
for
many
cases.
B
This
detailed
intermediary
insight
and
I
think,
if
we
manage
to
make
that
clear
to
him,
maybe
some
of
our
scenarios
make
more
sense
and.
A
I
think
like
if,
if
the,
if
the
intermediary
is
instrumented,
it's
for
example,
has
has
auto
instrumentation
in
it
and
like
if
we
manage
to
get
our
let's
say,
producing
consumer,
as
as
we
want
to
do
like
this
layer,
and
if
we
manage
to
do
that
and
then
later
on.
If
the
the
the
intermediary
is
is
also
instrumented,
then
we'll
have
what
blog
done
wanted
like
the
whole
picture.
A
But
if
the
intermediary
is
not
instrumented
for
some
reason,
because
there's
no
instrumentation
for
it
or
because
the
user
didn't
use
or
it's
out
of
control
whatever
and
then
and
then
you
will
not
have
it,
and
I
I
would
imagine
that
this
is.
This-
would
be
common
because
sometimes
intermediary
some
other
party,
that
I
don't
know
that
I
don't
have
control
or
something
like
that.
C
B
So
I
think
the
challenge
here
is
that
for
producer
and
consumer
we
need
a
stable
way
to
kind
of
compare
those
traces
with
or
without
intermediary,
so
whether
indometer
is
instrumented
or
not.
I
think
we
cannot
say.
Okay.
Our
future
goal
is
that
everything
is
instrumented,
including
the
intermediary.
B
I
think
that
is
not.
That
does
not
cover
all
our
customer
use
cases,
and
I
think,
maybe
if
we
managed
to
explain
that
to
bogdan
and
make
him
understand
that
some
of
our
kind
of
choices
yeah
more
clear
to
him.
A
Yes,
maybe
that
maybe
showing
the
do
we
have
that
those
exams
that
we
looked
at
at
some
point.
I
guess
not
right.
It
was
long
time
ago.
B
Yeah
I
I
didn't-
I
didn't
have
time
to
spin
that
up
again
if
needed.
Actually
I
plan
to
do
it
for
today,
but
if
it's
still
needed
for
next
week,
but
we
can
do
that
next
week.
B
Okay,
so
but
yeah
I
just
quickly
wanted
to
then
get
started
about
the
attributes
and
the
span
names
just
to
get
your
perspective
and
your
opinions
on
that
I
mean
here
we
already
have
have
things
in
the
existing
semantic
conventions.
So
maybe,
let's,
let's
start
looking.
Let's
start
looking
over
that
and
let's
see.
B
Whether
what
is
there
makes
sense
for
us
or
whether
there's
anything
that
that
will
not
change.
I
thought
we
start
with
like
the
span
name
and
here
basically
what
the
current
spec
asks.
It
asks
the
span
name
to
consist
of
two
parts.
B
The
first
part
is
a
destination
name,
and
the
second
part
is
an
operation
name
so
operation
name,
I
think
that's
the
easier
one
to
start
with,
because
there
is
a
there's,
a
list
of
operation
names
here
that
will
that
list
will
be
according
to
what
we
came
up
in
our
existing
in
discussion.
Up
to
now
extend
it
basically,
instead
of
send,
we
would
have
publish
and
create.
B
Basically,
this
this
step
would
be
a
split
up
because
we
have
published
spans
and
we
have
create
spans
on
the
receive
side.
Basically,
that
would
also
be
split
up.
We
would
have
receive
and
deliver.
We
have
a
different
operation
here
for
push
and
pull
scenarios
and
for
processing.
That's
still
yeah
the
one
open
question:
whether
we
are
gonna
mandate
or
recommend
any
processing
spends
and
then,
in
addition,
we
will
also
have
a
settle
operation.
B
B
So
that
basically
operation
will
be
part
of
the
span
name,
which
somehow
completely
makes
sense
and
is
almost
self-evident
to
me
that
this
just
this
operation
needs
to
bring
the
span
name
for
the.
B
B
Yeah
what
it
says
here,
it's
a
destination
is
usually
identified
by
some
name
unique
within
the
messaging
system
instance.
So
usually
it's
like
the
name
of
a
topic
or
the
name
of
a
queue.
I
mean
that
is
trim
as
terminology
and
the
idea
is,
you
have
to
put
the
topic
or
q
name
there
as
the
as
the
as
the
destination.
B
B
D
That
the
topic
when
you
consume
it
usually,
you
can
sometimes
know
the
pattern
like
the
local
denali
butter
that
match
the
topic,
but
for
a
publisher
there
is
no
way
to
do
it.
So
if
you're
publishing
into
a
topic
that
contain
ideas
or
some
other
high
cardinality
namespace,
then
we
will
run
into
problem.
B
B
A
B
It
says,
use
an
artificial
destination
that
best
expresses
the
an
artificial
destination
name
that
best
expresses
the
destination.
So
that's
so
that's
a
that
can
be
anything
I
guess,
but
it
it
just
seems
like
somehow
some
best
effort
here
that
you
say:
okay
use
this
destination,
it's
kind
of
messaging
system
specific.
B
So
there's
always
a
already
question
mark
here
and
if
it's,
if
the
cardinality
is
too
like
a
high,
then
use
whatever
kind
of
basically
standing
can
stand
in
for
this
destination
name.
A
A
We
cannot
force
anything.
I
guess
anyway,.
C
Like
when
I
originally
read
this
spec,
I
had
trouble
understanding
what
the
cardinality
problem
is
and
and
when
what's
considered
high
cardinality
and
low
cardinality.
I
think
the
name
guidelines
there
that
link
mentions
that
generally,
if
it's
something
that's
configured
that
usually
implies
that
it's
low
cardinality,
our
our
broker,
you
can
configure
200
000
cues
per
broker
and
if
you
had
a
network
of
them,
you
know
if,
let's
say
five
brokers,
that
could
be
like
a
million
different
cues
is
a
million
low
cardinality
or
is
that
high
cardinality?
You
know.
B
B
It
more
refers
to
like
capability
of
kind
of
the
visualization
and
the
analysis
analysis
of
the
trace
data,
because
what
you
can,
for
example,
do
you
could
I
mean
that
is
true
for
metrics
for
sure,
but
also
for
spans
to
a
certain
extent,
you
could
basically
look
at
all
your
spans
and
then
analyze
your
how
how
many
basically
messages
or
how
many
spans
do.
B
I
have
to
send
messages
to
this
kind
of
a
topic
and
if
you
have
derived,
if
you
put
this
into
a
let's,
say
a
bar
chart-
and
you
have
200
000
topics
there,
then
this
will
not
really.
This
will
not
really
help
anybody
much.
So
I
think
the
the
cardinality
here
is.
B
The
idea
here
is
that
you
can
do
some
kind
of
analysis
or
kind
of
aggregate
those
bands
based
on
topics
on
aggregate
the
spans
based
on
the
span
name,
while
still
keeping
like
this
making
it
possible
that
when
you
look
at
the
data,
you
can
kind
of
make
sense
of
it.
So
it's
it's
hard
to
give
like
a
hard
limit
here.
C
Yeah,
I
just
wonder:
if
is
it
possible,
to
give
a
little
more
guidance
to
someone
reading
this
to
help
them
decide
whether
they
should
use
an
actual
destination
name
or
a
stand-in,
because
it
confused
me
like
just
not
having
much
of
a
tracing
background
and
understanding.
C
B
We,
we
definitely
can
add
some
clarifying
words
there,
because
yeah,
if
it
confuses
you,
it
very
likely
confuses
many
others
even
more,
so
I
think
we
definitely.
I
mean
there
is
there's
a
link
to
this
spam
guidelines.
I'm
actually
not
sure
if
there
is
much
more.
B
B
A
A
Yeah
or
maybe
some
examples
in
different
messaging
systems,
what
what
they
want
or
like
what
the
person
could
use,
because
I
assume
that
in
different
messaging
systems,
there
are
different
terms
for
for
like
destinations
or
topics
or
queue,
or
something
like
that.
B
A
The
the
way
that
I
that
was
easiest
to
understand
or
to
reason
when,
when
producing
spin
end
was,
was
to
use
the
like
a
request.
Example
like
this,
like
if
I
want
to
derive,
for
example,
a
matrix
from
it
after
like
what
is
like
how
many
requests
I'm
getting
for
this
endpoint
or
for
this
for
this
yeah.
For
for
this
endpoint,
and
if
I
have
first
strings
all
over
in
my
spin
name,
then
I
cannot
aggregate.
I
cannot.
A
You
cannot
group
them
together
in
any
way,
and
I
guess
for
the
message
is
the
same
like
if
there
is
an
id
every
time
or
if
there
is
like
200,
000
ids
or
something
or
I
don't
know,
even
even
200
ids.
I
would-
or
I
don't
know
like
something
like
this.
It's
already
a
lot
so.
C
A
B
I
mean,
I
think,
to
maybe
attempt
that
answer
to
a
trans
question,
and
here
we
have
destination
also
as
an
attribute,
and
it
says
that
this
might
be
equal
to
span
name
but
is
required
nevertheless,
so
I
think
this
means,
I
think
this
is
an
attribute-
do
already
hints
that
it
can
be
different,
otherwise
it
wouldn't
make
sense
to
add
it
as
an
attribute.
So
I
I
would
assume
that
the
there
is
some
kind
of
here
at
the
massive
destination.
B
C
Yeah-
and
I
guess
I
just
don't-
have
a
good
sense
of
why,
what's
the
benefit
of
putting
anything
in
the
span,
name
at
all,
how
how
is
a
span
name,
a
special
thing
to
these
systems?
That's
because
when
I
talk
about
with
other
people
who
who
spent
less
time
than
I
have
looking
at
this
stuff,
you
know
they
kind
of
say
like
well.
When
I
look
at
this
thing,
I
want
the
span
name
to
look
like
something
helpful
as
a
human
right.
Why
would
I
just
put
q
in
in
the
spending?
C
Why
would
I
put
the
actual
cue
name?
And
I
don't
I
don't
have
the
answers,
but
this
is
the
kind
of
thing
like
we've
had
in
discussions.
We've
had
in
internally
the
kind
of
thing
that
comes
up
over
and
over
again-
and
we
have
a
hard
time
coming
to
a
decision.
Is
people
want
the
spam
names
to
look
human
readable
because
they're
fairly,
you
know
prominent
in
the
display
and
at
the
same
time
there's
this
kind
of
competing
thing.
They
should
be
low
cardinality
and
I
don't
know
whether
readability
or
cardinality
should
win.
C
D
Then
you
can
select
a
you,
have
a
filter
on
the
left.
You
have
a
filter
for
service
and
then
a
filter
for
operation,
the
span
names,
they
fill
up
this
filter
and
then
you
have
a
drop
down
and
you
can.
If
you
have
then
10
distinct
operations,
then
you
can
just
say
show
me
places
with
this
operation
and
it's
very
friendly,
but
sometimes
you
open
it
and
there
are
like
hundreds
of
records
and
there's
no
way
to
navigate
it.
So
I
always
think
of
it.
B
I
mean
that's
a
that's
an
interesting,
that's
a
good
way
to
look
at
it
actually
does
it
the
question:
does
it
fit
in
the
drop
down
box.
C
C
Like
it's,
it
is
a
helpful
way
to
describe
it,
putting
something
like
that
in
a
specification
is
a
little
you
know
perhaps
too
tailored
to
an
implementation
or
something
like
that,
but
yeah
it's
hard
it's
hard
to
get
too
specific
in
a
specification.
I
know,
but
it's
just
at
the
same
time,
for
someone
trying
to
implement
against
it
it's
hard
to
make
the
right
decision.
If
you
don't
understand
why
a
statement
is
being
made.
B
I
think
one
needs
needs
to
leave
like
the
implementers
a
bit
of
kind
of
freedom
there
to
choose
for
their
for
their
particular
case.
B
What
makes
sense
that
is
hard
on
the
one
hand,
because
then
those
people
come
here,
look
at
us
back
and
say
I
don't
really
know
what
to
do,
but
on
the
other
hand,
I
think
we
shouldn't
limit
people
too
much,
especially
here,
because
this
destination
name
is
not
well
defined,
so
that
can
be
something
very
different
for
different
messaging
systems
and
what
what
makes
sense
for
one
kind
of
destination
name
probably
does
not
make
sense
for
another
kind
of
of
destination
name.
B
C
What
I've
seen
in
other
specifications
that
can
be
pretty
helpful
is,
if
you
have
specific
sort
of
non-normative
text
sections
right.
Just
saying
this
is
non-normative,
but
it
just
provides
some
background
on
you
know,
and
you
said,
if
you
call
it
out
as
non-normative,
it's
clear
that
you're
not
specifying
anything,
but
if
you're
trying
to
provide
some
background
explanation
on
on
something
that's
mentioned
in
respect,
maybe
that
something
like
that
would
work
here.
B
Yes,
definitely,
that's
definitely
something
I
tend
to
do
because
here
it's
it's
completely
unclear
to
me
in
this
version
of,
what's
normally,
what's
innovative,
it's
kind
of
all
mixed
together
and
in
the
in
in
the
old
type.
I
actually
tried
to
set
this
apart
like
here.
That's
that's
the
normative,
that's
that's
the
normative
wording,
and
that
is
all
basically
explanatory,
and
that
goes
throughout.
B
So
actually
the
normal
distractions
are
pretty
pretty
short,
but
there's
lots
of
explanation
around
it
and
I
actually
think
it
makes
sense
to
have
something
similar
in
the
actress
back,
because
now
it's
pretty
unclear
what
this,
what
what
is
normative
texture
about
this
explanation
I
mean
you
can
look
for
those
uppercase
shortened
mason
masts,
but
it's
pretty
hard
to
figure
out.
D
I
want
to
discuss
what
we
mentioned
there
before
about
the
cardinality
of
destination
yeah
like
currently
in
aspecto,
we're
experimenting
with
like
processing
the
spans
and
extracting
some
uniqueness
out
of
them
and,
for
example,
in
http
we
have
the
http
route,
which
is
by
spec.
It
should
be
low,
cardinality
attribute,
and
then
it
opens
a
lot
of
opportunities
in
the
back
end
to
kind
of
like
aggregate
based
on
this
data
calculate
some
uniqueness
for
spam
and
messaging.
D
I
was
really
missing
something
similar,
something
that
I
can
hold
on
to
and
know
that
it
has
low
cardinality
similar
to
what
we
do
with
the
span
name.
But
spanning
is
not
good
for
processing,
because
it's
too
er
to
it's
not
structured,
very
well,
it
can
people
can
place
their
some
other
texts
which
are
not
general
enough,
and
I
think
that
we
can
really
benefit
from
having
like
another
attribute
to
describe
the
destination
which
is
guaranteed
to
be
local.
D
Yeah,
like
like
http
route
and
http
path,
so
we
can
have
like
a
similar
for
messaging.
B
B
I
mean
it's
interesting:
we
have
the
we
have
the
messaging
operation
as
an
attribute
that
is
supposed
to
be
in
the
in
the
span
name.
Two.
The
operation
is
also
supposed
to
be
in
the
span
name.
So
yeah,
it's
a
good
question.
I
should
not
also
the
destination
name
here.
The
locationality
destination
name
also
be
be
set
as
an
attribute.
D
B
Yes,
I
mean,
I
think
that
actually
might
make
things
a
bit
clearer,
because
then
we
have
operation
name
described
as
an
attribute
and
we
have
the
low
cardinality
destination
name
described
as
an
attribute
and
they
can
put
or
basically
the
details
there
of
what
is
required
for
that
and
then
for
the
span
name.
We
just
can
say,
combine
those
two
attribute
values,
and
that
gives
you
that
gives
you
the
span
name.
B
B
I
mean
I
have
a
question
also
regarding
the
temporary
temporary
destinations
here.
It
says
that
there's
something
like
temporary,
skew
cues
that
are
just
established
for
a
particular
set
of
communication
partners,
like
of
one
to
one
conversations
I
just
was
wondering
the
is
that
the
thing
that
happens
very
rarely
is
this
something
that
happens
often.
C
That
at
all,
it's
quite
common
in
in
our
messaging
systems,
like
if
you're
doing
a
request
reply,
you
might
create
a
temporary
destination
and
send
a
request
with
your
temporary
destination.
As
the
reply,
I
feel
that
temporary
is
a
bad
term
to
use
because
we
like-
and
I
don't
think
we're
alone
here,
but
we
have
the
concept
of
sort
of
a
well-known
temporary.
So,
like
it's
durability,
we
refer
to
these
things
as
sort
of
anonymous,
endpoints
or
anonymous.
C
Destinations
and
durability
is
like
a
separate
concept
from
anonymous
or
well-known
and
using
temporary,
and
they
say
there
that
I
think
the
motivation
is
that
often
where
you
just
had
it
on
screen
there.
Yeah
often
such
destinations
are
unnamed,
have
an
auto-generated
name,
but
that
combining
that
with
the
constant
temporaries,
is
not
quite
correct.
In
my
opinion,.
B
Okay,
that
makes
sense,
but
for
for
for
those
scenarios
doing
whatever,
if
we
call
like
this
temporary,
let's
call
it
anonymous
anonymous
when
you
see
like
a
span
name
anonymous
scent,
is
that
kind
of.
Is
that
a
satisfying
solution
for
for
those
scenarios.
C
Or
do
I
think
that
leaves
I
mean
how
satisfying
it
is?
I'm
not
sure
I
find
all
of
these
stand
in
things
to
achieve
low,
cardinality
unsatisfying
to
some
degree,
but
I
understand
that
it's
a
some
a
problem
right
to
to
always
put
an
actual
identifier
there,
but
I
I
can't
think
of
anything
better
I
mean.
Maybe
you
want
to
combine
the
concept
of
anonymous
with
a
cue
or
anonymous
topic
right.
Maybe
if
you
care
about
topic
versus
q
in
a
spam
name,
you
might
want
to
know
it
anonymous.
C
What
here,
I'm
not
sure?
Yes,
but
if
you're
just
saying
if
you
already
are
forced
to
substitute
q
or
topic
here
in
parentheses,
as
opposed
to
the
actual
q
name
or
the
topic,
do
you
really
want
to?
Is
it
really
important
to
say
this
is
anonymous
versus
something
that's
configured
but
high
cardinality?
A
Like
what
what
would
you
like
to
see
in
the
screen
names
like
if
we,
if
we
don't,
have
the
constraint
of
cardinality,
what
what
would
you
do?
You
think
would
be
a
like
a
good
thing
or
a
valuable
thing
to
have
in
the
same
name.
C
Well,
I
mean
part
of
it.
Is
I
just
don't.
I
haven't
used
these
systems
enough
to
know
how
the
spam
name
is
a
special
magic
thing.
You
guys
described
it
a
little
bit
for
me,
but
you
know,
what's
most
natural
is
to
just
put
the
actual
name
of
the
thing
right,
the
actual
topic,
the
actual
cue
name,
but
if,
but
if
that's
used
to
populate
some
drop
down,
as
you
suggested,
it's
ridiculous
right
to
put
so.
A
A
I
I
think
that
still
should
still
be
okay,
because,
like
the,
for
example,
if
you,
if
on
a
uber
for
example,
that
you
have
like-
I
don't
know,
several
thousands
of
of
micro
services
and
and
probably
like
silos
of
microservices
having
their
own
queues
and
so
on-
and
you
could
have-
I
don't
know
like
300
of
them.
But
I
wouldn't
count
that
that
as
high
cardinal,
because
it's
still
still
like
a
topic
name
or
a
q
name,
it's
still
valid.
A
You
still
have
a
lot,
but
just
because
your
scale
is
massive,
but
but
I
think,
like
the
hardcore
denied
thing
would
be
like
putting
an
id.
For
example
like
this
is
like
immediately
like
a
no-no.
I
would
say,
because
I
mean
it's
not
user-friendly
and
unless
you
really
know
what
the
uid
means
or
something
yeah.
B
It's
definitely
fine
to
have
this
in
the
span
name,
but
if
there
is
some
kind
of
automated
process
that
creates
that
creates
like
a
a
queue
name
that
just
like
has
some
random
guit
in
the
end.
Exactly
basically,
when
I
look
at
the
span
name,
it
doesn't
really
help
me
to
see
the
one
guide
or
the
other
guide.
It
doesn't
give
me
that
much
information.
B
On
first
sight
I
mean-
maybe
maybe,
if
I
go
into
like
some
deeper
details
or
I
I
dig
into
some
into
the
don't
know,
q
itself,
then
this
helps
me,
but
just
as
a
first
sight
to
kind
of
identify.
Okay.
What
is
this
about?
What
is
this
ban
about?
This
random
guide
in
the
end
does
not
really
help
me
much.
C
Yeah-
and
I
guess
it's
just-
I
definitely
get
that
and
I
think
the
thing
I
guess
the
question
is:
should
it
say
just
if
it's
a
if
it's
like
a
cue
with
a
random
good
in
it,
should
it
just
say
q
or
should
it
say
anonymous
or
should
it
say,
anonymous
q?
C
I
have
a
hard
time
deciding
what's
right
because
I
don't
know
what's
more
useful,
yes,
and
in
the
case
of
queues
like
where
you
have
tens
of
thousands
of
queues
and
they're
all
names
chosen
by
an
application
for
their
use
case
where
it's
there
is
no
id
and
it's
just
a
statically
configured
thing,
but
you
have
tens
of
thousands
of
them
in
a
system
that
that's
sort
of
where
we're
at
right.
That's
typical
for
us
and
deciding
whether
this
falls
under
high
cardinality
or
low
cardinality
is
is
true.
I
mean.
A
Like
in
this
case,
I
wouldn't
say
I
mean
I
I
I
like
without
looking,
but
in
this
case
for
me,
I
I
wouldn't
consider
that,
as
as
high
cardinality,
because,
as
I
said,
it's
a
static,
you
typed
it.
It
makes
sense
to
you
and
in
in
your
domain,
so
I
that
one,
I
don't
think
it's
it.
I
would
consider
it
as
hard.
It
would
be
something
like
this
shop
order,
for
example,
it's
I
mean
you
have
a
lot
of
them
because
you
ended
up
having
a
lot
of
them,
but
but
they
they
are
the
queue.
A
So
it's
not
some
dynamic
thing
so,
but
to
me
that
would
be
like
if
I
look
at
the
trace
of
everything
that
is
done,
for
example,
in
this,
in
this
queue
or
or
in
this,
let's
say
area
of
my
system,
then
having
the
shop
order,
for
example
like
this,
would
would
make
sense,
I
think
so.
Yeah
I
think,
like
the
red
flag
is
every
time
that
there
is
something
auto
generated,
that
you
don't
have
control.
C
Right,
yep,
yeah
and
and
and
for
us-
and
I
think
many
messaging
systems
that
that
kind
of
strive
for
decouple
pub
sub
the
topics
that
on
messages
are
often
contained
things
like
that
that
are
auto-generated,
but
the
you
kind
of
as
a
messaging
system.
C
You
don't
know
if
the
application
chose,
something
that
you
know
has
an
idea
in
it
or
something
like
that
or
not,
and
so
I
think,
you're
sort
of
if
your
topic
can
be
generically
used
you're
sort
of
forced
into
treating
it
as
a
generic
thing,
because
it
might
be
used
that
way.
B
Yeah
I
mean
I'm
just
looking
up
here.
What
http
currently
requires
for
the
span
name,
I
mean
it's
also
interesting.
They
differ
here
between
client
and
server
spans
and
for
service
bands.
They
say
I
use
this.
I
think
that's
what
what
you
can
call
a
route
just
use.
Basically
these
local
analytic
routes
and
for
client
spam
names.
They
say
often
on
the
client
on
the.
If
you
have
a
client
actually
be
spam,
you
cannot
kind
of
extract
the
route.
B
A
B
I
mean
another
interesting
question
coming
here
to
a
mind
I
mean
for
for
http.
Basically,
each
http
span.
B
Because
because
I
mean
what
we,
what
we
have
here,
if
we
just
map
this,
what
we
have
here
for
http
can
span
to
messaging,
but
you
what
we
would
have,
then
would
be,
let's
say,
kafka,
publish
or
you
would
have
a
rapid
mq
deliver
that
would
that
would
correspond
to
what
is
there
in
http
I
mean
that
would
guarantee
that
would
guarantee
low
cardinality,
but.
A
But
this
I
mean
my
experience
with
this,
for
example,
looking
at
traces,
client
traces
like
this,
I
can
say
to
you
that
is
pretty
much.
This
is
pretty
much
useless
like
just
look
a
lot
of
them
into
http,
get
it
to
be
get
it
and
it's
like
it's.
It's
really
like
it's
really
bad,
and
but
what
I
think
it's
possible
to
do
are
some
back-ends,
for
example.
A
In
that
case,
what
we
do
is
you
show
this
at
the
top
level,
but
you
also
show
below,
like
I
think
it's
called
operation
the
attribute.
What
does
it
that?
Because,
for
example,
for
clients,
so
you
can
still
send
there
is
some
some
paths
being
sent,
so
you
showed
http
get
and
then
the
path
because,
just
seeing
like
I
don't
know,
100
http
get,
and
then
you
don't
even
know
where
which
operation
you're
calling
it.
I
think
jager
also
does
the
same.
B
A
B
But
what
would
that
be?
Maybe,
like
the
actually
a
very
good
solution
that
you
that
you
see
like,
let's
say,
rabbit
and
q,
publish
you
see
that
in
bold,
but
then
and
then
exactly
and
then
in
like
underneath
you
see
this
messaging,
the
destination,
that's
actually
the
real
destination
which
can
be
high,
cardinality.
A
B
Mean
that
is
actually
then
I
mean
that
puts
like
additional
how
to
say
strain,
let's
say
on
backhands,
but
I
I
think
it
would.
B
It's
a
visualization
question,
but
it
would
resolve
us
from
coming
up
with
some
artificial
destination
here
that
doesn't
really
like
that
so
coming
up
with
an
artificial
destination
just
for
the
sake
of
reducing
the
cardinality
right,
because
then
we
both
would
basically
have
here
here
the
the
messaging
system
and
operation.
That
is,
we
don't
need
to
worry
about
cardinality
here,
because
we
have
both
of
those
are
pretty
limited
sets,
so
we
have
low
cardinality
and
then
we
we
don't
need
to
for
destination.
We
just
have
the
attribute.
B
We
don't
need
to
worry
about
cardinality
and
then
in
the
ui.
Basically,
that
that
can
be
can
be
optimized
that
you
see
here,
the
locality
span,
name
above
and
then
maybe
underneath
in
a
smaller
font.
You
see
the
actual
destination.
A
D
Rabbit
queue,
you
send
a
message:
you
have
to
specify
a
both
exchange
name
and
a
routing
key,
and
then
you
ask
yourself
how
how
do
I
write
it
as
the
spanner
and
like
people
just
do
what
they
think
is
right
and
the
reviewing
for
these
pros
is
very
relaxed
like
it's.
It's
not
a
big
thing.
If
your
spend
name
is
not
perfectly
match
some
spec
or
or
some
follow
somewhere
common
pattern,
so
people
just
write
what
they
think
is
right
and
it's
being
accepted,
so
anything
that
we
say
about.
B
Yes,
I
mean
it's,
it's
all,
it's
all
shoots
here.
So
if
you
have
a
good
reason
for
doing
it,
otherwise
you
can
still
do
it
without
basically
breaking
or
without
you
can
still
say
you
implement
this
back,
and
if
you
have
a
good
reason,
you
can
do
something
different
with
with
the
span
name.
D
B
So
there
I
think
there
are
no
masks
in
here
at
all.
So
it's
it's
kind
of
relaxed.
A
I'm
trying
to
find
out,
because
I
I
did
I
was
using
the
the
other
day.
I
was
trying
something
out
when
I
was
doing
the
cloud
events
thing.
I
implemented
something
in
the
in
their
go
sdk
and
I
used
the
the
the
hotel
go
sdk,
and
I
remember
that
that
this
fans
working
on
the
client
spans
they
were
showing
like
http
posts,
which
you
get
and
then
underneath
you
could
have
some
hooks
or
something
to
to
hook
into
that
and
add
something
else.
A
For
example,
I
could
add
the
name
of
the
service
that
this
request
is
going,
for
example,
but
I
try
to
find
which
field
in
the
in
the
which
property
in
the
span
that
does
that
value
goes
because
like
if,
for
example,
for
http
things,
I,
like
the
for
examples,
could
use
this
to
show
like,
like,
like
we
were
discussing
the
bold
http
post
and
then
underneath
the
whatever
else,
but
it
has
to
be
some
field.
A
That
is,
I
don't
know
well
known
or
standard
right,
so
it
would
be
the
same
for
them
for
messaging.
So
like
like
this
other
thing
that
we
want
to
put
beneath
that.
It
would
have
to
match
the
same
that
is
used
for
for
http
spans
just
trying
to
find
what
it
I
don't
know.
It
makes
sense
what
I
said,
but.
B
Oh,
you
mean
that
the
attribute
names
you
mean
would
need
to
be
compatible
yeah
exactly
for
http,
it
might
be,
it
might
be
target
or
it
might
be
url.
I
mean
there
is
there's
weird
requirements
here,
because
you
might
have
yeah.
B
Because,
here
you
might
either
have
your
l,
you
might
have
scheme
host
and
target
you
might
have
scheme
pure
name,
pure
host
and
target.
I
mean
there's
one
of
those
four
basically
is
required
for
for
http,
which
already
probably
makes
this
pretty
tricky
to
implement
another
messaging
yeah.
We
would
add
basically
one
more
option.
We
basically
say:
okay
for
messaging
yeah,
if
you,
if
it's
if
the
span
is
like
a
message
being
spam-
and
you
have
a
message
to
destination-
then
add
this
at
this
stage.
B
I
mean,
but
I
I
I
think,
having
the
span
name
very
generic
like
http,
actually
the
more
I
think
about
it.
I
I
think
it
makes
sense,
because
also
what
we
do
here
basically,
is
that
we
give
the
the
back
ends:
lots
of
possibilities
to
kind
of
create
and
create
an
organized
visualization,
because
otherwise
I
mean
the
span
name.
I
think
the
backend
is
not
really
supposed
to
change
the
span
name.
I
think
that
would
be
very
confusing.
B
I
think
the
backend
needs
to
display
this
main
name
as
this,
but
basically,
if
we
make
this
more
modular
and
we
don't
pack
any
everything
in
the
span
name
because
that's
the
span
name,
that's
very
generic
and
that's
kind
of
attributes-
you
can
more
or
less
rely
on.
Then
the
backends
have
more
kind
of
flexibility
to
kind
of
display
this
in
a
in
an
ergonomic
way,
and
I
think
to
her
quite
good.
Something
in
the
domain
said
that
it
or
it
also
makes
it
easier
for
people
writing
instrumentation.
B
That's
there's
not
much
ambiguity
there
and
you
add
your
real
destination
name,
there's
also
not
that
much
ambiguity
there
and
then
you
basically
can
say
whether
it's
a
temporary
or
anonymous
destination
or
not
that's
also
an
attribute
and
then
basically
on
the
backhand
side,
you
have
all
the
or
when
you
look
at
the
traces,
you
basically
have
order
all
the
information
there.
B
And
also
I
mean
another
problem
is
that
we
avoid
some
redundancy.
We
don't
have
the
destination
name
in
the
span
and
in
the
attribute,
and
furthermore,
we
are
kind
of
more
or
less
compatible
with
what
http
does.
A
I
think
that's
that's
a
good
start.
I
guess.
C
That
sounds
pretty
good.
One
question
I'd
have
is
what
the
identifier
should
be
in
the
span
name,
whether
because
it's
not
entirely
clear
to
me
what
messaging
system
versus
a
messaging
protocol
is,
you
know
like
amqp
is
a
protocol
and
you
can
use
it
to
talk
to
many
different
messaging
systems
such
as
standard
protocol
and
a
an
amkp
client,
wouldn't
necessarily
know
what
message
in
the
system.
It's
talking
to.
It's
just
an
application
that
uses
an
amqp
api,
so
yeah,
I
would
think
it
may
like.
C
In
some
cases,
kafka
has
a
standard
protocol,
as
as
do
many
of
the
ones
listed
there,
but,
and
sometimes
your
standard
and
active
mq
also
supports,
I
believe,
mqp
and
and
perhaps
other
standard
protocols,
so
differentiating
a
system
and
a
protocol,
and
what
we
mean
by
these
things,
I
think,
is
important.
B
Yes,
I
mean,
I
would
actually
let
me
check
here
with
the
maybe
we
might
want
to
have
something
similar
to
the
databases.
I
think
it
was
here.
Let
me
quickly
check
yeah
for
databases.
Basically,
there
is
a
for
databases
or
something
like
dbsystem,
and
there
is
an
exhaustive
list
here
of
known
and
supported
database
systems
and
maybe.
C
B
And
there
are
only
sections
basically
for
like
particular,
like
attributes
like
for
rocket
and
queue
here
and
kafka,
but
maybe
we
want
to
have
something
something
similar
to
here
where
there
is
a
list,
basically
for
people
to
choose
from,
and
then
there
is
less
ambiguity
I
mean
the
question
is
that
this
list
also
has
to
be
maybe
updated
it
might
it
might
get
pretty
long.
That's
the
my.
C
Question
is
how
do
you,
how
does
an
like
a
client's
application
like
if
you
have
auto
instrumentation
on
an
amtp
api?
How
does
it
know
what
messaging
system
it's
talking
to
and
what
it
should
use
for
the
system?
C
I
just
wonder:
if
protocol
isn't
the
thing
that
we
want
to
use,
because
that's
the
thing
that
everybody
knows
both
clients
and
brokers
and
the.
B
Protocol,
you
always
know
I
mean
it
seems
they
had
a
similar
problem
here
and
they
just
maybe,
then
we
just
have
something
like
other
underscore
mqb.
So
when
you,
when
you
know
your
mqb,
but
you
don't
know
which
messaging
system
you
just
and
this
because
as
cradle
also
sql,
it's
it's
it's
our
secret.
It's
not
a
it's,
not
a
database,
it's
just
a
more
or
less
like
protocol,
but
I
think
to
end
it.
That's
a
that's
a
good
question.
Actually
what
what
can
be
a
messaging
system
name-
and
I
agree
it's.
C
C
Are
you
somehow
supposed
to
pack
all
that
information
in
here
or
should
there
be
separate
attributes
for
that
those
pieces
of
information
because
protocol
likes
this
transport
protocol,
but
there's
many
layers
to
transports,
and
so
is
it
just
the
top
level
or
or
like
it
depends
on
what
the
use
of
this
is.
I
suppose.
B
C
C
It
could
be
useful,
I
should
put
it
all
in
here
and
the
spec
doesn't
really
say
and
so
making
it
clear
what
is
desired
here
is,
I
think,
good,
and
I
think
my
feeling
is
is
that
if
you
pack
too
much
things
in
with
like,
if
you
put
amtp,
slash,
tls,
slash
tcp,
it
makes
it
harder
to
search,
because
I
don't
know
how
good
wildcarding
might
be
on
attributes
and
stuff
like
that
and
back
ends.
If
you
have
more
information,
you
probably
want
to
split
it
up
into
multiple
attributes.
I
assume.
B
I
mean
actually
event
here.
There
is
this
other
part
of
the
mandy
conventions
which
are
network
connection
attributes,
and
I
mean
people
who
want
to
pack
in
more
information.
They
can't
just
add.
Like
those
attributes
onto
the
span,
I
mean
there's
lots
here
here.
You
have
to,
for
example,
the
net
the
transport
protocol
and
that
might,
for
example,
that
might
differ
from
the
messaging
dot
protocol
that
we
have
here
so
that
messaging.protocol
might
amqb.
B
But
then,
then
you
go
a
level
over
and
you
can
add
details
about
the
the
lower
level
protocols
here
on.
I
think
that's
the
intention
of
this
net
yeah,
I
I
and
here
you
can
have
you-
can
go
in
even
more
details.
C
B
C
B
Yes,
but
I
think
the
main
point
here
is
that
when
we
talk
about
like
messaging
protocol
here,
we
are
definitely
referring
to
a
messaging
specific
protocol
and
if
you
want
to
add
information
about
like
the
lower
level
stuff,
that
is
a
different
area
of
semantic
conventions
that
are
also
shared
across
different
because
you
might
add
those
same
attributes
to
http.
Those
are
not
not
messaging
specific,
so
I
think
we
we
need
to
follow
more
modular
approach
here
and
for
messaging.
We
just
keep
to
stop
that's
really
specific
yeah.
I
I.