►
From YouTube: 2022-09-15 meeting
Description
Instrumentation: Messaging
A
A
C
B
B
A
A
Now
I
mean
I
share
their
pain,
I
want
it
like
three
months
ago,
but
you
know
yeah
no
I
heard
that
and
I
was
super
excited
by
that
because
it
I
mean
when
it
helps
us
motivate
us,
but
two.
It
also
gives
us
I
think
like
really
good
feedback
to
have
somebody
using
it.
I
know.
There's
a
few
customers
here
at
spunk
they're
also
looking
to
use
it
but
I.
Imagine
the
collector
will
be
faster
in
getting
this
into
their
I.
A
Cool
well,
I
think
we're
a
minute
and
a
half
into
the
hour.
Although
I'm
looking
at
the
attendees
currently
there's
I
think
a
pretty
good
Quorum,
so
we
could
probably
get
started
here.
So,
if
you
haven't
already,
please
add
yourself
to
the
attendees
list
on
the
agenda
doc.
If
you
have
something
you'd
like
to
talk
about,
please
make
sure
it's
on
the
agenda
and
we
can
get
started
here
in
just
a
second
I'm.
A
A
A
It's
it's
hard
to
tell
sometimes,
but
it
definitely
has
been
more
than
three
months
so
I
want
to
say,
like
please
take
a
look
at
this
and
make
sure
I
did
this
right,
because
this
is
also
a
little
bit
confusing
trying
to
resolve,
merge
conflicts
and,
as
you
can
see,
a
pretty
big
change
sets
going
in,
all
of
which
should
have
been
reviewed.
So
it
shouldn't
be
a
surprise
but
just
a
I.
Imagine
a
cursory
glance
at
maybe
like
the
file
listings
is
also
probably
a
good
place
to
start.
A
That's
what
I've
been
doing
for
about
an
hour.
It
looks
good
I'm
still
reviewing
it,
but
just
a
heads
up
on
that,
but
yeah
I
mean
with
that
said
like
this
is
it
this
is
going
to
be
the
the
closing
of
the
development
branch
and
we'll
be
moving
on
to
the
beta
Milestone
after
this
I
plan
to
once
this
is
out
release
the
metrics
SDK
or
do
a
metrics
release
or
experimental
metrics
release.
A
I.
Imagine
if
really
kind
of
depends
on
the
timeline
of
when
this
is
merged.
When
that
release
will
come
out,
but
it'd
be
cool
tomorrow,
but
I.
Imagine
more
realistically
it'll
be
next
next
week.
Sometime
early
next
week
is
what
my
guess
is:
I
don't
know.
If
anybody
else
has
something
else
they
wanted
to
add
to
that.
A
A
Yeah
examples
or
some
testing
might
so
that's
a
good
point.
We
should
definitely
I
think
probably
as
a
standard
practice
now
create
a
release
issue
here
and
maybe
just
track
the
the
merge
conflicts
by
doing
a
point
update
essentially
using
the
commit
in
contribute
before
we
actually
do
the
release
here,
I
can
I
can
take
that
on
as
a
as
an
action
item
after
this
merged,
but
yeah
that's
a
good
point.
A
A
Play
yeah,
okay,
so
I
guess
with
that
said.
Maybe
then
early
next
week
is
when
you
could
probably
expect
this
this
release
to
go
out.
If,
if
that's
the
case,
what
are
people
feeling
on
timeline
for
merging
this
I
know?
I
just
opened
this
27
minutes
ago,
but
it's
just
one
of
those
things
that
we
could.
Oh,
we
can
merge
at
a
faster
rate
if
we
allow
the
24
hour
rate
on
this.
One.
D
C
Yeah
I
would
like
to
give
this
a
quick
once
over
as
well,
because
there's
a
kind
of
Sanity
check,
but
we've
we've
already
reviewed
all
of
this
code,
going
on
to
the
branch
that
it's
coming
from
so
I'm
not
terribly
worried
about
waiting
24
hours,
I
see,
we've
already
got.
You
know
three
approvals,
I
think
when
Aaron
and
I
sign
off
on
it.
It
should
be
good
to
go.
C
A
Okay,
yeah,
that
sounds
good
I
will
I
will
wait.
I'll
definitely
wait
for
your
views.
Josh
did
review
the
other
one
that
I
tried
merging
turns
out
when
you
have
a
a
branch
with
a
lot
of
controls
on
it.
It's
really
hard
to
update
it.
So
I
just
essentially
split
it
off,
and
this
isn't
actually
the
new
SDK
main
branch.
It's
this
merge
branch
of
it
just
to
just
to
be
transparent
on
that
one.
A
But
I
will
close
the
other
two
branches
that
we
have
for
the
new
SDK
once
this
is
merged:
yeah,
okay,
okay,
all
right,
well,
I!
Guess
with
that
I!
Don't
think!
There's
much
else
to
talk
about
here.
We
can
definitely
jump
into
the
Beta
SDK
next
week,
but
otherwise
we
can
move
on
to
the
next
agenda
items.
So
Damien.
You
had
a
topic
here
of
how
to
split
the
contrib
handlers
to
do
a
single
thing
and
have
a
separate
one
for
metrics
and
traces.
B
Yeah,
that's
a
proposal.
I've
left
a
message
on
stack
as
well:
I
went
out
out
and
I
went
to
old
people
things,
but
what
I'm
seeing
is
country
handlers
are
starting
to
do
like
Gathering
the
same
data
in
both
tracing
and
metrics,
and
it
seems
to
me
that
people
who
are
using
tracing
are
unlikely
to
be
interested
in
the
same
data
in
metrics
and
I.
C
C
I
think
I've
always
been
a
little
on
the
fence
about
including
the
the
metrics
instrumentation
in
the
HTTP
instrumentation.
Precisely
for
the
the
reason
you
mentioned,
like
it
kind
of
overlaps
with
information,
you
can
extract
from
the
trace
data,
but
I
also
know
not.
Everybody
is
using
the
trace
back
end
that
gives
them
those
capabilities,
so
it
might
be
valuable
for
some
and
I.
Don't
know
if
having
two
distinct
instrumentations
is
the
way
to
go.
What
about?
Having
controls
for
enable
Trace
enable
metrics
within
a
single
instrumentation.
B
D
Yeah
I
would
kind
of
like
to
compare
the
different
approaches
to
this,
because
there
could
be
some
benefit
from
having
them
not
overlap,
but
it
also
seems
like
it
would
make
like
instrument
and
HTTP
more
complicated
when
you
have
to
have
different
instrumentations.
So
if
there
would
be
some
kind
of
comparison
of
that
I'd
appreciate
it,
I
don't
I,
don't
know
if
there's
an
issue
that
already
tracks
that
or
not,
but.
A
Yeah
I
think
that
would
be
my
suggestion
as
well
as
to
track
this
with
an
issue,
maybe
like
an
internet
proposal
I
like
Anthony's
idea
of
having
some
control
over
it
and
how
that's
actually
implemented
on
underneath
it
once
you,
you
know,
have
like
some
sort
of
creation.
Setup
I
could
definitely
see
like
you
getting
one
thing
back.
If
you
say
traces
are
often
getting
another
thing
back,
they're
kind
of
they
essentially
don't
have
any
overhead
from
traces,
but
they
would
implement
the
same
interface
or
something
like
that.
A
A
D
A
I
do
know,
there's
a
lot
of
talk
to
in
the
hotel,
spec
I
think
it's
to
disabled
the
SDK
entirely,
but
it
may
be
a
signal-based
disable
as
well,
but
you
know
that's
also
something
using
environment
variables
to
do
that,
but
essentially
you
could
also
just
pass
their
configuration
option.
That
says
like
that.
You
could
also
say
like
exactly
like
David
said,
like
you,
just
don't
want
anything
personal
off.
C
A
A
A
Something
like
that
that
under
the
under
the
system,
since
this
influenced
the
interface
doesn't
actually
ever
do
any
of
those
API
calls,
it
may
be
optimizes
optimized
a
little
bit.
So
in
that
situation
you
may
want
to
ask
if
they
want
those
things
enabled
or
not,
but
there
might
also
be
a
way
to
just
say
also
is
this
is
this?
Is
this
recording
in
some
way
because
I
mean
like
you're,
saying,
like
the
Tracer
like
you
could
find
that
out
through
introspection?
But
you
have
a
meter.
A
A
B
Yeah
so
we
had
talked
at
a
couple
meetings
ago.
Maybe
one
of
the
concerns
well,
there's
a
couple
of
concerns:
I
guess
related
to
having
additional
surface
area
additional
code
that
had
to
be
maintained
and
not
using
some
of
the
built-in
stuff
from
the
otlp
exporter,
for
example,
and
also
a
lot
of
interest
in
having
an
auto
exporter
package
similar
to
the
auto
propagator
package
that
could
then
ultimately
be
used
in
the
launcher
or
hotel,
init
or
whatever
that
ends
up
being.
B
So
we
wanted
to
put
together
this
proof
of
concept,
to
try
and
get
some
eyes
on
it
and
see
if
this
could
get
merged
in
and
then
I
would
want
to
update
our
design
dock
for
the
launcher
to
be
a
little
more
explicit
right
now.
It
says
it
could
use
an
auto
exporter
package
once
it's
available,
so
just
a
little
more
explicitly,
it
will
use
the
auto
exporter
package
once
it's
available
and
again
one
thing:
that's
kind
of
nice
is.
B
So
ultimately
the
launcher
point
of
concept
that
were
proof
of
concept
that
we're
putting
together
should
be
almost
like
cut
in
half
as
far
as
lines
of
code.
So
I
guess
I
wanted
to
see
if
there
was
any
initial
thoughts.
Anyone
had
on
this,
like
I
said
I
want
to
get
that
auto
exporter
package
in
a
place
that
it
can
then
be
reviewed
as
a
PR
to
go
in,
but
then
the
goal
would
be
to
you
know
kind
of
bless
it
for
the
design
dock
for
the
launcher.
A
Yeah
I
I,
definitely
I,
think
I
five
seconds
looking
at
this,
but
I've
got
some
feedback,
but,
like
that's
a
great
sign,
I
think
this
is
a
I
got
a
lot
to
say
about
it.
I
wish
it
was
a
PR
against
control
is
all
I'm
saying,
because
I
think
it's
ready
to
to
get
proposed
there
and
I
think
it
would
be
great
to
see
it
included
there.
Yeah.
A
Yeah
I
gotcha
I
gotcha.
Well,
you
may
have
a
different
level
of
perfection
then,
because
this
looks
great,
this
looks
definitely
ready
to
be
submitted
as
a
PR
from
what
I'm
seeing
so
far
there's
maybe
I,
don't
know
the
testing
but
like
yeah.
This
looks
like
the
API
structure,
looks
like
it's
worth
the
conversation
at
this
point
and
I.
Think
you
have
it
like
90
of
the
way
there
so
yeah
I
would
love
to
I'd
love
to
see
this
think
the
trip.
B
E
It
quick,
okay,
the
the
key
I
mean.
So
the
key
thing
is
like
Auto
exporter
like
as
a
separate
PR.
Let's
get
that
done,
let's
figure
that
out
and
do
that,
but
then
the
second
half
is
we
don't
want
to
stall
the
launcher
and
we
want
to
like
take
the
launcher
and
have
it
like
depend
on
this
design
and
then
keep
moving
ahead
with
a
launcher
design
so
like
getting
the
design
doc
done
and
getting
you
know
have
and
and
being
able
to
move
forward
into
this
rather
than
just
having
it.
C
Yeah
yeah,
it
looks
like
this
is
doing
exactly
what
I
think
we
had
talked
about
and
hoped
it
would
do.
Is
that
it'll
pull
a
lot
of
this
work.
That
was
in
the
launcher
off
into
a
reusable
thing
that
that
is
completely
agnostic
to
anything.
What
exporters,
what
configuration,
whatever
that's
in
line
with
what
we'd
already
started
with
with
the
Proprietors,
and
then
that
simplifies
the
launcher
a
great
deal
so
I
look
forward
to
seeing
that
follow-up.
Okay,
perfect.
A
D
Yeah
I
just
wanted
to
let
people
know
as
of
today,
it
was
earlier
today.
Go
117,
isn't
required
to
merge
anymore,
but
119
is
this
paves
the
way
to
let
us
actually
deprecate
117
in
the
next
in
the
next
release.
So
there
just
wasn't
like
a
big
PR
around
it,
so
I
figure,
some
extra
notice
would
be
helpful
and
then.
C
D
A
So
maybe
that
answers
that
question
so
it'll
just
be
an
SDK
release,
I
think
which
yeah
like
you're
right,
like
it's
already
configured
to
only
use
118
in
the
metrics
SDK,
so
that
yeah
I
guess
I
was
just
asking
project
wise
if
we're
going
to
officially
just
drop
support,
then,
but
that
would
also
be
only
like
a
week
of
the
release
Cadence.
So
I
was
a
little
concerned,
but
also
if
we
don't
have
the
111
out,
then
I.
Don't
think
that
we
can
actually
do
that.
A
A
A
So
the
idea
is
to
kind
of
hold
off
on
that,
and
this
issue
was
here
to
Res
all
of
the
scope
attributes
for
this
next
release.
But
I
think
that,
as
of
this
is
a
pull
request
that
landed
yesterday,
we
may
just
want
to
not
even
address
this
at
this
point.
So
I
think
that's
kind
of
the
question
is:
if
we
want
to
even
just
take
this
out
of
the
the
next
race,
I
I
think,
maybe
to
that's
a
little
bit
of
a
backstory.
We
talked
yesterday.
A
One
of
the
things
that
is
required
by
the
specification
in
the
API
is
to
accept
attributes
when
you're
creating
a
meter,
Tracer
or
a
logger,
and
so
we
would
need
to
add
some
sort
of
option,
but
then
we
would
essentially
just
throw
them
on
the
floor
and
I
think
that
that
might
be
the
resolution
to
this
issue,
and
then
we
can
release
118
or
I'm.
Sorry
111.
C
That's
my
read
of
it:
yes,
I
I
think
like
we
currently
got
a
and
with
scope,
attributes,
option
and
the
implementation
that
it
adds
the
attributes
to
the
config
and
then
presumably
nothing
does
anything
with
that
config,
but
I
think
we
can
just
make
that
option.
I
know
up
entirely
just
haven't
written
an
option
Funk
that
does
nothing
has
no
body,
because
we
don't
need
those
attributes
and
I
wouldn't
want
to
make
them
available
to
anybody
to
accidentally
rely
on.
D
C
A
B
A
A
I
do
too
and
I
think
that
there
are
ways
to
use
it,
so
it's
not
identifying,
but
I
still
don't
have
a
good
understanding
of
what
the
behavior,
when
you
ask
for
the
same
meter.
Back
that
you
already
asked
for
one
with
different
attributes
is
like
I
can
definitely
see
how
to
like,
essentially
wrap
the
scope
instrument
type
and
like
essentially
not
use
the
attributes
in
the
identifying
like
lookups
for
any
of
the
maps,
but
then,
like
yeah,
that
comes
back
to
that
question
of
like
okay.
A
Well,
then,
you
just
hand
back
the
original
that
had
the
original
attributes
or,
like
that's
the
that's
the
problem
like
because
then,
if
this,
if
the
specification
comes
along
and
says
like
well
I
doubt
they're
gonna
say
but
like
drop
them
on
the
floor
or
we're
hearing
a
no-op
or
or
give
an
update,
like
maybe
there's
an
upsert
sort
of
thing
that
goes
on
there.
I
I,
don't
know
what
I'd.
C
A
Yeah,
so
are
you
saying
we
should
should
add
some
it's
like?
Are
you
saying
we
should
add
some
implementation
where
at
scope
attributes
are
eventually
propagated
because,
like
our
current
thing,
we
just
described
is
that
we
just
drop
them
on
the
floor,
but
you're
saying
that
maybe
we
should
try
to
support
them
in
some
way.
A
C
A
A
requirements
on
that
yeah
I
think
it's
pretty
silent.
That
I
I
do
think
just
like
from
a
user's
perspective
that,
like
you're
gonna,
be
super
annoyed.
If
you
went
through
the
trouble
of
adding
attributes
to
a
scope
and
then
like
get
to
the
end
and
there's
just
nothing
there,
but
yeah
I,
I
I,
don't
know,
I
mean
I
kind
of
like
that
idea
that,
like
maybe
like
just
say
like
you
know,
our
behavior
is
first
in
wins,
with
the
caveat
that
this
may
change
in
the
future.
A
I
I
mean
I'm.
Also
I,
like
the
behavior
of
like
last
in
wins
like
I
I.
Don't
that's
fine
to
me
too,
but
I
just
wanted
to,
like
you
know,
I!
Think!
That's!
That's!
The
big
question
is
it's
like
I?
Don't
think
the
specification
is
going
to
come
along
and
say
like
if
you
ask
for
the
same
identifying
Tracer
with
different
attributes,
drop
everything
that
goes
back
to
that
Tracer
I,
really
doubt
that
there's
that's
going
to
be
accepted.
A
The
spec
but
I
I,
don't
know
which
one
they're
going
to
choose
of
like.
Do
you
just
pick
the
first
one
or
the
last
one,
or
do
you
try
to
add
these
as
identifiers
or
do
you
try
to
merge
them
like
there's
like
a
few
possibilities
there
and
I'd
I'd
want
to
cause
like
the
least
amount
of
user
frustration
in
that
translation
process
when,
when
the
specification
does
add
something.
A
C
A
A
A
D
Yeah,
so
we're
in
a
big
planning
week
right
now
and
we're
looking
forward
into
the
future
and
I
know.
This
is
getting
a
little
bit
ahead
of
where
we
are,
but
it's
still
just
kind
of
putting
feelers
out
for
what
do
we
actually
want
to
require
for
our
stable
release
of
metrics
SDK
I
assume
this
will
happen
sometime
after
beta
and
have
some
kind
of
metric
around
that
it's
being
used
somewhere
at
least,
but
what
do
we?
D
A
Yeah,
that's
a
great
question:
I've
been
talking
with
a
bunch
of
people
on
this
one
and
I.
Think
there's
I
think
the
the
founding
like
the
North
Star
on
this
one
is.
It
needs
to
conform
to
our
stability
and
versioning
guarantees
right
like
if
it
releases
stable.
It
needs
to
be
able
to
do
that
right
and
I
think
what
that
means
is
from
the
user's
perspective
that
API
can't
change
in
a
backwards
and
compatible
way
with
the
little
asterisks
there
that
maybe
interfaces
could
have
things
added
to
them.
A
But
let's
just
say
that
that's
that's
just
kind
of
like
a
stable,
well
that
that
is
where
guarantees
are,
and
so
I
think
to
do
that.
We
need
use
case
and
we
need
to
address
any
API
level
concerns
before
the
that
could
actually
be
released
as
stable
in
my
in
my
understanding.
So
David
and
Anthony
were
talking
about
the
collector
trying
to
adopt
this
I.
Think
that's
a
great.
A
The
feedback
signal
right,
I
think
that
that
should
be
done
before
we
have
a
stable
release.
If
they're
willing
I
mean
they're,
they
sound
like
they're,
really
willing
to
to
try
out
this
Alpha
release.
Right
that'd
be
great
if
they
could
use
that
and
they
come
back
and
they
say
like
well
there's
like
no
way
we
can
achieve
this.
One
thing:
that's
required
by
the
specification:
that's
great
feedback
or
or
they're
able
to
work,
and
it's
and
it
works.
Just
fine.
A
A
Alpha
releases
sometimes,
but
you
know,
I
think
just
like
uses
would
be
really
good
and
then
I
think
that
yeah
then
any
identified
issues
that
deal
with
the
API,
those
are
resolved
in
a
beta
or
another
Alpha,
and
then
I
think
we
can
go
into
the
release
candidate
phase.
I
do
think
that
like
if,
if
we
identify
performance
issues,
but
we
identify
them
under
the
hood
like
they're
internal
packages,
their
internal
implementations
that
can
be
addressed
without
changing
the
API
I,
don't
think
those
should
block
the
release.
A
You
know
I
think
that's
close
to
the
standard
of
like
don't
let
perfect
block
good
enough
and
similar
to
like
how
early
versions
of
go
were
not
great
at
performance,
especially
like
the
garbage
collection,
or
something
like
that.
I
really,
don't
want
it
to
be
something
that
we
like
hold
a
release
candidate
off
on.
A
So
this
is
kind
of
like
I
thought
a
lot
about
this
as
to
like
what
we
want.
The
next
phase
to
be
I
do
think.
There's
also
got
to
be
a
soap
time
just
for
that
first,
one,
like
the
use
case,
has
to
get
an
adoption
has
to
get
you
know
drawn
out.
So
we
need
a
little
bit
of
time
for
people
to
actually
give
them
time
to
actually
try
it,
but
it
also
like
it's
really
tough
when
that
is
done
into
a
void.
A
A
A
Yeah
I
think
that's
also.
Another
good
topic
of
conversation
is
like
one
of
the
things.
That's
like
feature
Edition
right
like
there's
a
proposal
to
have
the
exponential
histogram
be
added
as
an
aggregation
type,
but
it's
still
I
think
unless
things
have
drastically
changed
an
experimental
feature
of
the
specification,
so
yeah
I
think
we
we
do
need
to
identify
something
like
I.
A
Don't
think
we
have
to
have
a
solution
here,
but
we
need
a
way
to
actually
add
experimental
features
still
into
that
stable
package
that
we
do
release
as
the
SDK
so
like
whether
that
means
that
it
includes
the
exponential
histogram
and
that
release
or
not
like
we
want
to
make
sure
that
we
have
some
sort
of
approach.
There,
I
think
is
pretty
key.
D
A
A
A
We
should
probably
work
on
exemplars
next,
but
yeah,
okay,
I
think
that's
that's
a
good
thing
and
that
honestly
it's
just
it's
it's
still.
We
need
to
be
able
to
add
things
in
experimental
ways.
So
that's
a
good!
That's
actually
a
good
point,
because
the
aggregation
type
I
think
this
goes
back
to
like
this
whole
problem
is
like
in
go.
They
aren't
well
in
the
specification
they
aren't
plugable
because
there
is
no
aggregator,
it's
just
a
essentially
like
a
static
list
of
enums,
so
you
can't
essentially
build
out
another.
A
So
it's
like
I
yeah,
like
maybe
we
need
to
actually
address
that
so
yeah
yeah,
okay,
there's
a
lot
here,
but
I
think
there's
just
a
great
excitement
for
the
next
phase
as
well.
So
that's
where
that's
coming
from
we're
at
the
end
of
our
agenda
I'll,
pause
here
and
see.
If
anybody
else
has
something
else,
they
want
to
talk
about
foreign.
A
A
Well,
I
might
have
two
actually
okay,
so
one
of
the
things
that
I
built
out
a
little
while
ago
and
I
don't
know
if
I've
published
this
too
broadly
was
this
package
called
redact
I
saw
at
a
few
different
places
that
people
were
trying
to
like
remove
sensitive
information
like
passwords
user
secrets
and
that
kind
of
stuff
from
their
spans,
and
so
I
just
built
this
out.
Really
quick.
It's
it's
not
perfect.
A
In
fact,
it
almost
intentionally
isn't
perfect,
but
essentially
what
it
is
is
it
creates
a
sensor
where
it's
a
span,
processor
and
if
a
standard
started
with
something
in
some
sort
of
deny
list,
then
it
will
redact
that
key
value.
So
if
you
have
a
secret
in
there,
the
the
key
is
persistent
that
the
value
just
turns
into
this.
A
This
value
here,
which
is
great,
although
it's
not
perfect,
because
if
you
try
to
add
attributes
after
the
standard
started,
this
does
nothing,
and
so
there
are
definitely
ways
to
address
that.
Essentially
do
a
wrapper
around
this
read-only
span,
which
I
haven't
actually
addressed
yet,
but
I
thought
it
was
kind
of
a
cool
project.
Just
kind
of
heads
up
I
think
span
attributes
are
a
really
cool
area
of
kind
of
creativity
to
start
playing
with
open
slot
dream.
A
One
of
the
other
things
that
I
created
in
this
is
redacting
spans
themselves
like
we
have
in
a
lot
of
instrumentation
ways
to
you
know,
avoid
creating
experience
for
health
check
and
that
kind
of
thing,
but
if
you're
an
operator
of
the
project
not
defining
the
instrumentation,
sometimes
like
it's
too
late,
so
I
created
a
actually
I
have
no
idea
what
I
did
here.
I
created
another
spam
sensor,
that
is
a
oh,
it's
a
sampler,
that's
right,
and
so,
if
it
finds
a
span
with
a
particular
name,
it'll
drop
the
span.
A
So
it
technically
is
still
in
the
memory,
but
it
won't
ever
be
exported
and
it's
not
recorded
as
well.
So
it's
kind
of
cool,
too
cool
to
tooling
issues
here.
I
think
I
have
another
issue
here
to
create
something
for
an
entire
instrumentation
scope,
which
I
don't
know.
If
there's
a
way
to
do
that
currently,
which
may
be
an
issue
that
comes
back
to
the
open,
Telemetry
project
itself
but
yeah,
it
was
kind
of
just
a
cool
use
case.
I
found
I
had
so
many
users
asking
me
about
this.
E
You
know
it
was
basically
a
redacting
or
an
encrypting
proxy,
and
one
of
the
things
that
actually
is
is
useful
in
this
context,
sometimes
is,
instead
of
just
replacing
a
span
with
rejected,
replacing
it
with
a
masked
value
that
preserves
the
cardinality
of
the
original
value
so
being
able
to
like.
So
you
run
it
through
a
hasher
with
some
salt
or
something
like
that,
so
that
identical
values,
income
become
identical,
values
out
and
there
were
contexts
in
which
that's
preferred.
E
We
used
to
we
used
to
have
this
thing.
That
was
a
secure
proxy,
that
all
the
data
would
go
to
it.
We'd
encrypt
all
the
strings
with
all
the
keys
staying
in
the
proxy
and
then
the
client
would
hand
off
encrypted
strings
back
to
the
proxy
and
get
them
and
decrypt
them
in
the
clients,
so
that
the
the
client
could
view
the
site
almost
as
if
nothing
had
been
encrypted.
E
C
C
A
Well,
yeah
and
exactly
I
think
that
API
is
really
restrictive,
exactly
like
you're
saying,
because
there's
no
like
chaining
there
either
it's
just
like
it
hands
it
to
the
spam
processor
and
it
hands
it
to
each
span.
Processor.
That's
not
like
you
can't
mutate
it
for
the
next
one.
So
if
you
want
to
mutate
it
Downstream,
you
have
to
essentially
wrap
your
underlying
span.
Processor
yeah.
That
is
a
big
one.
That
I
noticed
the
API
is
a
little
limited
on
that.
A
D
A
Pretty
cool
I've
done
that
in
a
few
other
places
the
only
problem
is
there's
memory.
Overhead
was
what
I
was
trying
to
deal
with,
because
you
know
like.
If,
if
there's
no
spans,
you
would
actually
get
doesn't
really
matter.
But
if
there
are
you
all
you
need
to
allocate
a
new
slice
like
I
said,
like
it's
not
impossible.
In
fact,
I,
if
I
have
another
half
day,
I'll
probably
try
to
implement
that,
because
it's
not
that
hard,
but
yeah
I
think
you're.
A
C
C
Don't
have
any
like
customer
stories
or
anything
like
that,
but
I
will
note
anecdotally,
I'm
getting
more
and
more
inquiries
internally
about
using
Hotel,
so
word
is
spreading.
People
are
trying
to
use
it
even
at
a
ship
as
large
as
Amazon.
So
that's
a
long
time
before
we
figure
out
how
to
use
it
effectively
and
well,
but
people
who
I
have
no
connection
with
or
have
never
worked
with
are
are
now
starting
to
ask
about
it,
which
is
great.
A
Yeah
I
also
I'm,
noticing,
in
other
libraries
there's
instrumentation
in
hotel,
like
lib
PG
I,
saw
the
other
day
had
their
own
instrumentation,
where
I
was
just
like.
When
did
this
happen
like
yeah,
like
I,
think
I've
written
instrumentation
for
it,
so
it's
really
cool
to
see
that
it
had
it
so
and
I
think
there's
a
few
others
in
slack
that
people
are
like
chiming
in.
A
A
D
A
A
A
A
E
C
A
I
gotta
go
check
that
out
yeah
that
sounds
really
cool
yeah
and
if
you
aren't
aware,
David
did
great
work
getting
at
CD
and
the
crew
Kubla
stuff
done.
So
that's
like
yup.
It's
happening.
It's
really
happening
cool
well,
I!
Think
with
that
we've
run
through
our
agenda
gone
through.
Some
use
cases
got
10
minutes
left,
but
I
think
we
can
end
it
here
just
to
respect
everyone's
time
thanks.