►
From YouTube: 2022-12-08 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
D
Put
me
on
the
spot:
let's
do
it
yeah
I'm
planning
to
release
tomorrow,
yeah
I
think
the
This
Global
open
to
love
entry
change
is
the
the
controversial
one.
It
doesn't
seem
to
be
controversial
so
far.
It
seems
to
have
kind
of
unanimous
agreement
and
thumbs
up,
but
it
is
a
behavior
change
that
is
impactful
or
could
be
to
some
and
so
I
have
tried
to
solicit
some
feedback
by
talking
about
it
in
the
cncf
slack
Channel,
but
I.
D
Think
more
feedback
is
better
on
this
and
and
kind
of
the
what
I'm.
What
I'm
trying
to
think
about
is.
You
know,
we've
gotten
all
positive
feedback
so
far,
but
is
it
the
type
of
change
where
we
want
to?
You
know
maybe
give
some
more
time
to
allow
more
people
to
to
offer
feedback,
because
it's
only
really
been
open
for
a
week.
D
E
Yeah
I
think
holding
off
on
this
until
the
next
release
is
a
good
idea
to
get
a
little
bit
more
more
feedback
from
people.
D
Well,
let's
talk
about
that
there's
a
couple
of
PR's
that
depend
on
that
change
to
Global,
open
Telemetry,
but
they're
just
kind
of
background
things.
So
you
know
I've
been
doing
this
task
to
refactor
the
auto
configuration
module
to
split
out
the
implementations
into
to
being
SPI
implementations
that
that
doesn't
have
any
impact
on
on
on
users.
D
There's
this
change
4948
that
we
might
want
to
consider
that's
a
little
further
down.
That's
using
JC
tools,
Hue
in
the
log
SDK.
So
right
now,
batch
span,
processor
uses
JC
tools,
implementation
of
a
queue
instead
of
instead
of
array
blocking
Cube.
So
this
change,
you
know,
makes
makes
batch
log
record.
Processor
use
the
same
thing.
It's
not
critical,
but
you
know
maybe
there's
some
folks
out
there
that
care
about
the
performance
benefits.
E
Yeah
I
guess
so
it
may
be.
It's
worth,
I
mean
putting
in
optimizations
is
awesome,
but
we
should,
in
my
opinion,
we
should
put
in
optimizations
when
we
know
they
actually
improve
things
and
I
know
that
this
one
also
potentially
has
we've
run
into
issues
with
JC
tools
and
some
internals
that
have
broken
in
various
places.
If
I
recall,
I
think
we've
accounted
for
all
of
them
by
now,
but
I
guess.
Maybe
we
should
have
some
benchmarks
before
before.
E
D
Yeah
and
if
it's
not,
then
we
kind
of
have
to
rewind
the
decision
to
have
the
batch
spam
processor
use
JC
tools.
F
E
We
we
have
run
into
issues
with
JC
tools
in
the
past,
around
I,
don't
remember,
was
unsafe
or
or
something
so
I
think
we
should
get
benchmarks
for
this.
F
E
If
I
recall
benchmarking,
the
batch
fan
processor
was
very
tricky
because
I'm
trying
to
remember
why
a
lot
of
it
depended
on
configuration
of
the
spam
processor
itself
and
Q
depth,
and
things
like
that,
so
I
think
I,
don't
I,
don't
actually
don't.
I
haven't
looked
at
those
benchmarks
in
a
really
really
long
time,
but
I
know
they
ended
up
being
relative
somewhat
controversial,
because
sometimes
they
were
testing
things
that
people
didn't
think
were
the
right
things
to
be
tested.
So
we
have
a
bunch
of
them.
E
B
B
I
vaguely
remember
there
was
a
whole
blog
post
that
came
out
of
that.
Yes,
the
user.
It
was
some
user-driven
benchmarking
and
it
was
around
that
the
loop
like
the
like
low
CPU
usage,
for
it
wasn't
like
a
high
throughput
scenario.
B
Yeah
I
I
should
say:
that's
that's
the
extent
of
what
I
remember
about
it.
Beyond.
E
B
D
Well,
you
know
I
wonder
if,
instead
of
trying
to
copy
and
paste
the
and
adapt
the
span,
the
batch
span,
processor
benchmarks
I
should
just
try
to
make
them
generic.
So
the
same
benchmarks
can
test
the
batch
band
processor
and
the
batch
log
record
processor,
and
it's
just
like
a
a
parameter
which
which
which
one
is
being
tested
that
would
make
sure
that
whatever
tests
are
in
benchmarks
are
in
place,
are
always
synchronized
between
the
two
signals.
Yeah.
E
E
D
And
then,
okay,
the
last
one
and
I,
don't
think
we
I
don't
think
we
should
try
to
resolve
this
for
this
release.
But
it's
about
the
semantic
sugar
event.
Api
conversations
are
ongoing
about
that.
I.
Don't
want
to
do
anything
with
that.
Yet
so
so
in
a
nutshell,
John,
where
I'm
at
with
this
is
like
I
I,
agree
with
what
you
and
Trask
are
are
saying
with
you
know,
splitting
out
a
different
event,
API,
so
a
different.
D
But
that's
just
not
what
the
spec
says
today
and
so
like
I
have
a
I
have
a
hard
time
making
a
change
to
to
our
project.
That
is,
you
know,
is
not
aligned
with
the
spec,
and
so
you
know
it's
kind
of
a
chicken
in
the
egg
problem.
D
It
does
because
I
wrote
that
spec,
but
but
I
was
doing
the
simplest
possible
thing,
so
my
goals
were
to
get
to
like
the
exact
spot.
I
think
we
should
be.
My
goals
was
to
decouple
events
from
logs
so
that
we
could
have
a
better
chance
at
stabilizing
logs
and
so
Simplicity,
and
you
know
not
not
rocking.
The
boat
was
one
of
my
motives
or
part
of
my
motivation.
B
B
But
yeah
I
mean
that
I
would
love
to
see
this
change
at
the
spec
level
of
breaking
that
dependency
between
those
two
apis
I've.
E
E
Group,
just
because
I
think
that
the
logging,
the
logging
group
is
getting
wrapped
around
the
axle
around
logs
and
events
being
logs
rather
than
thinking
about
the
user
use
cases
for
actual
events
independent
from
logging,
but
I
haven't
yet
tried
to
rock
that
boat
and
I
don't
have
time
to
do
it.
Unfortunately,.
D
E
E
All
thinking
about
logging,
logging,
logging,
logging
and
oh
events,
they
look
like
logs
I
want
someone
to
say,
let's
think
about
events
as
a
first
class
thing
and
the
fact
that
they're
implemented
via
the
logging
data
model
is
incidental
and
I,
don't
think
it
hasn't
seemed
to
me
that
the
logging
saved
what's
been
coming
out
of
them.
Has
any
thinking
about,
like
users
are
using
this
as
a
first
class
thing,
they're
all
thinking
about
how
we
make
this
into
a
logging
thing.
D
But
to
your
point,
John
one
of
the
one
of
the
main
things
that's
missing
is
other
other
use
cases.
So
everybody
brings
up
this.
This
use
case
of
like
custom
events
well
to
do
custom
track,
custom,
business
things
and
well.
What
are
those
things?
What
like?
When
would
you
want
to
use
a
custom
event
when
is
it
not
appropriate
and
so
I
think
like?
If
we
could,
if,
if
you
could,
you
know,
contribute
to
some
example,
use
cases
that
would
help
further
the
conversations
yeah.
B
E
But
I
think
there's
this
big
big
use
case,
and
it's
one
that
you
know
Jack.
Maybe
you
can
get
a
product
manager
from
New
Relic
to
help
out
here,
like
New.
Relic
really
has
this
event,
this
insights
event
API
that
at
least
for
a
long
time
was
really
pushed
to
drive
business
outcomes
like
let's
use
this
event
to
measure
business
things,
not
necessarily
like
technical
logging
things,
but
really
like
business.
E
Let's
measure
the
the
it's
a
cart
like
cart,
checkout
and
or
cart,
failure
to
check
out
or
all
of
these
things
that
are
really
business
oriented
metrics
that
can
be
captured
via
events.
E
Maybe
there's
a
if
there's
a
new
Relic
PM
like
the
insights,
VM
I,
don't
know
if
that
team
even
exists
anymore,
but
someone
who's
really
familiar
with
how
customers
use
events
to
actually
track
business
outcomes.
I
think
that
could
be
very
helpful.
E
B
I'll
reach
out
also
because
we
also
have
a
custom
event
record.
That
is
very
much
that
exact
same
thing
of
for
business
events,
so
I
can
reach
out
to
the
PM
group
here
see
if
I
can
get
somebody
to
engage
in
that
discussion.
D
B
D
Okay,
one
thing:
I,
guess:
okay,
so
one
thing
that
I
I,
the
only
reason
I
think
that
this
this
PR
is
important.
This
semantic
sugar
event,
API,
PR
and
I.
Don't
think
we
need
to
do
anything
imminently
with
it,
but
I
think
it
would
be
great
if
we
could
find
some
sort
of
way
to
decouple
events
from
logs
and
whether
that's
like
events
have
a
dependency
on
logs
or
events
are
completely
separate
from
logs
I'm.
Not
that
specific,
but
like
pulling
the
event
stuff
out
of
the
log.
D
The
log
module
allows
us
to
more
easily
stabilize
logs,
which
is
a
goal
of
mine,
so
we're
we're
churning
we're
trying
to
currently
we're
trying
to
collect
all
the
remaining
issues
that
it
would
be
in
the
way
of
stabilizing
the
log,
API
and
SDK
and
which
I
think
is
a
good
thing
to
do,
and
there's
not
that
many
issues
left
and
so
we're
getting
close.
And
so
it
will
become
increasingly
important
to
tease
those
two
apart
in
in
some
way
and
yet.
E
Another
way
to
think
that
we
could,
that
you
know
you
have
a
you
have
contacts
in
the
Legacy.
Jack
is
like
step
away
from
logs
altogether
and
divine
div
Define
an
event
API
like
the
simplest
possible
event,
API
and
don't
worry
initially
about
how
the
fact
that
it
Maps
into
model
into
the
log
model
or
how
like
how
all
these
other
event
apis
might
map
into
it,
like.
E
Let's
define
something
super
simple
that
fulfills
a
single
use
case,
but
is
still
extensible
and
then
go
from
there
like,
rather
than
trying
to
boil
the
ocean
which
it
feels
like,
is
what
has
been
happening
so
far,
and
that
would
be
a
good
way
to
decouple
like,
let's
think
about
the
API.
Let's
not
worry
about
the
implementation,
let's
only
think
about
the
API,
and
that
is
independent.
Then
of
a
logging
API.
D
F
E
Well,
that's
why
I
think
if
you've
been
separate,
I
think
the
bike
shedding
tends
to
all
be
about
how
it
Maps
into
the
log
model
rather
than
and
that
people
get
wrapped
around
the
axle
around
that
mapping,
rather
than
really
making
focusing
on
getting
an
event
API
that
makes
sense
to
users
that
should
be
super
simple,
a
name
and
some
attributes
done
like
in
a
timestamp.
Obviously,
but
like
that's
all,
you
need
it's
like
the
simplest
possible
API.
B
Jack
would
it
help
if
I
raised
a
separate,
a
new
spec
issue
specifically
about
this.
D
I
mean
I,
think
so,
and
you
know
like
I'm,
not
I'm,
not
I,
don't
have
a
I,
don't
have
a
strong
opinion
about.
You
know
whether
the
event
API
is
completely
separate
or
has
a
dependency
in
the
log.
Api
I
think
the
ergonomics
of
it
being
completely
separate
are
a
little
bit
better,
but
frankly,
I'd
be
happy
with
either
like
I
just
want
to
make
progress.
D
If,
if
this
does
succeed,
if
you
open
an
issue-
and
that
succeeds
Trask-
that
it
would
be
kind
of
interesting,
because
that
would
be
the
solution
that
was
you
know,
we
were
in
favor
of
as
a
group
I
don't
know
six
months
ago,
when
we
were
trying
to
decide
if
there
was
like
a
separate
log,
API
an
event
API
or
if
they
were
combined
into
one.
That's
like
exactly
the
solution
that
we
were
in
favor
of.
B
A
B
Okay
with
it,
okay,
fine,
it's
there,
it's
for
building
a
Pender
adapters,
but
outside
of
that
end,
users
would
rather
end
users
not
see
it.
D
B
I'm
glad
that
we
have
it
because
it
makes
our
life
easier
from
on
the
Java
agent
side
and
bridging
and
adapters.
We
we
had
already
essentially
had
to
build
a
log
AP,
a
fake
log
API
for
our
instrument.
Logging
adapters,
no.
E
A
E
B
I
thought
that
was
the
point
of
this.
This
PR
make
sure
make
sure
it's
very
clear.
We
are
not
building
a
login
API.
E
D
It's
you
know,
the
language
I
guess
has
shifted,
because
at
one
point
it
was,
you
know
the
the
idea
was
hey.
This
isn't
a
logging.
This
is
primarily
for
writing
appenders,
but
if
a
language
wants
to
take
it
further,
they
can
have
a
like
a
first
class
API
for
their
users
to
use
directly.
But
it
seems,
like
you
know,
we've
kind
of
backed
away
from
that,
and
now
it's
strictly
for
appenders
yeah
or
you
know,
whoever
is
in
favor
of
writing
a
first
class
API
this.
B
All
right
so
on
the
releases
on
the
instrumentation
side,
I
just
wanted
to
do
a
quick
check.
If
there's
any.
B
Er's,
so
the
instrumentation
release
will
be
next
Wednesday,
so
we
have
a
few
days
still.
G
B
G
It's
mostly
copy
paste
and
trying
to
extract
common,
fixed
common
things
into
common
modules,
so
don't
be
scared
by
its
size.
D
And
Mateus
with
that
with
the
API
for
that,
if
you're
using
the
library
instrumentation,
would
that
return,
the
Jakarta
version
of
the
filter.
G
G
B
Yeah
I'm
I'm
very
proud
of
spring
for
pushing
the
that's
what
the
Java
ecosystem
needed
in
order
to
push
forward
to
Java
17
and
Jakarta,
like
I
thought.
That
was
very
bold.
E
I
saw
it
recently
or
the
thing
that's
keeping
me
from
moving
to
Java
17
that
I
recently
saw
there
was
a
fairly
significant
bug
with
the
way
it
interacts
with
Docker
and
Resource
Management
that
still
hasn't
been
released.
I
think
so
that's
I!
That's
the
big
thing!
That's
holding
me
back
from
going
to
Java
17..
E
They
broke
some
sort
of
resource
detection
code
with
the
relation
to
docker.
E
B
I
remember
this
was
initially
POC.
Is
it
still
POC
or
is
it.
G
I
mean
it's
kind
of
working,
but
it's
it's
demo
level.
I,
don't
have
a
demo
today,
because
I
would
I
was
on
the
secret
of
all
the
last
week,
so
I
didn't
I,
wasn't
I'm
not
really
prepared
for
today.
I
can
show
it
to
you
next
week,
unless
you
decide
to
like
test
it
out
or
merge
it
before
that
I,
don't
think
that's
necessary
for
those
three
days.
I
would
rather
have
it
like
properly
and
properly
reviewed,
then
merge
it
too
early.
G
B
B
Why
didn't
I
merge
no
reason
not
to
merge?
Yes,
Jack.
Thank
you
for
doing
this.
This
was
awesome
and
we
will
have
to
keep
keep
at
it.
D
Yeah,
thanks
for
reviewing
that
I
know,
there's
a
lot
of
work
and
it's
files
kind
of
cumbersome
to
read.
D
It's
terrible
but
I
guess
when
it
renders
it's
okay.
B
I
think
I
had
that
problem
when
I
was
trying
to
diff
it
with
the
the
rich
view,
also
and
I
think
it
hung
my
browser
where
it
is
sorry
I
just
wanted
to
show
off
for
people,
so
the
table
of
supported
libraries
and
Frameworks
now
includes
which
semantic
conventions
they
implement
they
produce
with
links
and
some
of
our
own
internal
things
like
us.
A
lot
of
our
instrumentation
is
just
about
providing
good
span
names,
HTTP
route,
attributes,
controllers
bands,
yeah
a.
D
A
B
Nothing
that
was
is
preventing
merge
and
it's
not
one
is
not
one
of
the
required
checks.
I.
B
So,
that's
why
we
don't
include
test
latest
steps
as
a
required
check
right,
okay,
because
it
so
that
it
doesn't
block
PR's,
but
we
do
it
with
every
PR
we
do
now.
We
didn't
previously.
B
But
it
was
biting
us
where
there
would
be
breakages
related
to
the
pr,
because
of
like
an
instrumentation
update
or
something
yeah,
okay,
okay
or
most
commonly
new
instrumentation.
Any
kind
of
new
instrumentation
that
was
added
people
would
forget
to
test
it
with
the
latest
depths
locally.
B
E
B
It's
this
is
the
kind
of
thing,
though
that
would
be.
Potentially
you
know
nice
like
we
could
use
some
GitHub
GitHub
actions.
Automation
to
you
know,
tell
post
a
comment
that
could
be.
You
know
more
helpful.
B
A
B
All
right,
I
think
we're
good
there
I
I
will
there
was
one
this
one
would
be
nice
to
include.
There
was
just
one
update.
We
were
waiting
on
so
I
upping.
C
So
yeah
it's
been
a
while
the
project
has
made
a
ton
of
progress
and
it's
fun,
seeing
all
the
all
the
changes.
C
So
just
this
past
couple
this
past
week
or
so
I've
been
exploring
a
little
bit
the
the
AWS
Lambda
instrumentation
and
and
trying
to
understand
how
the
the
propagation
for
that
works,
and
while
I
was
doing
so
I
ran
into
some
issues,
with
the
the
way
that
it
was
doing.
The
instrumentation
for
the
tracing
request,
handlers
and-
and
it
posted
a
an
issue
about
that
specifically
around.
If
you
were
using
the
library
instrumentation.
C
This
isn't
the
one
the
issue
I
posted
somewhere
else,
yeah
anyway,
sorry
I
didn't
pull
that
up.
But,
like
you,
get
a
Class
cast
exception
anyway.
So
so
I
wasn't
trying
to
talk
about
this
specific
one.
I
was
just
mentioning
that,
but
the
the
one
thing
that
I
was
a
little
bit
confused
about
is
when
I
was
looking
at
when
I
was
trying
to
use
this
Library
instrumentation.
C
It
has
a
dependency
on
the
the
SDK,
and
you
know
my
my
normal
inclination
would
be
to
use
the
the
global
open
Telemetry,
but
that
doesn't
provide
the
SDK
where
this
wants.
The
SDK
and
I
wasn't
aware
of
a
way
to
get
the
the
agent
provided
SDK.
So
the
way
I
had
to
do
that
was
using
the
the
auto
configure
SDK
just
for
for
the
simple
test
that
I
was
doing,
and
so
I
got
that
working.
But
that
seemed
not
ideal.
C
D
G
Yeah
I
think
it's
probably
very
specific
to
this
particular
kind
of
instrumentation
right
when
you
have
a
Lambda
function
that
just
suspense
after
finishing,
you
really
want
to
be
sure
that
you
send
out
the
Telemetry
before
it
suspense.
D
C
H
I
guess
I
can
provide
some
context
about
that.
There
was
this
fear
that
users
may
have
used
this
one.
You
know
to
be
flushing
all
the
time
and
we
played
conservatively
I
think
that
if
we
can
provide
more,
you
know
evidence
like
this,
that
we
actually
need
that
it
could
be
great.
You
know,
I
opened
racing
had
such
functionality
and
probably
it's
about
time.
We
do
that
in
open,
Telemetry
I
think
Ted
Young
have
some
concern
about
these,
so
we
can
talk
to
him.
D
Riley
suggested
an
interesting
solution
to
this,
so
he
suggested
a
an
auto,
flushing,
processor
and
I.
Think
the
rough
idea
is,
you
register
a
processor
with
your
SDK
and
you
look
for
spans
that
match
a
certain
predicate,
and
if
that
predicate
is
matched
you,
you
automatically
flush.
Those
and
you
don't
wait.
D
C
Anyway,
that
was
just
something
that
came
up
that
I'm
like
this
is
weird
I
anyway,
just
feedback.
B
C
Well,
so
the
auto
instrumentation
only
instruments,
the
the
Lambda
event
handler
and
so
with
sqs
there's
a
bunch
of
messages,
and
so
I
was
just
trying
to
understand.
I
I,
don't
think
that
the
so
like,
for
example,
if
you're
using
the
auto
the
auto,
the
the
Java
agent,
it's
not
going
to
apply
the
instrumentation
at
the
message
level,
just
at
the
event
level,
and
so
you
lose
a
lot
of
visibility
in
the
current
system
for
auto
instrumentation.
In
terms
of
like
the
individual
messages.
C
B
C
So
if
you
go
back
to
the
link
that
I
posted
you,
you
can
see,
there's
a
distinction
here.
C
Go
to
the
the
code
browser
open,
the
sidebar
for
GitHub
there
yeah.
So
here
you
can
see,
there's
an
sqs
event
handler
that
looks
at
just
the
event,
but
then
there's
also
an
sqs
message:
Handler,
which
iterates
through
all
of
the
messages
from
the
event
and
does
things
with
them.
G
Well,
that's
probably
I
think
because
the
message
under
is
just
like
completely
custom
in
implementation
of
the
original
Handler.
C
Yeah
I
I
totally
understand
why
it's
not
done
in
the
instrumentation
for
automatic
and
I
mean
it's
a
difficult
problem
to
solve.
I
think
the
way
that
if
I,
were
to
go
about
doing
this
I'd,
probably
do
something
similar
to
Kafka
the
Kafka
instrumentation,
how
you
have
to
instrument
the
iterator
and
then
iterate
through
each
of
the
the
messages
or
something
like
that.
G
B
G
C
Yeah
I
don't
know
if
it
still
uses
the
iterator
in
a
hotel.
B
It
does
but
we're.
A
B
Have
a
whole
issue
about
get
removing
it.
C
C
Cool
anyway,
that
that's
what
I
I
mean
the
the
problem
is
is
with
messaging
I.
Think
that
it's
pretty
common
to
not
necessarily
use
the
iterator
I
think
that
it's
probably
fairly
common
to
say,
hey
I'm,
just
going
to
get
the
first
one
or
something
like
that.
If
you
know
that
you're
not
doing
batching
and
so
using
the
iterator
instrumentation
approach
would
would
also
not
necessarily
work.
A
hundred
percent
of
the
time.
B
A
B
Peter
how's
the
have
do
you
have
any
user
feedback
from
the
jmx
Insight
stuff,
yet.
F
No,
not
really
some
internal
feedback
only
from
my
colleagues,
so
we
are
thinking
about
writing
a
blog
entry
which
would
advertise
this
feature
a
little
a
little
bit
more
because
I
think
people
are
simply
unaware
of
its
presence.
D
D
Think
that
was
Severin,
oh
yeah,
so
he
brought
that
up.
It's
you
know
we
can
do
this
in
a
couple
of
different
ways.
So
you
know
you
could
have
this
entire
configuration
in
you
know
a
config
file
or
you
could
have
the
config
file
reference.
Another
file
that
specifically
configured
this
specific
tool
to
me.
It's
kind
of
like
akin
to
you
know
if
you're
configuring,
if
you're
configuring
secrets
for
like
TLS
or
certificates,
do
you
reference
the
certificate
directly
in
the
config
file?
D
Or
do
you
reference
a
file
that
contains
the
certificate
so
kind
of
a
similar.
B
D
The
initial
conversation
was
just
like
hey.
This
is
an
example
of
configuration,
that's
happening
over
in
the
instrumentation
area.
We
and
we're
kind
of
aggregating,
all
the
different
types
of
things
that
you
want
to
configure
in
instrumentation,
just
so
that
we
make
sure
that
whatever
design
we
come
up
with,
can
accommodate
those
types
of
things
eventually,
and
so
it
hasn't
gotten
so
specific
that
we're
talking
about
Solutions.
Yet.
C
Can
I
go
back
to
a
quick
question?
I
had
yeah
so
Peter
going
back
to
the
the
jmx
thing,
so
I
I
thought
it
was
a
really
cool
PR
having
the
jmx
Integrations
within
the
Java
agent
I.
Think
that
there's
also
a
similar
kind
of
effort
on
The
Collector
side
to
be
able
to
remotely
you
know
query
for
jmx
metrics.
It
would
be
awesome,
I,
I,
think
if
the
file
configurations
for
such
could
be
shared
between.
You
know
the
Java
agent
and
The
Collector.
B
Our
yeah
we've
we've
discussed
this.
Our
our
hope
is
that
Peter's
work
can
basically
replace
none
of
us
like
The,
Groovy,
jmx
gatherer
that
exists
and
contrib,
so
we're
hoping
that.
D
B
Foreign
yeah,
so
we're
hoping
that
for
people
who
want
that
external
process
external,
like
say
from
a
Kafka
server
or
something
that
they
don't
want
to
run
the
Java
agent
in
that
we
could
reuse
that
code
and
configuration
and
replace
The,
Groovy
jmx
metric
gatherer
and
then
have
consistency
between
the
two
awesome.