►
From YouTube: OpenTracing Monthly Call - 2018-11-02
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
Okay,
now
recording
welcome
everyone
to
the
monthly
open
tracing
specification
council
call.
Today,
we've
got
two
presentations
that
I'm
excited
about
both
of
them
and
to
kick
it
off.
Johannes
is
going
to
talk
to
us
about
service.
Maps
Hannes
works
for
the
platform
lab
a
team
at
envision
he's
been
working
on
open
tracing.
It's
also
good
playing
with
some
like
step
passed.
A
He
worked
at
New
Relic,
so
he's
familiar
with
APM's
and
tracing
in
general,
honest
good,
to
see
you
virtually
in
person
here
yeah
and
if
you
would
like
to
if
you
have
slides,
if
you'd
like
to
screen,
share
and
kind
of
take
over.
Oh
great,
why
don't
you
give
us
an
introduction
to
what
you're
going
to
present
I
know
it's
a
service
Maps
and
it's
something
new,
but
you
think
it's!
It's
kind
of
a
novel
approach
to
service
map,
visualization
yeah.
B
B
There
we
go
okay
yeah,
so
my
little
presentation
is
called
service
maps
with
open
tracing
and,
as
Ted
said,
I'm
I'm
an
engineer
at
the
platform
labs
team.
So
we
do
kind
of
like
various
little
tech
things,
and
this
is
just
like
a
very
minor
thing,
so
unfortunate
I
haven't
been
able
to
spend
too
much
time
on
it.
So
what
you'll
see
here
is
more
an
idea
than
anything
like
a
full
implementation
of
anything
and.
B
And
yes,
so
so
the
problem
that
I'm
trying
to
solve
is
a
Domitian.
We
don't
really
have
a
service
mark,
meaning
like
a
graph
showing
the
interdependencies
between
micro
services.
We
kind
of
have
a
ton
of
them
already
and
a
lot
of
people
or
no
one
has
the
full
idea
of
all
of
them
and
how
during
interconnected.
B
Ways
to
build
a
these
and
I'm
gonna
build
one
with
open
tracing,
but
one
thing:
I
I
have
like
two
bonuses
that
I
don't
see
too
often
and
that's
like.
Can
we
get
a
real-time
one?
So
if
dependencies
change
or
if
there's
some
kind
of
like
outage,
will
the
service
map
update?
Can
we
come
and
get
that
and
also
normal
service
maps?
B
So
yeah
I've
seen
some
tools
out
there,
as
mentioned,
but
I,
don't
think
I
know
if
anyone
they
use
open
tracing,
although
I
wouldn't
be
surprised.
If
that's
the
case
anyway,
that's
that's
that's
what
I
used,
and
one
thing
that
was
important
for
this
project-
is
that
it's
just
like
for
me,
then
it's
just
like
maybe
5%
of
my
time
and
so
I
definitely
can't
go
to
other
teams
and
say
like
hey.
B
And
what
I
did
was
to
create
so
lights
that
you
can
configure
to
send
HTTP
HTTP
direct
messages
to
the
lights
that
satellite
which
collects
them,
and
so
what
I've
done
is
built
a
proxy.
That's
proxies
all
the
data
and
also
dumps
it
on
Kafka.
So
at
4
it's
a
fifth
message:
it
works.
Is
it
and
also
creates
the
Kafka
message.
B
Yeah
so
light
step
is
proprietary,
I
mean
it's
open-source,
but
it's
just
one
provider
of
open
tracing
and
so
I
guess.
This
is
one
I'll
make
a
little
side
point,
which
is
probably
for
this
group.
The
most
important
point,
which
is
that
I
would
love
love,
love
to
have
open
facing
not
only
be
the
API,
but
also
the
the
format,
maybe
the
transport,
so
that,
like
I
said,
we
have
instrumented
everything
with
lights
that,
but
it
would
be
so
sweet
if
I
could
just
say:
we've
instrumented
it
with
open
tracing.
B
B
Cool,
so
so
now
that
I
have
this
data
I
have
a
service
that
I'm
actually
running
on
my
laptop.
So
instead
of
deploying
a
service
and
everything
I'm
just
running
this
tool-
kafka
consumer
on
my
computer,
slurping
in
all
the
spans
as
they
come
in
on
Kafka
and
then
aggregating
them
in
memory,
and
this
is
probably
how
most
open
tracing
things
work.
I
assume.
B
And
so
the
kind
of
the
first
to
answer
the
first
question
that
I
post
in
the
beginning,
which
is
just
like
which
services
talk
to
which
services
I
just
count
ad
just
basically
so
this
service
and
I'm,
looking
at
the
component
name,
which
that's
light,
stuff,
specific
or
open
tracing,
and
then
the
operation
name
actually,
first
of
all,
I'm,
just
looking
at
component
name
so
which
service?
Is
it
and
so
I
just
mapped
services
talking
to
each
other
and
then
using
graphs
in
this
I.
Get
something
like
this.
B
B
Yeah,
okay,
yeah
no
I
just
had
a
zoom
window,
blocking
it,
okay,
okay,
so
here
you
can
see.
This
is
just
a
subset
of
the
services
we
have,
and
this
is
running
and
testing
as
well.
I
didn't
I
wasn't
quite
ready
to
deploy
my
one
of
service
to
production.
Quite
yet,
and
so
here
you
can
see
like
a
little
group
of
services
that
depend
on
each
other.
One
thing
that
was
immediately
came
out
of
this,
for
me
was
that
we
had
this
users
API
service
and
teams
API
service,
and
they
depend
on
each
other.
B
My
first
bonus
question,
which
is
that
this
this
kind
of
piece
of
Kafka
and
could
spit
out
a
graph
every
five
minutes
or
whatever,
and
so
you
could
really
get
like
an
updated
view.
There's
no
need
to
like
update
some
yeah
mold
dependency
file
or,
like
figure
it
out
manually.
It's
just
like
feeds
off
of
open
tracing
data.
B
B
So
so
that's
like
the
first
approach
and
what
I
have
been
doing
just
a
little
bit
and
which
I
think
might
be
more
novel,
and
this
I
haven't
seen
it
for
service
maps,
which
is
that,
instead
of
doing
this
kind
of
shallow
map,
where
you
have
sorry
where
you
have
just
like
you
can
see,
but
the
likelihood
of
where
it
goes
out
of
the
service.
But
you
can't
really
see
the
path
that
it
took
to
get
there.
B
So
I'm,
just
counting
so
for
each
like
complete
pass
that
happens
within
my
aggregation,
I'd
make
a
little
hash
of
it
and
then
I
increment.
The
counter,
so
just
a
side
note,
is
that
this,
like
it's
running
on
my
laptop
and
it's
running,
just
fine
on
my
laptop,
because
I
just
need
these
like
hash,
two
integer
nothings.
It's
not
really
a
lot
of
data
at
all,
and
the
output
of
this
thing
is
also
tiny.
I
just
need
to
like
for
every
canonicalized
path,
I
need
to
store
it
and
then
store
the
counts
associated
with
it.
B
B
Yeah,
so
the
idea
with
these
paths
is
that
you
can
answer
questions
like
like
what
is
the
entry
point
to
all
our
services
that
ends
up
with,
like
a
certain
call
to
your
service
Michael?
Why
are
we
getting
so
many
of
these,
like
everyone
calls
them,
but
what's
the
origin
of
these
calls
another
thing
that
I
think
is
interesting
for
something
like
lights,
that
or
other
open
tracing
providers
is
that
you
can.
If
you
have
an
outlier
say
in
in
response
time,
you
can
see
like
okay.
This
thing
takes
ten
seconds.
B
B
B
We
have
the
component
name
and
we
also
have
the
operation
name,
and
so
one
thing
you
might
wonder:
if
you
look
at
this,
you
see
that
there's
like
we
have
a
bunch
of
calls
to
this
team's
API
get
team,
and
so
the
question
it's
like
how
did
I
get
here
because
we
can
follow
this
arrow,
and
so
we
know
that
it
came
from
this
users
API
which
came
from
this
one.
This
is
just
by
following
that.
B
The
only
arrow
is
pointing
in
that
direction,
but
here,
like
once
we're
here,
we
can't
say
like
did
the
calls
that
came
through
here.
Did
they
come
from
the
team's
API
or
the
conversation
service,
or
did
they
come
through
our
system
originally?
So
those
are
the
three
paths
that
could
be
taken
to
get
into
this,
and
so,
if
you
want
to
reason
about
the
path
of
this
in
just
the
diagram
view,
you
can't
we
can't
really
see
that,
but
with
the
paths
I
can
I
can
generate
those
counts.
So
now
I
highlight
this.
B
B
C
B
Not
but
I
think
that's
a
really
good
question
and
I
think
that's
something
where
you
could
see
a
lot
of
interesting
data
like
that
and
tags
and
yeah,
yeah
and
I.
Think
so.
I
think
if
I
built
this
service
for
real,
then
I
think
it
would
be
interesting
to
try
to
dynamically
figure
out
like
what
are
the
big
groups
of
things
that
make
a
difference
here,
and
so
you
can
break
it
down
by
those
interesting
things.
Oh
yeah,
so
far,
I
haven't
done
it
oh
cool!
Thank
you.
Yeah.
B
Yeah,
so
actually
what
I
really
wanted
to
build,
but
I
didn't
have
time?
Is
google
analytics
tab?
Has
this
really
cool
user
flow
diagram?
That's
a
Sankey
diagram.
If
people
are
familiar
with
us,
which
is
I,
think
a
great
visualization
for
this.
Unfortunately,
I
didn't
have
time
to
to
make
that
for
this
presentation.
I
also
think
Netflix
is
visceral.
B
This
is
a
screenshot
from
the
other
thing.
I
think
that
could
be
a
cool
way
to
be
sure.
I
said
it's
actually
more
like
cool
than
useful,
because
it's
again
one
of
those
shallow
mappings.
So
it
doesn't
really
tell
you
like
the
story
of
the
path
through
the
system,
but
it
does
give
you
a
very
nice
live
view.
So
this
will
these
dots
on
the
diagram
would
actually
move
if
this
was
a
alive
instance
of
it.
B
A
Thank
you,
Johannes
I
wanted
to
mention,
because
you
were
discussing
standardized
wire
protocols
in
data
format
that
work
we're
not
doing
it
directly
and
open
tracing,
because
that
project
right
now
is
just
trying
to
stick
to
the
sort
of
language
API
level,
but
it
is
going
on
with
many
of
the
same
people
through
the
w3c.
Oh
I'll
post,
just
posted
a
link
in
the
chat,
the
w3c
trace
context
working
group.
We
actually
just
met
last
week
in
the
Lyon
France
for
the
big
w3c
meeting.
That's
got
two
parts,
one
part,
that's
that's
nearly
two.
A
A
That
works
interesting,
also
because
it's
focused
not
just
on
standardizing
for
individual
tracers,
but
for
interrupt.
So
if
you
had
a
trace
that
actually
went
through
several
tracing
systems.
The
canonical
example
is,
if
you
have
a
service
provider
like
an
infrastructure
provider
and
they
have
tracing
data,
and
then
you
have.
A
You
know
your
own
tracing
system
that
you're
running
an
application
and
you'd
like
to
link
that
information
together
so
that
you
can,
you
know,
say
you've
got
oh
I,
don't
know
you're
running
New,
Relic
or
light
step
in
your
app
and
then
you're
running
on
top
of
Microsoft
Azure
or
Google
cloud
and
you're
using
one
of
their
services.
They're
not
going
to
be
running
it
step
for
new
relic
on
spanner,
but
perhaps
they
can
give
you
some
kind
of
interesting
trace
data
out
of
spanner
or
similar
service.
A
So
if
you
just
had
kind
of
a
standard
wire
protocol
for
trace
data
being
propagated
in
band
and
then
some
more
standard
way
of
being
able
to
attach
to
a
process
and
get
some
kind
of
standard
export
format
or
a
push
model
like
like
syslog,
you
know
something
that
everyone
could
consume
without
having
to
know
the
particular
kind
of
monitoring
service
that
was
running
inside
of
the
app.
So
I
think
that's
something
you
would
probably
have
liked
to
have
had
here
running
this
experiment.
Definitely
that's
super.
A
I
think
this
is
interesting.
I
haven't
seen
I've,
certainly
seen
service
maps,
but
I
do
like
the
idea
of
not
just
of
they
tend
to
be
service
level,
I.
Think
in
not
I
like
the
idea
of
digging
down
into
a
path
history.
I
can
see
this
being
interesting
for
outlier
analysis
and
also
the
percentages
that
you're
showing
I
could
see
that
being
very
interesting
if
you're
just
trying
to
figure
out
generally.
Where
is
the
traffic
coming
from
kind
of
getting
a
sense
of
the
various
flows
that
are
generating
some
particular?
A
D
I
can
like
share
some
experience
with
this,
so
we've
implemented
deep
service
Maps,
but
you're
so
ago.
I
actually
showed
them
at
the
last
cube
con.
So
one
thing
about
that
is
that
the
the
way
you
showed
them?
It
works
fine
if
you
were
architecture
small.
D
As
soon
as
you
go
to
large
scale
like
at
uber,
we
have
three
something
thousand
services,
so
those
those
Maps
by
themselves
like
if
you
do
the
whole
architecture,
they
become
completely
useless
and
unusable,
and
so
our
service
master
is
step
down
from
the
like
point
of
view
with
service
developer.
So
you
pick
a
service
first
and
then
you
visualize
all
the
paths
going
through
that
service,
rather
than
like
the
whole
architecture
advice
it's
too
huge
and
I
was
like
curious
to
see.
D
B
D
E
D
A
E
Yeah,
that's
we've.
That's
probably
one
of
the
directions
we're
gonna
take
with
the
next
iteration
of
the
dependency
Maps
kind
of
restricting
it
more
severely
because
I'm,
larger
or
likes
more
popular
or
more
relevant
or
I
guess
commonly
used
services.
It
becomes
pretty
difficult
to
use
so
we're
gonna,
probably
limit
it
to
a
single
service
being
on
all
paths,
so
it's
kind
of
a
focal
service
and
then
like
a
number
of
hops
up
from
that
service
and
down
from
that
service,
I
then
allow
the
user
to
kind
of
progressively
expand
or
collapse.
A
Great,
that
was
an
awesome
presentation.
Thank
you
so
much
Johannes
for
putting
that
together.
Yeah,
please!
Let
us
know
if
you
publish
that
work
in
any
way.
Well,
there
Thanks,
yeah,
okay!
So
next
up,
we
have
some
fun
work.
We've
been
doing
at
light
step,
7
Sarris
lives
in
thailand
and
he's
been
working
with
us
on
java
agent
work.
However,
rather
than
a
code
of
a
black
box
agent
approach,
we've
been
trying
to
look
at
one
that
would
leverage
existing
open
tracing
instrumentation
and
some
somewhat
similar
to
the
existing
Java
agent.
A
That
was
in
contribu,
came
up
with
a
kind
of
interesting
way
of
actually
putting
it
together.
So
stuff
was
on
the
call
today
and
he's
gonna
lead
us
through
an
overview
of
that
project.
It's
just
about
getting
to
the
point
where
it
would
be
great
for
other
people
to
kind
of
get
involved.
So
this
is
sort
of
a
welcome.
F
F
F
All
right
so
hi
everybody,
my
name,
is
Sarah
safra's
and
I
have
been
working
on
the
special
agent
project
with
Ted.
Just
to
give
you
guys
a
jump
start
into
the
context
of
the
project.
This
project
is
essentially
the
Java
agent,
but
more
so
basically
it
does
everything
that
the
agent
does,
but
it
also
does
automatic
instrumentation.
So
let's
talk
about
what
that
means
all
right.
So,
first
of
all
motivation.
What
is
the
motivation
behind
the
special
agents.
F
Special
motivations
are,
with
with
a
single,
with
a
single,
with
a
single
command,
effectively
achievement
and
tracing
to
be
able
to
instrument
all
RPC
libraries
runtime
frameworks
in
every
service
manual.
Installation
configuration
of
plugins
is
significantly
cause
is
a
significant
cost
barrier,
so
the
idea
is
to
make
it
easy
and
efficient
to
to
effectively
instrument
an
entire
application.
F
With
with
the
least
of
effort,
since
it's
possible
to
automate
the
process
of
installing
plugins,
we
basically
are
trying
to
create
a
tool
that
would
do
exactly
that
automatically
instrument
the
third
party
libraries
in
an
entire
application.
This
would
be
helpful
for
large
organizations
with
big
code
bases
and
many
services,
and
especially
helpful
for
teams
that
do
not
have
access
to
the
to
the
source
code
itself.
F
All
right
so
high
level
goals,
high
level
goals
of
this
project
or
to
allow
any
plugin
in
the
open
tracing
contribute
to
be
automatically
installable
in
an
application
right.
So
essentially
you
you
are
with
one
command.
You
instrument
an
entire
application
that
leverages
all
of
the
instrumentation
plugins
in
the
open
tracing
contrib
project
selling
install
any
plugins
regard
regardless
in
which
class
loader
the
library
is
loaded.
So
this
is
a
pretty
big
one
because,
as
we
all
know,
in
Java,
you
never
can
be
certain
which
class
in
which
class
loader
any
class
is
loaded.
F
F
Also,
to
provide
a
lightweight
test,
lightweight
testing
methodology
to
test
auto
instrumentation.
So
this
is
effectively
a
testing
tool
that
would
allow
a
developer
to
easily
test
his
baikman
script
and
ensure
that
the
instrumentation
plug-in
is
being
properly
loaded
and
is
resulting
in
in
traces
via
via
the
Amon
tracer.
F
The
the
idea
behind
this
this
test,
this
test
methodology,
is
that
it
would
simulate
the
exact
conditions,
the
exact
toughest
conditions
that
would
have
to
be
met
by
any
application
and-
and
those
would
basically
be
that,
the
that
the
classes
that
need
to
the
instruments
that
are
loaded
in
a
class
loader
that
is
disconnected
from
from
the
system,
class,
loader
and
and
finally,
to
initialize
the
mark
tracer
and
to
provide
a
reference,
an
easy
reference
basically
to
the
test
methods.
And,
lastly,
is
so
this.
F
This
special
agent
needs
to
be
configurable,
and
this
is
the
kind
of
still
still
out
in
the
in
the
foreshadowing
stages
of
the
project
and
by
the
way.
If
anybody
has
any
questions,
please
feel
free,
ok,
so
very
high-level
architecture.
The
idea
is
that
the
special
agent
is
built
with
all
of
the
instrumentation
packages
inside
of
it.
F
So
the
basically
when
you
declare
the
Java
agent
parameter
or
Java
agents
of
VM
arguments
on
the
command
line
for
an
application
when
you're
statically,
attaching
that's
jar,
has
every
instrumentation
plug-in
inside
of
it,
which
also
then
so
so
that's
sation
packages,
the
OT
rules.
Files
are
also
are
also
packaged
inside
of
the
special
agents
and
they
are
correlated
to
the
instrumentation
packages,
so
that
so
that
effectively
it
is
known
which,
which
rule
is
is
attached
to
which
instrumentation
package,
and
so
then,
when
the
special
agent
attaches
to
the
application.
F
F
It
is
a
it.
It
does
have
an
like
a
super
parents
as
the
class
loader,
but
in
this
example
the
contrary
is
custom
class
loader,
one
which
has
a
parent,
that
is
the
system
class
loader.
That
then,
is
connected
to
the
blue
cluster
okay.
So
how
does
the
special
agents
deal
with
this
situation?
The
way
the
special
agent
operates?
Is
you
quick,
quick
overview
here,
because
it's
on
the
next
slide
so
bite
man
bite?
Man
gets
injected
into
the
boot
class
loader.
F
F
The
way
that
the
special
agent
is
able
to
operate
with
custom
class
loaders
is
that
it
leverages
it
fully
leverages
the
OTA
rules,
BTM
files.
So
what
what
do
these
files
represent?
These
files
represent
the
trigger
points
into
the
third-party
library
for
instrumentation,
that
is
to
say
that
if
the,
if
this
bite
man
rule
gets
triggered,
then
this
library
exists
in
the
system
and
from
this
points
we
can
extract
some
information.
F
The
first
point
that
so
number
one
is
something
that
is
done
beforehand
before
the
trigger
ends,
and
that
is
to
associate
the
instrumentation
package
with
each
OT
a
rule
study
sample
so
that
basically
links
together
the
implementation
of
the
instrumentation
plugin
with
the
bite
man
rules
file.
Okay
number
two
is
when
trigger
happens
when,
when
white
man
triggers
when
the
rule
triggers
the
special
agent
uses
the
trigger
it
uses
the
object
on
which
the
rule
was
triggered
to
determine
the
target
class
libera.
Okay.
F
These
special
agents,
loads
bytecode
of
the
instrumentation
classes
in
the
target
class
loader
directly
and
the
way
it
does
this
is
it
actually
uses
bite
man
itself
to
override
the
class,
loader
dot,
fine
class
method
and
also
then
exposes
the
defined
class
method
so
effectively.
What
the
code
is
doing
is
it
is
forcing
the
class
loader
to
be
able
to
resolve
any
of
the
classes
in
the
instrumentation
plug-in
and
upon
resolution.
F
So
if
anybody
has
any
questions
about
the
class
lawyers
or
feel
free,
I
if
I
skipped
a
lot
of
complexity,
but
but
that's
basically
the
the
idea
and
what's
great
about
this-
is
that
the
this?
This
solution
effectively
works
for
any
class
loader,
because
it's
operates
with
the
with
with
with
java.lang
class
loader
class.
F
So
the
Special
Agent
is
a
maven
project
and
it
has
two
artifacts
that
are
built.
It
has
the
main
artifacts
and
it
has
the
tests
artifact
and
effectively
these
two
artifacts.
These
two
jars
are
the
only
jars
that
are
necessary
to
use
special
agents
either
for
instrumentation
or
for
testing
of
instrumentation
plugins,
okay.
F
F
F
Is
effectively
all
that
you
need
for
testing
of
your
of
your
of
your
plugin,
it
does
not
have
any
of
the
instrumentation
plugins.
This
jar
does
not
have
any
answer,
instrumentation,
plugins
and
within
it,
and
it
also
supports
the
job
agent,
VM
arguments
and
the
standalone
execution.
Okay,
let
me
okay.
So
this
is
the
main
usage.
F
F
F
F
Elevates
all
of
the
code
inside
of
the
test
method,
into
a
class
loader
that
is
detached
from
system
class,
loader
and
and
that's
it
and
then,
whatever
whatever
OTA
rules,
file
that
you
have
in
in
the
in
a
class
pass
and
whatever
instrumentation
classes
that
it
points
to,
then
then
it
just
does
its
thing
and
you
have
your
reference
to
the
tracer
and
you
can
check
to
see
that
that
things
are
properly
working
so
effectively.
This
this
pattern,
the
the
Java,
sorry,
the
agent
runner.
F
F
One
of
the
more
serious
hurdles
that
we're
trying
to
get
past
is
the
fact
that
many
instrumentation
plugins
use
the
inheritance
pattern
to
instrument
to
instruments
third-party
classes.
Libraries
in
this
pattern,
unfortunately,
is
very
difficult
to
to
implement
with
with
triggering
with
bite
man,
because
vitamin
does
not
support
triggering
off
of
new.
A
G
G
If
I
understand,
it
correctly
seems
seems,
like
you
know,
could
solve
a
problem
that
was
with
the
the
current
Java
agent,
but
I'm
just
wondering
I
mean
in
terms
of
from
a
project
perspective,
I'm,
not
sure
it's
a
good
idea,
having
like
the
existing
Java
agent
and
this
special
agent
so
I
mean
do.
Is
it?
Would
it
be
better
to
collapse
them
into
one
project
or
you
know
deprecated
the
existing
one
when,
when
it
end,
was
this
that
you
know
the
instrumentation
rules
that
the
current
one
handled,
yeah
Gary.
A
I
we
didn't
want
to
touch
the
we
when
we
were
experimenting
and
rewriting
this.
You
know
it
was
different
enough
in
this
current
agent
that
we
felt
it
would
be
better
to
kind
of
get
farther
along
and
then
make
a
proposal
rather
than
kind
of
mutating
that
codebase
in
case
other
people
were
were
using.
It
I'm
not
sure
what
the
current
usage
for
the
current
Java
agent
is,
but
yeah
I
agree.
If,
if
y'all
think
this
is
a
an
interesting
approach
and
improvement
upon
the
existing
ones
and
yeah,
we
should
we
should
merge
them.
Yeah.
G
It's
just
the
you
know
if
you
do
somebody's
instrumenting,
their
services
Matt,
you
know
currently
with
the
the
other
instrumentations
in
in
OTT
contrib.
They
can,
you
know,
use
those
existing
instrumentation,
but
they
can
also
get
hold
of
the
trace
or
enact
their
own
spans.
So
I,
don't
think
it's
any
different.
When
you
have
you
have
rules
or
automatically
installing
the
instrumentations
I
think
you
will
still
want
to
be
able,
you
know,
add
their
own
custom
rules
very
logic.
G
F
G
A
Yes,
Gary
I
think,
what's
the
reason
why
it
was
an
on
goal
for
this
project
is
not
that
that's
not
interesting,
but
it
seems
like
there's
a
variety
of
there's
being
able
to
safely
install
plugins
that
are
targeting
you
know
third-party
software,
which
has
a
lot
of
its
own
trickiness
around
making
sure
you're
targeting
the
right
version.
For
example,
some
of
the
interesting
edge
cases
here
are
like
you
know
you
might
have
instrumentation
for
multiple
versions
of
JDBC
or
something
they're
slightly
different.
You
want
to
make
sure
you're
installing
the
right
one.
A
You
know
pre-existing
instrumentation
for
pre-existing
libraries
and
potentially
be
using
different
additional
techniques.
If
you
were
looking
to
kind
of
target
your
application
code
or
do
something
dynamic
there.
Since
there's
like
a
couple
different
approaches,
people
seem
to
potentially
want
for
instrumenting
their
application
code.
One
is
something
similar
to
these
sort
of
writing.
Batman
rules
where
you
just
don't
want
to
modify
the
source
code,
but
you
do
know
ahead
of
time
what
you'd
like
to
target
and
then
there's
sort
of
other
approaches
around
you
know.
A
Well,
the
application
is
running
just
give
me
some
insights
around
different
things
that
it's
doing
so
it
just
seemed
like
the
approach
to
that
would
be
like
additional
work.
You
do
on
top
of
that
and
potentially
you
might
want
them
all
a
cart
as
well,
since
the
well
I'm
not
sure
if
there's
extra
safety
issues
there,
but
it
just
seemed
like
things
that
could
be
done.
All
a
cart
potentially
so
is
that
that's
the
only
reason
why
we
put
that
that
sort
of
limited
scope
there,
but
but
I
could
be
wrong.
F
Gary,
actually
I
totally
get
what
you
were
saying
and
actually
this
is
already
implemented
in
in
the
in
the
test
version
and
the
test
in
in
the
agent
Runner
the
way
that
the
agent
runner
works
is.
It
does
not
have
any
prepackaged
plugins
inside
of
it,
but
it
is
still
able
to
do
the
instrumentation
with
white
men
executing
the
rules,
but
for
the
specific
plugin
that
you
are
testing
and
so
effectively.
F
This
is
exactly
the
use
case
that
you're
talking
about,
but
not
for
for
testing
you're
talking
about
actually
using
it
for
instrumenting
an
application
with
custom.
Ota
rules
found
so
it's
it's
not
far
off
at
all.
I
I
mean
I
just
feel
like
some
code
would
have
to
be
moved
into
the
main
from
test
to
main
and
that's
it.
G
A
That's
for
right
now
the
big
blocker
really
is
byte
meant
not
supporting
new,
which
sounds
like
something
they're
interested
in
supporting
so
I.
Think.
A
concrete
next
step
is
to
work
with
with
that
group
to
see
if
we
can
get
that
over
the
finish
line,
because
that
will
extend
the
reach
of
this
to
include
like
most
most
of
the
plugins
we're
looking
at
and
ot.
A
So
yeah,
if
you're
interested
in
Java
agents
and
Java
instrumentation
in
this
manner,
what
I
think
is
interesting
about.
It,
though,
is
that
you're
tracing
system
there's
a
PMS
out
there
that
do
these
kinds
of
things.
But
if
you're
using
a
tracing
system
with
open
tracing,
it
doesn't
necessarily
need
to
be
doing
this
style
of
stuff.
So
you
can
be
taking
Jaeger
or
something
like
that,
and
then
using
this
to
install
things
on
top
of
open
tracing
and
I,
don't
know.
A
A
If
people
have
any
final
questions
on
this,
I
suggest
maybe
going
to
get
er
the
open
tracing
public
Channel
and
continuing
the
discussion
there
and
in
the
meantime,
it's
been
lovely.
Seeing
all
of
your
faces
and
I'll
see
you
again
next
month,
yeah
and
thank
you
again
for
your
honors
for
your
service.
Mac
talk
yeah
thanks.