►
From YouTube: 2021-11-17 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
B
B
A
bit
of
traces,
a
bit
of
metrics
for
both
really
yeah,
just
trying
to
figure
out
the
best
way
to
do
it
at
atlassian.
At
the
moment,.
A
B
Yeah,
oh
yeah.
I
know
that
there's
experimental
metrics
for
the
hdb
conventions
and
there's
a
few
conventions.
It's
just
there's,
no
like
yaml
or
there's.
No
there's
a
couple
things
missing,
actually
working
with
someone
called
diego
on
getting
yammel
into
metrics
convention
at
the
moment.
B
E
B
Yeah,
I
think,
basically,
it's
just
trying
to
get
the
build
tool
to
work
with
matrix
yaml,
and
then
I
gave
him
a
kind
of
metric
yaml
to
work
with.
That
would
hopefully
generate
something
close
to
what
there
is
currently
not
convention.
Nice.
A
So
dennis,
do
you
want
to
talk
about
free,
tries
anything
we
forgot
about
that.
F
Yep
yeah-
I
do
have
this
this
topic,
so
maybe
we
can
start
from
from
this
one
then
so.
F
F
So
this
this
should
be
the
correct
screen
so
yeah
I
just
wanted
to
like
a
slightly
like
or
just
give
a
heads
up
on
the
work
that
we
are
doing
for
read
right
for
http,
retries
and
redirects.
So
we
do
have
this
like
a
pull
request
open
for
for
the
specification
for
http,
symmetrical
specification
saying
that
we
need
to
or
the
new
span
must
be
started
for
new
try
and
it
should
be
linked
to
the
previous
and
it
like.
F
Yeah
must
be
started
and
linked,
and
some
some
additional
information
can
be
included.
So
what
we
did
wizard
mill.
Actually,
in
the
past
couple
of
weeks,
we
do
have
a
prototypes
for
nets
and
for
java
actually
in.net.
We
do
have
like
a
really
good,
like
a
consensus
on
how
it
can
how
it's
possible
to
do
so
so
like
there
are
some
some
different
ways.
F
How
we
can
do
this
like
a
for
pure
http
client,
like
a
code
or
to
some
instrumentation,
live
or
to
open,
telemetry,
instrumentation
library,
for
that
net
and
just
today
looks
like
we
have
this
consensus
that
we'll
make
some
kind
of
trade-off
for
like
a
for
old
net
versions.
We
can
do
it,
an
instrumentation
library
like
a
purely
instrumentation
library,
just
to
not
change
anything
in
existing
two
existing
code
to
not
release
any
patches
or
whatnot,
but
in
new
version
upcoming
version
of
map.net
7.
F
It
can
be
done
directly
to
http
client
code
and
I'm
going
to
start
a
discussion
with
http
client
folks
in
microsoft,
starting
from
next
week.
So
that's
that's.
The
update
from
my
site
and
also
ludmila
has
some
example
how
it's
possible
to
do
the
same,
basically
the
same
instrumentation,
but
for
java
the
mail.
Do
you
want
me
to
share
the
screen
or
you
have
you
have
something
you
want
to
show
yourself.
A
I'm
sorry
yeah,
I
don't
want
to
go
too
deep
into
the
code,
but
what
I've
done?
I've
tried
to
do
this
for
khtp
in
existing
location
instrumentation.
It
was
super
simple.
We
can
definitely
instrument
each
try
there.
We
can
stash
the
the
try
information,
the
previous
try
information
in
the
open,
telemetry
context
under
our
hidden
key.
We
can
use
network
interceptor
instead
of
interceptor.
It
would
work
the
same
for
engine
based
instrumentation
and
for
if
this
instrumentation
is
enabled
manually.
F
Yeah,
so
I
just
wanted
to
clarify
some
like
things
here
like:
should
we
want
to,
should
we
have
more
prototypes
or
like
some
implementations
for
some
other
languages
just
before
we
can
go
and
submit
the
the
like
the
approved,
basically
requested
merged,
or
are
we
okay
with
just
having
these
two
of
them.
E
I
think
we
tend
to
prefer
something
like
java.net
are
very
similar
and
we
tend
to
like
to
see
something
in
a
language.
That's
that's
like
very
different
from
them.
I
don't,
I
don't
think
it's
I
I'm
kind
of.
E
I
personally
think
this
is
not
really
like
an
api
change
where
we
have
to
worry
about
language
differences
if,
if
anything,
we're
gonna
possibly
run
into
library
level,
weirdness
potentially,
you
know
not
not
language
weirdness,
but
I
don't
think
you
guys
should
have
to
like
audit
all
of
the
different
http
libraries
out
there
to
figure
out
which
ones
might
might
be
implemented
in
some
strange
way
where
you
don't
don't
have
access
to
this
kind
of
knowledge,
but
I
think
what
everything
is
is
pretty
reasonable.
G
I
do
sorry
go
ahead.
I
was
gonna,
say
ted,
but
isn't
that
where
we
need
like
some
participation
from
some
of
the
other
language
sigs
who
understand
those
libraries
that
you're
talking
about
because
there
is
a
breadth
of
libraries
that
are
out
there,
that
may
be
specific
to
a
language
or
not.
G
E
I
do
think
we
need,
especially
you
know
once
this
is
merged,
we're
gonna
want
to
go,
update,
instrumentation
out
there,
and
so
we
definitely
need
to
get
other
sigs
aware
of
this
work
and
that
it's
coming
in
particular
tracking
down
who
the
contrib
maintainers
are
for
the
various
pieces
of
instrumentation
we
already
have.
E
I
can
try
try
to
do
that
for
next
week,
see
if
I
can
generate
a
list
of
of
maintainers
to
start,
so
we
know
who
we
need
to
bother
one
thing
that
should
be
helpful
here.
I
don't
know
how
up
to
date
it
is
but
the
open
telemetry
registry,
like
we
have
a
registry
on
our
website
and.
E
I
suspect
our
registry
is
probably
a
little
out
of
date
with
reality
and
I'm
just
doing
a
keyword
search
because
I
don't
think
we
have.
I
don't
think
we
have
a
like
labels
for
things
like
http,
but
that's
a
fair
pile
of
things
in
a
bunch
of
different
languages.
E
A
I
think
we
have
a
bunch
of
different
tiny,
small
things
related
to
http
that
might
need
fixing,
and
my
opinion
is
we'd
rather
create
some,
the
the
rough
final
version,
and
then
we
go
and
ask
to
do
it
in
one
pass
right.
Otherwise
it
will
be
a
flood
of
different
dishes.
A
Yeah
and
I
don't
want
to
create
more
work
but,
like
imagine
like
we
already
are
in
the
situation
where
everyone
does
their
own
thing
and
it's
inconsistent
and
I'm
pitching
this
idea
for
a
while,
and
I
feel
bad
that
I
don't
volunteer.
But
we
need
a
test
right.
We
need
something
to
validate
it
and
then
nobody
needs
to
track
how
we
behind
they
are
from
the
specification
work.
E
Yeah,
yes,
that
that
sounds
like
a
schlep
for
sure
standing
up
some
kind
of
test
harness
for
all
of
these
semantic
conventions
and
getting
all
of
our
instrumentation
to
use
it,
but
I
can
totally
see
the
value.
E
I
also
think
this
is
where
the
value
of
some
kind
of
instrument
or
object
like
what
java
currently
has
where,
if
we
turn
the
work
around
to
where
the
integration
is
just
setting
up
how
to
inject
this
stuff,
how
to
get
this
stuff,
interacting
with
the
library
it's
trying
to
instrument,
but
the
actual
say,
keys
and
values
and
other
things
are
maybe
done
inside
of
an
instrument
or
object.
E
That
potentially
makes
it
easier
to
update
that
instrument
or
object
rather
than
having
to
go
around
right.
Then
you
just
have
like
one
per
language
that
you
have
to
update
rather
than
going
around
and
trying
to
keep
track
of
every
individual
library.
E
A
Do
we
feel
we
are
ready
to
finish
instrumentation
api
and
agree
on
it
by
the
q1
2022,
because
at
least
it's
like?
If
we're
tying
the
success
of
semantic
conventions
to
instrumentation
api,
then
we
we
need
to
go
and
figure
instrumentation
api.
E
Yeah,
I
think
that's
a
place
where
we
need
more
participation
from
other
languages.
I
think
what's
stalled.
There
is
no
one's
known's
building
prototypes
in
other
languages,
so
we've
got
something
robust
in
java,
but
I
have
asked
some
people,
like
diego
on
my
team,
to
take
a
look
at
this,
but
they're
all
buried,
trying
to
get
the
metrics
clients
at
the
door.
E
So
I
think
that's
that's,
like
it's
gonna,
maybe
be
a
little
bit
difficult
to
get
bandwidth
from
like
core
open,
telemetry
client
developers,
while
they're
trying
to
get
metrics
kicked
out,
which
means
you
know,
other
people
could
could
take
a
crack
hit
at
this
instrumentation
stuff
but
yeah.
I
think
it's
so
yeah.
We
could
totally
totally
wrap
it
up
in
q1,
provided
we
find
people
to
do
it.
G
Yeah,
I
think
all
the
folks
are,
like
you
said,
like
metrics,
the
timelines
you
know
coming
for
them
right
like
they
need
to
get
it
out.
So,
yes,.
E
E
Yeah
and
likewise
you
know
when
they
get
done
with
metrics
like
logging,
it's
just
around
the
corner
too.
So
at
the
same
time,
I
feel
something
like
this
instrumentation
object.
I
mean
I
think
this
should
be
baked
into
open,
telemetry
and
it
because
it
needs
to
have
strong
stability
guarantees.
E
If
we're
gonna
go
around
and
tell
you
know,
lots
of
people
to
use
it,
but
it
is
like
a
bit
separate
potentially
from
you
know
the
core
sdk
work,
so
it
is
feasible
for
for
other
people
to
be
focusing
on
this
stuff
and
there
wouldn't
be
getting
their
wires
crossed
with
the
you
know,
the
core
sdk
development.
E
H
I
do
I
do
want
to
give
it
a
try
for
ruby.
It's
like
one
of
those
things.
That's
been
sitting
on
the
tube
the
to-do,
but
the
to-do
just
keeps
getting
longer
and
it
keeps
kind
of
shuffling
back
and
I
keep
opening
up
like
that
jar
and
rag
opened
and
I'm
like.
I
look
at
it
and
then
something
else
comes
up.
So
I
will
do
my
best
to
like
actually
prototype
this,
because
I
think
there
is
a
lot
of
good
stuff
that
will
come
out
of
there.
Yeah.
E
Right
yeah,
so
yeah,
that's
what
I
was
saying,
though
it's
like
people
like
you,
I
think,
definitely
are
interested
but
buried
by.
You
know
this
core
work
and
honestly,
I
think
the
core
work
is
as
important
as
this
is.
The
core
work
is
a
little
more
important.
You
know
I.
If
I
had
to
pick
between
an
instrumenter
and
a
metrics
client,
I
would
choose
a
metrics
client
not
to
you
know
not
to
have
a
favorite
child,
but
so
yeah.
F
This
actually,
I
really
like
this
idea
from
the
bill.
That's
we
can
actually
have
both
so
like
we
can
do
this.
We
can
have
this
api.
We
actually
can
help
us.
You
know
to
to
be
consistent
in
the
unified,
but
it
also
will
be
great
to
have
some
verification
pipeline
kind
of
something
that
we
can
just
build
and
run
through
or
run
against
some
specific
version
of
different
semantic
conventions
just
to
see
what
actually
like
which
violations
we
have.
I
believe
going
forward.
F
It
will
be
something
that
will
you
know,
help
us
a
lot
just
to
see
like
how
which
differences
we
have
in
different
platforms.
With
regards
to
the
current,
like
http
convention
versions,
yeah
yeah,.
E
But
I
do
want
to
emphasize:
we
don't
want
to
have
perfect
to
the
enemy
of
good
enough
like
testing
harnesses
are
great.
Like
you
know,
encapsulation
with
an
instrumenter
is
great,
but
we
don't
need
those
to
move
the
spec
forward
and
then
go
around
and
like
update
all
the
libraries
right
we.
What
we
do
need
is
to
engage
with
and
figure
out
kind
of
who's,
maintaining
all
of
that
stuff
and
work
with
them
to
get
it
to
get
it
updated.
E
Maybe
in
the
process
of
doing
that,
we'll
also
be
able
to
pull
some
of
those
people
in
to
to
you
know
it
would
be
a
good
opportunity
to
pitch
him
on
the
value
of
an
instrument
like
would
you
not
you
know,
so
they
don't
have
to
keep
doing
this
work.
F
Yeah
and
just
one
more
question
related
to
this,
like
what
is
the
like
a
regular
process
when
we
do
some
changes
to
the
specification,
how
we,
like
you,
know,
propagate
this
knowledge
for
different
instrumentation
library,
maintainers.
E
We
don't
don't
have
a
process,
we
release
it
and
they
can
go.
Look
at
the
change
log.
We
don't
have
much
of
a
process
because
most
of
the
changes
we
make
are
focused
on
you
know
core
stuff
and
and
the
the
core
maintainers
follow
the
spec
and
you
know
try
to
keep
their.
E
You
know
they
have
a
backlog
and
are
generally
kind
of
aware
of
what's
going
on
in
the
spec,
but
contrib
is
generally,
I
think,
in
a
difficult
spot,
because
I
think
it's
a
mix-
and
this
is,
I
think,
it's
it'll
just
be
good
to
do
this
research
and
figure
out
what
the
list
of
maintainers
looks
like,
because
I
know
part
of
the
struggle
is
that
in
some
languages
a
lot
of
that
instrumentation
was
ported
over
from
somewhere
else
at
one
point,
but
doesn't
necessarily
have
a
maintainer
and
it's
actually
the
core
maintainers,
who
are
also
kind
of
de
facto
maintainers
of
the
instrumentation
and
the
contrib
packages
and
like
that
is
painful
for
them.
E
I
don't
really
have
the
bandwidth
to
to
deal
with
all
of
the
instrumentation
as
well
as
core,
and
also
I
don't
feel
comfort.
I
don't
feel
qualified
when
someone
comes
in
with
like
an
issue.
E
Http
is
fine,
but
it's
like
redis
or
some
other
thing
like
they
feel
like
a
little
uncomfortable,
just
pushing
the
accept
button
on
on
pr's
because
they
feel,
like
you,
know,
they're,
not
they're,
not
they
don't
have
the
bandwidth
to
like
do
a
bunch
of
research
to
figure
out
if,
like
some
change,
someone's
requesting
this
good
idea
or
not
so
so,
I
think
figuring.
Some
of
that
out
will
be
helpful.
E
A
number
of
these
instrumentation
libraries
do
have
maintainers,
but
I
think
it's
part
of
the
reason
why
they're
in
a
bit
of
a
state
is
it's
the
core
people
who
essentially
have
to
have
to
deal
with
them
and
solving
that
people
problem.
E
I
I
mean,
I
know
something
about
like
organizing
open
source,
but
it's
kind
of
a
an
advocacy
thing
right
like
how
do
we
make
this
stuff?
Look
appealing
enough
like
that
more
people
might
raise
their
hand
and
show
up
from
the
community
at
large
to
help
maintain
contrib,
because
there's
plenty
of
room
for
parallelism
there.
E
You
know
you
don't
need
to
to
have
a
deep
understanding
of
the
inner
workings
of
open
telemetry
to
maintain
those
things,
but
I
think
those
contribute
maintainers
would
need
some
better
support
for
from
us
in
terms
of
like
not
just
the
spec
being
updated,
but
you
know
guides
or
or
something
to
help
help
them
have
a
little
bit
of
traction.
E
You
know
onboarding
themselves,
so
maybe
that's
a
thing
we
can
think
about
is
like
what
kind
of
documentation
can
can
go
along
with
the
spec
changes,
we're
making
that
would
make
it
simpler
for
for
people
and
a
test.
Harness
is
an
example
of
a
thing
that
could
potentially
make
life
easier
for
people.
It's
just.
E
You
know
you
only
have
to
write.
Well,
I
guess
I
take
it
back.
You
you
shouldn't
just
write
the
documentation
in
one
language.
You
should
write
in
multiple
languages,
but
writing
the
documentation
in
english
helps
all
the
different
programming
languages,
whereas,
like
a
test
harness
it's
a
lot
more
work,
so
you
have
to
do
it
nine
times.
E
E
True
yeah,
that's
very
true
right,
like
there's
a
way
to
to
to
do
it:
integration
style,
but-
and
maybe
it's
like
it's
fairly
straightforward.
If
we
can
make
that
that
integrator
easy
to
work
with
then
and
have
an
explanation,
then
for
like
how
how
to
verify
this
stuff
is
correct,
that
that
might
be
sufficient
for
getting
more
maintainers
involved
without
having
to
write
stuff
per
language.
F
That
sounds
reasonable
yeah,
for
this
particular
for
this
particular
one.
I'm
actually
have
some
plans
to
you
know
actually
also
communicate
with
wiz.net's
instrumentation
library
and
as
a
part
of
the
request,
basically
like.
I
have
like
provide
this
description
in
english.
What
is
what
is
happening
inside
like
what
is
the
general
approach,
and
I
believe
this
approach
can
be
used
for
other
languages
as
well,
because
what
you
need
to
do
basically
is
to
like
reuse,
the
current
or
reuse.
The
http
request
object,
and
you
can
then
use
some
context.
F
You
can
stash
some
some
information
and
basically
reuse
it
for
the
next
try
or
redirect.
So
basically,
the
idea
is
really
really
simple
here
that
that's
why
we
have
this
implementations
or
prototype
for
net
and
java,
and
I
believe
it
will
be
really
really
really
similar
for
some
other
platforms
and
languages,
okay,
so
yeah,
and
try
to
try
to
communicate
with
with
other
maintainers
as
well.
E
Awesome,
but
I
think
we
can't
go
ahead
and
if
we
get
enough
approvals
start
merging
these.
These
changes
into
the
spec
all
of
this
stuff
is
still
marked
experimental.
Obviously
we
want
to
put
it
in
the
spec
with
confidence,
we're
not
going
to
go
back
and
change
it.
E
We
feel
like
we
have
some
confidence
about
that
right
now
with
redirects,
so
I
think
it
is
okay
to
to
continue
to
move
the
spec
forward
and
while
trying
to
figure
out
how
we're
gonna
wrangle,
maintainers
and
instrumentation
libraries-
and
it's
not
the
case
that
every
time
we
put
something
in
the
spec,
everyone
has
to
run
out
and
update
their
libraries.
E
We
could
we
could
make
a
set
of
changes
where
we
feel
like
we're,
we're
no
longer
adding
some
new
thing
every
other
week
to
the
spec,
and
then
at
that
point
you
know
try
to
to
engage
all
the
maintainers
to
update
it.
If
something
comes
out
of
that
broad
process
of
you
know
trying
to
update
all
these
things.
If
we
discover
edge
cases
or
or
difficulties
here
or
there,
we
may
have
to
revise
what
we
put
in
the
spec
would
be
a
bummer
if
it
was
a
big
breaking
change.
E
E
I
think
it's
fine
to
go
ahead
so
long
as
so
long
as
we've
prototyped
it
out
in
a
couple
places
just
to
just
to
make
sure
that
you
know
it
can
actually
be
implemented
somewhere
right.
F
Yeah
yeah
and
yeah.
This
is
like
a
first
step
or
one
of
the
steps
towards
stable
specification,
and
probably
once
we
have
it,
it
will
be
a
good
idea
to
have
some
kind
of
validator
or
integrator
part
of
things,
so
we
can
go
through
it
and
actually
validate
all
other.
E
E
Okay,
so
thank
you
yeah.
I
actually
sorry.
H
Go
ahead
guys
is
there
room
for
me
to
like
ask
an
off-topic
question
in
this
yeah
I'm
just
going
to
quickly
share
a
screenshot.
I
had
taken
a
while
back
so
ludmila
had
brought
this
up
my
screen
being
shared
properly.
Here
was
I
I've
been
in
and
out
of
the
meetings
for
a
while?
Has
there
been
any
further
discussion
around
this
behavior
where
you
have?
H
It
was
basically
around,
like
the
suppression,
but
also
like
the
same
problem
applied
to
sampling
versus
like
a
non-recording
span,
and
how,
if
you
had
a
span
nested
under
that
non-recording
span,
what
would
its
parent
be
like?
Was
there
any
follow-up
discussion
around
that
like?
Is
it
just
sitting.
A
Yeah,
so
we've
had
a
I'm,
I'm
not
sure
how
far
you've
gone
in
this
discussion.
It
seems
this
is
the
problem
we
want
to
be
solving.
We
don't
have
a
solution,
yet
I
think
the
the
last
time
we
talked
about
it.
We
decided
okay,
let's
go
ahead
and
figure
out
what
retries
look
like
in
http
and
then,
with
this
in
mind,
we
can
come
back
so
the
the
suppressed
span,
as
I
you
see
it,
how
it
looks
like
it's,
it's
a
thing
that
just
refers
to
the
previous
span.
H
H
Right
so
like
this
is
something
we're
like
like
my
company.
We're
looking
at
right
now
is
like
similar,
similar
ideas
to
like
what
you're
talking
about
like,
but
it's
more
niche
to
say,
like
we
have
a
really
one
of
our
services
really
high
traffic.
We
would
like
to
sample
them,
but
not
in
the
traditional
way,
because
we
don't
want
to
break
traces
because
they
sit
between
a
lot
of
services
and
so
we're
looking
at
like
controlling
the
verbosity
of
it
right.
H
So
basically,
we
just
want
to
trace,
like
the
extremities
of
this
like
service
like
anytime,
someone
reaches
in
like
calls
in
or
it
calls
up
to
another
service.
H
We
want
to
keep
those
fans,
but
we
want
to
drop
everything
else,
because
if
we
do
that,
we'll
reduce
the
volume
of
the
trace,
that
means
we
can
technically
sample
100
of
the
traces
while
some
of
them
a
subset,
is
like
verbose.
But
if
you
do
that,
then
you
have
a
bunch
of
no
op
spans
that
break
the
structure
of
the
trace
of
that
service.
H
You're
controlling
the
verbosity
and
so
like
we're
like
on
the
precipice
of
like
trying
something
kind
of
hacky
where,
if
you
have
a
non-recording
span,
it
just
points
to
its
parent.
H
So
like
it's
fan
id
is
the
recording
parents
fan
id
and
we're
like
testing
just
like
not
in
the
open
source
repo,
because
that
would
be
awful
but
we're
just
like
funky
patching
it
in
our
own,
like
wrapper
to
see
how
this
works,
because
it
it
looks
like
a
really
good
solution,
but
it
would
be
really
unfortunate
if
it
we
had
to
deviate
from
the
spec
to
actually
accomplish
this,
because
it
seems
like
it'll
work
really
well,
but
it
would
be
nice
to
like
I'll
report
back
to
see
how
it
is
in
high
volume
traffic
and
whether
or
not
it
actually
works
well,
but
yeah.
H
A
Yeah,
I
I
just
sent
an
link
to
whatever
in
the
chat
like
we
are
talking
about
two
different
things
and
the
same
mechanism
that
they
can
use
the.
What
you're
talking
about
is
verbosity
right,
so
you
want
to
have
something
on
the
span
that
will
say:
okay,
how
verbose
is
it?
What
I
am
suggesting
is
we
have
something
on
span
that
will
say
what
it
is
like
it's
http
or
its
database,
but
then,
in
your
case
you
want
to
have
a
thing
click
suppressed
spend
and
what
they
created
to
address.
A
This
duplication
is
also
a
suppressed
span.
I
just
created
an
implementation.
The
new
implementation
of
spam
interface
in
java
and
basically
suppressed
spending
well
acts
exactly
as
what
you
described.
It
has
the
same.
It's
roughs
that
the
the
one
that
was
recorded
before
yeah
or
the
unsampled
one
it
doesn't
matter
it.
It
sounds
like,
though,
this
this
mechanism
that
the
trigger
for
suppression
is
different.
H
Yeah,
so
the
idea
here
for
us
is
like
the
motivation
is
that
we
know
that
some
of
our
applications
are
very
noisy
with,
like
just
like
internal
spans
or
even
specifically,
like
a
lot
of
say,
like
calls
to
like
a
memory
store
or
something
like
that,
and
we
know
that
in
the
grand
scheme
of
things,
if
we
want
to
preserve
the
quality
of
life
for
services
that
are
lower
volume,
but
maybe
talking
to
this
high
volume
service,
we
want
to
not
break
the
trace
or
break
the
structure,
but
we
still
need
to
control
the
span
volume
of
this
really
noisy
service
like
how
do
we
do
that?
H
How
do
we
preserve
the
structure
and
we're
trying
to
do
it
with?
Just
like
the
sampler
like
we're?
We
realized
that
the
only
kind
of
bumping
point
was
that
the
non-reporting
span
needed
to
be
amended
a
bit
to
support
this
yeah.
I
don't
really
have
like
everyone
should
do
this
kind
of
point,
I'm
just
sharing
something
that
I
thought
it
was
interesting
because
it's
like
potentially
solving
our
sampling
issue
with
one
of
our
highest
traffic
services,
and
I
wonder
if
there's
like
any
appetite
for
something
like
that
to
become
formal.
A
Yeah
yeah,
we
evaluated
that
the
sampling
idea
and
the
problem
was
that
with
sampling,
usually
what
it
means.
I'm
making
decision
for
this
span
and
everything
that
happens
after
it
under
it
right
so
and
like
if
you
plug
a
different
sampler.
If
you
don't
control
sampler
fully,
it
can
break
everything.
A
E
But
but
that's
there
is
now
a
version
of
sampling
like
this
trace
ratio,
sampling,
which
is
exactly
what
you're
describing
robert
it's
a
form
of
verbosity
control
where
individual
spans
can
be
sampled
out,
but
in
a
way
that
has
potentially
a
feedback
loop.
So
basically.
E
H
It
off
of
like
the
trace
id
ratio
sampler
and
then
we're
adding
our
own
custom
rules
to
the
things
that
we're
saying,
let's
dial
down
the
the
volume
of
these
spans
and
we
wanted
to
look
to
use
like
implement
the
probabilistic
sampler
and
then
actually
pull
some
of
that
in
there.
So
you
could
say:
oh
okay,
like
when
you
do
look
at
this.
This
span
is
represented
by
or
represents
like
100
spans,
or
something
like
that.
H
D
H
Like
so
yeah.
E
Yeah
yeah,
I
think
no
it's
great,
but
that
to
your
point,
there
is
like
there
was
a
sampling
group
who
was
trying
to
you
know,
get
the
trace
id
ratio
sampling
and
all
of
that,
over
the
finish
line.
E
Unfortunately,
I
had
to
stop
attending
that
group
because
it
conflicted
with
the
messaging
groups
we're
in
the
same
time
slot,
but
I
think
circling
back
with
j
macd
and
other
people
who
were
working
on
that
because
it's
the
same
problem.
I
guess
that's
what
I'm
saying
it's
like
open.
Telemetry
already
has
this
problem
because
we're
adding
this
ratio
sampling
to
it.
So
there
has
to
be
a
way
to
not
only
ensure
the
you
know.
E
The
traces
are
still
linked
together
through
the
sampler
being
able
to
come
back,
and
you
know
say
something
that
would
trigger
that
behavior,
but
also
a
way
to
you
know
preserve
an
indication
that
something
has
been
taken
out
of
the
trace,
which
I
think
is
the
other
critical
bit
and
they
have
some
trace
ratio
specific
stuff
there.
But
you
always
want
to
know
that
the
trace,
you're
looking
at
is
actually
incomplete
and
and
some
some
components
were
dropped,
but
both
as
a
human.
E
You
want
to
know
that
in
the
ui,
but
also
tools
that
analyze
trace
structure
and
do
like
comparative
analysis
across
trace
structures.
Jaeger
has
some
of
these
tools.
You
know
I've
seen
people
make
use
of
these
things
and
those
tools
just
get
get
totally
screwed
over
by,
I
think
more,
but
by
by
especially
like
a
ratio
sampling
thing
where
now
all
the
traces,
a
bunch
of
the
traces
are
going
to
be
subtly
different,
just
because
we
didn't
record
all
the
information.
E
So
at
any
rate,
I
think
those
are
the
two
things
that
have
to
happen
just
propagating
the
parent
id
so
that
things
stay
linked
together,
but
also
making
a
note
somehow
that
something
has
been
removed
from
this
trace.
E
H
E
Yeah,
that's
that's
really
a
hard
requirement
that
sampling
yeah
fracture
trees
yeah,
so
so
that
that
that
has
to
be
in
there
one
way
or
the
other
and
the
sampler
has
to
be
able
to
trigger
it.
And
then
this
collapse
span
collapsing
mechanism
that
lumila's
working
on
also
has
to
be
able
to
do
it.
Two
different
mechanisms,
but
I
think
both
of
them
can
be
determined
at
span
start
time
right.
So
you
know
they
can
both
just
trigger
the
same
same
mechanism.
A
I've
been
thinking
that
the
proposal
I
have
now
relies
on
adding
new
apis
right.
So
I
I
want
to
instrumentations
to
say
which
type
they
are
like
http,
for
example
right,
and
it
feels
to
me
that
whatever
api
additions,
we're
going
to
make
will
be
super
hard
to
do,
and
I
think
what
actually
serves
the
same
purpose
and
is
extensible
enough
is
having
a
convention
for
this
type
as
an
attribute.
A
A
We
have
a
prefix
on
database
database
does
something
we
on
cloud
events.
We
actually
put
it
into
the
spam
name
and
it's
something
some
piece
of
information
we
need
and
we
have,
but
it's
not
standardized.
A
So
I'm
I
was
thinking
about
changing
my
proposal
to
attribute
and
if
we
think
about
verbosity
it
sounds
like
it.
It
is
also
an
attribute,
and
this
is
there
is
a
convention.
A
The
other
idea
is
based
on
anarch's
instrumentation
api.
So
if
we
have
an
idea
of
attributes
like
basically
by
by
knowing
a
set
of
attributes,
we
can
say
what
the
type
is,
but
this
marries
this
proposal
to
other
things
which
we
might
don't
want
to
have,
or
I
don't
want
to
have
an
api,
so
do
anyone?
Does
anyone
has
any
thoughts
here
or
they
can
go
ahead
and
think
more
about
it?.
H
Okay,
I
feel
I
feel
like
it's
tricky
like
I
don't
want
to
just
throw
random
garbage
words,
because
it's
like
I'm
starting
to
really
venture
spending
more
time
recently
into
like
controlling
span
volume
like
for
reference
we've.
Finally,
gotten
about,
I
think,
98
of
all
of
our
applications
that
jumped
by
and
open
telemetry
like
we're
almost
done.
H
We
just
have
like
two
left,
so
this
is
why
these
like
there's
these
two
top
producers,
that
we
really
need
to
control
the
volume
on,
and
so
we're
spending
a
lot
more
time,
just
talking
about
sampling
and
like
the
implication
of
like
parent-based
and
like
controlling
the
verbosity,
and
I
think
that
ties
into
a
little
bit
of
what
you're
talking
about
and
like
the
suppression
bit
and
I'm
it's
it's
hard
and
it's
hard
because,
like
I
remember
last
time,
I
participated
in
those
conversations
like
I
have
that
bias,
where
I
have
full
control
over
everything
right,
whereas
a
lot
of
times
this
stuff
comes
up
and
you're
working
from
a
position
where
you
can't
modify
necessarily
the
code
that
is
operating
so
it's
like
for
me,
I'm
always
like.
H
E
E
E
You
know:
engineering,
architectural.
You
know
some
service
that
went
down
that
road.
At
some
point,
I'm
not
saying
that's
what
you're
doing
you
know
just
to
be
clear,
but
I
like
this
is
one
of
those
places
where
I
I
can't
I
can't
think
of
off
the
top
of
my
head.
A
super
clean,
simple
way
to
do
it,
but
I
am
a
little
nervous
about
getting
tricky
because
of
the
potential
for
that
to
create
edge
cases
or
to
to
create
behavior.
That
is
confusing
to
the
end
user.
E
Right,
like
the
more
the
more
of
a
deeper
under
the
more
of
this
kind
of
stuff.
We
add
the
deeper
the
understanding
of
the
end
user
needs
to
be
about
open
telemetry
if
adding
an
additional
piece
of
instrumentation,
for
example,
causes
what
another
piece
of
instrumentation
was
reporting
to
disappear.
E
That's
like
a
thing
people
would
have
to
have
to
understand
so,
and
I
haven't
thought
of
like
a
super
simple
way
to
to
to
do
it.
So
I'm
hoping
to
be
more
of
an
editor
and
look
at
other
people's
proposals.
Maybe
that
will
that
will
jog
my
brain
a
bit.
A
Yeah,
I'm
just
still
trying
to
understand
what.
Where
is
the
complexity,
and
what
I'm
saying
is
there
is
a
specification
which
tells
how
http
should
be
instrumented
right
and
whoever
follows
the
specification
says:
okay,
I'm
following
it,
and
if
something
underneath
it
says:
okay,
I'm
following
the
specification
too,
then
it's
it's
suppressed.
E
We
just
we
live
in
an
imperfect
world
and
a
mechanism
where
I
I'm
trying
to
write
some
code
and
add
some
spans
or
change
something,
and
then
it's
I'm
not
seeing
it
it's
not
showing
up,
and
it
turns
out
because
there's
this
behavior
where,
because
I
have
some
other
piece
of
instrumentation
running
it
actually
swallows
this
instrumentation
there.
I
just
worry
a
bit
about.
I
just
think
you
know
we
have
to
make
sure
it's
it's
either
super
bulletproof
or
or
it's
super
simple
for
people
to
understand
what
what
it's
doing.
B
A
E
A
What
I'm
saying
I
think
I
have,
but
I
don't
see
a
pass
forward
because
nobody
knows
so
I'm
trying
to
find
people
who
would
give
me
some
feedback
that,
like
based
on
this
idea,
but
I
what
I
hear
is
no,
it's
not
what
we
are
looking
for,
but
maybe
maybe
we
will
find
something
eventually,
but
it's
not
I'm
just
trying
to
understand.
Should
I
do
more
or
it's.
I
should
stop.
E
Sometimes,
like
maybe
like
a
code
example
doing
a
version
of
it
in
like
python
or
javascript
or
go
might
might
help,
because
that
would
widen
the
range
of
people
who
could
look
at
the
code
itself.
A
thing
I
found
whenever
it
people
start
to
struggle
a
little
bit
to
understand
the
spec
and
what
it's
doing.
E
We
really
had
to
do
a
lot
of
this
with
the
context
propagation
mechanism,
for
example,
there's
a
lot
of
people
bringing
up
edge
cases
and
doesn't
need
to
do
this.
It
doesn't
need
to
do
that
and
it
was
really
hard
to
sort
through
that
in
english,
just
working
on
the
spec,
but
having
everyone
just
like
write
code
examples
showing
the
situation
they
were
concerned
about
either
one
made
them
realize
it
wasn't
a
concern
or
two
made
other
people
understand.
E
You
know
what
what
the
concern
is
so
yeah.
That
might
be
my
suggestion.
I
guess
is
like.
Rather
than
just
inspect
some
example
code
in
like
another
language,
might
might
help
and
like
go
python
javascript.
Those
are
those
are
like
common
languages
that
are
like
easy
for
people
to
read
and
very
explicit
about
kind
of
what
they're
up
to
so
that
might
that
might
help
people
see.
Oh
okay.
This
is
a
simple
thing
I
get.
I
get
what
it's
doing.
E
A
Yeah
there
is
a
person
in
the
slack
nick.
A
He
works
on
some
apache
library,
the
database
and
he
asked
about
how
to
represent
attributes
for
batching.
We
don't
have
anything
about
it.
We
have
an
issue.
A
A
And
we
have
a
convention
which
says,
let's
say,
database
statement
right.
Oh
I'm
not
sure.
I'm
sorry
do
you
see
my
screen
yeah,
perfect
yeah.
So
when
we
set
database
attributes
or
realistically
any
attributes,
we
will
have
the
same
problem
in
messaging.
Conclude
events
everywhere.
A
If
we
deal
with
batching,
how
do
we
describe
those
attributes
on
a
single
batch
span?
So
the
statement
is
different.
The
operation
is
different
right.
We
don't
have
an
answer
and
I
guess
we
need
somebody
to
come
up
with
the
proposal
and
evaluated
right.
I'm
curious
if
anyone
tried
it
and
if
we
have
it
in
any
of
our
instrumentations.
E
E
E
The
answer
there
is
well
maybe
using
links
to
hook
all
these
batching
operations
together,
but
I'm
not
sure
if
that's
yeah,
I'm
not
sure
if
that
works
here.
A
I
E
Yeah
I
mean
that
is
that
it
is
tricky.
I
think
part
of
it
is
there's
probably
a
wide
range
of
how
people
use
batching
when
it
comes
to
figuring
out
like
if
you're
gonna
model
it
as
one
span.
What
should
the
span
name
be?
E
You
know
if
they're
consistently
making
the
same
batch
over
and
over
again,
then
you
could
come
up
with
a
a
good
name
for
processing
that
batch
of
stuff,
but
if
it's
like
arbitrary
things
being
batched
together,
just
for
you
know,
optimization
sake
yeah,
I
don't.
A
H
There's
a
bit
of
similarity
between,
like,
like
thinking
of
like
kafka,
instrumentation,
I've
done
and
looking
at
like
how
they
handle
batching
and,
like
the
current
spec,
like
there's
certain
parts
where
it
says
like
even
for
like
a
a
batch
span,
that's
processing
a
batch
of
messages
or
consuming
a
batch
of
messages
like
you
should
set
the
topic
that
these
messages
are
coming
from,
but
some
of
the
kafka
instrumentation
or
some
of
the
capital
libraries
that
exist,
one
of
the
more
popular
ones,
actually
will
pull
messages
from
multiple
topics.
H
So
how
do
you
set
that
attribute?
You
set
like
that
attribute
to
be
all
of
the
topics
and
just
like
remove
like
make
sure
it's
unique
right.
Like
I
don't
know
what
the
right
answer
is
like
the
current
proposals,
just
like
omit
that
attribute,
because
it's
going
to
be
either
incredibly
long
or
incredibly
incorrect
right,
which
I
don't
know
which
one's
worse
right
so
we're
just
dropping
it
for
that
particular
instrumentation
library,
but
that
is
like
the
whole
batching
thing
around
bad
attributes
is
like
seems
incredibly
difficult.
I
Yeah
that
reminds
me
that
I
didn't
even
think
about
bringing
up
the
spec
probably
should
have,
but
like
in
the
sqs
instrumentation.
I
think
right
obvious.
We
do
have
that
situation,
so
I
just
arbitrary
just
instead
fill
in
multiple
topics,
just
this
constant
word,
because
that
was
the
only
thing
that
I
could
come
up
with
to
deal
with
them.
I
E
E
You
know
like
what
are
when
you're,
trying
to
observe
these
batch
operations
and
sort
out
some
problem
like
what?
What
are
you
trying
to
do?
What
information
would
be
helpful,
like
what
kind
of
knob
are
you
going
to
try
to
turn?
E
So
that
might
be
helpful
if,
if
their
their
answer
is
like
well,
I
need
to
disaggregate
this
batch
of
things
to
figure
out
which
one
of
these
things
was
the
slow
thing.
That
sounds
like
information.
You
would
have
to
get
from
the
server
side,
potentially
right,
like
the
processing
side
where
it
takes
in
the
batch,
and
then
it
disaggregates
them
and
performs
various
queries
like
that.
H
I
didn't
want
to
create
the
expectation-
and
I
know
that
there
is
like
the
messaging
spec
that's
being
worked
on,
but
like
one
of
our
instrumentation
libraries
for
kafka,
you
can
hook
and
hook
into
like
the
batch
processing
loop,
so
it
pulls
like
a
batch
and
then
it
will
give
you
each
message
in
the
batch
and
then
like
allows
like
the
consumer
or
the
client
to
just
like
get
one
message
at
a
time
and
we
will
actually
extract
links
from
the
individual
messages.
H
So
each
like
this,
the
batch,
the
span
for
like
the
entirety
of
the
batch,
has
many
links,
and
I
thought
maybe
those
individual
links
can
have
attributes
and
maybe
those
attributes
could
potentially
carry
the
topics
for
each
of
those
messages
right
so
that
if
you
now
now
you
are
de-aggregating,
you
don't
have
a
single
attribute
for
like
each
one
of
those,
but
that
seemed
okay.
H
A
And
the
problem
was
a
messaging
that,
like
I
own
the
sdk
who
does
it,
but
I
don't
control
how
it's
used
right
and
I
I
can.
I
cannot
split
this
one
bench
spun
into
multiple
and
I
have
to
put
everything
on
on
one
and
for
many
people.
They
they
just
aggregate
stuff
right.
They
don't
it's.
It's
logical
one
thing
as
a
process
doesn't
match.
So
it's
just
hard
to
find
the
generic
enough
model
here
but
attribute
some
links
sounds
promising.
E
Yeah
and
speaking
of
attributes
on
links
actually
for
the
retry
situation
we
were
just
looking
at.
I
was
going
to
bring
it
up
before,
but
we
were
talking
about
other
stuff.
E
This
also
seems
like
a
place
where
link
attributes
would
be
helpful,
potentially
right,
like
if
you're
trying
to
show
this
is
a
chain
of
retries
at
minimum.
Explaining
the
type
of
link
that
is
going
on
here
would
probably
be
helpful
information
to
a
back
end
so
that
it
knows
it's
looking
at
at
retries
or
back
offs
versus
you
know
batch
processing
or
something
else.
E
E
H
They're
like
because
there's
no
formal
job
spec
we've
been
using
the
messaging
spec
and
we've
been
just
like
adding
the
option
for
like
jobs
that
in
queue
jobs,
because
you
have
a
spam
for
the
inquiry
of
the
processor,
we
use
the
links
to
connect
them
and
that's
not
the
I
think,
that's
like.
Actually
what
we
have
is
the
default
for
instrumentation,
because
yeah
it
just
makes
more
sense.
You
guys
have.
H
Built
observability
system
for
like
no,
we
well,
we
we
try
to
if
the
spec
doesn't
define
the
default
in
like
if
there's
no
default
definition
of
what
it
should
be,
we
try
to
do
what
we
think
is
best
and
so,
like
our
internal,
we
have
a
just
a
pre-configured
wrapper
for
all
the
apps
that
shopify
to
use
so
that,
like,
if
you're
an
app
owner,
you
just
pull
in
our
gem
that
we
own
internally,
and
it
just
like,
gives
you
all
the
defaults
points
to
our
collector,
all
that
kind
of
stuff
it
sets
like
yeah.
H
It
just
does
all
the
things
that
we
think
are
the
right
correct
thing,
but
for
the
most
part
it
is
very
close
to
parity
with,
what's
upstream,
because
like
right,
if
it
makes
sense
for
us,
it
probably
makes
sense
for
the
other,
like
the
rest
of
like
the
ruby
community,
and
we
work
with
like
people
at
github
and
stuff
like
that.
So
we
try.
B
H
Interact
with
the
other
big
ruby
companies
to
just
make
sure
like
just
do
what
makes
sense.
We
don't
want
to
maintain
like
that
two
things
we
don't
want
to
maintain
the
open
source
one
and
then
our
own
fork
right.
E
Yeah
yeah,
but
but
I
meant
you're
you're
shoveling,
all
this
data
into
some
kind
of
analysis
tool,
slash
storage,
place
that
that
understands
links,
you've
got
a
you're
getting.
H
Packages,
yeah
yeah,
so
we
have
a
couple
places
we're
stuffing
all
our
spans
right
now
and
yeah.
We
do.
Our
ui
doesn't
really
do
a
good
job
of
surfacing
links
to
be
honest
right
now,
that's
like
something
that
I've
been
kind
of
complaining
about
too.
If
you
can't
are
responsible
for
that,
I
think
links
are
incredible
like
they're,
so
powerful.
E
They're,
really
good
lightstep
doesn't
really
support
them.
Yet
I
think
a
lot
of
these
analysis
tools
don't
because
they're
a
little
bit
novel
like
open
senses,
kind
of
had
them,
but
nobody
cared
and
like
open
telemetry
has
them,
but
you
know
there
there
hasn't
been
a
lot
of
like
market
pressure
to
use
a
term
of
art.
E
H
People
don't
get
how
powerful
they
are
yet.
We've
actually
considered
this
isn't
special
knowledge,
but
we're
we've
actually
considered
like
breaking
up
our
entire
traces
by
link.
So
no
longer
you.
H
A
continuous
trace
from
all
across
your
services,
it
would
be
links
connecting
them
together,
because
what
we
found
just
from
like
I'm
the
person
who
gets
the
brunt
of
the
feedback
from
all
of
our
like
observability
users,
and
they
don't
really
care
about
somebody
else's
server
service,
like
99
of
the
time
they
care
about
how
theirs
is
behaving.
H
But
we
still
want
to
connect
the
two,
so
they
can
see
like
what
was
going
on
above
or
below
them.
When
an
incident
happened
right,
but
most
of
the
time
they
just
want
to
look
at
their
stuff
right.
So
why
not
make
that
the
default
and
break
all
the
service
boundaries
with
links
right?
So
that's
something.
We've
discussed
that
we
haven't
committed
to
that.
H
It
has
other
like
desirable,
upstream
effects
that
it
can
remove
a
lot
of
pressure
from
your
collection
pipeline
and
your
storage
pipeline
having
something
store
like
we
have
generated
30
million
spam
traces
before
breaking.
That
up
is
a
really
nice
thing
to
do
to
your
infrastructure
team
so
so
like
there
are
a
lot
of
positive
effects
there,
but
we
still
have
to
consider
like
the
ui
implication,
because
they're
not
bi-directional
right
or
we
probably
wouldn't
implement
bi-directional
legacy.
H
So
so
there's
that
part
that's
been
something
we're
like
do.
We
want
that
right
now,
we're
saying
no
we'll
keep
it
in
our
back
pocket
as
like,
further
improvement,
but
francis
I
don't.
I
don't
know
if
you've
ever
talked
to
francis
bogdany
before,
but
he's
kind
of
her
her
big
brain
and
he
he's
coined
the
term
trace,
fragments
for
it.
E
E
I
just
can't
trust
the
trace
id
coming
in
here.
You
know
just
having
that
trace
end
and
starting
a
new
trace,
but
linking
it
to
the
external
trace
is
just
a
very
simple
solution
for
what
would
otherwise
be
a
tricky
security
problem.
H
Yeah,
that's
something
that
we're
working
on
right
away
as
well,
because
we
just
don't
because
we
want
to
use
baggage
in
a
lot
of
weird
and
interesting
ways,
because
why
not
baggage
is
wonderful
and
you
can
have
people
do
experiments
and
maybe
actually
change
the
behavior
of
the
code
based
off
of
baggage
values.
Why
not
do
that
right?
A
lot.
H
E
H
Yeah
right,
but
you
have
to
be
able
to
control
who
is
setting
it
where
those
values
are
coming
from
right
and
so
like.
We
want
to
basically
look
at
improving,
like
the
sanitation
layer
on
the
boundaries
of
our
entire
ecosystem-
right,
oh
my
god,
having
to
control
that
so.
E
Right
like
this
there's
just
like
a
this
is
a
thing
that
exists
in
reality,
but
is
like
an
architectural
void
in
like
the
tooling
that
we
have
that
really
sucks,
even
something
as
simple
as
just
like
wanting
to
drop
baggage
when
it
it's
heading
towards.
You
know
the
edge
of
your
trust
boundary.
You
just
want
that
to
happen,
but
you,
if
there's
no
concept
of
a
trust
boundary
like
how
are
you
supposed
to
do
that.
A
We've
been
investigating
how
we
can
do
like
in
cloud.
We
have
a
different
problem
as
well,
where
we
want
to
expose
some
traces
to
users,
but
they
are
when
the
boundaries
right
and
that
we
also
want
to
have
traces
internally
and
we,
we
kind
of,
have
to
report
to
different
things
and
we
ended
up
like
we
actually
stuck
at
the
idea.
How
do
we
describe
the
stress
boundaries?
How
do
we
configure
it?
So
it's
not
crazy
and
like
actually
the
baggage
thing
it.
A
It
is
the
one
that
replaces
like
continuous
traces,
because
this
is
your
business
logic
right.
They
can
vary
everything
for
this
user
for
this
transaction
and
I
don't
actually
care
how
many
traces
there
are
yeah
and
so
the
all
these
trust
boundaries
and
the
baggage
questions
are
super
interesting,
but
we
are
so
far
from
solving
them.
H
Right,
yeah,
that's
something
that's
been
asked
too
that
I'm
terrified
to
actually
start
working
on
is
like
we
are
the
consumers
of
our
observability
stuff,
but
as
like,
our
company
has
like
tenants
that
are
operating
businesses
on
it
and
they
have
potentially
their
own
developer
teams.
How
do
we
surface
observability
observability
signals
to
them
about
how
their
code
is
potentially
operating
on
our
system,
and
I
haven't
touched
that
and
I
don't
that's
scary.
That's
a
scary
one.
E
Yeah
yeah
but
important.
I
think
I
would
love
this
is
where
column
compress.
I
don't
know
if
you've
looked
at
that
robert,
like
a
column,
compressed
proposal
for
another,
basically
another
encoding
of
otlp,
like
a
columnar
encoding,
that
at
scale
has
like
much
better
performance
characteristics
than
the
row
encoded
version
of
it.
We
have
right
now
here.
Let
me
let
me
say
that.
E
It
is
based,
it
uses,
apache
arrow,
it's
basically
apache
arrow
for
open
telemetry
proposal,
but
that's
one
of
the
things
I
mean,
I
think
in
general.
It's
probably
would
be
helpful
for
big
operations
like
shopify,
but
certainly
when
it
comes
into
like
I
want
to
fire
hose
like
all
of
the
like
tracing
like,
I
have
a
multi-tenant
tracing
system
and
then
each
tenant
is
going
to
have
a
fire
hose
of
otlp.
E
H
H
On
my
my
team,
who's
been
working
like
I
work
pretty
much
exclusively
on
the
instrumentation
side
of
things
and
then
one
of
my
just,
like
actual
like
real-life
friends,
joined
the
company
and
he's
working
on
just
the
transport
side
of
things
and
he's
been
talking
about
getting
apache
arrow
as
like
part
of
our
transfer
pipeline
for
a
long
time
now
he
really
wants
to,
but
he's
just
there's
so
much
stuff
like
getting
set
up
first
right,
but,
like
he's
gonna,
be
ecstatic
and
he
has
already
been
talking
about
it
right
and
I
think
he
just
wanted
to
share
the
proposal.
H
I
didn't
remember
what
the
name
was
yeah
he's
like
watching
that
stuff,
like
a
hawk,
because
it
seems
like
a
great
idea.
E
Yeah
get
get
them
over
here,
just
adding
that
to
the
collector
is
it
would
like
really
make
implementing
a
lot
simpler
if
you
can
just
flip
a
switch
in
the
collector.
Obviously,
your
back
end
has
to
deal
with
it
too,
but
whatever
so
so
yeah.
If
you
have
an
excited
person
over
there,
please
please
point
them
towards
this
lots
of
excited
people,
not
a
lot
of
time.
That's
the
issue
right
now.
E
We're
getting
some
help
here,
it's
actually
f5.
That's
that's
pushing
this
particular
proposal
because
they're,
I
think
similar
similar
place.
Right
of
you
know
they
want
to
use
open
telemetry,
but
they
run
huge
honking
systems
that
are
very
high
throughput,
and
so
the
current
otlp
protocol
is
just
like
not
very
optimal
to
like
pull.
You
know,
spew
data
out
of
a
cdn
or
some
super
high
volume
service,
like
that,
we.
H
Would
just
like
to
get
off
of
we've
been
using
the
google
protobuf
gem
for
ruby
and
it
has
not
been
my
best
friend.
I
have
had
a
lot
of
angry
people
yell
at
me,
because
it
will
cause
memory
leaks
and
bring
down
services
from
minor
revision
changes.