►
From YouTube: OpenTracing Monthly Call - 2019-02-01
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
A
A
B
Got
ready
from
Facebook
when
I
introduce
yourselves
real,
quick.
A
A
A
D
A
D
A
A
A
So
a
while
back,
maybe
December,
a
sort
of
exploratory
technical
work
group
started
getting
together
because
these
projects
are
so
similar
if
there
api's
are
very
similar
but
on
one
hand
you've
got
a
project,
that's
more
like
an
implementation
and
on
that
doesn't
have
a
really
abstracted
API
and
then,
on
the
other
side,
you've
got
an
abstracted
API,
but
no
reference
implementation
and
so
for
a
while.
We've
been
like
man.
A
If
we
could
just
bridge
these
api's
and
share
one,
then
we
could
have
a
bigger
project
where
it
was
just
as
abstracted,
so
people
can
still
continue
to
plug
their
own
agents
into
the
instrumentation,
without
necessarily
having
a
whole
bunch
of
hardware
in
the
middle
that
they
may
or
may
not
want
by
hardware.
I
mean
software,
sorry
and
at
the
same
time
we
could
have
a
really
really
awesome
reference
implementation
that
people
were
willing
to
invest
money
into
and
kind
of
hold
down.
So
that
seemed
like
a
big
win.
A
A
A
A
That'll
be
coming
soon
to
review
and
there's
also
now
some
movement
from
the
founders
and
single
men
on
one
side,
I
believe
Preet
who's
in
charge
of
the
open
census
project
on
the
Google
side,
looking
to
found
a
kind
of
like
governance,
bootstrapping
group
to
figure
out
what
a
governance
model
would
look
like
for
the
merged
projects.
A
Last
but
not
least,
we're
also
really
interested
in
a
new
name.
If
we
are
gonna
merge
these
projects,
the
scope
will
be
increased
beyond
list
and
open
tracing
to
include
metrics.
At
the
same
time,
open
tracing
is
like
a
large
existing
project.
We
don't
want
to
lose
the
name.
Open
census
didn't
lose
their
name,
so
we
decided
everyone
would
lose
a
name
and
we'll
come
up
with
a
new
name
for
the
merged
project.
If
we
do
it,
of
course,
no
one
has
this
new
merge
name.
A
F
As
yeah
test
that
most
of
it
already
I
I
would
maybe
it's
not
like
this
is
like
literally
dying
I,
mean
I,
think
there's
the
I
would
maybe
add
to
everything
to
have
said
that
there's
overall,
a
feeling
like
both
these
projects
really
exists
in
order
to
accelerate
the
adoption
of
tracing
metrics,
observability
technologies
and
so
on
and
so
forth,
and
not
having
two
projects
out
there,
even
if
both
of
them
are
great
having
two
projects
instead
of
one
actually
decelerates
adoption,
or
at
least
a
suboptimal.
So
that's
really
like
the
biggest
problem.
F
I
think
it's
true.
If
you're
going
to
have
reference
implementation
and
an
API
and
all
that,
but
really
like
fundamentally,
the
biggest
problem
is
that
having
both
of
these
projects
is
creating
confusion
and
tax
in
terms
of
adoption
like
us,
really
like
the
biggest
problem,
we're
trying
to
solve
I
think
the
the
governance
discussion
I
think
is
like
pretty
good
in
that
it's
some.
The
alignment
in
terms
of
what
we're
trying
to
achieve
is
really
clear
and
obvious,
but
it's
not
actually
done
and
I.
Think
like
this.
F
In
my
mind,
the
presentation
of
this
update
should
be
more
like
everyone
wants
this
to
happen
versus
this
is
definitely
going
to
happen.
This
will
definitely
happen
once
it's
actually
happening,
but
it's
not
quite
there
yet
and
I
think
we
fall
like
would
be
good,
giving
people
a
heads
up
that
the
discussion
is
happening,
so
we
don't
want
to
feel
like
some
kind
of
closed-door
thing,
but
it's
not
actually
done
yet
and
until
it
is
I,
don't
want
to
say,
okay,
great,
like
let's
pop
the
champagne
etc.
F
Although
I
think
everyone
recognizes
that
continuing
in
the
current
parallel
track
is
pretty
wasteful
and
confusing
for
end
users,
so
that
best,
like
the
really
concerning
part
of
it,
I
would
say
like
the
next
month
or
something
like
that.
We
should
probably
be
able
to
say
that
this
is
actually
happening,
but
I
don't
want
to.
You
know,
call
it
before
it's
done
or
something's
yeah.
A
D
A
That
group
this
past
week
hit
a
point
where
we
felt
like
managed
to
address
everything
different
between
the
two
project
and
it
seemed
like
there
was
a
pretty
obvious
way
to
like
solve
those
differences
in
a
way
where
you
could.
We
could
put
out
a
new
API
and
just
simply
say
this
is
like
the
next
version
of
the
API
for
each
project
and
wouldn't
feel
like
like
a
huge
record
scratch
or
something
that
would
be
very
difficult.
A
You
know
to
continue
to
maintain
that
kind
of
like
backwards,
compatibility
and
bridging
that
we
always
like
to
do
in
open
tracing
from
version
to
version,
and
since
we
again
we
don't
have
a
new
API,
but
we
have
enough
of
a
spike
that
that
feels
good.
It
feels
like
the
right
time
to
be
starting
to
ring
the
bell
about
this
project.
F
Yeah
sort
of
I
want
to
say
that
I
mean
this
is
I
mean
anything
about
like
the
technical
details.
I
think
does
like
we're
a
little
bit
more
discussion,
but
I
have
been
arguing
for
whatever
the
Smurfs
thing
is
to
try
and
be
more
decoupled
about
things.
Then
sentences
been
I
think
the
hook
and
tracing
scope
is
probably
a
little
bit
too
narrow
and
retrospect
in
that
people
don't
want
to
have
like
many
different
nouns
they
have
to
deal
with.
F
They
want
to
have
like
one
now
but
like
having
all
of
the
different
pieces
coupled
together,
any
more
than
is
necessary.
That
weakens
the
whole
I
think.
If
for
something
like
this
I
could
get
kind
of
sprawling
or
it's
like
well
now,
let's
not
stack
traces
now,
that's
that
long
it
just
it
could
get
really
big
very
quickly,
so
I
think
like
it
should
have.
I
would
argue
if
I
mean
I'm
not
saying
well.
F
G
I
can
definitely
say
that
one
of
the
things
that
we've
been
talking
a
lot
about
from
the
open
tracing
side
is
making
sure
that
there
is
a
clean
separation
like
of
attractions
and
interfaces
from
implementations.
So
we
focused
on
the
tracing
piece
for
now,
but
I.
Don't
see
a
reason
that
we
couldn't
also
do
the
same
for
the
metrics
piece.
H
C
A
G
F
F
A
If
you
have
concerns,
you
feel,
are
more
private,
you
know
absolutely
reach
out
to
me,
reach
out
to
Ben
we're
happy
to
address
it
and
get
you
up
to
speed
on
what's
going
on
and
as
far
as
governance
and
other
things.
That's
that's
still
a
big
question.
Mark
though
I
know
in
talking
to
at
least
some
people
that
Trent.
H
A
And
it's
fine
talking
about
this
stuffing
dinner
as
well.
I
would
think
people
to
read
this
and
and
just
ask
questions
and
get
her.
Basically,
it's
probably
the
easiest
way
to
get
answers.
Cool
I
would
say
the
biggest
change
we
might
want
to
make
as
part
of
this
from
the
open
tracing
side.
Is
this
general
feeling
that
you
know
especially
just
separate
in
open
tracing,
perhaps
for
convenience,
the
tracing,
API
and
the
context
propagation
API
are
the
same.
A
So
you
know
the
spans
are
the
are
the
context
and
they're
propagating
the
context
and
in
open
tracing
there
is
a
lower
sorry,
an
open
census,
there's
a
lower
level
kind
of
context,
propagation
mechanism
and
then
tracing
and
metrics,
and
these
other
things
they're
all
writing.
On
top
of
that,
there's
kind
of
a
feeling,
like
that's
a
better
model,
that's
just
a
cleaner
separation,
so
I
would
say
from
the
open
tracing
side
trying
to
move
over
to
that
model.
In
this
next
version,
the
API
is
probably
the
biggest
change
we
would
see
from
our
end.
I
Mean
I
definitely
be
more
than
willing
to.
You
know,
help
with
those
discussions
and
sort
of
look
into
them.
I.
Think
one
observation
is
that
we
actually
do
have
sort
of
partial,
open
tracing
bindings
for
our
stuff
internally,
that
you
know
some
folks
who
want
to
open-source
their
things
are
using
the
the
span
model
is
sort
of
more
constrained,
but
so
we
just
have
to
be
a
little
bit.
I
You
know
opinionated
about
how
we
we
sort
of
do
that
mapping
from
for
more
things
into
spans,
but
you
know
it's
it's
doable,
but
anyway,
yeah
I'd
be
I'd,
be
super
interested
in
you
know,
being
a
part
of
those
conversations
you
know
and
sort
of
seeing.
If
there's
anything
that
makes
sense,
you
know
there
I
think.
The
real
thing
is
that
the
data
model
we
have
with
canopy
is
inherently
more
flexible,
but
also
inherently
more
complicated
right.
I
So
it
and
people
are
like
super
familiar
with
spans
and
things
like
that,
and
the
language
and
terminology
around
it,
so
I
sort
of
get
that
from
an
external
point
of
you
know
view
it's
like.
Do
you
really
want
to
really
want
to
try
and
go
with
a
you
know,
another
another
data
model
when
there's
sort
of
one
that's
been
around,
for
you
know
a
couple
decades
that
works
for
most
people
so
but
anyway,
yeah.
If
people
are
interested
in
that
yeah,
let's,
let's
figure
out
something
we
can
talk
through
it
yeah.
A
I
definitely
be
interested
for
feedback.
I
would
be
nervous,
I
you
the
opportunity
to
merge
these
projects
and
there's
an
opportunity
to
to
fix
things
while
we're
at
it.
But
I
also
would
be
wary
that
you
know
we
don't
it'd
be
straight
to
too
far
away
from
what
either
like
the
other
thing.
This
project
has
to
do
is
make
sure
we've
got
a
bridge,
so
we
don't.
A
We
don't
pull
a
you
know,
Python
3000
or
a
Perl
6
in
the
process
of
doing
this,
but
I
think
the
number
one
thing
it
in
forward
is
to
make
sure
yeah
everyone
who
is
binding
agents
or
complicated
things
or
people
like
Chris
or
way
or
y'all
at
Facebook.
You
have
some
evented
model,
that's
just
like
totally
different
from
spans,
but
would
still
like
to
you
know,
play
making
sure
there
hasn't
been
something
that
makes
that
worse
or
if
there's
some
easy
way
to
make
it
better.
I
Yeah
I
can
I
can
I
can
make
jump
in
the
Gator,
and
then
we
can
sort
of
you
know
start
talking
through
it
through
it
there,
but
but
yeah
I
mean
to
the
extent
that
we
can
provide
sort
of
like
useful
feedback
here.
You
know
I
think
we
definitely
be
interested
in
doing
it.
You
know,
but
also
sort
of
definitely
understand
the.
I
If
you
really
think
that
the
events
are
interesting,
but
what's
really
interesting
is
it's
just
very
different
sort
of
data
models
right,
a
tree
of
spans
versus
a
data
model,
that's
composed
of
a
block
at
the
end
of
the
day.
You
know
both
system
will
send
a
fence
right,
it's
what's
in
them
right
and
how
they
get
put
back
together
into
a
data
model.
It's
interesting
in
the
language.
I
A
I
What
it's
worth
I
would
say:
we're
also
to
kick
off
an
effort.
This
half
to
get
more
analyze
complex,
prop
as
well,
very
similar
observation
that
that
should
be
at
a
lower
layer.
Alright,
other
things
other
than
tracing
can
ride.
On
top,
you
know
things
like
you
know:
scooter,
datasets,
metrics,
corporation,
that's
sort
of
another
point,
conversations
or
I
didn't
sort
of
compare
design
notes.
You.
A
A
People
to
start
playing
around
with
it,
so
I
kind
of
wanted
to
remind
people
of
its
existence
and
just
sort
of
pitch
it
again
just
to
quickly
explain
the
idea
behind
special
agent.
Is
it's
like
an
agent,
but
really
it
just
has
one
job
which
is
to
install
manual
instrumentation
so
rather
than
having
the
agent
inside
of
it,
have
all
the
instrumentation
bundled
up
and
a
lot
of
tricky
ways
of
inserting
everything.
A
It
has
a
more
generalized
model
where
you
have
a
program
that
at
boot
has
a
jar
of
jars
that
contain
all
possible
instrumentations.
Each
instrumentation
has
a
way
of
basically
identifying
whether
it
could
bind
to
something
and
rules
for
for
how
it
might
get
injected,
and
so
the
agents
job
is
just
to
go
down
that
list
and
try
to
install
everything.
So
it's
sort
of
like
when
I
say
it's
an
open-source
agent
I,
don't
just
mean,
like
the
code,
is
open
source
but
we're
hoping
that
it's
a
more
extensible
agent.
A
In
particular,
we
don't
want
a
world
where
open
tracing
as
a
project
is
providing
some
kind
of
like
agent
think
or
installing
instrumentation.
But
then
the
instrumentation
you
get
is
somehow
different
than
the
instrumentation
you
would
get
if
you
manually
install
the
plugin,
that's
using.
Why
we're
doing
the
extra
effort
to
keep
things
decoupled?
Here's
you
know
if
we
have
a
plugin
for
okay
HTTP,
just
because
your
instrumenting
HTTP,
with
something
like
an
agent
that
installs
that
for
you
versus
I,
installed
that
okay
HTTP
instrumentation
myself
from
open
tracing
contribs.
A
Ideally
that's
like
the
same
piece
of
instrumentation
and
if
you
update
that
manual
instrumentation
and
can
trim,
then
special
agent
would
just
consume
the
latest
version
of
that.
So
it's
a
way
of
having
an
agent
but
still
having
all
of
the
instrumentation
being
developed
and
managed
by
the
community
and
by
the
ecosystem
rather
having
to
centralize
it
all
into
one.
One
group
that's
trying
to
manage
all
of
the
instrumentation,
because
it's
baked
into
the
agent.
That
was
like
the
big
nut
we
wanted
to
crack
and
we
feel
like
we're.
A
We've
got
something
dead,
wobbly
works
pretty
well,
and
the
final
piece
was
the
final
two
pieces.
We're
working
on
right
now
are
getting
it
to
install
tracers
and
allowing
you
to
configure
your
instrumentation
and
your
tracers
and
so
for
I.
Imagine
there's
a
number
of
people
who
are
in
groups
that
are
involved
with
open
tracing
who
already
have
their
own
agent
because
they
work
for
some
traces.
You
know
observability
company,
that
has
an
APM
thing
and
I.
A
Imagine
those
people
are
a
little
less
interested
in
the
open
tracing
agent,
but
I
would
still
encourage
them
to
take
a
look
at
it
think
about
how
they
might
make
use
of
it
for
groups
that
don't
have
an
agent
and
would
just
like
they're
tracing
client
to
be
bundled
in
this
thing,
so
that
if
someone
is
running
that
using
this
agent
to
install
instrumentation
for
them,
you
know
they
can
also
use
it
to
install
their
a
tracing.
Client
I'm
not
sure
about
this
agent,
installing
other
agents
or
how
all
of
that
would
work.
H
A
A
Not
quite
it's,
it's
we've,
just
we're
just
now
getting
up
into
a
place
where
we
feel
like
someone
could
use
it.
I
mean
it.
What
has
been
able
to
do
so
far
is
take
some
amount
of
Java
instrumentation
and
if
you
install
it
that
will
install
it,
and
that
seems
fine,
but
to
really
get
feedback
we
feel
like
it
needs
to
also
install
the
tracing
clients
and
be
little
configurable
before
we
could
really
get
that
kind
of
feedback
of
like.
A
If
you
just
throw
this
agent
at
your
jar,
do
you
now
get
traces
coming
out
of
it
so
that
we're
just
kind
of
launching
into
that
so
I
think
in
this
next
month
we're
gonna
be
trying
to
run
with
it.
Explain
to
us
how
they're
deploying
things
you
know
how
they're
how,
as
like
from
a
deployment
standpoint
in
an
operational
standpoint,
they
would
want
to
be
combining
something
like
this
agent
with
with
their
soft
way
that
they're
running.
H
A
E
Hit
you
up
and
get
er
I
would
be
interested
in,
like
some
opinions
from
vendors
as
to
what
is
different
about
their
engines
from
versus
this
one,
and
because
obviously,
data
dog,
an
elastic,
went
after
their
own
ones,
and
so
like
is
there
anything
that
we're
missing
in
it
or
why
can't
we
just
converse
on
this
thing?
Yeah.
H
J
A
What
one
thing
I
we
are
concerned
about
with
this
approach
is
we
think
it's
a
harder
approach,
because
we
want
to
have
a
kind
of
standardized
generic
mechanism
where
someone.
In
addition,
they
write
their
manual
plugin
and
then
they
add
a
file
there.
It's
used
to
be
sort
of
like
bite,
man
rules,
but
we've
actually
moved
away
from
bite
man
over
to
fight
buddy,
at
least
for
Java.
Just
reasons
like
you,
wouldn't
you
would
add,
you
know
your
little
set
of
rules
for
how
this
plug-in
wants
to
be
detected
and
wants
to
be
installed.
A
But
I.
You
know,
runtimes
are
notoriously
cranky
agents
traditionally
end
up
with
like
lots
and
lots
of
special
tricks,
and
you
know
all
kinds
of
like
there's
all
kinds
of
shortcuts
and
special
tricks
and
like
horrible
kitchen,
sink
garbage,
you
would
never
want
people
to
see
that
you
could
stuff
inside
an
agent
if
you
were
just
doing
it
all.
It's
all
one
big
black
box,
and
by
doing
it
as
not
a
black
box,
where
we're
saying
here's
the
official
mechanism
for
how
it
works
and
here's
how
you
can
plug
into
it.
A
J
Think
the
biggest
trickiness
around
agents
is
around,
or
at
least
for
Java-
is
the
the
class
path
dealing
with
the
class
path,
oh
my
god
yeah
so
yeah.
On
the
plus
side,
there
is
no
two
distinct
implementations
of
commercial
agents
that
you
can
look
to
to
see
how
that's
being
figured
out
both
us
and
elastic,
so
yeah.
A
J
Actually
started
that
so
the
the
folks
that
did
the
very
very
first
POC
with
data
dog
kind
of
started,
with
the
open,
tracings
Java
agent
as
a
template,
and
so
they
were
also
based
off
of
white
man
and
yeah
very
early
on.
We
made
that
to
bite
buddy,
and
it
was
a
significant
improvement
in
in
in
our
life
yeah.
A
I'm
gonna
just
paste:
this
is
in
the
in
the
agenda.
I'm
just
gonna
paste
a
link
to
the
repo
in
the
chat,
so
people
have
it
we'll
probably
be
doing
a
blog
post
about
this
the
next
week
or
two
but
yeah.
This
is
just
a
heads
up
and
also
just
a
reminder
like
I
open
tracing
is
100%
focused
on
you
know,
an
abstract,
API
and
manual
instrumentation,
and
not
somehow
getting
people
glued
on
to
any
one
particular
vendor
implementation,
and
so
we
see
this
special
agent.
A
It's
the
beginning
of
we've
got
this
solid
manual,
instrumentation
API.
How
can
you
build
the
rest
of
like
an
open
source,
open
ecosystem?
On
top
of
that?
That's
you
know,
can
helping
the
community,
but
also
you
know,
part
of
the
community
effort,
and
we
see
this
special
agent
as
it's
filling
that
role
installing
the
I
think
we
still
have
room
to
grow
in
terms
of
coming
up
with
a
simpler
instrumentation
pattern,
for
the
simpler
cases
like
easier
API
is
for
manual.
Instrumentation.
A
A
And
that's
my
pitch
on
special
agent.
Please
check
out
the
repo,
so
you
start
poking
around
with
it
if
you
are
interested
in
Java
and
if
you
are
interested
in
this
project-
and
you
think
this
is
a
cool
idea
and
we
are
interested
in
starting
a
similar
special
agent
for
other
languages
where
this
might
be
possible.
That
would
be
super
awesome.
So
please
contact
us
if
you're
interested
in
Ruby
or
Python
or
some
other
language
and
working
on
this
project.
F
It
would
be
interesting
to
have
other
vendors
kind
of
poking
at
it.
I
guess,
if
sort
of
a
mutual
interest
I'm
not
sure
how
both
feel
about
this,
but,
generally
speaking,
my
impression
is
that
sort
of,
like
smart
agents
are
not
that
differentiating
anymore.
It's
like
I,
really
don't
what
I
mean
I,
don't
want
to
build.
One
I
think
it's
kind
of
a
waste
of
time
not
to
just
contribute
it.
F
Maybe
this
is
not
the
time
people
gonna
say
it,
but
if
people
actually
want
to
like
differentiate
this
stuff,
it's
kind
of
surprising
to
me,
and
if
this
is
not
the
right
approach
to
do,
it
would
be
great
to
hear
like
what
is
the
right
approach.
So
I
feel
like
we
would
all
benefit
anyone
who's
trying
to
implement
tracing
from
a
back-end
standpoint.
We
would
benefit
by
making
adoption
lot
easier
and
it
would
probably
we
probably
get
there
faster
and
basically
kind
of
accelerate
adoption
of
things
like
this.
F
If
there
was
a
really
solid
like
zero
touch,
pure
open-source
option-
and
that's
really
what
this
product
is
attempting
to
accomplish
is
to
be
a
lightweight
layer
between
you
know
the
application
end-user,
and
all
this
you
know
diaspora
instrumentation.
So
if
this
approach
seems
totally
wrong
and
that's
the
reason
people
don't
want
to
get
involved,
it
would
be
great
to
hear
that
feedback
too.
F
I
do
have
a
sense
yeah.
I
tasked
them
about
that,
because
I
felt
like
it
was
really
tempting
to
throw
all
that
into
the
same
repo
and
jar
whatever,
as
as
the
thing
itself
for
just
you
know
vertical
ization
reasons,
but
it
also
can
get
really
nasty
because
there's
a
lot
of
software
out
there
and
it
seemed
like
the
direction
they
wanted
to
take
was-
and
this
is
you
know,
I'm
I
could
be
off,
but
last
I
spoke
about.
It
I
think
they
felt
like
they
wanted
things
that
were
really
in
their
mind.
F
Kind
of
elevated
to,
like
course,
status,
be
part
of
the
main
repo
like
something
like
G
RPC
would
be
on
that
list.
But
if
there
is
some
random
framework
or
something
I,
don't
think
that
their
intention
was
to
put
that
into
the
open
sense.
This
main
repo
and
I
think
they
wanted
to
take
a
path.
Similar
boat
racing
has
done
whether
if
they
had
a
control,
repo
or
uncomfortable
organization,
or
not
that
things
that
were
outside
of,
like
the
you
know,
fully
embraced.
Core
projects
would
not
live
in
open
census,
repo.
What.
F
A
A
J
J
A
J
G
C
G
A
I
do
think
the
long
term
plan
in
open
tracing
and
I
believe
it
was
for
open
census
was
like
the
way
to
have
like
automatically
installed.
Instrumentation
would
be
if
this
could
reach
a
point
of
standard
being
standard
and
stable,
that
people
would
start
natively
instrumenting
their
their
libraries
with
something
like
open
tracing.
A
So
you
would
need
something
like
special
agent
to
install
software,
but
it
would
only
be
the
things
that
didn't
have
native
instrumentation,
and
so,
if
you're
looking
at
big
core
projects,
the
goal
for
those
core
projects
would
be
to
convince
them
to
to
just
come
with
instrumentation
pre-baked
so
that
they
can
so
that
the
people
writing
the
software.
Are
the
people
thinking
about
tracing
it.
A
J
I
guess
going
back
to
my
question:
around
open
census,
I
think
they
originally
started
out
with
my
buddy,
and
that
was
one
of
the
reasons
that
inspired
me
to
explore
my
buddy
as
well,
so
that
might
be
worth
considering
like
since
we're
talking
about
kind
of
merging
in
a
per
se
the
projects
to
a
degree.
Maybe
this
could
be
a
good
starting
point
to
kind
of
work
closer
together
with
them
on
a
particular
project,
rather
than
trying
to
build
it
separately.
Yeah.
J
A
The
one
thing
I
do
like
about
building
these
more
advanced,
these
kinds
of
value,
on
top
of
the
standards
that
feels
good
is
like
we
all
have
to
agree
on
the
standards,
and
that
has
to
move
very
slow
and
I
would
like
us
all
to
pile
in
and
make
something
like
special
agent
great.
But
one
thing
I
do
think
that
is,
nice
is,
if
once
you're
building
on
top
of
that
platform
one's
like
less
important.
G
We
have
a
are
just
like
some
housekeeping
stuff
about
the
registry,
yeah
yeah,
just
so
I,
don't
know
if
everyone
pays
attention
to
all
the
mini
day
of
the
open
tracing
repos,
but
last
month
we
I
took
everything.
So
there
had
been
this
open,
that's
meta
repo.
They
had
just
a
huge
list
of
tracers
and
plugins
and
instrumentation
and
whatnot,
so
I
went
through
last
month.
They
for
the
ones
that
weren't
already
in
the
open
tracing
registry,
which
is
at
open
tracing,
got
io
/
registry
I
made
entries
for
those
and
put
them
there.
G
So
that
includes
all
of
like
the
data
dog
agents
and
and
stuff
like
that,
and
so
now
the
meta
repo
is
just
kind
of
a
pointer
to
the
website.
So
if
you
have
internal
links
or
if
you
go
looking
for
something
and
it's
not
there,
that's
why
it's
all
migrated
to
the
registry
and
just
as
a
general
note,
if
you
have
instrumentation
plug-ins,
tracers
libraries,
other
open
tracing
related
things
that
you
would
like
to
put
into
the
registry,
please
feel
free
to
make
floor.
G
Requests
on
open
tracing
at
I/o
repo
or
you
can
ask
me
for
help
if
you
need
it
monitor
and
yeah
we've
we've
had
so
a
lot
of
really
good
growth
of
the
registry
over
the
past.
And
how
long
has
it
been
now,
three
months,
four
months
plus
my
counted,
we're
up
to
like
140,
odd
pieces
of
flair
in
there
and.
A
Would
do
a
quick
shout
out?
You
know
that
I'm
super
stoked
about
the
registry
there's
plenty
of
friend
and
work
that
could
still
be
done
on
it.
Things
like
searching
and
filtering
and
all
of
that
jazz
could
just
use
some
elbow
grease.
So
if
people
are
have
front-end
skills
and
are
looking
for,
you
know
a
way
to
show
some
open
tracing
love
working
on
the
registry
interface
is
definitely
a
place.
People
can
plug
in
yeah.
J
G
The
registry,
all
the
registry,
is,
it's
a
you,
add
a
markdown
file
to
one
of
the
content
directories
and
it
shows
up
it
gets
indexed
or
it
gets
turn
to
yeah.
It
gets
converted
when
we
built
the
site.
Yeah,
there's
more
explicit
instructions
on
the
webpage
to
about
exactly
where
you
need
to
put
the
markdown
file
and.
G
A
Another
thing
for
people
to
maybe
think
about
the
right:
there's,
no
API
or
anything
we
just
have
like
a
hugo
site.
But
sorry,
yes,
you
go
site,
but
if
people
do
have
thoughts
about
how
the
registry
could
be
like
actually
useful
as
part
of
operations
in
some
way,
if
there
would
be
some
way
to
make
it
useful
if
it
had
an
api
of
some
kind,
that
you
could
query,
that
would
be
interesting
thoughts.
A
G
Technically
you
can
there's
an
endpoint.
You
can
curl
to
get
the
JSON
that
makes
up
that
registry
back
it
or
back
end.
So
if
you
really
wanted
to,
you
could
be
something
with
it,
but
you
know
pick
me
up
on
get
her
if
you
want
to,
if
anyone's
on
the
call
and
wants
to
talk
about
it
and
would
love
to
chat
I'm
more
about.