►
From YouTube: 2021-09-10 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
No,
no,
I
mean
the
all
the
java,
the
all
the
other
cigs
like
wait
till
before.
After
to
start,
we
usually
start
the
morning.
One
right
on
time.
Also.
A
It
wasn't,
though,
it
was
before
that
it
was
before
that.
Oh
interesting,
oh,
I
know,
I
know
it
was
mateosh's
pr.
He
introduced
that
clock
timer
thing
for
the
the
nano
capturing
nano
time,
for
it
was
one
of
the
message
queuing
things,
and
so
I
had
ended
up
looking
over
here
at
how
it
was
implemented
yeah.
So
I
was
just
curious
because
the
this
right
this
would
work
on
both
on
java
8
also.
B
It
wouldn't
be
microsecond
precision,
so
you
plus
some
performance
versus
just
the
simple
current
time
release.
I
think
that's
the
only
reason.
A
Okay,
that's
what
I
was
wondering
if
this
is
just
purely
optimization
yep,
since
we
know
okay.
A
C
D
A
With
the
docker
desktop,
I
I
just
licensing
change,
I'm
not.
C
B
C
A
brew
based
solution,
I'd
love
to
know
it,
but
splunk
is
just
gonna
pay
pay
up.
B
A
D
B
B
A
Oh
yeah,
this
one
I
just
came
across.
I
was
going
to
open
a
issue
to
discuss,
but
since
have
you
heard
that
I
would
run
it
by
get
your
thoughts,
so
I
don't
know
if
you
caught
this
in
the
jdbc
library
instrumentation
to
right.
We
need
to
keep.
A
Cache
or
keep
the
original
prepared
statement
or
the
original
connection
info
tied
to
that,
and
normally
in
the
agent
we
would
do
instrumentation
context,
and
so
this
is
sort
of
a
hack
to
get
the
instrumentation
context
usage
when
it's
running
as
an
agent,
but
I
was
wondering
and
that's
partly
based
on-
I
just
sent
this
javadoc
clarification
that,
because
I
noticed
that
these
so
lori
had
made
instrumentation
context,
work
outside
of
advice,
and
it
actually
works
even
better
outside
of
advice
than
we
documented
it.
A
The
only
we
don't
have
to
do
anything
manual.
The
only
downside
is
you:
should
it's
a
little
expensive,
so
you
should
look
it
up
once
and
historic
midfield,
and
so
what
I
was
thinking
about
was
if
we,
if
it
made
sense
to
in
our
api
in
the
instrumentation
api
to
expose
something,
like
you
know,
give
me
a
cache
from
you
know
of
these
two
classes
and
the
default
implementation
of
that
could
just
do
this,
while
the
when
the
agent
is
running
the
agent
could
substitute
in
its
own
implementation.
B
B
A
You
can
so
right
now,
like
you,
couldn't
cat
put
two
in
put
two
fields
into
the
connection.
Yeah.
B
B
D
B
B
A
B
D
E
E
Yes,
so
so
I
first
off,
let
me
preface
by
saying
I'm:
I'm
really
not
a
java
person
that
I
am
working
currently
on
the
java
application,
which
uses
grpc
and
it
uses
the
just
unary.
You
know
future
grpc
calls
now.
I
have
been
following
the
java
open,
telemetry
tracing
stuff,
since
I
know
about
a
year
ago
and
I've
taken
what
the
auto
instrumenter
does
and
translated
it
into
a
open,
telemetry,
client
interceptor,
which
effectively
operates
the
same
way.
So
it
creates
a
listener.
E
A
Oh,
no,
we
actually
we
do
have.
We
know
that's
an
important
use
case
also
for
a
variety
of
reasons
that
people
would
want
to
instrument
not
using
the
java
agent,
and
so
I
did
wanna.
Do
we
not
have
doc
on
this.
E
So
I
have
been
able
to
over
time-
and
I
think
I
asked
this
at
some
point
a
long
time
ago
I
have
been
able
to
migrate
over
time
to
use
more
of
the
instrumentation
api
classes
directly,
rather
than
they
have
to
sort
of
copy
code
out
of
what
essentially,
the
instrument
does
so
yeah.
That's
made
me
happy
now.
The
issue
is.
A
Have
you
seen
this
particular
artifact,
this
particular
artifact?
May
you
may
be
able
to
use?
You
may
be
able
to
replace
your
interceptor
with
using
here.
These
are
actually
designed
for
using
directly
and.
D
A
Time
we
are
trying
to
shift
our
trying
to
move
more
of
our
auto
instrumentation
out
into
what
we're
calling
these
library
instrumentation
and
then
in
the
java
agent
instrumentation.
We
reuse
that
we
pull
in
the
library
instrumentation
there
right.
E
So
this
this
is
actually
very
close
to
what
I
want.
If
I
don't
know,
if
you
can
click
on
that
tracing
client
interceptor
and
go
to
the
very
bottom
where
the
listener
yeah,
so
this
on
message,
type
thing.
So
actually
sorry,
no
on
close,
I
think,
is
the
issue
so,
like
I
said,
I
don't
understand
the
existing
application
that
well,
but
it's
a
very
asynchronous
application.
There's
a
it's
got
a
it's
running
in
jersey,
so
a
http
request
comes
in.
E
That,
then,
will
make
another
potentially
grpc
call,
and
the
issue
is
that,
if
I
just
have
it
basically
the
same
way
as
this,
where
you
say
scope
ignored,
equals
context.make
current,
what
happens
is
that
everything
becomes
those
subsequent
cores
become
child
spans
of
that
first
call,
and
is
that
does
that
make
sense
or
does
anyone
understand
what
I'm
talking
about,
and
so
essentially
what
happens
is
the
first
jrpc
call
extends
from
when
you
initiate
that
jpc
call
to
the
effectively
the
end
of
the
http
server
processing
and
any
subsequent
calls
that
are
sort
of
callbacks
from
that
that
are
part
of
this
futures
and
callback
from
the
google
guava
stuff.
E
They
appear
as
sub
as
children
of
that
initial
grpc
span
and
once
again,
there's
another
callback
tacked
on
the
end
of
that
it
becomes
a
child
of
that
span
and
they
all
extend
all
the
way
to
the
end
of
the
request,
which
is
not
really
what
I
want
right.
What
I,
what
I
really
want
is
I
want
to
have
each
time
it
comes
back
from
the
song
glows
and
the
course
of
the
callback
that
is
going
to
do
a
subsequent
potential.
Another
grpc
call.
E
B
I
don't
know
if
we
have
a
unit
test
for
that
specific
case
where
we
make
another
call
within
a
future
callback
which
we
should,
but
your
behavior
sounds
like
what
I'd
expect
to
happen.
It's
not
correct
like
in
most
of
instrumentation,
we
mount
the
parent
context
current
when
calling
the
final
callback
to
go
back
to
the
user.
B
E
E
E
E
I
guess
I
don't
have
enough
confidence
to
write
a
write,
a
test
because
I
don't
know
groovy
either
and
I
don't
know
all
the
testing
framework
you
have
for
for
the
java
stuff
but
yeah.
That's
essentially
what
I
what
I
have
and
yes
it's
a
callback
and
future
callback
and
like
I
say
he
had
that
issue
with
all
getting.
E
E
Okay,
so
situations
michaels
send
message
so
somewhere
we
make
a
event
that
says
that
message
has
been
received
or
message.
Is
that
the
one
yes
sent?
E
Maybe
I'm
misunderstanding
what
the
semantic
conventions
mean,
but
it
seems
strange
because
those
events
always
appear
towards
the
end
of
the
span
right.
It's
when
the
you've
initiated
the
client,
call
the
grpc
server
processes
and
sends
back
the
response
that
callback
gets
invoked.
We
mark
an
annotation
which
says
sent.
B
E
I
mean
you:
do
you
do
make
that
send
right
with
the
initial
grpc
when
it
starts
to
do
in
the
grpc
and
it's
sending
that
message
across,
but
we
don't
have
an
annotation
for
that
right.
We
don't
have
a
ad
event,
but
we
do
have
an
ad
event
for
this
response
coming
back
and
yet
we
mark
it
as
sent
instead
of
received
or
whatever.
E
C
E
E
Any
of
these
with
anything
more
complex
than
unary
stream
stuff,
I
haven't
tried
bi-directional
stuff,
so
I
don't
know
what
it
does
for
those
cases
when
that
complicates.
B
E
So
actually,
I
guess
the
other
thing
here
is
that
the
the
atomic
long
field
updater
there
is
a
static
right,
which
means
that
it
will
continue
to
increment
every
time.
A
message
goes
back
and
forth,
so
I
actually
thought
that
was
the
reason
we
had
that
there
that
you've
got
this
persistent
connection
right,
you're,
making
these
unary
requests
back
and
forth,
and
this
counter
would
be
incrementing
each
time.
B
Static
is
an
updater.
This
isn't
an
atomic
long,
it's
an
atomic
lung
updater
and
it's
a
so.
This
is
not
a
common
pattern,
but
if
you
want
to
avoid
the
overhead
of
an
atomic
long
object,
you
can
use
this
pattern,
but
so
the
initial
value
for
this
message
id
variable
is
zero
and
then
that
static
updater
is
used
to
update
it
with
one
bit
here
or
whatever,
but
that.
E
Okay,
okay,
anyway,
so
that's
that.
Thank
you
very
much
for
your
help
and
that
confirming
I
wasn't
way
off
base
here.
Yeah.
E
E
So
I
asked
this
question
not
necessarily
related
to
the
open
telemetry
agent
because,
like
I
say,
we've
been
doing
mostly
manual,
but
I
occasionally
I
occasionally
look
at
other
companies
who
are
doing
this.
You
know
new
relic
lightstep,
whatever
that
have
their
own
agents,
and
I
have
the
same
question:
how
do
do
they
handle
async
context,
propagation
or
does
the
open
telemetry
one
handle
async
context,
propagation
correctly
in
enough
cases
that
you
can
trust
it
to
do
the
right
thing.
C
I
want
to
hear
I
want
to
hear
your
answer.
I'm
very
curious.
D
D
C
A
Yeah,
there's
there's
a
ton
of
there's
a
lot
of
tests.
We've
got.
We've
got
tests
that
do
a
lot
of
concurrent
operations
because
we
have
found
bugs
where
jumping
to
thread
pools
automatically
propagating
to
thread
pools
would
work
fine
in
a
single
like
not
under
load
but
under
load.
A
You
would
have
some
other
behaviors,
so
yeah
I
mean,
and
I
think
the
the
great
thing
I
think
about
the
open
telemetry
java
agent
is
that
we're
getting
a
lot
of
companies
adopting
that
so,
for
example,
lightstep,
for
example,
even
like
app
dynamics,
big
companies,
splunk
cloud
vendors
and
so
the
more
different
users
and
use
cases
people
throw
at
this
the
more
of
those
warts
that
we
uncover
and
make
work.
E
Yes,
because
because
this
project
that
I'm
working
on
I'm
only
one
person
working
on
half
time,
but
it
started,
I
think
about
a
year
ago
when
the
agent
was
very
fresh,
and
I
know
that
we
had
some
issues,
then
that
it
wasn't
doing
the
correct
thing
for
async
at
least
didn't
seem
to
be
doing
the
correct
thing.
That's
also
why
we,
we
did
manual,
propagation
or
manual
instrumentation.
E
E
A
I
yeah
that
works
and
that's
another
great
thing.
I
think
in
the
open
telemetry
project,
where
the
sdk
groups
at
john
and
honorag
and
myself,
we
work
across
both
sides,
and
so
we
do.
We
have.
The
agent
is
completely
aware
of
the
tracing
apis
and
even
metrics
in
its
in
unstable
format,
but
yeah.
So
the
context
in
particular
there's
a
bridge
of
that
will
handle
your
context.
A
So
in
your
app
you
would
just
use
the
open
telemetry
api
to
create
spans,
update
context
and
but
the
implement
the
agent
is
going
to
replace
and
take
over
the
implementation
of
all
of
that
yeah.
Okay,.
E
A
Well,
yeah
and,
as
you
found,
there's
still,
there's
still
plugs
to
be
found
still
yeah,
so
yeah
the
the
best
thing
that,
if
you
do,
if
you
are
able
to
you,
know,
report
an
issue
with
a
repro,
that's
usually
the
the
fastest
way
for
us
to
be
able
to
identify
and
fix
something.
A
E
Okay,
so
that's
that's
all
I
had
I
took
a
while,
but
thanks
for
answering
and.
E
E
C
A
Oh
yeah,
we've
we
have
discussions,
enabled
on
all
the.
A
D
A
To
hop
off
to
dinner
here,
it's.
C
E
I
work
for
well.
We
changed
our
name
as
of
three
days
or
nine
days
ago.
We're
I'm
back
to
yahoo.
So
I
worked
at
yahoo.
I've
worked
at
yahoo
before
it
was
acquired
by
verizon
and
I'm
now
just
being
unacquired
by
verizon
and
now
zone
by
apollo
private
equity,
which
has
caused
a
lot
of
people
to
leave,
as
you
might
imagine,
but
I'll
see
how
it's
still
going.
I've
been
I'm
a
fairly
senior
engineer
there.
So
even.
C
B
B
I
think
the
marshmallow
apis
are
pretty
easy
to
use.
Now,
though,
so
maybe
it's
okay,
because
the
only
problem
is
as
soon
as
we
do
this
every
time.
It's
a
regression
for
the
agent
like
if
we're
able
to
get
rid
of
the
proto-dependency,
that's
awesome,
but
then,
if
it
comes
back
when
we
want
to
have
the
exporter,
that's
annoying
and
then
because
it's
annoying
I'll
probably
be
the
one
that
writes
the
martial
art
yeah.
C
A
B
B
So
I
don't
think
we
have
to
do
that
like
as
long
as
it's
not
the
agent.
I
don't
see
any
problem
either
so
yeah,
which
would
like
we
wouldn't
be
adding
the
logging
exporter
that
the
next
agent
released
either
way,
probably
right,
right,
yeah,
so
our
logs
exporter.
I
should
call
it
this
so
then
it
doesn't
matter.
B
B
C
C
Yeah
I
saw
35
you
we
just
merged
that.
So
that's
a
good
excellent!
C
B
B
A
Yeah,
but
the
payoff
is
huge.
It's
going
to
close
10
of
our.
B
A
C
A
I
had
since
I
watched
the
datadog
repo
I've
noticed
over
the
last
six
months
around
six
months
ago.
They
did
a
whole
bunch
of
that
also
of
caching
utf-8
stuff,
even
down
to
like
span
names
and
things
for
otp,
not
for
otlp
just
for
their
their
wire
protocol.
B
Yeah
yeah,
you
know
I'm
quite
happy
with
the
jsons
realize
I
feel
as
if
I've
done
some
weird
innovation
that
I
wasn't
expecting
because,
like
it's,
actually
it
wasn't
that
hard
to
make
this
marshaller
that
support.
B
A
B
D
C
A
C
Yeah,
so
if
we
don't
have
anything
else
we
need
to
get
in,
you
can
either
release
anytime.
You
want,
or
I
can
do
it
tomorrow,
either
way.
It's
fine.
C
Either
either
way,
I'm
super
happy
to
do
it
if
you
don't
get
to
so
yep.
Of
course,
I
know
we
so
I
haven't.
I
haven't
yet
crafted
any
change
log
of
release
notes,
so
that
still
has
to
be
done,
although
I
don't
think
there's
a
huge
amount
of
changes
there,
but
there
are
definitely
a
few.
C
That
is
also
fine,
but
there's
also
right,
like
the
yeah,
the
http
of
the
gzip.
A
B
Oh
yeah,
this
should
I
do
one
more
pr.
So
are
we
good
with
releasing
the
spi.
B
C
B
Been
forgetting
every
day
I
mean
to
send
up
here,
but
I
keep
on
forgetting
to
rename
to
get
list
and
get
map
which
matteo
suggested.
That
would
be
the
only
change
I
make
for
conflict
properties
right
now.
It's
get
comma
separate
list,
long
name
which
I
agree
is
unnecessarily
wrong.
So
I
could
send
a
pr
to
fix
that
and
then,
if
you're
ready
to
release
this
public
or
if
we
still
have
support,
we
can
keep
it
as
alpha
for
one
release.
C
I
don't
have
any
problem
with
it.
There
was
somebody
had
a
there
was
a
discussion.
There's
a
discussion
been
ongoing
that
I've
tagged
you
on
today
about
someone
wanting
to
do
wanting
to
be
able
to
use
their
sdk
tracer
provider
configurer,
so
it's
called
but
have
available
and
auto
configured
exporter
for
it
to
use
which
we
definitely
don't
have
support
for
it.
Now
I
don't
even
know
what
that
api
would
end
up.
Looking
like
it
would
be
really
messy.
B
B
Somehow
be
able
to
bigger
decorating
stands
yeah.
C
Data
by
the
way
we
ran
into
a
really
interesting
thing
in
android,
and
we
weren't
sure
how
to
address
and
mateo
should
build
a
clever
little
solution,
but
it
might
be
worth
asking
just
asking
the
question,
so
we
want
to
be
able
to
give
people
the
ability
in
the
android
instrumentation
to
redact
and
modify
span,
attributes
and
names
and
all
sorts
of
protecting
this
pii
et
cetera,
and
the
only
way
we
can
really
do
that
at
the
moment
is
at
the
exporter
level
like
give
them
like
do
some
export
modifications,
but
give
them
an
api
to
actually
that
we
will
then
do
exporter
stuff
for
them
like
modify
the
spam
data,
because
we
don't
want
to
expose
spam
data
like
we
don't
want
to
expose,
expose
sdk
interfaces
as
a
part
of
our
android
instrumentation
library,
and
because
we
aren't
exposing
any
sdk
interfaces.
C
C
Just
principle:
we
want
to
keep
the
surface
of
what
we're
giving
them.
Okay,.
C
Yeah
I
mean
there's
nothing,
I
mean
we're
installing
an
sdk
in
their
application,
so
there's
one
there,
but
I
think
we
also
would
like
to
like,
for
example,
right
now,
we're
we're
forced
to
use
a
zipkin
exporter
because
of
our
back
end
right
now
only
in
jessican,
but
we
want
to
be
able
to
modify
that.
We
want
to
be
able
to
mess
with
all
those
kind
of
sdq
sdk
configuration
things
without
giving
it
like
giving
too
much
control
to
the
user
at
the
moment.
C
So
at
the
moment,
all
we
can
do
is
we
can
give
them
like
hey,
give
us
a
function
that
will
modify
the
name
or
filter
based
on
name
or
all
that
et
cetera,
et
cetera,
and
then
we'll
do
all
the
work
of
actually
under
the
hood
modifying
the
screen
data
before
we
export
it.
But
I
was
wondering
if
people
had
any
other
ideas.
A
A
Kind
of
like
the
the
rule
based
sampler
yeah,
but
in
this
case
it
would
be
a
rule-based
span.
Exporter
and.
B
C
B
C
Well
right
now
we
have
a
very
limited
thing
amount
of
things
they
can
do
and
we
give
them
very
specific
apis
for
it.
So
it's
not
like
that.
It's
not
like
you're!
You
can
make
really
anything
about
the
space
right
right
now.
You
can
do
a
couple
things
with
the
you
can
do
things
with
the
attributes
and
you
can
do
things
with
the
spam
name.
C
So
maybe
the
answer
is
we
just
like
give
them
a
give
them
something
like
either
we
give
them
the
span
data
directly
and
let
them
monkey
around
with
it
or
we
give
them
some
some
proxy
of
the
span
data
that
we
can
then
convert
back
and
forth
easily.
I
don't
know
I'm
not
sure.
A
Thing
I
would
not
wish
that
on
users
from
a
simplicity,
you
know
if
you're
looking
for
a
simple
story.
B
Like
the
backing
object
was
a
span
but
like
it
did
some
interface
magic
to
be
able
to
expose
like
a
spam
like
it
has
a
spam
customizer
interface.
I
forget
exactly
what
the
details
were,
but
that
was
a
design
like
it's
not
the
spam.
It
doesn't
allow
everything
to
be
mutated.
I
think
it
still
have
some
sunset
or
something
like
that
and
yeah.
The
main
reason
for
that
was
then
you
could
also
take
the
lockout
during
before
and
after
all,
the
customizations,
rather
than
each
operation,
or
something
like
that.
B
B
C
C
C
Yeah,
in
this
case,
we
also
it
needs
to
be
not
only
just
standard
and
span
data,
but
it
needs
to
be
span
data
to
optional
screen
data
right
so
mandated
question
mark
in
kotlin
world
right,
because
you
might
want
to
remove
it
all.
Dropping.
C
I
mean
at
the
moment
we're
not
even
doing
propagation
like
we're
relying
on
response
headers
to
to
hook
up
the
http
requests
to
a
back
end
trace,
so
our
trace
ids,
don't
even
line
up
with
the
back
entry
settings.
They're
done
synthetically.
A
Is
that
that's
just
a
temporary,
mid
temporary
point
in
time
thing.
C
C
A
I
see
sue
if
you
make
a
request
to
your
back
end
when
you
care
about,
then
the
back
end
sends
back
a
response
header
exactly
and
that's.
Okay.
It
sounds
kind
of
like
browser,
yeah.
A
A
C
Not
too
sure
I
mean,
if
you're
assuming
you
assume,
that
your
incoming
requests
from
your
mobile
and
web
are
not
intended
to
be
propagated,
because
if
they
were
intended
propagated.
Well
I
mean
I
don't
know
exactly
how
it
hurts,
but
you'd
end
up
with
a
bunch
of
weird
parent
trace,
ids
coming
from
nowhere,
which
could.
C
C
A
Oh
yeah
josh
was
asking
about
the
the
jmx
receiver
and
the
collector
contrib.
I
don't
know
if
you
saw
he
sent
the
pr
just
to
update
the
releasing,
I
think,
still
figuring
out
how
to
keep
those
in
sync.
Okay,.
C
Yeah
and
then
josh
tried
to
convince
me
that
we
should
update
to
proto
0.10.0,
because
what
arm
could
there
be?
The
collector
worked
fine
with
it
and
I'm
like
nope
nope
not
going
to
do
it
not
until
the
collector
actually
releases
nope
not
going
to
be
fooled
again,
not
to
be
fooled
again.
Yep.
C
A
And
then
we
talked
about,
probably
we
should
be,
and
I
think
this
probably
affects
the
instrumentation
repo
more.
A
A
It
was
the
first
thing
I
just
went
over
to
the
collector
repo
and
looked
at
the
last
five
commits.
D
C
A
B
A
So
the
because
I
remember
when
I
updated
there's
so
there's
two
docker
images
right.
There's.
B
D
B
B
C
B
C
B
B
A
A
B
A
A
This
was
kind
of
interesting.
I
have
a
feeling
that,
because
I
it's
come
up
before,
where
somebody.
C
B
A
D
B
With
the
maven
shade,
plugin,
not
charger,
have
you
ever
used
charger?
No
me
neither
luckily,
but
like
trust,
I
would
just
randomly
came
up
when
I
was
talking
to
question
like
I
think
in
our
myriad.
They
added
code
to
handle
shade
like
to
detect
shading
like
if
our
mirror
is
shaded
like
it
needs
some
special
logic,
and
I
asked
like
this
is
needed
even
shade,
plug
in
to
shade
it
anyways.
It's
like
just
like
jar
jar
which
don't
do
it.
A
B
A
B
A
Yeah,
all
I
ever
I
never
atta.
I
don't
think
I
ever
used
needed
twitter
outside.
D
A
Oh
yes,
and
then
we
can,
then
we
can
use,
we
can
use,
oh
no,
where
is
oh?
Did
they
close
it?
What
happened.
D
A
But
apparently
they're
using
it
in
production
in
elastic's
ci
platform,
which
is
cool
so
yeah.
I
sent
them
over
to.
A
Well,
they
had
seen
this
already,
but
I
think
thought
that
it
was
only
java
agent
and
we
could
still
do
it
over
there.
But
I
think
the
contrib.
B
Yeah
nick
that's
a
topic,
I
guess
brought
up
the
point
of
moving
our
instrumentation
to
the
country.
I
like
the
way
he
phrased.
The
question
like
this
is
something
we're
still
interested
in
and
I
mean
I
will
say
still
say
my
answer
is
not
really
like.
Not
that
interested
like
it
seems
sort
of
nice,
but
it
also
seems
like
a
lot
of
effort
and
could
have
its
own
problems
so
like
I
would
push
anyone
to
do
it.
If
nikita
wants
to
do.
D
B
B
A
B
D
B
A
Yeah
interesting:
oh,
we
had
a
lot
of
people
come
this
morning
and
tyler
introduced
stuart.
So
that's
good!
I'm
hoping
that
we'll
be
able
to
kind
of
pick
up
with
the
datadog
folks
going
forwards.
B
Yeah,
I
didn't
see
a
random
dev
blog
thing
talking
about
open
commentary.
This
is
interesting
to
see
like
there.
I
guess
some
team
that
just
they
want
to
unify
all
their
open,
all
the
geometry
stuff
into
open,
telemetry
and
rewrite
their
stack
or
something,
and
so
they
are
looking
at
three
backgrounds.
One
of
them
was,
it
was
honeycomb
light,
stuff
and
datadog,
but
then
I
was
like
so
like
that's
purely
like
not
the
data
dog
agent
or
anything,
it's
purely
open,
telemetry
they're
using
them.
So
that's
obviously
a
use
case
for
them.
A
Yeah
yeah
because
it's
gonna
get.
A
Yeah-
and
I
expect
I-
I
was
kind
of
expecting
like
like
app
dynamics,
folks
kind
of
mentioned
previously-
that
you
know
they
were
sort
of
see,
seen
the
open
telemetry
java
agent
as
sort
of
the
really
call
it
not
a
community.
But
a.
A
Consumer
account
commodity
commodity
agent,
sort
of
just
that,
and
so
I'm
I
mean
I'm
hoping
that
more
people.
So
I
think
data
dog
and
elastic.
D
A
B
A
Trying
to
probe
probe
in
slack
for
who
are
the
decision
makers
over
there
who
do
we.