►
From YouTube: 2021-07-07 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
A
A
A
A
A
A
E
A
B
B
E
A
A
A
A
To
merge
yours,
and
we
should
definitely
list
this
as
as
another
spec
meeting
since
it's
missing.
E
A
You
know
the
main
I
think
debate
that
was
coming
up
or
question
that
was
important
was
around
giving
guidance
to
instrumentation
like
native
instrumentation.
So
third
parties
are
starting
to
natively
instrument.
Their
code,
like
I
think
apache
camel,
was
the
case
in
point,
but
they
were
doing
things
that
were
making
open
telemetry
annoying.
A
You
had
to
like
switch
it
on
basically
like
they
were
kind
of
adding
an
extra
layer
of
configuration,
and
the
way
we
kind
of
designed
open
telemetry
to
work
is
that
you
should,
by
default,
just
like
don't
do
anything
to
enable
or
disable
open
telemetry,
just
like
by
default,
grab
the
global
tracer
provider,
and
if
that
thing
has
been
set
up,
it'll
start
recording
and
if
it
hasn't
been
set
up,
it'll
be
no
ops.
A
So,
there's
no
need
to
add
your
like
own
layer
of
no
ops
or
stuff
like
they
had,
but
you
should
always
provide
the
ability
for
end
users
to
hand
you
a
tracer
provider,
as
configuration
like,
in
other
words,
use
the
globals
by
default,
but
always
allow
the
user
to
to
pass
you
providers
as
configuration
if,
if
they're
not
using
the
global
since
the
community,
you
know
the
the
world
of
software
is
kind
of
divided
on
whether
or
not
globals
are
evil
and
there's
some
cases
where
people
are
running.
Multiple
tracers.
E
E
E
A
D
A
Like
extra
layers
of
indirection
and
make
it
harder
for
the
end
user
to
configure
this
stuff
at
the
end
of
the
day,
right
like
if
they
just
use
open
telemetry,
then
by
default
stuff,
should
work.
If
people
are
running
in
like
the
the
basic
use
case
of
just
installing
a
global
provider,
and
we
want
that
to
be
easy,
while
at
the
same
time.
A
At
the
same
time,
another
thing
that
was
coming
up
was
anthony
from
the
go
sig
the
go.
Maintainer
was
pointing
out
cases
where,
at
least
with
the
tracer,
like
you
can
dynamically
provide
this
stuff
and
for
like
multi-tenancy
situations
and
other
situations
actually
pulling
the
tracer
provider
pulling
the
providers
out
of
the
contacts
like
having
those
things
flow
with
the
transaction
and
just
using
the
provider
that
that
kicked
off
the
transaction
was
another
approach
that
would
maybe
solve
some
issues.
A
They
were
looking
at
with
again
a
third
party
library
instrumenting
themselves,
but
wanting
to
to
dynamically
associate
providers
rather
than
statically
associate
providers
and
that's
not
something
we
had
really
considered
from
our
perspective.
There's
always
this
bit
of
statically
configured
stuff.
E
A
Out
how
to
solve,
but
like
what
I'm
nervous
about
is
this
incremental
approach
of
he
was
just
like,
so
just
just
tack
on
the
ability
to
the
to
get
the
tracer
provider
from
a
span
and
like
that'll,
solve.
D
A
A
problem
right
here
for
now
and
we'll
keep
going,
but
I'm
kind
of
like
I
that
that
actually
like
we're
attacking
on
things
that
are
then
going
to
actually
like
it's
a
fundamental
rearrangement
like
if
that's
someone's
going
to
dynamically.
Do
this,
then
that's
just
going
to
to
spread
then
like
anyone
who's
using
that
thing,
any
other
library
or
code
that
they
touch
also
has
to
do
it.
That
way.
A
So
I
don't
didn't
like
the
idea
of
just
framing
it
as
like,
just
tack
it
on
to
to
solve
some
edge
case
over
here,
because
I
think
it's
it's
like
something
more
fundamental
than
that,
and
we
should
address
it
as
like
something
that's
major
and
important,
because
it,
it
seems
like
actually
going
back
to
the
drawing
board
a
little
bit.
If
we're
saying
like
all
of
this
stuff
is
dynamically
allocated
and.
A
So,
like
I'm
like,
I
feel
like
we
need
to
like
parse
these
issues
out
and
and
solve
them
solve
them
separately,
but
anyways.
The
thing
he
was
bringing
it
up
is
like.
If
this
all
happens
dynamically,
then
the
the
libraries
don't
have
to
deal
with
any
configuration
at
all
like
it
gets
configured
like
upstream
for
them,
which,
which
makes
sense,
but
oh,
hey
and
anthony
just
joined
the
call.
A
Speaking
of
the
devil,
hello
hi,
we
were
just
reviewing
this
morning
discussion.
I
was
catching
honorary
up
on
issues
with
configuring
configuration
for
third-party
software,
both
the
issue
of
like
providing
people
guidance
and
then
bringing
up
your
issues
around
dynamic
versus
static
configuration.
B
I
shared
a
link
and
I
I
agree
with
what
ted
mentioned
so
in
open
senses.
I
I
was
the
open
census,
python
maintainer.
At
that
time
I
figured
one
thing
we
did
wrong.
Probably
was
the
context
tracer
and
I
shared
the
link
here.
If
you
look
at
the
context,
tracer
it's
very
similar
to
what
I
got
from
ted
like
earlier
in
this
meeting.
So
the
the
tracer
in
open
senses
is,
is
the
one
that
owns
the
exporter
and
processor
in
open
sources,
and
we
allow
tracer
to
be
part
of
the
contacts.
B
D
Yeah
yeah,
I
expect
it's
going
to
be
a
trade-off
right.
It's
going
to
solve
some
problems
and
it
it
may
introduce
others.
One
of
the
things
I
kind
of
liked
about
the
approach
that
we
took
by
tying
it
to
the
span
rather
than
just
having
the
tracer
floating
in
the
context,
is
that
at
least
the
tracer
can't
get
out
of
sync
with
the
spans
that
created
it
right.
D
D
Spanner
yeah
it
it,
it
is
it's
it's
operating
under
the
assumption
that
the
thing
that's
going
to
be
creating
the
first
vein
in
the
process
is
configured
explicitly
with
a
tracer
provider,
whether
that's
an
http
handler
or
an
rpc
handler,
or
something
right,
and
then
client
libraries
that
may
be
nested
fairly
deep
in
and
in
call
stack
might
be
constructed
without
knowledge
of
the
tracer
provider.
And
thus
they
say:
hey.
Is
there
a
spam
in
the
context?
B
Yeah
and
when
we
mention
like
the
multi-tenancy
problem,
probably
it's
a
dumb
question
on
my
side,
but
I
want
to
clarify
what
type
of
multi
tendency
are
we
talking
about
because
we
we
talked
about
a
similar
term
in
the
matrix
part
and
and
not
not.
To
my
surprise,
I
ask
many
folks
and
each
one
is
giving
their
own
definition
of
multi-tenancy
and-
and
they
were
talking
about
many
different
things,
I'll
just
give
two
things
for
for
you
to
have
a
bad
idea
like
for
bigger
companies.
I
talked
with
aws,
google
and
microsoft.
B
They
have
when
they
look
at
multi-tenancy.
The
the
major
scenario
they
have
is
hey
you're,
running
a
service
and
that
service
is
a
high-density
service.
That
means
your
cloud
provider.
You
have
something
like
a
storage
blob
or
like
lambda
or
something,
and
that
nothing
is
consumed
by
by
thousands
of
customers
on
a
single
node.
So
imagine
you
have
a
dynamodb
that
dynamodb
instance
running.
You
will
have
a
thousand
customer
reaching
to
you
and
for
each
customer's
request.
You
want
to
send
the
telemetry
to
that
customer's
place.
B
This
is
what
they
call
multi-tenancy,
but
for
smaller
companies.
Normally,
what
they
have
is
inside
one
application.
They
have
different
components
running
and
for
some
of
the
data
the
company
running
this
infrastructure.
They
want
to
say
I
want
to
collect
the
telemetry,
send
back
to
my
place.
Well,
the
customer
hosting
application.
They
might
say
I
have
specific
metrics.
I
don't
want
to
send
to
that
company.
I
want
to
send
to
my
place
in
this.
In
this
case.
It's
a
low
density
scenario.
B
You
probably
have
10
tenants,
20
tenants,
but
for
the
cloud
providers
they're
talking
about
thousands
of
tenants
and
and
when
you
think
about
for
each
tenant,
you
have
one
explorer.
If
you
look
for
high
density,
this
is
a
show
stopper.
So
I'm
I'm
not
sure.
If
here
we're
even
talking
about
one
of
the
multi-tenancy
scenario
I
mentioned
and
and
that
term
is
very
vague,.
D
Not
necessarily
a
super
high
density
number
of
tenants
and
potentially
a
varying
number
right.
This
gets
the
the
dynamic
versus
static
configuration
piece
that
I
think
ted
was
alluding
to
earlier
as
well.
One
of
the
things
that
buildkit
was
doing
was
using
a
a
trace
pipeline
that
they
construct
inside
of
a
docker
container,
that's
being
built
to
push
the
telemetry
back
up
to
the
place
it
originated,
and
I
think
that
that
may
be
happening
inside
of
an
application.
D
You
know
the
the
build
the
or
look
at
the
service
that's
running,
so
it
may
need
to
create
multiple
of
these
for
each
of
the
the
containers
that
it's
building
concurrently
right.
If
it's
building
multiple
concurrent
containers,
so
they
may
be
kind
of
ephemeral,
right,
they're
constructed
they
can
hand
it
back
to
the
calling
process
that
created
it
so
that
it's
able
to
tie
it
all
together.
B
I'm
curious
in
this
case,
if
you
have
like
a
multiple
tenants
and
do
you
have
a
the
requirement,
you
want
to
send
this
thing
on
the
same
otlp
stream
or
you
think
they
should
be
totally
separate.
You
want
to
provide
physical
isolation
because
otlp
today
we're
not
even
trying
to
explore
the
tendency
issue
and
when
the
tendency
comes
there,
there
has
been
question
about.
Hey,
should
otlp
support
multi-tenancy,
so
I
have.
D
Yeah
and
I
think
that's
for
the
the
operators
of
the
services
to
decide-
I
don't
know
if
that's
something
tlp
should
get
into
like
in
the
high
density
multi-tenancy
scenario,
the
cloud
provider
scenario
that
you
described
earlier,
that's
how
I
would
think
about
it
too.
Right
have
the
process.
That's
got
high
density
multi-tenancy
put
an
attribute
in
the
metrics
that
goes
down
to
a
collector
that
can
then
out
of
the
hot
path
demux
into
wherever
it
ends
up
going.
That
also
keeps
all
of
the
information
about.
D
B
D
B
Yeah
yeah,
okay,
I
hear
you
so
so
ted.
This
is
something
I
I've
seen
like
in
microsoft.
We
learned
lesson
from
that.
So
we
start
with
a
low
density
scenario
and
eventually
people
will
have
the
business
demand.
They
start
to
have
a
50
tenants.
Should
I
use
this
and
I
have
a
hundred
and
eventually
they
they
use
the
the
thing
that
was
not
designed
for
the
high
density
scenario,
and
then
we
got
all
kind
of
issue.
Connection
management
like
throttling
yeah,
balancing.
A
Yeah
yeah
exactly,
I
think
it's
helpful
to
even
if
we
don't
solve
all
of
these
problems
today,
certainly
demarcating
the
difference
between
them
would
be
really
helpful.
There's,
for
example,
anthony.
I
would
actually
love
if
you
could
write
up
the
the
specific
thing
you're
you're
trying
to
solve,
because
I
know
you
have
like
a
specific
use
case
like
there's
like
a
framework
and
go
right.
That's
doing
wants
to
do
some
amount
of
dynamic
stuff.
Is
that
correct.
D
Yeah,
actually
probably
be
great
if,
if
I
could
get
tunis
from
buildkit
to
come
and
talk
to
us
at
some
point
about.
D
Done
that
might
be
helpful,
because
he's
definitely
got
a
much
deeper
knowledge
of
what
it
is
they're
doing
and
how
they
had
done
it
with
open
tracing
and
why
this
was
important
to
them
to
for
their
migration,
to
open
telemetry.
A
A
I
think
riley
went
over
this,
which
is,
I
think
something
nev
has
brought
up
in
when
they're,
adding
open
telemetry
to
teams,
which
is
you
have
some
components
that
are
going
to
be
reporting
to
one
place
and
other
components
that
are
going
to
be
reporting
to
another
place,
but
those
end
up
being
pretty
like
boxed
up
from
each
other,
like
they're,
entirely
different
subsystems
from
beginning
to
end
they're.
Not
it's
not.
In
other
words,
it's
not
dynamic.
A
It's
it's
statically
defined
in
that
case,
but
what
you
need
is
like
genuinely
completely
separate
export
pipelines,
and
so
the
question
I'm
wondering
is
like:
is
there
some
middle
ground
where
you
need
this
like
completely
separate
export
pipelines,
but
it
also
needs
to
be
dynamic,
like
that's
the
because
it
sounds
like
that's
what
the
I
keep
spacing
on
the
name
of
this
this
framework.
But
that
seems
like
what
they're
doing
build
kit
yeah
build
kit.
A
Yeah
that
right,
like
that
seems
like
specifically
what
they're
doing
is,
is
where
people
have
like
multiple,
like
there's
like
a
pile
of
of
totally
separate
export
pipelines,
but
it's
actually
one
system,
that's
juggling
them.
So
it's
multi-tenancy
as
opposed
to
what
ned
was
talking
about
in
teams,
which
was
more
just
like
isolated,
sub
components
or
isolated
processes
with
different
audiences.
D
Yeah,
I
think
the
isolated
sub-processes
story
we've
got
good
support
for
now.
That's
just
the
don't,
don't
use
the
global
tracers,
don't
use
any
global
anything
global
explicitly
provide
and
in
go
we've
tried
to
ensure
that,
like
all
of
our
components,
take
a
tracer
provider
as
an
option,
you
can
configure
it
with
a
tracer
provider.
Explicitly
it's
just
the
question
of
what
do
we
do
when
you
don't
or
can't
explicitly
provide
that
at
construction
time
you
know,
can
you
use
the
global?
A
If
someone
forgets
to
configure
a
certain
thing,
then
that
thing
picks
up
the
global
and
if
the
global
is
being
used
for
something
else,
then
this
data
is
going
to
like
the
wrong
spot,
but
the
flip
side
would
be
like
they
failed
to
configure
the
thing.
A
Therefore,
the
data
is
going
nowhere
and
so
there's
just
like
some
inherent
some
something
inherently
fraught
in.
A
But
then
you
get
into
metrics
and
some
other
cases
where
it
seems
like
there's,
always
some
amount
of
configuration
that
might
need
to
get
handed
around,
and
so
I
don't
know
if
we
can
like
totally
escape
this
problem
by,
like
slight,
like
perhaps
there's
a
way
to
slice
this
stuff
up
under
the
hood,
where
the
things
you
hand
around
is
configuration
to
different
parts
of
the
program.
A
Don't
at
that
static
time
have
a
reference
to
like
the
export
pipeline
or
sdk
that
there
they're,
making
use
of
and
like
that
part
gets
passed
around
elsewhere.
But
I
don't
know
I
just
I
haven't
thought
through
it
very
well.
It
seems
like
actually
getting
the
the
things
the
problems
we
currently
have
and
like
writing
them
out
clearly
would
be
helpful
because
I
feel
like
I
start
trying
to
solve
one
problem
and
then
I'm
noticing
that
some
of
these
solutions
might
help
solve
a
different
problem,
but
maybe
they
don't
fault.
B
Yeah,
it
seems
like
the
team's
situation
from
nav
is
more
about.
You
have
different
components
and
they
can.
They
can
use
different
providers,
whether
it's
tracer
provider,
meter
provider,
whatever
provider
or
anthony.
I,
I
guess.
The
scenario
you
were
looking
for
is
if
you're
you're
the
owner
of
an
application-
and
it
took
some
instrumentation
library,
for
example,
http
client
and
for
all
the
outgoing
http
calls
you're
going
to
use
the
http
client.
B
B
D
So
I
think
that
was
a
large
part
of
the
build
kits.
Concern
was
not
only
do
they
do.
They
have
the
the
latter
concern
of
generic
components
that
are
should
be
stateless
and
should
be
reusable
across
different
pipelines
where
they
have
them,
but
they
also
have
a
lot
of
components
and
they
didn't
have
to
wire
through
a
tracer
provider,
with
open
tracing
that
they
were
using
before
and
having
to
to
go
back
and
do
that
would
significantly
complicate
their
migration
from
open
tracing
to
open,
telemetry
and,
and
so
that
seems
like
it's.
D
A
significant
developer
experience
concern
for
component
authors,
who
are
writing
large
systems.
I
see
sure
it's,
it's
mostly
a
one-time
cost.
You
pay
up
front,
but
it
then
also
adds
overhead
to
every
new
component.
You
want
to
add
as
well.
B
Yeah,
let's
see
so
for
matrix,
I
think
the
challenge
is.
If
we
don't
give
the
multi-tenant
system,
we
are
going
to
put
the
tenant
as
one
extra
dimension
and
then
they're
going
to
do
creative
things
and
later,
even
if
they
introduce
tendency
they're
not
going
to
use
that
or
they're
going
to
miss
you.
That.
D
Yeah
metrics,
I
think
it's
probably
even
more
important
that
we
figure
out
how
to
deal
with
that
upfront,
because
I
I
don't
at
least
with
my
understanding
of
how
you
would
construct
instruments
right
now.
You
construct
instruments
kind
of
once
up
front
when
your
library
is
initialized
and
then,
whatever
your
request
for
every
operation,
you
you,
may
you
modify
them
in
some
way.
D
But
how
would
you
deal
with
the
same
instrument
for
multiple
tenants
unless
it
is
just
adding
an
attribute
right
and
then
perhaps
having
metrics
processors
that
send
those
out
to
different
pipelines?
But
then
you've
got
the
push
versus
pull
question
and
how
to
deal
with
that.
So
I
I
don't
know
what
the
answer
is
there,
but
it
probably
is
a
good
question.
D
B
B
C
One
idea
that
I've
done
in
previous
languages
projects
it
sort
of
goes
back
to
my
I
o
version
of
control
days
with
spring
framework,
one
so
showing
my
age.
If
the
beard
doesn't
do
that
is
effectively
constructing
a
single
single
single
container.
C
So
this
is
probably
part
of
the
convenience
method
stuff
where
we
can
actually
say.
Okay,
we
have
this
single
registry
for
one
of
the
better
name
and
effectively
it's
just
like
a
a
named
center
config,
which
would
include
the
tracer
or
the
metrics,
the
whatever.
And
then,
when
we
go
to
you
know
initialize
some
component,
we
can
say
here's
the
name
of
the
thing
to
go,
fetch
your
your
config
versus.
If
you
know
it
can
then
turn
around
grab
the
default,
potentially
just
an
idea.
A
E
A
One
thing,
I
wonder,
is
like
to
what
degree
for
multi-tenancy
can
this
be
done
under
the
hood,
because
I
I
just
wonder
also
about
I
feel
like
at
the
end
of
the
day,
going
with
a
model
where
something
in
code
on
the
user's
side
is
swapping
around
which
tracer
provider
is
the
way.
It's
done,
oh
see,
honorable,
that
it
kind
of
puts
a
really
heavy
onus
on
the
thing.
A
That's
kicking
off
the
trace
and
because
that's
when
you
start
the
trace
in
your
process
right
the
thing
that
basically
extracts
any
kind
of
upstream
context.
That's
the
place
where
you
you're
forced
to
make
the
decision
and
oftentimes.
A
I
can
imagine,
there's
like
plenty
of
scenarios
where,
like
that
code
wants
to
be
really
dumb
and
generic
and
isn't
necessarily
gonna,
be
the
isn't
necessarily
gonna
know
how
to
switch
things
as
like
the
person.
Writing
that
library,
the
http
client
library
or
whatnot
like
it
feels
like
that
person
is
not
necessarily
the
person
who
would
know
how
to
juggle
this
stuff,
and
so
it
makes
me
wonder
whether
there's
like
some
way
yeah
right.
C
A
It
makes
me
wonder
whether
there's
some
way
to
handle
this
kind
of
dynamic
multi-tenancy
like
under
the
hood
in
some
way,
where
there's
only
one
sdk
in
use.
In
other
words,
this
is
separate
from
the
like
compartmentalized
total
isolation
thing
we're
saying
like
this.
This
is
multi-tenancy,
we're
reusing
the
components
and
is
there
some
way
for
the
sdk
under
the
hood
to
to
be
configurable
like?
A
A
C
Yeah,
where
the
registry
idea
comes
in,
where
that
you
know,
rather
than
passing
in
everything,
it
really
is,
we
could
have
you
know
some
sort
of
naming
convention
where
it
picks
up
their
component,
something
something
or-
and
it
just
falls
back
gracefully
but
yeah.
It's
it's
not
an
easy.
It's
tricky.
A
D
It
does
yeah,
like
I'm
thinking
through
the
go
http
server
component
right,
the
the
wrapper
hand
or
handler
wrapper
that's
responsible
for
constructing
a
new
span
and
doing
the
propagation
and
all
of
that
right.
D
How
would
that
know
which
tracer
provider
to
use,
because
all
of
the
context
is
coming
remotely
there
isn't
an
existing
span
for
it
to
key
off
of
it's,
it's
the
one
that
has
to
make
that
choice.
I
I
think
I
agree
with
nev
that
having
a
registry
of
multiple
tracer
providers
with
their
their
pipelines,
configured
that
could
be
keyed
by
you
know
some
tenant
id
or
something
that
it's
able
to
pull
out
of
the
the
request
would
be
useful.
That
would
then
have
to
be
some
pluggable.
D
You
know
tenant
identifier,
extractor
method
that
could
be
put
in
because
that's
business
logic
that's
going
to
vary
from
component
to
component
or
from
system
to
system,
it's
kind
of
hard
to
make
that
general,
without
knowing
the
business
logic
of
the
system
that
is
being
used
in
a
multi-tenant
manner.
Right
in
one
system
it
may
be
a
part
of
the
request
path
and
another
is
part
of
the
host
name
and
then
another
it's
a
header
or
something
like
that
right.
A
D
So
then
what
would
happen
at
export
time
when,
when
the
span
has
ended
and
it
sent
down
the
pipeline,
some
attribute
of
the
span
would
be
used
to
determine
where
to
go
from
there.
I
mean
I
certainly
could
see
that
working
having
a
span
processor
that
can
be
configured
with
multiple
different
exporters
and
determines
which
way
to
send
it
based
on
a
span
attribute.
A
That
knows
how,
like
let's
say,
we're
just
dealing
with
a
case
where
we
can
get
this
information
at
http
headers
and
that
we're
using
http
like
we're
already
making
a
bunch
of
assumptions.
But
like
let's
assume
you
can
do
that,
then
you
could
have
a
x
a
propagator
right,
like
you
have
like
one
system,
which
is
a
propagator.
A
That
knows
how
to
sniff
for
this
information
and
and
provide
the
tenant
identifier,
and
then
you
have
an
sdk
with
multiple,
with
this
registry
of
pipelines
based
on
a
tenant
id
or
something
like
that.
A
A
And
then
it's
it's
all
kind
of
happening.
If
you
do
it
that
way,
I
guess
what
I'm
saying
is
you
could
hand
that
stuff
to
an
http
client,
the
same
way
we're
currently
handing
it
to
an
http
client
and
it
would
just
work
because
it's
happening
under
the
hood.
The
the
http
client
doesn't
care
in
its
code.
It's
just
the
the
propagator
and
the
sdk
figuring
this
stuff
out
and
then
it's
the
person
who's
like
booting.
The
application
up
who's
writing.
Whatever
customized
logic
needs
to
be
written
in
there
to
like.
A
D
Yeah,
I
think
that
sounds
very
similar
to
what
I
was
thinking
as
well.
You
know
thinking
a
an
option
for
extracting
the
tenant
id
instead
of
a
propagator,
because
I
think
that
the
propagators
api
is
already
fairly
well
focused
on
spam
context
and
baggage.
D
Will
we
really
want
to
stretch
that
concept
to
tenant
identifier,
or
is
that
part
of
baggage?
Is
that
something
we
codify
as
like
a
semantic
invention
for
baggage?
I
don't
know.
A
Yeah,
I
mean
well,
I
guess
like
just
pointing
out,
there's
a
way,
there's
a
way
to
do
this
right
now
that
wouldn't
involve
any
api
changes,
if
you
could,
if
the
way,
if
you
can
do
this
by
yeah
using
baggage.
Essentially,
let's
just
say
it's
like
just
say
this
thing's,
a
form
of
baggage
or
your
pattern
matching
based
on
host
name
or
something
else
you
you
could
do
that
today,
just
by
making
a
tweaked
implementation
of
a
propagator
and
sdk.
A
D
A
This
information
would
then
just
be
if
this
would
yeah
just
be
something
in
the
context
that
floats
along
basically
right
like
it's
something
you
you
have
one
sdk
with
multiple
pipelines.
Basically,
like
you,
have
an
sdk
with
like
a
registry
of
different
export
pipelines
and
one
way
or
another
you're
putting
the
tenant
id
into
the
context.
A
So
when
you
say
start
span,
that
thing
is
like
okay,
I
I
can
see
which
tenant.
I
see
that
there's
a
tenant
id
here
and
I'm
going
to
use
the
pipeline
associated
with
that
tenant,
id
or
dynamically
create
a
new
pipeline
because
it's
a
new
tenant,
but
you
could
do
all
that
by
having
like
an
sdk,
that's
like
a
multi-tenant
sdk,
rather
than
on
the
application
side,
juggling
a
bunch
of
sdks.
A
If
that,
if
that's
right
right,
where
this
all
starts
to
suck
is
like,
when
someone
wants
multi-tenancy
based
off
of
taking
a
database
lookup
right
where
they're
like
first,
I
get
the
request
in
and
then
I
take
some
id
out
of
the
request
and
then
make
a
database
look
up
and
in
that
database
lookup
I
have
account
id
or
whatever
the
heck.
It
is
that
I'm
using
for
my
tenancy.
A
C
Add
metrics
to
that,
where
more
than
one
tenant
wants
to
know
the
fact
that
they've
just
burnt
some
cpu
to
do
that.
Look
up.
A
I
just
wonder
if,
like
we
can
tell
people
it's
like
those
are
your
two
choices
like
you,
either
have
like
fully
compartmentalized
components,
because
that's
what
you're
trying
to
do,
which
is
like
nev's
use
case
and
like
the
multi
multi-processes
within
a
process
use
case
or
you
have
multi-tenancy,
in
which
case
you
have
to
demux,
that
in
a
collector
or
somewhere
later,
when
you
have
like
when
you've
assembled
the
trace
and
there's
like
no
good
way
to
do
it
without
like,
like
maybe
like,
we
just
provide
those
two.
A
D
I
think
that
could
be
viable,
but
to
do
it
we
would
have
to
have
a
good
implementation
in
the
collector
that
we
could
point
people
out
right.
I
think
it's
kind
of
worked
for
exporters
to
be
able
to
say
yeah
th
this.
This
third-party
provider
doesn't
have
an
exporter
in
your
language
but
send
otlp
to
the
collector,
and
you
can
get
it
to
them
there
because
they
have
a
collector
exporter
right.
D
If
the
collector
has
good
support
for
okay,
we'll
take
in
traces
and
here's
a
way
to
decide
which
of
the
the
downstream
pipelines
to
go
to
from
that
point
on,
then
we've
got
a
much
better
story
to
tell
about
why
we
don't
have
the
first
class
support
for
each
language,
doing
it
up
front.
E
D
A
Like,
like,
I
kind
of
almost
want
to
rename
baggage
like
trace
context.
If
that
makes
sense,
I
know
we
can't
use
that
word.
It's
not
right,
but
it's
almost
like.
You
have
span
level
context,
but
there's
also
trace
level
context
which
currently
is
trace
id.
D
Right,
there's
also
a
trace
state,
though,
which
I
was
never
super
clear
on
what
trey
state
was
supposed
to
be
for.
Oh.
A
Yeah
yeah
I
mean
trace
state,
was
a
place
to
put
info
that
that
was
a
place
for
traces
or
implementations
to
put
their
details.
A
So
it's
like
another
form
of
like
if
you
have
multiple
tracers
tracing
implementations
working
in
the
same
trace
so
like
one
example,
might
be
you're
using
light
step
in
your
application,
and
then
you
talk
to
an
amazon
or
microsoft,
hosted
service
and
the
amazon
or
microsoft
hosted
service
is
not
going
to
be
using
white
step.
Obviously,
but
later
you
want
to
assemble
the
traces
and
then
you
may
have
like
say
that
hosted
service
talks
to
yet
a
third
thing
out
there
that's
using
its
own
tracing
system.
A
So
there
we
wanted
a
way
for
there
to
be
more
than
one
there
to
be
a
we
there
needed
to
be
a
place
for
the
tracing
system
to
put
its
specific
configuration
information
which
would
be
like.
A
Like
sampling,
information
or
or
just
whatever
the
heck
it
needs,
some
tracers
need
to
extract
some
extra
information
from
the
headers
in
order
to
function
properly.
That
was
like
an
assumption,
so
that
data
goes
into
trace
data
and
then
because
you
might
have
multiple
tracers
operating
across
on
the
same
trace,
trace
data
is
actually
a
list
of
configurations,
complicated,
weird
and
like
to
some
degree,
not
a
thing
we
have
to
think
about,
except
that
the
open
telemetry
sdk
if
it
wants
to
schlep
along
extra
information.
A
So
it
knows
what
it's
doing
then
it
would
put
that
information
there,
but
that
wouldn't
be
things
like
tenant
id
like
it
wouldn't
be
like
shared
global
concepts.
It
would
just
be
like
like
random,
like
not
random,
but
it
would
be
like
configuration
information
specifically
for
the
sdk
so
that
the
sdk
would
have
a
consistent
configuration
setting
across
the
trace.
A
D
A
Think
it
wouldn't
be
just
because
you
would
want
it's
not
like
how
I
conf
it
sounds
like
a
yeah,
a
broader
concept.
Right
like
you
would
want
to
it's.
Not
it's
not
an
internal
like
that's
for,
like
sdk
internals,
basically
like
stuff,
the
end
user
is
not
worried
about
but
stuff
the
sdk
needs
to
know.
So
it's
just
like
a
spot.
If
we
like
at
some
point,
are
like
oh
we've
added,
this
cool
awesome
feature
to
open
telemetry
sdks,
but
that
feature
needs
to
have
some
trace
level
context
in
order
to
work.
D
A
Yeah,
which
is,
I
think,
maybe
thinking
this
through
what
we
might
want
to
come
back
to
this
framework
with
and
say
like
actually
like
the
place
to
do
this
is
to
is
to
to
have
a
registry
like
nev,
is
saying
and
to
put
the
registry
key
in
the
baggage
or,
if
you
don't
want
to
propagate
it
to
the
next
service.
I
don't
know
why
you
wouldn't
want
to
do
that,
but
if
you
don't,
then
you
just
put
it
directly
into
the
context,
because
we
have
a
context
api.
A
D
Yeah,
I
would
think
you
probably
would,
but
now
that
you
mentioned
that,
though
it
does
raise
the
the
point
that
is
there
a
general.
I
don't
know,
I
don't
think
the
hotel
contact
specification
talked
about
a
general
purpose
way
of
setting
user
state
in
context.
D
It's
just
expected
that
you,
you
store
spans
in
there.
You
store
baggage
in
there,
but
not
you
know,
hey
I've
got
some
value
that
I
want
to
put
in
there.
We
couldn't
put
a
trace
state
in
the
general
context.
You
could
in
a
go
context.
If
you
come
up
with
your
own
context,
key.
A
Yeah,
I
think
the
the
open
telemetry
spec
has,
like
the
context,
is
specified
as
its
own
low-level
subsystem.
That
just
says
get
value
set
value
right
where
set
value
gives
you
a
new
context.
So
it's
basically
what
what
the
go
context
object.
Does
it's
just
in
other
languages
that
object
doesn't
exist
so
open
telemetry
provides
one
so
I'll
point
you
to
the
place
yeah
here.
A
Yeah
and
go
you
don't
like
our
rule
is
like
if
there
is
like
the
language
has
already
agreed
upon
a
construct
for
doing
this
stuff,
then
we
use
that
if
there's
no
agreement,
then
or
there's
no
like
thing
that
we
feel
like
we
could
grab
that
would
like
meet
all
of
our
requirements,
then
we
have
to
provide
our
own
and
so
and
that's,
I
think,
most
other
languages,
though
I
think
python
has
a
concept
of
like
context,
vars
or
something
so
in
python.
It's
covered
as
well.
A
But
but
it's
extracted
out
to
be
its
own
subsystem
actually,
for
this
very
very
reason,
which
is,
you
can
take
context
and
propagators
and
build
whatever
the
heck.
You
want
on
top
of
that
stuff,
totally
independent
of
the
open,
telemetry,
observability
stuff,
we've
built
on
top
of
context
propagation
and
we
actually
wanted.
A
Because,
inevitably,
people
come
back
and
they're
like
now.
I
want
to
build
some
like
totally
different
system
on
top
of
this,
like
an
authentication
system
or
a
b
testing
or
feature
flagging
or
whatever,
and
you
can
just
point
them
and
be
like
cool,
so
here's
the
context,
propagation
primitives
go,
go,
have
fun
or,
and
then
like.
They
don't
technically
have
to
install
like
an
open,
telemetry,
sdk
and
all
this
observability
stuff,
if
they
didn't
want
to
to
go,
build
their
own
thing.
At
least
that
was
a.
A
C
A
D
That's
yeah,
yeah
yeah,
I
think
camel
was
what
started
the
conversation
this
morning
and
I
may
have
had
a
misunderstanding
of
what
they
were
doing.
That
made
me
think
it
was
slightly
more
like
what
build
kit
was
trying
to
do,
but
it
sounds
like
they.
The
camel
just
has
a
flag
that
says:
do
you
want
to
use
open,
telemetry
or
not
that
you
have
to
enable
everywhere,
which
we
kind
of
don't
want
to
see
propagating
there?
D
A
I
think
they
they
were.
Basically
they
were
interfering
with
easy
mode
right.
The
easy
mode
for
open
telemetry.
Is
you
configure
a
global
provider
and
you're
done?
A
You
don't
need
to
go,
configure
all
your
components,
because
they'll
just
grab
that
thing
by
default,
but
camel
was
not
grabbing
that
thing
by
default
and
saying
like
no,
you
have
to
explicitly
configure
me
all
the
time,
and
so
that
was
like
annoying,
especially
in
the
context
of
java,
where
that
gulp
global
provider
is
provided
by
just
attaching
an
agent,
so
zero
configuration
right.
You
just
attach
the
agent
and
now
you've
got
open
telemetry
coming
out,
but
in
camel's
case
you're
like
no.
No,
you
have
to
do
that
plus.
A
Go
modify
a
palm
file
somewhere
or
something
like
that
to
make
this
work,
and
I
think
that
was
like
that
seemed
to
be
their
problem
at
least
pointing
out.
The
solution
is
like
by
default.
Just
grab
the
global
provider
and
assume
that
thing
is
working
seem
to
make
the
splunk
people
on
the
call
happy.
A
Yeah
exactly,
and
so
it's
less
about
even
like,
should
they
provide
their
own
rapper
abstraction
or
not
like
they
can
it's
just.
A
And
it
avoids
the
hell
that
people
have
the
first
time
they
try
to
use
this
stuff,
which
is
they
fail
to
configure
everything
like
that?
First
time,
experience,
I
think,
is
important
where
you
can
just
say
like
copy
paste,
this
bit
of
initialization
or
attach
the
agent
and
now
like,
trace
propagation
works.
A
The
globals
are
like
the
way
that
you
can
have
that
first
time
experience
effectively
and
if
you
don't
have
the
globals,
then
end
users
are
stuck
in
this
situation
where
they
have
to
figure
out
all
the
things
they
have
to
configure
and
I've
done
like
a
bunch
of
user
testing,
and
I
can
definitely
say
like
that:
that's
painful
and
and
because
the
users
are
new,
so
they
don't
totally
know
what
they're
looking
for
and
it's
like
difficult
for
them,
the
the
one
set
of
users
that
seems
to
actually
do
pretty
well
in
that
scenario
are
go
users
I
actually
should
mention
just
because
go
is
so
non-magical
and
manual.
A
It's
like
the
stick
shift
of
programming
languages
so
go.
Users
are
actually
like
used
to
that
more
than
other
programmers
they're
like
yeah.
Well,
of
course,
I'm
gonna
have
to
go
hunt
around
and
like
figure
out
how
to
like
pass
this
stuff
through,
because
that's
just
kind
of
like
what
I
do
and
go
so
they
actually
like
have
a
better
getting
started
rate
than
people
in
like
python
and
other
languages,
where
they're
kind
of
used
to
there
being
a
thing
that
can
just
kind
of
set
it
up
for
them.
D
I
was
just
talking
with
one
of
our
interns
the
other
day
and
that's
what
I
said
was
my
favorite
thing
about
go.
Was
that
it's
so
non-magical
there
is
very
little
if
not
no
magic
to
it
right.
You
want
to
know
what
it's
doing
you
can
follow
it
all
the
way
down
until
you
disappear
in
the
run
time,
and
even
that's
written
and
go
so
you
can
really
follow
that
down
if
you
want,
but
everything
is
very
explicit,
very
concrete,
there's
you
know
no
monkey
patching,
no
fight
code,
reinterpretation
or
anything
like
that.
A
Totally
agree
unless,
like
all
the
ruby
programmers
I
know
start
going
to
town
and
trying
to
you,
know,
do
a
bunch
of
dynamic
programming
and
go
which
doesn't
work
very
well
or
that
all
the
java
developers
I
know
who
go
to
go
and
start
trying
to
add
a
bunch
of
dependency
injection
paradigms
and
like
none
of
that
stuff
works.
But
that's
not
good's
fault.
A
If
you
ripped
out
the
garbage
collector
go
would
be
my
favorite
language.
I
guess
that's
all
I'll
say.
A
Basically,
basically
yeah
extend
goes
type
system
like
be
like
the
brilliant
idea
of
rust,
which
is
hey
we're
using
types.
Why
not
use
types
to
manage
concurrency
and
like
concurrent
and
safety,
rather
than
just
you
know
what
we're
already
using
for
like
go.
Do
that
and
then
get
rid
of
this
garbage
collector
because
that's
hell,
this
is
some
special
penn
hill.
A
Okay,
I
think
we're
at
time
we
could
probably
wax
on
about
this
stuff
forever.
I
do
want
to
point
people
at
honorags,
instrumentation
otep,
if
you
haven't
taken
a
look
at
that
on
the
call.
Please
take
a
look
at
that.
A
This
is
about
how
to
make
things
easier
for
library,
authors
in
general,
when
they're
instrumenting
themselves
like
how
can
we
provide
some
high
level
thing
so
that
when
it
comes
to
doing
like
traces
plus
metrics,
it's
it
becomes
like
a
very
it
becomes
something
that's
heavier
on
take
this
standard
blob
of
configuration
and
less
on
sprinkled,
just
like
a
jillion
instrumentation
calls
everywhere
in
your
code.
A
But
I
think
it's
also
relevant
for
the
discussion
we
just
had,
because
you
can
ask
whether,
like
this
high
level
object,
is
a
good
place
to
kind
of
hide
some
of
these
more
advanced
concepts
like
multi-tenancy
as
well.
D
A
Yes,
the
the
straw
that
broke
the
camel's
back
for
me
was
request,
duration,
people
starting
to
be
like.
So
I
want
the
request.
Duration
as
a
metric,
so
I'm
now
gonna
like
have
a
like
start
request,
timestamp
and
an
end
request,
timestamp,
and
then
I'm
going
to
like
calculate
the
duration
and
hand
that
to
metrics
as
a
as
a
as
a
label,
and
it's
like
one
you're
doing
that
non-monotonically
and
that's
wrong
and
two
you're
the
thing
sitting
right
next
to
you
is
already
doing
that
for
you
so
yeah.
A
Something
like
this
high
level.
Instrumentation
object
would
encapsulate
all
of
that
kind
of
stuff
so
that
all
the
shared
attributes
between
all
of
the
metrics
labels
that
can
be
derived
from
span
data
are
derived
directly
from
span
data
rather
than
getting
schlepped
about
or
entered
twice
or
things
like
that,
and
then
the
other
part
of
it
is.
Can
we
standardize
our
configuration
language
for
this
kind
of
stuff
like
when
you
have
an
http
client?
A
And
then
what
configuration
language
should
you
use
to
allow
the
end
user
to
like
tweak
all
that
stuff
when
they
want
to
and
then
package
all
of
that
up
into
like
an
object
with
a
config
and
be
like
here
just
use
this
thing
and
then
you
don't
have
to
think
about
any
of
that.
D
It
provides
a
good
extension
point
too.
We
recently
had
an
issue
request
about
adding
common
attributes
to
a
grpc
handler
right,
so
every
every
method
request
is
going
to
come
in
was
going
to
have
these
common
attributes
they
wanted
to
extract
and
put
in
they
actually
realize.
Oh,
I
can
just
do
this
inside
my
hand
or
pull
the
span
out
of
the
context
and
add
them,
but
their
their
first
thought
was
hey.
D
Why
can't
I
just
tell
the
this
rapper
that
I'm
putting
around
there
always
extract
these
attributes
and
and
put
them
in
which
I
think
makes
sense
right.
We
should
be
able
to
say:
okay,
there
are
things
that
I
know
are
always
going
to
be
on
every
request
and
I
want
them
added
to
a
free
span
and
I've
got
this
thing.
That's
constructing
the
span.
Let
me
tell
it
how
to
pull
these
out
plus
then
they'll
be
there
for
sampling
when
the
span
is
created,
which
might
end
up
being
very
important.
A
Yeah
totally
and
then,
when
you
just
say
end
on
the
instrumentation
span,
object
when
you
say
end
on
that
thing,
then
it
just
spits
out
all
the
metrics
as
well.
So
you
end
up
not
actually
having
to
sprinkle
metrics
instrumentation
anywhere
in
your
library,
if
it's
doing
some
of
the
stock
stuff
instead,
what
you
do
is
you
have
like
this
handle
is
basically
like
a
very
beefy.
A
You
generate
like
a
beefy
one
of
those
that
also
has
like
a
pile
of
metrics
and
things
in
it
that
are
configured
along
with,
like
an
understanding
of
like
what
labels
it's
going
to
need
to
extract
and,
and
so
when
you
say,
start
span
with
that
thing,
it
gives
you
back
a
span
like
object
and
then,
when
you
call
end
on
that
it
it
does
all
of
this
stuff,
rather
than
just
just
in
the
span.
A
Yeah
yeah
this
is
this,
is
hot
stuff,
but
right
now
the
proposal
like
the
feedback
on
aurora's
gotten
is
like
it's
a
very
java-ishi
proposal.
He
has
a
java
implementation,
but
you'll
see
what
I
mean
when
you
read
it,
and
it
would
be
very
helpful
to
like
have
a
look
at
like
what.
What
would
some
of
this
stuff
look
in
languages
like
go
and
python
go
in
particular,
because
his
implementation
relies
on
a
lot
of
like
generic-y
stuff
that
you
can't
really
do
and
go
right.
D
Impression
as
well
was
that
this
felt
very
java-e
with
builders
and
factories,
and
things
like
that.
I
didn't
have
the
time
then
to
spend
thinking
about
how
it
could
be
adapted
to
something
like
go
I'll
see
if
I
can
find
the
time
to
do
that,
though,
yeah.
A
Yeah,
I'm
gonna
try
to
find
some
time
as
well,
and
this
is
what
hopefully,
we're
gonna
be
getting
more
people
coming
in
to
help
with
some
of
this
stuff.
That's
kind
of
the
request
I've
been
making
because
yeah
I
feel
like
maintainers,
are
stretched
a
little
thin
and
I
think
this
stuff
requires
like
genuine
design
cycles.
A
It's
not
just
like
you
know
just
jam
it
out
in
a
weekend
like
like,
like
there's
some
thinking
that
needs
to
go
into
this
stuff,
to
make
sure
it's
correct,
but
if
we
can
pull
it
off,
then
we'll
be
able
to
mark
the
conventions
as
stable
and
also,
I
think,
we'll
make
instrumentation
a
lot
easier,
or
at
least
a
lot
more
learnable
for
library,
authors
and
maybe
even
everyone,
because
it'll
be
more
like
hand-holding
around
like
so.
A
If
you're,
making
an
http
client
span
like
here's,
the
struct
or
whatever,
with
like
all
the
info,
you
need
like
fill
this
thing
out
like
fill
out.
This
form
and
then
hand
it
to
this
guy
and
you're
done
and
like
that's,
that's
all
you
have
to
think
about
and
like.
When
does
the
operation
start
and
when
does
it
end,
and
I
think
that
that
will
help
people
a
lot
when
it
comes
to
to
producing
instrumentation?
That's
like
very
uniform
and
high
quality.
A
As
opposed
to
right
now,
which
is
learn
this
api
and
then
learn
about
the
semantic
conventions
and
then
like
keep
the
spec
open
in
one
tab.
While
you
write
your
code
and
like
make
sure
you
like
pack
on
all
the
right
attributes
and.
D
That
kind
of
thing
right
in
go.
We
we've
kind
of
stumbled
into
this
with
some
helper
functions
in
our
semantic
convention
package
for
http,
but
that
really
only
covers
http
and
only
sort
of
some
of
it.
Maybe
if
your
request
has
all
the
attributes
that
it's
looking
for
so
it's
it's,
not
a
great
general
purpose
solution.
D
There's
always
the
the
question
of
how
do
you
deal
with
that?
For
you
know,
message,
brokers,
kafka
or
or
rabbitmq,
or
something
like
that?
How
do
you
deal
with
it
for
a
database.
A
Yeah,
what's
what
pattern
can
we
use
to
then
extend?
I
think
it
is
the
kind
of
thing
we're
going
to
end
up
with
a
huge
pile
of
these
things
because
they
are
specific
to
every
convention.
But
that's
okay,
like
it's
better
to
have
a
pile
of
helpful
things
than
a
pile
of
like
words,
someone
has
to
read.
So
that's
good.
A
The
other
part,
though,
that
we
need
to
figure
out
is
then
users
inevitably
want
to
configure
some
of
this
stuff
right,
and
it
would
be
great
if
we
can
kind
of
standardize
the
configuration
as
well
other
than
having
every
component
figure
out
its
own
little
configuration
language
and
give
its
own
little
set
of
options
for
how
you
can
configure
the
tracing
and
matrix
information
for
this
particular
http
client
from
prior
experience.