►
From YouTube: 2022-04-21 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).
B
A
D
C
Okay,
so
let's
start
out
with
the
project
board
that
actually
I
I
think
you
set
up
the
project
board
I
put
stuff
on
it.
I
think
you
were,
I
think,
not
here
last
week
in
a
week
before.
C
So
I
just
yeah
populated
the
project
board
with
stuff
that
we
are
working
on
and
also
open
issues
referring
to
the
messaging
semantic
conventions
and
to
try
to
split
up
into
like
what
we
need
for
v,
one
zero
and
also
for
this,
basically
post
post
version
and
there
there
are
like
a
variety
of
issues
here
for
postmoderate
zero.
I
mean
metric
semantic
conventions,
obviously
here
guidelines
when
there
is
excessive
amounts
of
recorded
data
that
will
tie
into
sampling.
C
I
would
also
propose
that
we
put
that
post
1.0
and
then
those
two
things
I
just
created
draft
things.
You
know
issues,
that's
what
we
also
put
out
of
scope,
the
context
propagation
for
particular
individual
protocols
and
the
intermediary
instrumentation
and
the
rest
of
the
issues
I
mean
it
looks
quite
like
like
a
lot,
but
it
actually
isn't
because
many
of
the
things
we
already
discussed
here,
we
have
questions
about
span,
relationships
in
messaging
semantic
conventions.
That's
what
we
discussed
very
extensively
up
to
now.
So
here
is
just
like
as
an
example.
C
This
is
regarding
the
work
that
throughout
it,
that
we
need
to
be
somehow
in
in
sync
with
the
cloud
event
semantic
conventions,
and
here
we
have
a
certain
most
of
those
other
issues
here
are
just
related
to
attributes
like
here
capture
cluster
id,
then
here
this
is
about
attribute
namings
for
attributes
across
different
semantic
conventions.
C
Here
that
I
think
we
also
discussed
messaging
batch
received,
this
is
also
about
like
about
how
our
span
relationships-
and
here
that
is
also
about
attribute
names
shared
between
different
semantic
conventions,
messaging,
fas
and
rpc,
and
this
is
the
one
issue:
erb
still
have
open
with
a
book
done,
so
there's,
basically
nothing
really
new
and
big.
Here
I
think
last
time
we
started
talking
about
attributes
by
naming,
so
this
will
be.
C
I
think
this
will
be
the
last
big
topic
we
here
talk
about
and
in
in
basically
in
the
scope
of
this,
we
will
actually
hopefully
resolve
lots
of
the
issues
that
we
have
here.
So
it
looks
as
I
said,
it
looks
quite
a
lot,
but
it's
actually
just
lots
of
just
more
issues.
C
Some
we
already
saw
it
anyway
and
with
putting
out
this
this
old
tap,
I
think
we
can
actually
deal
with
with
most
or
or
all
of
the
issues
here,
and
I
mean
we
also
have
a
quite
nice
post,
v1
roadmap
here
already
too
awesome.
B
C
C
So
if,
if,
for
example,
if
a
customer
said
or
if
a
user
says
okay
about
instrument,
I
want
to
see
like
mqb
spans
or
mqtt
spans.
This
is
basically
there
will.
For
that
use
case.
There
will
be
additional
requirements
for
for
for
propagating
context
over
mqb
and
mqtt,
and
this
will
be
part
of
this
issue.
I
think
we
lay
this
out.
Let
me
let
me
check
how
we
formulated
that
in.
C
Because
what
we
have
for
now,
we
just
have
the
requirement
that
that
we
need
to
attach
a
context
to
to
a
message
and
this
context
must
not
be
changed
by
intermediaries.
So
that's
basically
that's
what
we
need
for
1.0.
C
That's
our
requirement
for
1.0
for
future
requirements.
B
So
this
is
for
for
brokers
and
other
intermediaries
to
to
send
traces.
This.
B
C
And
here
that's
how
we
laid
it
out
in
autovisit,
currently
the
instrumentors:
they
have
to
decide
how
to
attach
and
extract
context
from
messages
in
order
to
fulfill
the
requirements
that
we
laid
out.
But
in
future
we
want
to
list
like
recommended
ways
of
how
to
propagate
context
using
those
messaging
protocols.
C
So
we
will
not
basically
for
this
endeavor.
I
think
that
would
really
blow
up
the
scope.
If
you
would
say:
okay,
we're
gonna,
have
standardized
ways
for
mqb
and
qtt
and
other
protocols
for
how
exactly
we
want
the
context
to
be
propagated.
C
B
C
So
but
yeah,
as
I
said,
if
there's
anything
here,
that
you
think
is
missing
or
anything
that
you
want
to
add,
or
that
kind
of
you
want
to
shop
around
if
you've
been
here
yeah,
maybe
just
looks
really
good
bring
it
up
in
or
I
mean
feel
free
to
shove
around
things
yourself
or
bring
it
up
in
one
of
the
meetings.
Maybe.
D
Just
for
the
contact
propagation,
maybe
if
we-
because
I
I
I
also
had
the
same-
I
guess
thinking
as
ted
like.
Maybe
you
should
another,
not
you
that
you
explained.
I
think
it
makes
sense,
but
I
maybe
we
should
rephrase
it
a
bit.
So
so
it's
so
it's
clear
that
it's
like
we
have
some
guidance,
but
this
is
more
like.
D
I
don't
know
how
to
face
it
though,
but
I
don't
know
if
you
see
what
to
me
what
I
mean,
but
because
if
someone
looks
at
this,
it
might
might
look
like
we
don't
have
any
any
anything
defined
for
how
to
do
context
propagates.
But
we
do
it's
just
not
really
really
well
like
defined
by
each
each
protocol.
I
guess
right.
D
B
C
We
have,
we
have
means
of
how
well
yes
in
context
with
proper
course,
but
it's
not
like
really
rigidly
standardized
perfect.
No,
it's
perfect.
C
Yeah,
I
I
I
was
off
the
beginning
of
this
week,
so
I
did
not
have
time
to
kind
of
extend
the
old
tap
with
what
we
talked
about
regarding
attributes
last
time,
but
just
to
continue
there
and
give
a
short
recap.
We
started
looking
into.
C
Usually
destination
name
is
kind
of
a
keyword,
topic
name
and
what
we
talked
about
a
lot
is
this
requirement
that
this
should
be
that
it
should
be
low
cardinality
and
that
it's
actually
hard
to
kind
of
define
what
is
low
cardinality
and
what
is
not,
and
that's
actually
good,
that
you
are
here
ted,
because
one
one
thought
that
we
had
is
that
when
we
compare
this
here
to
what
we
have
in
http
in
http,
basically,
we
just
have.
C
We
just
have
like
http,
and
then
we
have
an
operation
name
for
the
span
name
and
that's
it
and
that's
basic
for
for
clients,
bans
at
least
talking
about
client
spends
here,
and
this
basically
is
supposed
to
be
to
give
us
like
a
guaranteed
low
cardinality
here
by
making
this
destination
putting
or
requiring
this
this
destination
naming
the
span
name.
It's
we
open
some
like
it's
things
are
getting
a
bit
ambiguous
because
yeah
duane
was
bringing
up.
First
time
the
question:
what
is
low
cardinality?
C
How
do
I
know
when
the
name
is
low
cardinality?
How
is
that?
How
it
defined
and
it
kind
of-
and
we
wondered
here
whether
it
makes
how
much
sense
it
makes
it
all
to
keep
the
destination
name
here
in
the
span
name,
because
what
is
required
here?
It's
basically
that
yeah.
If
the
destination
name
is
low,
cardinality
use
it
and
if
it's
not
low,
cardinality,
then
kind
of
convert
it
to
something
that
is
low.
Cardinality.
B
Yeah,
so
I
think
it's
better
to
think
about
it,
not
as
low
or
high
cardinality,
so
much
as
it
needs
to
be
a
good
index,
so
actually
the
default
for
http,
where
it's
just
http
get
http
post
that
actually
isn't
a
good
default.
It's
too
too
low
cardinality
a
better
default
is
when
available
is
a
route
slug,
so
in
other
words,
not
the
full
url
like
customer
one,
two
three
slash
product:
four:
five:
six:
it
customer
slash
colon
customer
id
slash
product,
slash
colon
product
id.
B
That's
that
route
slug,
if
that
makes
sense,
is,
is
the
ideal
index
for
an
http
action,
because
that
means
we're
going
to
index
everything
based
on
the
route
name.
B
However,
if
you
don't
have
something
like
that,
which
can
definitely
be
the
case,
for
example,
something
like
that
only
exists
generally
in
the
context
of
having
like
some
kind
of
mvc
framework
right
or
some
some
higher
level
thing
going
on.
Where
you
have
a
concept
of
a
of
a
route,
then
you're
in
a
world
with
no
good
choices
right,
you
either
have
something.
That's
too
low
cardinality,
like
http,
get
which
is
too
low
because
you're
not
necessarily
interested
in
comparing
all
the
get
all
the
different
kinds
of
get
requests.
B
You're
making
right
like
that's,
not
necessarily
a
good
comparison,
but
the
other
side
of
just
using
a
url
that
includes
things
like,
like.
You
know,
identifiers
one,
two,
three,
four,
a
b
c
d:
that's
too
high
cardinality,
because
you're
not
going
to
to
get
a
proper
index
right,
because
every
request
you're
going
to
make
is
going
to
be
subtly
different,
like
the
the
number
that
will
have
the
exact
same
url
is
going
to
be
very
low
and
the
cardinality
is
going
to
be
very
high.
B
So
it's
going
to
be
like
not
very
useful
but
very
expensive,
and
so
what
we
say
with
with
sp
operation
names
is,
if
you
don't
have
like
an
ideal
choice,
if
there
isn't
something
that
would
clearly
make
a
good
index
and
you're
instead
having
to
choose
between
something,
that's
a
poor
index
with
very
high
cardinality
and
something
that's
a
poor
index
with
low
cardinality
choose
the
poor
index
with
low
cardinality,
so
don't
by
default,
throw
something
in
the
span
name
that
you
know
is
not
going
to
be
a
great
index
but
is
going
to
be
expensive.
B
So
maybe
that
that
shines
a
little
bit
better
light
on
how
how
we
define
it,
but
it
is.
It
is,
unfortunately,
a
little
bit
of
an
art.
You
know
different
analysis
tools
have
different
issues
with
different
amounts
of
cardinality,
but
the
ideal
is
like,
if
you
can
put
something
in
that
span
name,
that
would
be
the
the
right
index.
If
you're
trying
to
say
compare
latencies
is
a
the
best
way
to
think
of
it.
B
If
you're
trying
to
compare
latencies
and
error
rates
based
on
this
operation
name,
what
is
the
the
right
index
for
comparing
them?
Where,
like
that,
latency
comparison,
would
would
be
meaningful
to
to
the
operator
the
most
meaningful
index
you
can
think
of
is
what
what
should
be
in
there.
B
But
it's
not
always
the
case
that
that
that
primary
index
is
like
obvious
and
available,
and
if
it's
not
then
choose
choose
a
lower
cardinality
option
rather
than
one.
That's
that's
going
to
to
really
blow
up
the
amount.
The
the
heaviness
of
that
index.
A
That's
pretty
helpful
ted,
but
one
thing
that
so
it
just
strikes
me
that
the
url
or
maybe
something
more
typical
for
messaging,
like
a
topic
or
something
yeah,
is
that
the
application
layer
would
know
how
to
interpret
that
and
know.
Let's
say
which
portions
of
it
like
at
our
id
or
something,
but
as
you
send
that
through
a
transport
and
they're
generating
traces,
they
would
have
no
knowledge
of
that
application
layer.
A
And
so
would
the
suggestion
in
cases
like
that
be
where
the
the
application
could
perhaps
put
something
more
useful
in
a
destination.
But
then,
as
it
goes
through
the
transport.
It's
just
like
topic
yeah,
because
if
you
can't
know
how
to
interpret
it.
B
Exactly
exactly
it's
not
the
case,
generally
speaking,
when,
when
doing
these
comparisons
right
like
when
someone's
actually
going
to
set
up
alerting,
you
know
on
a
trace,
they
will
have
multiple
spans
to
pick
from
that
are
going
to
give
them
like.
B
You
know,
useful,
a
useful
alert
essentially
and
that's
kind
of
how
I
think
of
the
operation
name
that
there's
ideally
at
least
one
span
in
the
trace
that,
if
is
going
to
like
catch
all
the
errors
and
latency
issues,
so,
for
example,
with
http,
you
might
have
an
http
client
and
then
an
http
server
like
and
the
the
client
doesn't
have
like
a
good
way
of
attaching
the
route
name,
but
the
server
it's
talking
to
does
right,
like
it's
part
of
like
some
spring
or
some
mvc
framework,
and
so
it's
possible
to
attach
the
index
that
you
want
there
and
that
span
is
going
to
catch.
B
You
know
if
there's
latency
in
this
thing
processing,
you
know
it's.
It's
action.
That
span
is
going
to
capture
a
lot
of
that
latency.
If
there's
errors
in
the
request,
that
span
is
probably
going
to
turn
into
an
error.
So
that's
a
useful
span
to
to
take
for
setting
up
like
alerts
and
things
like
that,
and
so
it's
not
that
that
every
span
has
to
has
to
have
an
ideal
name.
B
But
hopefully
we
want
to
concentrate
on
finding
the
places
where
we
can
inject
a
good
index
like
that
into
the
into
each
leg
of
the
trace.
B
But
if,
if
you
don't
have
one
because
yes
you're
some
low-level
piece
of
machinery-
and
you
don't
have
access
to
concepts
like
topics
and
things
like
that,
then
you
want
just
a
more
low-level
generic
name
that
would
allow
someone
to
use
it
as
like
a
more
generic
index
right
if
you're
just
saying
generically,
I
want
to
just
look
at
all
of
the
message
processing
going
on
what
would
be
like
a
lower
level
way
of
putting
that
processing
into
different
buckets.
B
So
you
could
at
least
just
figure
out
in
general,
like
what
your
outliers
are
or
just
in
general.
You
know
what
your
errors
are,
and
hopefully
you
could
work
your
way
back
from
that
span
to
other
information
that
was
maybe
more
specific
about
what
was
going
on.
A
It
seems
that
there
could
be
other
things
that
could
be
useful
like
when
the
when
something
processing
a
topic
doesn't
know
anything
about
the
information
container,
how
it's
contained
in
the
topic
and
therefore
can't
assume
anything
that
perhaps
might
be
useful
to
say
well.
This
was
a
an
amqp
message.
B
A
An
http
message,
or
whatever
does
it,
make
any
sense
to
kind
of
in
a
particular
context,
like
really
change,
what
is
in
that
destination
portion
I
mean
htp
versus
amtp
or
whatever
is,
is
not
really
a
destination.
It's
it's
a
system
or
the
protocol.
B
B
I
would
give
me
good
information
if
I'm
looking
at
a
latency
spread
or
I'm
looking
at
errors
like
in
aggregate
like
what
what
would
be
a
decent,
a
decent
dimension,
to
look
at
those
those
latencies
or
or
errors
across,
and
so
just
just
trying
to
name
every
every
operation
type
with
a
as
accurate
as
an
index
as
you
could
get
is,
is
what
you
want,
and
if
it's
not
the
case
that
you
could
get
something.
B
If
it
is
the
case,
you
can
get
something
very
specific,
like
yeah
like
like
topics,
if
there's
a
place
where
there
is
some
some
higher
level
structure
that
the
the
end
user
has
created,
that
kind
of
like
application,
logic,
level,
structure,
those
you
really
want
to
get
those
operation
names
in
there
somewhere.
B
The
thing
you
would
just
want
to
avoid
is
something
like,
like
a
time
stamp
or
like
a
message
id
where
the
message
id
is
gonna,
be
like
different
every
time.
Those
are
the
things
you
wanna
make
sure
you're
not
putting
into
the
operation
name
because
as
soon
as
you
get
something
like
that.
B
A
C
I
think
the
the
challenge
that
the
that
exists
here
is
that,
even
when
we
yeah,
but
the
challenge
exists
just
to
end
it
when
you
go
a
level
lower
like
on
the
intermediary,
how
do
you
know
like
what
is
low
cut
analog
and
what
is
not,
but
it's
even
like
on
the
application
layer
when
you
have
other
instrumentation
or
you
have
an
sdk
that
is
pre-instrumented.
A
C
Many
cases
when
you're
trusting
in
an
sdk,
you
create
a
span
and
you
you
don't
know
if
this
destination
is
just
a
low
cardinality
or
not.
So
what?
What
should
we?
What
is
recommended
and
what?
What
should
we
recommend
in
those
cases,
that's
a
bit
of
a
question.
B
But
then,
when
you
across,
like
the
destination
id
dimension,
you
can
see
that
it's
like
whoop
one
or
two
of
these
destinations
actually
are
the
bulk
of
the
the
high
latency
or
the
bulk
of
the
errors,
or
actually
correlate
highly
with
a
particular
destination
id,
and
that
would
be
like
really
helpful
information
as
an
operator
you'd
be
able
to
to
move
forward
and
root,
causing
your
your
problem.
If
you
could
see
that,
then
that's
a
good
index,
that's
a
useful
index
to
have.
If
it's
the
case,
that
destination
id
is
some
unstable
identifier.
B
That's
just
getting
like
regenerated
every
hour
or
something
like
that
and
the
chance
that
it
would.
It
would
correlate
effectively
with
something
that
would
allow
you
to
to
move
forward.
Then
then
it
wouldn't
be
useful.
So
I
don't
it's
a
little
vague,
unfortunately,
because
because
operating
and
root
causing
these
systems
is,
is
not
actually
a
science
at
this
point
right,
like
these
things
are
not.
We
have
not
defined
our
our
network
architectures
sufficiently
for
for
operators
to
have
a
science
they
can
use
in
this
case.
B
So
it's
just
more
trying
to
think
of
like
what
are
the
if
you
could
instruct
someone
in
how
to
operate
the
system
and
then
how
to
triage
errors
and
latency
problems.
If
you
were
like
sitting
someone
down
and
trying
to
teach
them,
you
want
this.
The
operation
names
to
be
a
a
good
index
for
for
doing
that.
You'll
have
other
indexes
right,
you're,
going
to
have
these
other
attributes
on
these
spans.
B
So
it's
not
that
operation
name
alone
has
to
be
the
only
index
you're
going
to
use
you
you
could
use.
You
know
other
attributes
as
your
index
or
you
can
use
like
a
combination
of
attributes
to
build
up
a
a
better
index,
but
we
try
our
best
to
say
that
the
tracing
analysis
isn't
going
to
automatically
necessarily
build
up
indexes
around
all
of
your
attributes
or
combinations
of
attributes.
B
But
we
try
to
say
that
the
the
span
name
is
something
like
a
primary
index
which,
just
by
default,
if
your
your
analysis
tool
has
some
kind
of
like
default,
bucketing
or
default
behavior.
B
To
use
this
as
the
this
operation
name
is
the
the
default
index
for
creating
histograms
or
doing
any
kind
of
analysis
that
it's
going
to
do
so
again.
It's
like
I.
I
can't
I
can't
give
like
a
a
super
specific
instruction.
That
applies
applies
everywhere.
B
It's
just
for
each
each
each
operation
that
we're
creating
a
span
for
it's
best
to
just
think
about
will
of
the
information
I
have
available
commonly
available
when
making
this
operation.
B
What
would
be,
what
would
be
the
most
useful
index
here,
which
is
comes
down
to
basically
being
as
specific
as
possible,
without
becoming
so
specific
that
you're
without
the
specific
parts
being
so
unstable,
maybe
as
a
way
of
putting
it
yeah
without
being
so
unstable
that
you're
not
going
to
actually
be
able
to
use
it
as
a
dimension
for
for
comparing
things,
but
as
specific
as
you
can
get
up
until
that
point,.
C
I
mean
if,
if
I
put
on
the
operator
head
here,
I
mean
that's
a
good,
I
think
way
to
see
it.
I
would
I,
I
would
actually
say
very,
very
simplified.
There's
then
two
options
that
we
have
for
basically
for
the
operator
side,
either
we
kind
of
forcefully
limit
the
cardinality
here,
as
it
is
done
with
http
http.
Basically,
by
definition,
you
cannot
have
high
cardinality,
because
you
just
have
http
and
then
operation
get
or
get
so
that
is
kind
of
one
operate.
C
Experience
that
you
just
have
is
very
limited
experience
that
gets
that
gives
you
kind
of
low
cardinality,
guaranteed
more
or
less
or
building
yeah.
And
then
you
have
this
more
flexible
thing
that
you
have
here
and
also
from
the
operator
point
of
view.
Most
of
the
time
you
will
have
like
useful
locationality
stuff.
A
C
I
think
sometimes
it
will
blow
up,
because
when
you
give
basically
sometimes
the
destination
name,
it
will
maybe
an
id
and
deeper
or
it
will
be
something
different
that
we
didn't
think
about
here
and
we
can
write
here
what
we
want.
Sometimes
this.
I
think
there
are
cases
that
they
don't
think
about,
or
there
is
instrumentation
that
kind
of
doesn't
consider
that
and
sometimes
the
cardinality
will
blow
up.
B
Something
like
destination
or
conversation
id
you
know,
conversation
id
might
be
too
much
right
and
unfortunately,
I'm
not
enough
of
a
messaging
expert
to
say,
and
I'm
sure
these
are
concepts
that
this
is
where
things
start
to
really
vary
across
different
messaging
implementations,
and
some
of
these
things
might
be
things
that
unfortunately,
actually
vary
based
on
how
people
are
using
a
system.
B
If
people
are
using
a
system
where
there
are
long-running
conversations
and
that's
like
meaningful,
but
someone
else
could
use
the
system
correctly
in
a
way
that,
like
every
message,
is
a
new
conversation
id
or
something,
then
that's
where
it
gets
tricky
and
we
try
to
to
err
on
the
side
of
avoiding
indexes
that
might
blow
up
with
high
cardinality
part
of
the
thinking
being
that
this
is
default.
B
Instrumentation
right
like
like
these
are
the
defaults,
we're
gonna
turn
on
for
everybody,
and
so
it's
better
for
things
where
that's
like
a
risk
that
the
the
cardinality
could
blow
up
and
whether
or
not
it's
super
useful
is
debatable.
B
It's
better
in
those
cases
to
have
those
potentially
high
cardinality
values
and
attributes
so
that
the
end
user
could
build
start
building
like
compound
indexes
in
their
analysis
tool.
It's
just.
They
would
have
to
to
do
that
themselves.
Right
like
by
hand
starting
to
put
these
things
together,.
C
B
C
B
B
B
Have
a
lot
of
high
cardinality
low
value
indices
being
created,
we're
not
going
to
create
a
whole
bunch
of
little
tiny
spans
right
or
like
like
tons
and
tons
and
tons
of
logs
by
default,
because
that
the
presumption
is
that's
all
going
to
create
network
pressure
and
like
storage
costs
and
like
all
these
other
costs
associated
with
it.
So
we
want
our
instrumentation
to
be
kind
of
like
as
minimal
as
possible,
providing
the
maximal
amount
of
value.
B
C
A
question
comes
to
remind
you-
maybe
maybe
joanne
can
give
like
some
insight
here,
but
I
wonder
when
thinking
about
like
the
real,
like
user
use
cases,
I
I
just
think
that
in
most
cases,
this
destination
will
be,
or
at
least
in
kind
of
the
the
cases
according
to
the
book
that
will
be
low
cardinality,
because
it's
just
a
name
that
you
give
to
a
topic
into
a
queue
yeah.
I
actually-
and
I
want
to
like
in
in
the
real
world
like
how
how
how
far
can
you
rely
on
that?
C
Can
you
say
most
of
the
cases
it
will
be
low
cardinality
anyway
and
you're
fine,
or
will
we
run
into
those
kind
of
into
those
kind
of
ideas
and
anonymous
destinations?
Very
often
yeah.
A
I
mean
I
say
I
would
sort
of
categorize
messaging
into
sort
of
two
types
right,
there's
things
that
are
more
or
less
point-to-point.
The
kafka
is
very
sort
of
point-to-point
where
a
topic
is
a
place
that
messages
go
and
then
people
read
from
that
place
right
and
but
then
there's
more
distributed,
pub
sub,
which
is
a
very
different
beast
altogether
and
a
lot
of,
and
so
the
idea
there
is
that
you
could
have
a
topic
like
very
similar
to
ted's
http
example.
Earlier,
like
customer.123.order.456.
A
And
subscriptions
might
look
like
customer
dot,
star,
dot
and,
and
so
there's
aspects
to
that
topic
that
are
very,
very
high,
cardinality
and
not
of
high
value
at
an
index
probably-
and
there
are
so-
there
are
parts
that
are
in
parts
that
aren't
and
all
of
the
infrastructure
that
pushes
those
things
around
can't
know
which
pieces
are
useful
and
which
aren't
the
application
could
know
what
its
topic
structure
particular
messages
and
know
that
this
this
structure
is
customer.customerid.order.orderid.
A
And
it's
we
consider
it
a
best
practice
in
distributed
pub
sub
to
make
your
topic
hierarchy
as
descriptive
as
possible,
with
the
rationale
that
the
publisher
doesn't
know
where
the
message
is
going.
So
you
want
to
provide
as
much
useful
information
about
what's
in
the
message
and
let
consumers
describe
how
they
want
to
describe
subscribe
and
which
which
messages
they
will
or
will
not
want
to
receive
so
in
a
distributed
pub
sub
model.
I
think
topics
are
not
likely
to
be
topic,
which
is
the
destination
is
not
likely
to
be
low.
Cardinality.
A
Yeah
yeah,
I
mean
like
the
best
thing
I
can
think
of,
is
something
that
we
talked
about
last
week,
which
was
like
either
you
know
messaging
system
or
protocol.
I
mean
that's
not
that
it's
kind
of
along
your.
Your
earlier
example
of
you
know
something
that
just
forcing
them
to
be
very
low
cardinality
where,
where
maybe
you
say,
amtp
or
htp
or
whatever,
but
but
yeah.
A
So
it
depends
on
the
messaging
system
and-
and
I
think
it's
simplifying
to
say
that
there's
only
the
two
types
I
described,
but
I
think
loosely
speaking
systems
tend
to
kind
of
follow
one
or
the
other.
I
mean
often,
if
you're
the
very
distributed
pub
sub
you'll
support
point-to-point
concepts
as
well
like
publishing,
directly
to
a
cue
versus
to
a
topic,
but
but
yeah
the
distributed
pub
sub
model
is,
is
kind
of
gaining
a
lot
of
popularity
to
allow
for
decoupling
of
you
know,
publisher
and
subscriber
knowledge
right.
C
I
mean
some
some
thoughts
I
have
here
and
it's
basically
two
thoughts
and
I
will
just
throw
them
out
there
and
the
first
one
is,
I
mean
actually
not
related
to
what
we
discussed
now,
but
I
actually
was
wondering
why
the
mess
there's
no
messaging
system,
name
included.
Here
I
mean
we
have
this
as
a
attribute
here:
kafka
orbiting
queue
rocket
and
queue
and
actually
bounded
by
or
just
put
it
out.
C
So
there's
a
question
to
you
like,
if,
if,
if
you
think
that
would
actually
be
helpful
to
have
that
in
the
span
name
that
they
see
on
the
first
view,
okay,
that's
a
kafka
span.
That's
a
rapid
mq
span,
that's
a
sqs
or
whatever,
and
the
the
second
to
solder
idea
here
have
is
when
we
talk
about
this
destination,
name
being
high
cardinality
and
just
yeah
in
my
head.
Just
thinking
about
this.
C
C
If
you
know
it's
not
low
card
and
I
let
you
are
not
sure,
just
leave
it
out
and
you
just
have
kafka
publish
and
if
you
know
it's
low
cardinality,
then
you
have
kafka,
publish,
I
don't
know
shop.orders,
but
if
you
don't
know
or
you're
not
sure
you
just
leave
it
out,
that
is
just
yeah.
Just
wanting
to
throw
this
out
there
and
see
what
yeah.
A
Something
like
that
makes
sense
to
me.
I
think
what
I
I
I
if
and
when
we
get
to
it.
I
want
to
talk
about
the
distinction
between
system
and
protocol
a
little
bit,
but
but
at
a
high,
let's
not
dig
into
that
just
yet.
Let's
kind
of
I
think
we
should
try
to
nail
down
at
the
high
level
we
want
for
the
span
name.
First,.
D
You
see
that
we
are
really
close
to
the
same,
the
same
problem
and
what
I
was
thinking
is
that
like,
if
and
what
that
was
saying
that
in
some
cases,
the
application
or
there
is
like-
because
I
already
had
the
my
portion
of
being
the
operator,
for
example,
I
was
doing
developing
apps
in
the
past
and
I
was
the
one
that
was
on
call
and
debugging
and
looking
at
things
and
what
he
mentioned.
D
It
really
makes
sense,
because
there's
always
like
when
you're
the
operator,
there's
always
one
standard
to
know
that
that's
that's
the
one.
That's
they
wanted
to
create
the
alerts
that
they
wanted
to
know
that,
if
that
span
is,
is
wrong,
then
the
whole
thing
is
down
or
the
whole
thing
is
messed
up.
D
So
I
I
think,
that's
that
makes
all
sense
and
like
we
could
do
something,
for
example
in
the
convention
say
like
if
I
I
think
what
confuses
people
with
this
low
carb
and
this
for
that
there's
a
lot
of
text
in
it
and
it's
a
lot
of
new
new
words,
and
nobody
knows
what
local
narratives
I
mean
last
time
we
we
we
discussed
in
duane,
also
put
all
his
thoughts
on
it
and
we
tried
to
explain
him.
You
can
do
this.
You
can
do
that
like
folks.
A
D
Trying
to
start
it,
they
will
probably
be
confused.
What
I
was
thinking
is
that
we
can
just
say
like
if
your
destination
is
not
a
static
like
say
a
static
text
or
something
static
value
that
you
know
like
it's.
It's
not
gonna
change,
then
don't
use
it
in
this
play
name.
If
it's
a
static
thing
that
it's
not
gonna
change,
you
know
beforehand,
then
that
will
be
probably
fine
to
use
right
so
and
then,
in
that
case,
we
can
just
say
like
shop
order
send.
D
But
if,
if
we
say
like
okay,
if
your,
if
your
destination
is
somehow
it's
not
a
static
value,
it's
dynamic
then
fall
back
to
the
to
the,
not
so
great
but
low
cardinality
thing.
I
think
that
I
think
that's
the
best
we
can
do
probably
because
I
I
don't
really
see
any
any
other.
B
B
You
know,
then
that's
great
information
right,
because
you're
now
injecting
something
about
the
structure
of
the
application
into
the
operation
name,
if
topic
name
is
something
that's
just
getting
like.
Auto-Generated
like
an.
B
Then
it's
starting
to
get
a
little
suspicious,
but
if
it's
like
a
stable
identifier,
a
relatively
stable
identifier,
it
might,
it
might
still
be
useful,
but
as
soon
as
it
starts
to
turn
into
something
that
might
be
an
unstable
identifier,
then
then
you
really
want
to
stay
away
from
it
because
you're
just
it's
just
noise.
At
that
point,
yeah.
B
Application
did
so
so
this
is
actually
the
reason
why
operation
name
is
updatable,
even
though
we
really
hate
updatable
anything,
and
we
want
all
this
stuff
to
be
immutable,
and
we
want
it
to
be
available
when
the
span
starts,
because
you're
often
doing
some
kind
of
like
sampling,
information
there
or
whatever.
B
In
spite
of
all
those
reasons
span.
Name
is
still
an
updatable
attribute
for
precisely
this
reason,
which
is
you
find
at
least
in
http
systems,
and
I
bet
you
find
it
in
messaging
systems
too.
The
the
piece
of
code
that's
starting.
The
span
is
often
some
lower
level
piece
of
code
that
doesn't
have
access
to
a
lot
of
application
logic
right,
for
example,
it
may
not
have
access
to
those
those
tokens
right
like
those
replaceable
variables
where
it
just
has
it.
B
It
has
one
two
three:
it
doesn't
have
a
concept
of
product
id
as
like
a
concept
there,
but
in
what's
often
the
case
in
in
http,
is
that
gets
started
by
some
lower
level,
client
or
service,
but
then
is
handed
at
some
point
some
point
in
the
life
of
that
operation.
It
gets
handed
to
like
a
higher
level
piece
of
framework
code,
and
so
the
way
this
works
in
http.
The
way
we
end
up
with
those
route
slugs
tends
to
be.
B
It
starts
with
a
name
like
http
post,
but
then
at
some
point
it
happens
to
get
handed
to
like
a
piece
of
framework
code
that
does
know
something
about
like
the
route
slug,
at
which
point
that
higher
level
code
overwrites
the
operation
name
with
something:
that's
that's
more
application
specific,
and
so
I
suspect
it
might
be
the
case
with
with
with
messaging
systems
as
well.
B
So
one
way
to
think
about
it
is
like
we
can
put
in
the
defaults
as
like
these,
these
low-level
things,
and
then,
if
in
the
parts
of
the
system
where
some
higher
level
application
aware
framework
code
can
get
involved,
it
should
be
overriding.
These
fan
names
with
something
better
if
it
has
a
if
it
has
a
better
option.
C
Yeah,
I
mean
one
one
two
to
just
that
completely
makes
sense,
ted
yeah
and
to
what
I
this
idea
that
I
brought
up
before
just
to
put
it,
maybe
in
a
bit
different
words
and
maybe
put
like
or
incorporate
some
feedback
we
had
like
from
from
this
discussion.
Is
that
currently,
basically,
the
guidance
here
is
use
destination,
name
when
it's
of
low
cardinality
and
when
it's
not
then
just
create
some
kind
of
artificial
destination.
Name,
that's
not
really
defined.
C
B
C
Basically,
what
this
paragraph
here
kind
of
suggests
and
for
for
me
it
is
our
artificial
destination
name,
it's
quite
problematic,
because
of
course
they
can
say.
Okay.
That
can
be
something
very
helpful
for
the
operator,
but
it
can
also
be
something
pretty
undefined
that
you
don't
really
know
what
you
get
and
and
and
and
what
I
proposed
was
just
that
that
was
okay
use
the
destination
when
it's
low
cardinality
and
if
it's
not
low
low
cardinality,
then
just
leave
it
out.
C
I
think
that
is
basically
the
difference
here
for
my
proposal,
the
what
is
there
already
so
that
low
cardinality
this
decision
already
involves
some
kind
of
is
already
a
bit
like
faking
problematic,
as
we
saw
it's
not
clear-cut,
but
I
think
this
artificial
destination
name
is
even
more
kind
of
problematic,
because
what
should
it
be?
You
cannot
even
give
any
like
meaningful,
yeah
guidance
here,
so
that
would
be
my
proposal
that
we
kind
of
simplified
it
by
saying.
C
D
Yeah
one
thing
that
I
also
that
we
also
think
discussed
last
week
and
I
did
some
looking
so
what
I
was
like
what
what
we
thought
is
that,
for
example,
I
looked
already
a
lot
of
of
his
big
clients
fans,
and
what
do
you
see
is
just
like
http
get
all
over
the
place
and
if
you're
just
looking
at
the
trace,
it's
really
it's
really
useless
pretty
much,
because
it's
it's
like
unless
you
go
digging
into
things,
it's
it's
really
like
for
me.
D
It's
really
useless,
it
doesn't
doesn't
help
with
anything
and
and
what
I
noticed
as
well
is
that,
like
I,
I
saw
this
right,
but
I
didn't
like
realize
it
or
connect.
The
points
is
that
some
some
systems,
for
example,
jaeger,
if
the
if
the
service
name
is,
is
set
in
the
resource
jager
shows
like
service
name
and
then
the
http
get
like
in
front
of
it,
and
that
already
helps
because
at
least
I
know
this
get
comes
from
this
service
at
least
otherwise.
D
It's
just
there's
nothing,
and
in
dynatrace,
for
example,
we
had
we
had
the
posts
in
the
span,
there's
a
http
post
and
then
below.
We
have
this
little
hint
or
like
a
subtitle
with
the
service
name,
the
same
thing
so,
like
I
think,
last
time
last
week
we
discussed
this
as
well.
Is
that
x
exactly
yeah
exactly
yeah
so
last
time?
D
What
we
discussed
is
that,
for
example,
what
it
could
be
done,
but
then
I
also
discussed
with
arming
as
well
is
that,
for
example,
what
we
could
maybe
even
drive
in
this
spec
is
that,
for
example,
if,
for
example,
if
it's
an
http
call
like
a
http
client
call,
then
you
use
this
generic
thing.
Http
getpost,
but
the
spec
could
say
like
visualization
systems.
D
If
it's
http
client
spend,
then
you
also
put
this
other
field
below
yeah
and,
for
example,
if
it's
a
messaging
system,
it's
a
messaging
span.
Then
you
you
have
this
spanning,
which
is
will
be
like
I
don't
know,
m2p
send,
but
then
you
can
also
display
the
the
the
destination
below
then
even
the
even
that's
that's
low
cardinality
for
at
least
for
me
visualizing.
The
trace
is
already
useful
because
I
know
the
destination.
D
For
example,
it
doesn't
help
with
the
indexing
and
like
extracting
metrics
out
of
it,
because
it's
just
another
field,
but
it's
something
also
that
we
could
think
about
as
well.
B
B
The
best
visualization
someone
can
think
of,
but
but
yeah
when
visualizing
this
stuff,
you
wanna,
really
leverage
all
of
the
information
there
so
you'll
see.
Some
systems,
for
example,
also
will
will
come
up
with
like
different
colors
or
like
different
icons
to
represent.
B
Is
this
like
a
database
request
or
something
right
yes
or
like
if
they
know
whether
it's
rabbit
mq
versus
amqp?
You
know
they'll
they'll
use
like
the
logo
of
the
thing
right.
There's
like
lots
of
stuff
you
can
do.
You
can
also
like
build
better
indexes
like,
for
example,
by
default,
combining
the
http
you
know,
operation
name
with
the
the
server
name,
for
example,
might.
C
B
The
main
thing
we're
thinking
about
when
we're
we're
creating
these
is
to
provide
as
much
information
as
possible
without
well
just
trying
to
avoid
accidentally
overloading
systems
by
having
too
many
logs
too
many
spans
too
much
high
cardinality.
B
You
know
too
many
attributes
right,
like
you
know,
here's
a
hundred
attributes
that
might
be
useful
like
we
just
because
they
turn
it
all
on
by
default
and
actually
customizing
instrumentation
is
ridiculous.
Anytime,
there's
like
we,
we
hit
a
wall
and
someone's
like
well,
we'll
just
make
it
an
option.
It's
like
we
just
said
it's
useless,
because
you're
not
going
to
go
in
and
customize
instrumentation
for
every
thing
in
some
gigantic
distributed
system.
B
So
so
it's
just
it's
like
a
bit
of
an
art,
and
this
is
also
why
we
may
come
back
in
the
future
and
improve
some
of
these
things,
and
that's
why
we
have
this
schema
translation
system
that's
being
built
in
for
the
collector.
So
if
it
is
the
case
that
we
come
up
with
like
say
a
better
operation
name
for
some
of
this
stuff,
you
would
have
a
way,
maybe
of
being
able
to
to
reconstruct
the
old
right
old
operation.
D
B
If
it
potentially
was
breaking
dashboards
for
you
to
to
upgrade
to
the
latest
version
right,
I
don't.
B
Gonna
get
it
all
correct
all
at
once,
because
I
suspect
some
some
of
this
information
about
what's
what's
ideal,
is
going
to
come
from
using
these
tools
in
anger.
Right
like
yes
exactly
you
know
it's
just
it's
it's
just
a
little
hard
to
tell
like.
What's
what
you
wish
you
had
until
you're
you're
in
the
fire
fight
and
you
you
don't
have
it
so
it's
a
pain,
driven
observability!
B
But
I
think
we
can
make
make
good
guesses
and
I
think
a
good
rule
of
thumb
is
if
information
is,
is
application
specific?
Then
you
definitely
want
to
include
it
right.
So,
like
topic
names
like
if
those
are
like
actually
like
names,
that
the
application
is
giving
to
these
things,
that's
gold
that
is
like
pure
gold,
and
you
want
that
that
information
in
your
index.
B
If
it's
auto
generated
stuff,
then
it
starts
to
get
a
little
specific,
a
little
suspicious.
Unless
it's
like
something
auto-generated.
B
You
know
it's
definitely
true
that
you
may
find
correlations
between
slowness
and
like
a
particular
ip
address,
but
it's
better
for
that
to
be
like
recorded
as
ip
address
and
for
your
analysis
tool
to
to
run
a
correlation
across
like
ip
addresses
to
see
if
you
know
like,
but
that
wouldn't
be
a
great
primary
index
right,
because
ip
addresses
are
gonna,
are
gonna
change
and
swap
out.
B
B
C
Yeah
we
are
slightly
over
time,
so
I
will
try
until
next
week
to
just
extend
the
old
depth
by
some
like
draft
text
or
for
the
talk
today
about
this
plan.
Maybe
we
can
revisit
it
next
time
or
you
can
add
some
comments.
Remarks
like
during
the
week
once
I
edit
that
and
then
yeah.
C
Let's
continue
next
week,
where
we
left
off,
maybe
talking
more
about
the
span
name
and
also
has
to
end
say:
let's
try
to
get
talk,
also
about
the
difference
between
messaging
system
and
messaging
protocol,
because
he
had
some
questions
or
thoughts
there.
So
thanks
everybody
for
today
it
was
a
good
discussion.