►
From YouTube: 2020-05-22 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
B
B
B
C
Money,
but
that's
for
me
is
very
clear:
you
don't
want
to
ship
any
random
thing
in
the
main
package,
I
mean
you
have
to
to
limit
the
amount
of
code
in
the
main
package
is
correct.
It's
like
you,
don't
bring
the
season
to
too
many
things.
It's
just
a
matter
of
encapsulation
in
as
small
artifacts
as
possible
to
not
like
why
why,
if
I,
don't
use
something
want
to
include
it
in
my
jar,
okay,.
B
C
We
can
rename
that
the
other
thing
is
who
is
responsible
by
the
fact
that
is
in
the
main
rebel.
The
main
maintenance
of
the
wrap
off
applies
to
that
thing.
I
mean
the
maintainer
x'
and
approvers
applies
to
that
thing
to
that
directory
as
well.
So
indeed,
the
the
people
who
are
maintaining
the
API
are
maintaining
this
package
as
well.
Yeah.
C
B
That
most
probably
you're,
right
and
correct
my
perspective
right
now
is
that
of
you
contributor
and
when
I
check
out
the
repo
I
see
API
and
country
I,
don't
know,
what's
the
difference,
if
we
put
it
down,
we
write,
but
this
means
blah
blah
blah
blah.
Would
you
judge
it
just
said
like
like
it
two
sentences?
That
would
be
my
marshal
help
perfect.
D
C
C
E
D
F
C
D
Yes,
you
could
have
both
published
in
a
single
one,
but
then
you're
gonna
have
classes
that,
if
you're
using
as
library,
instrumentation
you're
going
to
have
classes
in
the
auto
instrumentation
site
that
you
never
need
and
just
extra
classes
and
same
thing,
vice
versa.
If
you
have
the,
if
you're
using
the
automatic
instrumentation
you're
likely
going
to
have
extraneous
classes
from
the
manual
instrumentation,
it.
C
B
C
B
D
Also,
the
question
of
dependency
is
like.
That
was
a
good
point.
The
other
thing
is
I
like
the
separation,
because
it
makes
it
clear
what
is
expected
to
work
where
so,
for
example,
there's
some
instrumentation
that
will
only
work
with
automatic
instrumentation
like,
for
example,
executor,
I,
don't
know,
and
if
you
see
those
published
all
to
the
same
place
in
you
see.
Oh
there's
executor,
instrumentation,
instrumentation
and
and
I
expect
to
be
able
to
use
that
as
manual
instrumentation.
That's
going
to
be
very
confusing.
Okay
make
sense.
Does.
D
C
D
C
B
D
My
thought
on
it
is
is
as
a
vendor,
for
example,
there's
this
whole
corpus
of
instrumentation
and
I,
so
so,
for
example,
for
me,
I
might
want
to
slowly
migrate
by
taking
one
artifact
at
a
time
in
migrated
individual
pieces.
Also,
there
might
be
some
differences
with
how
the
communities
have
builds
their
instrumentation.
That
doesn't
agree
with
how
I
want
to
build
it.
Yeah.
D
Those
are
I
think
this
is
mainly
for
for
Bogdan.
Those
are
I
think,
primarily
the
the
main
use
cases
that
I
can
think
of.
Why
I
want
it
separately
and
then
because
then
those
can
be
managed
to
simple
dependencies
and
not
have
to
get
into
like
removing
individual
class
files
out
in
in
a
more
ugly
fashion
and.
B
E
D
C
B
We
have
several
initiatives,
both
in
spec,
auto
Java
and
Java
instrumentation
about
those
tight
expands
or
Symantec
convention
based
Spanx.
So
if
we,
if
we
know
that
this
is
HTTP-
and
we
already
know
which
attribute
which
type
it
should
have
and
so
I
I
have
I
have
seen
a
lot
of
pull
requests
and
tasks
about
that
inspect
in
Auto,
Java,
repo
and
out
instrumentation
repo,
but
all
of
them
are
somewhere
in
unfinished.
C
Yeah,
so
personally,
this
is
another
example
of
an
artifact
that
I
will
put
in
extra,
so
I
mean
extra,
we're
in
the
I
think
in
the
corridor.
We
can
have
it
in
the
coral
in
the
extra,
because
it's
something
that
not
only
our
instrumentation
can
use
other
instrumentation
can
use
the
same
thing.
So
so
my
idea
of
of
this
kind
of
artifact
does
get
published
when
you
thought
yeah.
B
C
As
I
said,
I
think
is
not.
This
is
not
an
instrumentation
per
se.
It's
a
helper
think
on
top
of
it.
So
all
these
kind
of
things
we
can
absorb
them
in
the
main
main
wrapper,
because
that
means
people
don't
necessarily
have
to
use
any
anything
in
the
about
instrumentation
or
instrumentation
report
can
use
directly.
These
things.
C
A
C
C
By
the
way,
the
thing
about
the
money
is
it
do
we
need
okay,
an
example:
how
do
you
what
what
things
will
be
outer
journey?
Another
possibility
Giovanni
yeah?
Can
we
can
we
start
to
help
these
guys?
Can
we
start
having
them
manually
generated
the
way
how
they
will
become
automatic
generated
for
Topalov?
Yes,.
A
C
I
think
we
should
reopen
that
we
should
put
it
in
the
next
try
to
unblock
these
guys
because,
as
we
discuss,
if
we
break
things
it's
fine,
we
can
it
yeah.
It
doesn't
matter
too
much,
but
at
least
they
they
are
unblocked.
They
start
using
defined,
probably
problems
with
with
the
way
how
we
define
them,
and
they
will
say
this
is
not.
Okay,.
A
C
A
C
The
idea
was
like
we
will
define
all
the
semantic
conventions
using
Yama
and
will
define
what
attributes
are
required
for,
for,
let's
say
two
for
a
for
an
HTP
span
or
something
like
that
and
based
on
these
things,
we
can
generate
these
classes
with
with
builders
and
required
arguments,
and
so
on
that
becomes
a
bit
more
easier
on
our
side.
We
just
define
in
one
place,
they
are
multi,
but
what
I
write
is
before
we
have
that
complete
mechanism.
C
B
G
B
C
C
E
G
Now,
in
some
parts
it
might
be
more
defining
it
sort
of
the
name
comes
from
these
labels
or
whatnot
I
was
testing
out
the
the
author
instrumentation
here
on
my
wraps,
and
it
worked
great
that
the
crux
there
was,
if
we
have
a
huge
number
of
different
database
queries.
So
basically,
all
the
spam
names
are
all
like
slicks,
question
mark
question,
mark
question
mark
and
like
different
varieties
of
that.
G
Basically,
so
you
don't
find
anything
and
then
you
see
sort
of
something
named
set
them
get
which
ended
up
being
a
memcache,
but
you
don't
see
that
until
you
sort
of
go
into
the
spam,
so
we've
been
nice
to
sort
of
for
SQL.
Those
can
be
pretty
plentiful,
so
there
might
be
more
like
having
the
core
just
a
label
and
just
say
SQL
prepared
statement
or
an
SLS
execute
I.
Think
the
open
telemetry
for
scale
did
SQL,
execute
your
query,
for
example,
so
you
reduce
the
naming
cardinality
of
that
and
for
something
like
the
memcache.
G
B
G
No
suggestion
I
had
early
on
was
that
sorry
in
so
that
we
allowed
like
moustache
pattern,
basically
as
the
span
name,
so
that
the
collector
would
just
build
it
automatically.
You
could
you
say,
like
curly,
braces
or
something
used
as
label
for
for
naming
your
column
path.
For
example,
if
you
have
AC
people
would
be
something
that
would
allow
us
to
just
define
this
fairly
generically,
and
then
it
gets
filled
by
all
collectors.
Basically,
that
way
or.
C
To
remember
where
it
is
I
will
find
it
Stefan,
it's
good.
If
you
can
comment
this
suggestion
or
maybe
file
an
issue
and
I
will
find
after
that,
I
think
this
suggestion
of
not
using
select
question
question
use
other
names,
it's
a
better
the
thing
to
do
as
a
default,
at
least
in
terms
of
the
other
approach
of
allowing
some
kind
of
exporter
or
something
that
changes
the
name,
as
you
suggested
to
say,
he
grabbed
the
name
from
this
attribute
instead
of
the
default
name
that
was
given
I
think
it's
also
reasonable.
G
Well,
as
part,
it's
in
part
talking
about
this
and
then
in
part
talking
about
the
other
part
of
cardinality
I
would
note
this
making
spans
behave
a
little
bit
closer
to
metrics,
which
I
think
would
allow
an
easier
sort
of
let's.
Let's
have
a
metric
that
comes
out
from
a
span
basically,
and
you
only
define
one
or
one
of
them
have
some
comments
and
ideas
that.
G
D
So
this
grouping
key
that
you
just
mentioned
I
think
sounds
a
lot
like
a
notion
that
we
have
in
data
dog
that
we
actually
used
a
very
low
cardinality
key.
That
denotes
whether
it's
like
a
web
request,
a
background.
Ja
a
client
request
stuff
like
that,
so
it
it
kind
of
gives
a
little
bit
semantics
around
what
the
span
actually
represents.
Yeah.
D
B
B
D
Tracing
that's
what
we
actually
denoted
as
the
operation
name.
We
used
operation
even
as
the
super
low
cardinality
thing,
and
then
we
had
a
separate
tag
that
was
more
like
what
everyone
else
was
using
as
operation
name,
but
we
called
resource
name
and-
and
this
had
this
separation,
which
I
think
makes
a
lot
of
sense
because
you
have
this
like
hey.
This
is
what
is
going
on,
and
this
is
some
more
descriptive
information
that
has
a
little
bit
less
cardinality
restrictions.
B
D
A
B
We
decide
to
remove
it,
but
you
don't
you
don't
want
to
group
by
that
HTTP
GET.
You
want
to
group
on
the
list,
for
example,
or
item
list,
that
the
operations
that
you
want
to
group
that
the
duration
that
you
in
which
like,
for
example,
agencies
are
making
sense,
doesn't
make
it
doesn't
make
sense
to
aggregate
latencies
or
or
all
HTTP
GET
request
to
my
service
does
make
sense
to
aggregate
latency
over,
like
all
when
I
released
item
list.
So
and
that's
for
me,
it's
bad
name
over
which
you
aggregate
your
group,
etc,
etc,
etc.
D
To
me
that
sounds
like
something
that
would
work
well
in
in
practice
in
a
very
customized
instrumentation
world,
where
customers
or
users
are
the
ones
writing
their
instrumentation
and
in
charge
of
that.
But
I,
don't
know
how
that
would
map
to
a
concept
of
you
know
a
Javad
agent,
for
example,
providing
automatic
instrumentation
and
here
you're.
B
G
And
it
depends
on
sort
of
the
capabilities
of
storage
and
and
and
and
uy4
it.
But
if
you
consider
a
metric
for
HTTP
requests,
you
would
have
HTTP
sort
of
total
time
or
buckets
or
whatever
you
might
have.
Then
you
have
labels,
that
is
the
path
etc.
Whereas
here
we
turned
a
little
bit
around
words
of
the
metric
name
like
the
spam
name,
if
you
think
of
it
as
a
symmetric,
we
basically
have
the
the
name
of
the
metric
contain
the
path
instead
of
just
being
a
label
to
it.
So
what.
D
Clear
III
think
that
adding
that
complexity
is
a
little
bit
too
much,
for
example,
things
like
Zipkin
they're
there
or
like
Jaeger
landing
there.
They
probably
don't
need
that
concept.
It
mainly
is
useful,
I
think
in
in
more
complicated
use
cases
where
you
make
it
you're
generating
metrics
you're
you're
displaying
a
whole
sorts
of
spans
with
a
lot
of
different
UI
options.
D
So,
to
my
point,
I
think
that
the
better
way
to
handle
that
would
be
to
maybe
have
a
specific
attribute
that
can
be
visible
to
those
it
can
you
Jaeger
whatever
custom
client,
but
not
a
required
attribute.
All
of
the
automatic
instrumentation
will
obviously
like
maybe
utilize
that
attribute,
but
it's
more
of,
like
a
graceful
enhancement,
kind
of
situation
to.
C
D
So
to
be
clear,
like
I'm,
coming
at
this
from
the
the
the
way
that
data
dog
has
this
concept:
I,
don't
I
I,
actually
haven't
really
read
through
this
RFC,
so
I
don't
know
what
their
intent
is
with
it,
but
do
it.
So
maybe
somebody
is
more
familiar
with
this.
Rfc
would
be
a
better
one
to
speak
first,
which.
D
B
B
Two
attributes
one
is
grouping
and
one
is
display
exactly
what
just
bogan
said.
Other
people
like
me
wants
to
have
only
one
attribute,
the
name
and
UI
if
they
want
to
augment
and
make
better
UI
and
can
use
all
other
attributes
to
to
their
liking.
For
example,
already
a
lot
of
UI
display
HTTP
status
code
in
span
name,
which
is
certainly.
D
Not
a
name
like
a
way
of
you
know
having
something
that
you
can
generate
a
metric
off
of
that's
low
cardinality,
but
having
a
separate
thing,
that's
easily
displayable
that
has
more
meaning,
yes
things.
So,
for
example,
with
like
a
sequel,
query,
sequel,
query:
it's
hard
to
get
something
meaningful
to
the
user;
yeah
low
cardinality
without
like
parsing
the
query
and
like
doing
all
sorts
of
quantization
with
it
and
like
dealing
with
that
right
I
mean
you
can
say,
sequel,
dot,
select.
D
C
See
more
like
that,
yeah
I
I
think
to
simplify
our
life
so
Tyler.
There
is
also
this
zip
King
has
this
requirement
because
you
use
the
span
name
not
only
for
matrix
the
the
some
of
the
backends
like
zip
in
other
to
use
the
spanning
for
building
index
hit
and
their
back-end
does
not
scale
very
well.
I'm,
not
gonna,
go
and
fix
that
so
the
environment
to
have
it
low
cardinality,
because
they
they
use
that
as
a
primary
key
in
some
of
the
indexes.
A
C
C
G
Might
be
a
sort
of
mathematics,
defining
sort
of
almost
have
a
label
of
here.
Here
is
a
user
from
the
name
as
labeled,
and
then
we
have
a
method
like
the
way
I'm
coming
out
this
from
Mike
I'm,
not
the
Ben,
Durham
or
the
user
side
of
this
is
I
would
be
interested
as
a
developer
or
even
if
we
were
implementing
what
instrumentation
is
insert
to
span
here.
That's
measuring
the
time
around
that
so
that
code,
part
and
I
can
easily
generate
the
metric
for
it.
G
I
can
have
a
bunch
of
labels
in
the
span
and
we
can
have
a
way
to
define
like
okay
for
for
a
span.
I
will
have
10
labels,
let's
say,
but
when
I
generate
the
metric,
forts
I'm
just
interested
in
these
fives
to
keep
sort
of
the
cardinality
reasonable,
and
it
could
then
tail
in
back
into
logging.
It's
like
okay,
yeah
I
want
the
book
automatically
generated
for
something
from
here
and
for
that
load
line.
D
Going
back
to
my
comment
about
the
having
a
default,
a
required
field
in
the
attribute
I
feel
like
it's
really
late
in
the
project,
to
be
adding
like
a
second
required
argument
of
parameter,
so
I
feel
like
having
just
a
single
one.
Continuing
what
we're
doing
right
now
is
probably
the
right
approach
and
have
that
beat
the
the
low
cardinality
thing.
The
thing
that
we
can
guarantee
is
low,
cardinality
and
then
for
things
that
we
aren't
sure
like
this
addition
like
without
the
required
melody
restriction.
D
B
C
Your
point
that
we
may
duplicate
the
the
reason
why
you
want
to
have
a
one
for
everyone,
like
description,
is
to
simplify
on
the
on
the
consuming
side,
to
simplify
the
life
and
not
having
to
look
for
ten
or
twenty
different
possibilities
that
may
be,
maybe
in
the
span
I'm
not
but
I'm.
Just
explaining
why
I
think
Tyler
is
suggesting
having
something
like
that
it
simplifies
on
the
consequence.
You
always
look
for
description.
You.
D
Have
three
no
I
I
agree:
Nikita
like
front
from
a
agent
developer
like
from
the
instrument
or
side
of
things,
it's
much
better
to
have
things
collected
in
a
very
semantic
way
like
keep
everything
separate
and
and
don't
like
munch
everything
together,
but
I
feel
like
you
can
take
those
pieces
that
are
separate
and
then
utilize
them
in
a
very
useful
way.
B
D
C
D
Yeah,
if
I
can
brings
up
an
interesting
question,
I've
actually
battled
a
lot.
A
data
dog
is
trying
to
figure
out
a
good
way
to
us
to
visualize
a
case
where
you
have,
for
example,
a
servlet
applica.
Let's
say
you've
got
Tomcat,
you've
got
a
servlet
API
and
then
you've
got
spring
in
theory.
You
could
have
spans
at
each
of
those
layers.
You
could
have
Tomcat
showing
the
whole
request.
D
You
can
have
just
the
servlet
portion
and
then
you
could
even
have
like
this
bring
a
separate
span
for
the
spirit
each
of
those
are
going
to
have
different
layers
and
levels
of
information.
So
at
the
Tomcat
level,
the
the
low
cardinality
thing
that
you
have
is
really
just
like
the
the
verb
and
probably
the
response
code.
I,
don't
know
you
you,
you.
B
Want
to
take
a
look
at
my
today's
pool
request
because
it
concerns
exactly
this.
You
used
it.
It
explains
how
our
instrumentation
currently
handles
exactly
the
situation.
Essentially,
what
we
do
is
we
by
default.
We
create
spam
on
Tomcat
layer
11
on
the
entry
point
we
create
spam
on
the
spring
MVC
layer
level
and
then
spring
can
be
see,
updates
the
parent
spawn
name
to
go
through.
D
The
route
the
problem
with
that
is,
how
do
you
know
how
to
get
to
that
Tomcats
Pam
I
mean
all
you
have
is
the
looking
it
up
as
a
survey
attribute
right,
but
yeah
I
mean
things
like,
for
example,
with
jax-rs
annotations.
You
don't
have
access
to
that.
You
don't
have
access
to
the
request.
If
you're
looking
at
just
the
annotation
level,
you
only
have
access
to
you
know
the
current
scope.
D
G
It's
something
we're
hitting
like
we're
having
sort
of
surveyed
engine
and
then
jax-rs
underneath
and
it's
kind
of
nice
when
you
can
get
both
spans
support
with
the
open
tracing
country
of
its
move.
The
threaded
thing
that
doesn't
close
to
span
correctly
when
you
have
to
have
that
combination.
Basically,
you
have
to
filter
out.
D
D
The
route
correct
servlet
only
has
like
the
the
servlet
specification
gives
you
the
the
servlet
path,
which
is
not
always
very
useful.
Okay
and
then
all
you
have
is
the
URL
servlet.
You
have
servlet
path,
but
in
a
lot
of
frameworks,
that's
not
yet
very
useful.
If
there's
a
another
routing
mechanism
like
with
spring
so
spring
has
its
own
routing
stuff,
which
is
yet
a
third
layer.
Mm-Hmm.
C
C
B
D
That's
what
we
have
to
do:
an
auto
instrumentation!
That's
not
going
to
be
ideal
for
someone
like
manual
instrumentation
with
manual
instrumentation,
you
you're,
relying
on
the
fact
that
somebody
has
to
add
the
the
library,
the
instrumentation
library
in
many
different
places
and
then
you're,
relying
on
the
fact
that
they're
all
working
together
well.
B
C
G
C
That's
another
good
argument
that
I'm
I
heard
during
this
discussion:
I
heard
things
like
sequel,
dot,
select,
I,
heard
things
like
Tomcat
that
HTTP
that
I
think
it's
just
enough.
Tomcat
that
get
or
anyway
you
can
call
it
tonka
that
HDB
get.
I
heard
kind
of
people
would
like
to
see
this
this
product
name
or
something
in
the
span
kind
of
what
what
open
tracing
had
called
component
or
world
or
I
think
Giovanni.
You
also
added
this
notion
of
database
name
or
something
like
that
for
databases.
C
G
G
G
H
G
B
But
again,
spec
this
big
differ
different
shape.
We
have
service,
pants
and
client
spot
GB
queries
a
client
spots,
there's
certainly
other
beast
one
server
spots
and
they
fall
for
clients
pants
even
for
HTTP
client
I
can
I
use
the
whole
URL
as
a
bad
name.
Exactly
the
same
way.
I
cannot
use
the
whole
SQL
with
parameter
such
as
a
span
name.
I
have
to
normalize
that
somehow,
like
get
domain,
select
h2
base
or
something
like
that
for
clients,
path
for
sure
response.
We
usually
have
that
route,
for
example
ODB
table
name.
B
D
And
my
suggestion
is
that
we
don't
have
spans
interacting
with
other.
We
don't
have
instrumentation
interacting
with
a
span
of
unknown
origin,
but
if
we
want
to
collect
things
like
a
route
for
example,
you
should
have
a
expand
that
denotes
that
the
rap
handling
so,
for
example,
a
controller
or
a
or
something
like
that.
But
that
span
would
be
a
child
of
the
parent
span,
which
is
the
the
server
stop
start
and
stop.
Timing.
D
F
C
The
trace
name.
Imagine,
for
example,
you
are
not
at
front-end
with
this.
With
this
scenario,
you
are
not
a
front-end.
There
is
another
front-end
that
I
don't
know
it's
a
load
balancer
which
has
another
span,
though
the
trees
thing
that
you
are
mentioning
is
probably
that
one,
not
not
any
of
these
things
in
the
end,
it
might
actually
be.
C
Back
yeah,
we
can
even
be
there
like
you,
don't
know
at
any
moment.
If
you
are
the
root
span
or
not.
Now
there
is
a
good
question,
and,
and
now
in
now
to
be
honest,
for
example,
what
I'm
hearing
is
from?
Let's
put
this
the
other
way
from
Tomcat
perspective.
Am
I
really
interesting
to
see
matrix
from
Tomcat
HTTP
start?
Probably
not
I
can
explain
why,
because
Tomcat
is
going
to
be
almost
the
same
is
going
to
be
do
almost
the
same
work
just
a
bunch.
C
It
doesn't
matter
what
route
I
have
here,
so
probably
the
most
interesting
metric
that
I
would
build.
For
me,
my
personal
thing
would
be
actually
Tomcat.
Let
us
see
server
latency
as
one
metric
for
all
the
stands:
I
don't
of
whatever-whatever
Simplot
is
executing
whatever
what
spring
gravity
is
executing
and
the
same
thing
from
from
servlet
to
spring,
because
if
there
is
a
problem,
it
does
not
happen
to
be
only
for
this
specific
wrong
yeah.
C
B
C
That's
a
better
choice.
That's
yeah!
We
just
give
you
as
much
information
as
we
have
without
doing
too
much
magic
and
and
if
somebody
can't
blame
me-
and
we
can
explain
to
them
hey,
why
do
you
need
to
backwards
propagate
that?
It's
for
you,
the
first
two
layers
are
not
doing
anything
specific
by
route.
If
you,
if
you,
if
you
want
to
calculate
the
legacy,
has
these
layers
you
better
do
the
the
latest.
C
D
Not
to
be
clear,
this
is
where
I
think
the
the
identify
the
super
low
cardinality
span,
name.
That
data
dog
uses
is
very
helpful
because
then
we
can
I
didn't
set
the
the
Tomcat
request
from
the
spring
request
and
and
generically
say
hey.
We
want
to
generate
metrics
on
spring
requests
and
yeah.
We
don't
care
about
the
Tomcat
requests
and.
C
That's
why
that's?
Why
that's
why
I
heard
this
idea
and
I
was
mentioning
five
minutes
or
ten
years
ago?
Maybe
this
can
be
a
perfect
like
Tomcat,
that
something's
bringing
that
something
it
may
be
a
not
an
attribute,
but
what
I'm
here
people
are
always
saying
this
is
a
spring
HTTP
request.
This
is
a
this.
Is
a
tomcat
FCP
I'm
hearing
every
one
component
yeah
moving
this.
G
Hearing
yeah
until
your
point,
also,
if
someone
were
to
in
like
if
we
ignore
tracing
all
the
things
like,
if
someone
implemented
metric
or
multiple
metrics,
it
would
be
so
here's
my
metric
coming
out
of
Tomcat
for
a
to
be
a
request.
Here's
my
metric
coming
out
of
spring,
so
you
wouldn't
sort
of
have
those
just
pay
to
be
request.
It
would
be
sort
of
spring
HTTP
requests
or
whatever
they
would
call
it.
The
man
Tomcats
it
simmer.
Yep.
D
The
thing
is
we
already
kind
of
have
a
component
built
in
with
the
named
tracers,
so
I
don't
think
that
we
necessarily
need
to
have
component
as
a
separate
identified
identifiable
unit
yeah.
That
may
be
the
case.
That
may
be
their
answer.
The
thing
that
I'm
suggesting
is
within
a
tracer
within
a
name
tracer.
You
do
want
to
be
able
to
separate
things
like,
for
example,
say
you
have
a
message:
queue
library.
D
You
want
to
be
able
to
identify,
separate
out
the
the
consume
versus
the
produce,
and
so
that's
where
like
Kafka
consumed,
and
then
maybe
the
detail
would
be
the
the
topic
name
not
produced.
The
detail
would
be
the
topic
name,
but
the
span
name
is
still
something
that's
identifying
the
operation,
but
by
the
way
we
also
have
the
Spain
kind
for
the
Kafka.
F
C
G
The
other
part
of
metrics
of
on
the
back
instance
we
allow
sampling
it
wouldn't
be
exact
and
would
be
interesting
from
my
user
perspective,
implementing
things
like
not
using
alter
instrumentation,
but
we
have
serve
our
own
code
where
we
wouldn't
need
to
add
in
our
own
tracing.
Basically,
it
would
be
interesting
to
be
able
to
sort
of
define
a
bits
of
here's.
What
I
would
like
you
to
use
so
do
so.
G
C
Right
now,
by
the
way,
right
now,
you
can
build
your
own
sampler
in
the
library
that
has
access
to
the
attributes
added
during
the
building
time.
So
a
lot
of
this
will
be
added,
so
you
can
build
any
crazy
sampling
mechanism.
You
want,
you
can
say,
I
want
if
you,
if
I,
see
this
argument
and
that
argument
I
want
to
use
these
yeah.
C
Here
here
we
are
talking
about
Becca's
capabilities,
so
from
from
our
perspective
is
more
about.
Do
you
have
the
all
the
informations
as
a
back-end
to
be
able
to
build
this
feature
I'm
not
as
part
of
open
telemetry,
which
we
don't
have
a
background?
Okay,
I'm,
not
gonna
know
what
what
we
need
to
take
care
of
is
that
if
somebody
wants
to
implement
this
feature
on
the
backhand
side
or
even
on
the
our
collector
side,
for
example,
we
have
all
these
informations
yeah.
G
But
I'm
thinking
more
of
as
a
user,
someone
who
implements
using
open,
telemetry,
observability
cameras
or
just
add
one
type
of
thing
and
from
there
get
metrics
logging
and
span
road
and
a
half
Todd.
Okay,
here's
where
we
create
my
spam
and
here's
to
medicate
my
metrics
and
here's.
My
local
I
know
they're
all
separate
they're,
all
using
same
information,
but
I
have
to
sort
of
have
labels
on
my
spam.
G
C
Are
talking
a
completely
different
topic
here
and
we
can
chat
about
that
if
you
want
more
I
think
we
are
out
of
time,
but
let's,
let's
shop
next
week,
maybe
for
20
minutes
at
the
end
of
the
meeting
about
this.
This
problem,
I
think
your
request
is
completely
independent
of
the
discussion.
The
previous
discussion
about
the
span.
G
C
Most
likely
now,
if
that's
not
available,
what
do
I
do
most
likely,
I'm
gonna
back
on
on
using
HTTP,
GET
or
or
any
other
better
things,
because
if
that's
not
available
I,
don't
know
what
the
heck
is.
Gonna
happen
and
I'm.
Definitely
not
gonna
use
HTTP
URL,
because
then
there
does
not
a
metric.
It's
just
an
invalid
HTTP,
URL
being
unique
almost
for
every
request,
based
on
all
the
things
that
are
there.
C
G
C
G
C
Hard
to
know
which
attributes
you
want
to
build
labels,
or
which
not
anyway,
I'm
gonna-
think
about
this
I'm
gonna.
Think
about
this,
because,
ideally
you
probably
want
to
have
a
something
at
the
API
level.
Well
to
say:
I
want
to
build
a
little
distribution
out
of
this
or
not
the
problem.
By
the
way,
the
problem
with
using
attributes
will
be
very
interesting
because,
if
sampling
those
in
place,
all
the
libraries
will
drop
on
the
attribute
and
I
don't
think
that's
easily.
G
Like
we
have
to
figure
like
okay,
do
we
create
a
lightweight
spam
which
is
basically
just
a
metric
it
or
it
might
just
be
hidden
by
to
say,
like
it's,
it's
sort
of
almost
using
alter
generation
like
you
create
your
spam
and
you
say
you
want
to
metric
well,
then
it
will
add
a
metric
behind
the
scenes,
but
you
don't
need
to
add
it
in
your
codebase.
Let
me
find
an
issue.
E
D
G
B
C
C
Discussing
that
part
with,
how
do
we
allow
people
to
configure
the
storage,
and
what
exactly
do
we
allow
people
to
configure?
You
saw
the
discussion
on
the
on
the
Gator
about
that.
I
was
a
little
bit
yeah,
so
I
was
asking
about
what
what
do
we
need
to
configure?
Do
we
want
to
replace
the
entire
story?
G
C
C
Some
object
that
we
are
storing,
based
on
the
key
of
the
the
the
like
usual
instanceid
of
the
spam
processor,
because
we
don't
want
to
allow
people
to
communicate
between
spam
processors
because
of
the
security
like
yeah,
like
concurrency
and
the
synchronization
problems.
So
we
give
you
give
me
an
object
and
when
I
called
you
on
end,
I
give
you
back
that
object.
Yeah.
G
C
G
At
plc,
where
I,
instead
of
having
on
startin
on
end
I,
played
around
with
returning
a
callback
function
for
the
own
end,
which
works
nice
in
other
cases,
it
has
some
allocation
because
you
need
to
keep
track
of
it,
and
downside
is
sort
of
when
you
have
the
async
one
sort
of
obviously
don't
return.
The
own
end
function
until
that
one
gets
executed
so
impaired
basis.
Without
that
test
yeah,
you
cannot.