►
From YouTube: 2023-03-16 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
Am
back,
we
got
back
a
little
after
midnight
last
night.
Oh.
A
I'm
I'm
not
the
most
alert.
A
A
So
you
know
I've
been
in
Mexico
for
the
past
week.
One
day,
one,
my
daughter
calls.
We
have
rats
in
our
house
day,
three
or
two
Silicon
Valley
Bank
fails,
which
is
where
verta's
money
was
no
and
then
day
four
our
car
got
stolen
from
well.
My
daughter
was
staying
overnight
at
a
friend's
house,
so.
C
A
Know
super
relaxing
vacation
having
to
deal
with
all
this
in
a
foreign
country
jeez.
D
Well,
at
least
you
got
a
one
positive
set
of
news
and
that
virta's
money
is
safe.
All.
D
D
Yeah
I
can
share.
We
don't
have
an
agenda
right
now.
I
have
things
that,
or
at
least
like
one
thing,
that
I
would
like
to
at
least
like
Broach,
but
I.
Don't
know
it
might
be
kind
of
controversial.
A
I
will
just
say:
I
haven't
looked
at
GitHub
in
over
a
week,
so
I
have
no
idea.
If
there's
anything
urgent
for
me
to
look
at
or
not.
D
A
I
know
the
log
for
J2
API
is
kind
of
gross
or
for
doing
structured
logs.
D
Yeah,
let
me
let
me
bring
it
up.
D
All
right,
here's
one
that
I
actually
added
to
are
open,
Telemetry,
Java,
Docs,
so
fluent
API
specify
the
the
severity
level
you
have
Setters
for
all
the
the
typical
things
that
are
attached
to
your
log.
Like
your
message,
your
markers
and
then
there's
the
this
ability
to
add
key
value.
Pairs
to
you
know,
have
a
structure
to
it,
and
then
you
emit
the
record
with
that
log.
Is
it.
A
C
D
D
It
was
kind
of
in
an
alpha
release
or
pre-release
for
four
years,
and
we
weren't
ever
sure
whether
it
was
going
to
come
out
and
what
it
was
going
to
look
like
it
came
out,
and
it
has
this
edition
of
a
fluent
API
and
a
fluent
API
like
that
makes
it
really
easy
to
do
structured
logs,
structured
logging,
and
so
the
question
that
I
have
is:
should
we,
you
know
open,
Telemetry
Java,
we
don't
have
a
log
API
we're
not
going
to
have
a
log
API.
D
Should
we
formally
recommend
that
slf
for
J2
is
our
recommended
API
to
use
and
potentially,
as
a
as
another
kind
of
aspect
of
that
conversation?
Should
we
should
we
adapt
slf
for
J2
as
our
event,
logging
API
as
well?
D
You
know,
essentially
with
a
good
fluent
fluent
logging
API
emitting
log
records
that
are
shaped
as
open.
Telemetry
events
is
much
easier
because
you
just
have
to
include
two
attributes
each
time,
the
event
name
and
the
event
domain,
and
so
the
barrier
to
emit
open
Telemetry
events
is
much
smaller
than
it
has
been
in
the
past,
where
the
structured
logging
apis.
D
Yeah,
it's
being
actively
debated
right
now.
It
always
says
you
know,
there's
conversations
right
now:
John
just
to
catch
you
up
a
bit
we're
trying
to
stabilize
the
parts
of
the
log
API
and
SDK
the
log
Bridge
apis.
D
It's
called
now
and
the
SDK-
and
you
know,
I-
think
that
parts
of
the
log,
API
and
SDK
that
are
that
are
meant
to
bridge
existing
log
Frameworks
into
open,
Telemetry
and
and
process
those
in
an
SDK
and
batch
them
up
and
Export
them
to
network
location
over
otlp
I
think
those
things
are
are
pretty
solid
and
we
like
there's
not
a
lot
of
debate
about
them
and
I
guess
I'm
trying
to
I
would
I
would
I
don't
want
this
at
the
event
conversation
to
kind
of
derail,
the
stabilization
of
this
stuff
that
everybody
agrees
on
and
is
fairly
important,
so
that's
kind
of
where
my
head's
at
on
this
whole
thing.
D
Well,
so
there's
this
part
there's
a
couple
things
that
are
controversial
in
the
in
the
log
signal
discussion,
so
one
of
them
is:
should
we
have
a
user
facing
log
API
right
now,
the
in
that
really
there's
only
one
or
two
language
ecosystems
where
that
is
a
kind
of
a
controversial
thing.
Most
language
ecosystems
have
existing
Legacy
log,
Frameworks
and
apis
that
are
not
worth
competing
against.
Java
is
one
of
them.
We
don't
want
to
reinvent
the
wheel.
D
We
don't
want
to
try
to
supersede
log4j
or
slf
for
J,
but
a
couple
of
languages
like
C,
plus,
plus
and
and
maybe
JavaScript,
but
it's
it's
a
bit
more
shaky
over
there,
like
C
plus,
has
no
good.
You
know,
based
on
the
conversations
I've
heard,
they
have
no
good
logging
apis
that
have
you
know,
High
rates
of
adoption,
and
so
the
folks
over
in
the
open,
Telemetry,
C
plus
plus
group,
would
like
to
have
a
user
facing
log
API.
D
F
Got
it,
and,
and
is
this
a
potentially
holding
the
specification
from
becoming
stable.
D
D
It
it's
in
it's
part
of
the
conversation
about
stability,
because
you
know
there's
this
question
of
hey.
We
don't
want
to
use
your
facing
log
API
today,
but
if
we
want
to
loosen
that
restriction
and
allow
some
language
ecosystems
to
have
a
user-facing
log
API
in
the
future,
we
want
to
make
sure
that
what
we're
building
now
doesn't
like
doesn't
prevent
that
and
it
doesn't
box
us
into
a
corner.
Essentially
I,
like
I'm,
always
going
to
be
able
to
stance
that
Java
should
not
have
a
user
facing
log
API.
D
A
A
C
D
A
B
D
Guess
what
was
in
my
head
was
that
so
just
a
little
bit
more
background,
so
the
event
API
conversations
are
are
really
murky.
D
There's
very
little
agreement
about
you
know
whether
an
event
API
should
exist,
how
it
relates
to
the
log,
API
or
SDK,
whether
the
event
API
should
just
delegate
to
the
log
API
or
whether
it
should
be
a
standalone
thing
with
its
own
event
provider
and,
like
a
event,
emitter
interfaces
or
whether
you
know
you
know
the
the
event
API
shouldn't
exist
at
all,
and
you
should
just
we
should
just
have
event
semantic
inventions
and
we
should
recommend
to
our
users
how
to
emit
log
records
that
are
shaped
as
events
and
so
I.
D
D
And
so
you
know
that's
a
little
bit
of
context
and
bringing
that
back
to
why
why
we
might
want
to
have
a
recommended
log
API
if
SLO
for
J
is,
you
know,
checks
all
of
our
boxes
and
it
also
checks
the
boxes
for
being
able
to
emit
open,
Telemetry
events
in
a
very
clean
ergonomic
way.
Then
we
stop
having
to
have
a
stake
in
the
conversation
about
what
happens
in
an
event
API.
We
can
just
say
you
know
great.
Like
you
know,
open
Telemetry
can
take
the
position
of
build
an
event
API.
A
D
Does
you
have
to
opt
into
it
by
like
including
a
setting
on
your
appender
configuration
that
says?
Basically,
you
know
include
those
as
attributes
and
it's
kind
of
annoying,
because
we
include
like
a
prefix
on
the
attribute,
like
you
know,
for
map
diagnostic
contacts,
we
say
like
MDC
Dot
and
then
your
attribute
name,
your.
A
D
C
D
You
have
it
handy,
I
got
it
handy
because
I
you
know,
so
this
is
back
in
open,
Telemetry
javadox,
that
repository
I
added
this
example.
That
shows
all
sorts
of
different
things.
How
Jewel
logging
works
with
open
Telemetry,
how
log4j
Works?
How
slf4j
works?
You
know
log
back
all
the
different
things
and
one
of
the
things
I
have
going
here
is
a
map
message.
A
Yeah
so
I
mean
it
just
puts
the
yeah.
What
I
don't
know
what
the
behavior
in
hotel
is
but
and
I.
Think
there's
like
a
string
map
message
that
like
helps
you
with
it,
if
I
remember
like
so,
you
don't
have
to
build
the
map
up
separately.
So
there's
a
nicer
API
than
what
you
have
here
right
now,
so
I
guess
what
I'm
saying:
okay
I
think
you
can
say
like
string
I
only
let
me
look
it
up
real
quick
I
think
it's
like
string
map
message.
A
Map
new
news,
I,
don't
remember
how
this
works.
A
A
D
C
C
D
Well,
this
is
a
Java
8
environment.
That's
why
okay
yeah
job
11!
You
could
that
map
of
solves
all
the
usability
problems.
Yeah.
C
A
D
All
right,
all
right,
all
right,
yeah,
maybe
like
I,
was
messing
with
some
of
the
stuff
to
make
slf4j
and
log
back
behave
a
certain
way,
so
I
wasn't
sure
if
that
erupted
it.
So
we
have
two
log
messages
here:
okay,
this
is
kind
of
what
I
was
talking
about.
So
here's
our
string,
one
with
Foo
bar,
is
our
key
value
pair
and
it's
prefix
with
log4j.map
message.
D
We
do
translate
it,
but
we
add
this
annoying
prefix
for
now,
anyways
yeah,
that's
that's
not
pretty,
and
then
the
same
thing
happens
for
the
next,
the
yeah
that
okay,
this
is
actually
kind
of
interesting.
So
the
other
map
message
has
a
key
value
pair
and
then
another
one
with
whose
key
is
message-
and
it
looks
like
if
you
have
a
map
message,
that
the
key
entry
for
message
gets
translated
to
the
body
of
the
message
and
other
key
value
pairs
in
the
map.
Get
translated
to
attributes.
A
Yeah
this
I
mean
this
is
a
big
pain
with
the
log
for
J2
API.
Is
that
there
isn't
a
way
to
just
you
can't
both
give
it
a
string
like
here's,
my
main
message
and
then
here's
a
bunch
of
attributes,
like
it's
all
kind
of
crunched
together
into
one
thing.
Unfortunately,
does
the
the
slf
yes
I'll
have
two
have
a
better
like
it.
Let
you
have
a
message
and
attributes.
D
It
does
it
definitely
lets
you
have
a
message
and
it's
and
separate
attributes
you
know
coming
down
here.
You
have
a
message
right
of
argument
and
key
value
pairs,
but
I
actually
was
experimenting
with
this
yesterday
and
key
value
pairs
like
so
s
for
J
the
the
standard
like
back
end
for
this
is
log
back
and
log
back
doesn't
support
this
notion
of
key
value
pairs
until
version
1.3.
A
So
I
think
I'm
a
little
bit
with
Jason
on
like
it's
hard
to
I,
don't
necessarily
know
if
we
should
be
playing
sides
between
slf2
and
log
for
J2,
because
since
they
both
have
support
for
it,
although
maybe
we
think
the
slf
API
is
better
I,
don't
know
that
I
don't
know
that
playing
favorites
in
this
is
going
to
help
I,
don't
know,
I,
don't
know
what
it
will
end
up
solving
if
we
have
an
easy
enough
way
to
do
it
to
recommend
to
generate
like
in
the
future
world.
D
Yeah,
that's
true,
so
it's
just
the
well.
If
the
thing
that
is
driving
us
to
have
our
own
event,
API
is
the
ergonomics
of
the
existing
apis
that
are
available.
Then
you
know
maybe
the
the
improved
ergonomics
of
slf4j.
You
know
put
it
over,
put
it
ahead
of
log
for
Jay
and
PR,
and
you
know
prevent
us
from
having
to
have
our
own
API.
D
And
if
we're
looking
for
a
reason
to
not
have
one
too
for
like
Simplicity
or
just.
A
I
actually
think
so,
I
think
it's
actually
more
complex
to
do
it
and
I'm
using
the
complex
and
the
in
the
way
that
things
are
more
intertwined
because
then
you
have,
if
you
want
to
distinguish
your
events
from
your
logs
you're,
going
to
have
to
have
more
complexity
somewhere
in
the
pipeline
to
pull
them
apart.
So
anyway,
that's
you
know
a
complexity
versus
Simplicity
argument,
I
think.
Actually
it
would
be
more
complex
to
intertwine
the
log
API
in
the
and
the
event
API.
F
F
I
guess
it
results
in
the
same
outcome,
but
I
have
not
tried.
D
That
that's
the
I
think
that's
the
same
syntax.
That
I
was
that
I
was
using
so
logger
specify
the
severity
level.
Oh.
D
Yeah
we
were
looking
at
the
we
were
comparing
log
for
j2's
API
to
slf
for
J2,
so.
D
Foreign
well,
thanks
for
the
feedback,
everyone
I
hope
we
can
get
the
the
log
Bridge
API
and
SDK
stable
in
a
reasonable
time
frame.
G
Yeah,
thank
you.
So
thanks
everybody
for
giving
me
a
moment
to
ask
this
I'm
from
the
I
guess
for
folks
that
haven't
seen
me
before
I
I'm,
working
with
a
group
for
in
micro
profile,
which
we're
trying
to
expand
our
capability
of
what
we
call
microprofile
Telemetry,
which
is
a
if
you
want
to
think
of
it
as
a
a
runtime
based
implementation
or
different
vendors,
vendors
being
sort
of
different
application,
servers
or
runtimes
that
want
to
have
Telemetry
support.
G
This
defines
a
specification
for
them
to
to
basically
add
Telemetry
to
their
servers
and
the
intent.
We
had
a
first
release
based
entirely
around
micro,
entirely
around
open,
Telemetry
I
should
say
just
for
the
tracing
side
and
that's
and
then
we'll
get
to
too
deep
into
where
that's
going
at
this
point.
G
But
I
did
have
questions,
we're
trying
to
look
at
how
we
are
defining
new
spans
from
MP
Telemetry
that
we
want
to
require
any
of
the
implementations
to
to
provide
to
to
say
that
they're
compatible
with
microprofile
Telemetry.
So
imagine
that
we
are
as
MP
Telemetry
going
to
tell
our
our
runtime
providers.
G
They
all
have
to
provide
HTTP
spans
and
I
realized
from
looking
at
the
list
of
spans
that
you
guys
already
have
there's
lots
of
of
components
that
exist
things
like
Neti,
you
know
Neti
or
or
akka
or
other
HTTP
Frameworks
that
you
already
have
spans
for
so
I.
Look
at
this
as
a
stack
of
of
different
layers
that
we
could
potentially
tell
people
is
the
right
place
to
put
the
HTTP
spans,
starting
at
the
bottom,
I
guess,
with
the
otel
agent,
you
know
things
like
servlet,
Jacks,
RS
and
HTTP.
G
Frameworks
are
already
included
in
your
list.
There's
the
app
server
runtime
itself,
I'm
sort
of
splitting
out,
logically,
the
micro
profile
Telemetry
layer,
but
that's
basically
part
of
the
app
server
or
runtime
and
then
obviously
there's
the
application
sitting.
On
top
of
all
that,
so
the
thought
here
is
today.
G
We
tell
people
that
if
they
want
to,
they
can
run
with
just
microprofile
Telemetry
and
that
sets
up
the
open,
Telemetry
object
and
has
the
ability
to
connect
off
to
things
like
the
hotel,
collector
and
stuff
like
that,
which
is
cool,
but
to
get
the
additional
instrumentation
that
is
provided
with
the
Java
agent.
They
they
obviously
need
to
run
with
both
the
micro
profile
Telemetry,
as
well
as
the
Java
agent.
G
G
So
my
question
really
is,
as
we
look
at
adding
HTTP
requirements
to
MP
telemetry,
which
layer
of
the
stack
would
you
guys
recommend
that
we
say
that
that
stuff
should
go
into
and
obviously
I
mean
for
for
four
run
times
that
are
not
using,
for
example,
Neti
as
their
implementation
for
the
HTTP
stack?
If,
if
you
know
open,
Liberty
or
or
somebody
else
comes
along
and
they
want
to
add
HTTP
spans,
should
they
be
trying
to
add
that
to
the
Java
agent
through
through
open
Telemetry,
or
should
they
be?
G
D
I
think
it
makes
sense.
It's
a
tough
question
and
I
think
the
person
who
would
probably
be
have
the
the
most
useful
things
to
say
on
this
is
Trask
and
he's
he's
out
this
week.
D
Lori
is
here
from
the
instrumentation
group
and
and
Jason
does
a
little
bit
of
instrumentation
I
haven't
thought
deeply
and
hard
about
this
type
of
question
about
you
know
if
if
we
have
the
opportunity
to
have
native
or
Upstream
instrumentation
in
libraries,
kind
of
how
that
interplays
with
the
agent,
where
that
instrumentation
will
be
duplicated,
I
mean
you
can
always
disable
select
bits
of
instrumentation
from
the
agent?
D
So
you
know,
if
you
prefer,
if
you
prefer
the
upstream
or
native
instrumentation
from
micro
profile,
you
can
disable
the
the
parts
that
would
be
duplicated
in
the
agent.
Well,
you
know
continuing
to
let
the
agent
add
instrumentation
for
things
that
micro
profile
Telemetry
doesn't
capture.
G
That
makes
sense
yeah
and
last
week,
I
guess
I
was
on
and
I
I
did
see
trust
last
week
about
sort
of
the
question
of
where
spans
in
general
belong
that
are
microprofile,
specific
and
I
guess
it
seemed
like
everybody
was
on
the
same
page
last
week
to
say:
if
it's
something
that's
clearly
in
the
microprofile
space,
it
should
be
defined
in
microprofile,
just
because
it
doesn't
scale
very
well
to
do
everything
in
the
in
the
agent
right
and.
D
You
get
this
addicted,
you
get
this
distinctive
Advantage
too,
by
including
the
Telemetry
and
micro
profile
itself.
So
you
know
you're
going
to
have
some
class
of
users
that
might
want
to
use
micro
profile
with
the
hotel
Java
agent,
but
folks
that
just
want
to
use
microprofile
Telemetry.
They
can
do
so
and
have
get
useful
Telemetry
without
the
agent
at
all.
G
But
if
that's
the
wrong
thing
to
do,
then
be
better
to
know
that
at
the
front
so
that
we
consider
doing
it
in
the
Java
agent.
If
that's
better.
B
Yeah,
if
there's
a
specific
Liberty
stack
where
they
have
their
own
sort
of
implementation,
that's
not
covered
by
anything
else.
I
mean
I,
think
I,
think
open.
Telemetry
would
love
for
us
to
have
that
instrumentation
build
both
library
and
auto
instrumentation.
It
would
be
great
to
have
that
and
then
then
you
know
you
can
live
in
in
the
open,
Telemetry
agent
or
the
library
instrumentation
can
then
be
used
by
whoever
right
I
think.
That's
the
general
idea.
What.
G
Yeah,
when
you,
when
you
differentiate
between
the
library
and
the
agent,
are
you
saying
that's
that
you
would
open
source
the
library
that
that
has
the
instrumentation
and
you
could
use
it
by
the
agent
or
use
it
by
MP,
telemetry
yeah.
D
Do
you
add
a
dependency
to
your
application
and
you
pull
in
that
dependency
and
and
somehow
wire
in
the
instrumentation
that's
contained
in
that
dependency?
Either.
You
know
wrapping,
maybe
like
the
client
library
with
a
a
rapper
or
something
that
performs
the
instrumentation
or
plugging
it
into
some
pluggable
extension
Point
in
in
the
library
that
you're
instrumenting.
D
So
we
publish
a
number
of
library
instrumentations
for
a
variety
of
projects,
and
then
we
also
have
a
larger
number
of
Auto
instrumentations,
so
things
that
instrumentations
that
are
wired
in
through
bytecode
manipulation
from
the
Java
agent.
G
C
B
Sense,
if
you
look
in
the
instrumentation
repo
Mo
I'd
say
more
than
half
most
of
the
instrumentations
have
a
matching
with
agent
agent
and
Library
instrumentation.
B
All
right,
well,
a
bunch
of
them
have
it
and
that
that
does
make
it
nice
like
when
it's
when
it's
feasible
to
do
that.
What's
nice
about,
that
is
that
the
library
component
can
be
used
reused
by
other
Frameworks
right.
Okay,.
G
B
Yeah
my
first
thought
too,
and
this
may
not
be
appropriate,
I-
think
having
gotten
a
better
understanding
about
how
things
work
in
micro
profile,
but
my
initial
thought
was
well
micro
profile
could
also
do
a
distro
kind
of
like
we
do.
We
have
some
additional
instrumentation
that
we
pile
and
Telemetry
agent,
but
if
one
of
the
goals
is
to
is
to
not
is
to
be
able
to
run
without
agent,
then
maybe
that's
less
interesting.
G
G
Right,
cool,
yeah,
I
think
that
that
helps
so
I
guess:
I'll,
look
at
sort
of
what
we
can
do
for
for
I,
I,
guess,
you're,
calling
it
a
library
based
based
based
approach
to
the
instrumentation
and
and
potentially
looking
at
at
what
we
would
need
to
do
or
what
we
would
want
for
a
microprofile
from
the
subset
or
a
subset
from
the
the
list
of
all
of
all
of
your
instrumentations
is
that
list
of
supported
libraries
is
that
does
that
Encompass?
G
Both
the
agents
and
the
sorry,
the
auto
and
oh
sorry,
I
think
I
can
see
right
from
the
heading
Auto,
instrumented
versions
versus
Library
instrumentation,
so
thanks
I
think
that's
fairly
intuitive.
Now
that
I
understand
the
difference.
A
As
a
side
note,
if
someone
wanted
to
you
know
dip
their
feet
into
instrumentation,
the
Java,
HD,
client,
Library,
instrumentation
still
needs
to
be
written
and
I
think
it
actually
will
be
relatively
easy
to
do
just
because
the
Java
this
is
the
Java
11
plus
HTTP
client
still
needs
to
be
done.
It's
it
shouldn't
be
hard
to
do,
because
the
HCB
client
is
an
abstract
class.
A
So
you
can
extend-
and
you
know
add,
add
whatever
you
need
to
add
or
wrap
it
or
whatever
needs
to
be
done
anyway,
needs
to
be
done.
I
haven't
had
time
to
do
it.
I
have
a
really
hacky
version
of
it
in
the
vertic
code
base,
but
it
would
be
cool
if
someone
had
time
to
contribute
something
more
solid.
F
So
how
do
you
see
in
general,
the
relationship
between
Java
agent
and
Native
instrumentations
is
what
is
going
to
be
the
solution
in
a
couple
of
years?
Will
we
have
both
or
will
it
converge
to
one
of
them.
D
I
think
you
know,
I
would
want
the
instrumentation
folks
to
to
weigh
in
here
for
sure
I
think
the
more
native
instrumentation
that
exists,
the
better.
H
What
what
you're
you're
giving
them,
whatever
application
you've
got,
or
your
your
library
or
micro
profile
library,
then
you're,
giving
it
to
them
with
the
Noel,
the
API
and
the
know-up
one,
and
you
tell
them
that
if
you
point
it
at
the
SDK,
then
you'll
get
Telemetry
at
if
you've
implemented
it
yourself
in
your
application
or
in
your
framework.
H
If
you
don't
do
that,
then
you're
telling
them
they
have
to
install
the
agent
and
there
are
scenarios
where
the
agent
just
doesn't
work
so
you're
kind
of
limiting
yourself.
If
you
say
it's,
it's
only
in
the
agent
instrumentation,
so
every
framework
really
should
be
implementing
it,
not
in
the
agent
if
they
can.
I
I
also
have
a
similar
feeling,
because
on
quarkers
we
don't
use
the
agent
mainly
because
of
the
way
we
handle
the
context
between
vertex
and
the
imperative
world
and
I
also
have
this
from
that.
At
some
point,
I
want
to
to
get
a
bundle
of
all
those
libraries
that
instrument
code
and
make
them
available.
I
H
There's
there's
actually
three
different
options:
there.
The
API
comes
with
a
null
SDK,
okay
and
then
the
otel
SDK
will
actually
so
then
you
won't
get
any
Telemetry
coming
out
of
your
application.
If
you
then
point
it
at
the
SD
at
the
hotel
SDK
as
well,
then
you
do
get
Telemetry
whether
the
agent
is
there
or
not.
H
So
it's
it's
there's,
there's
three
levels
there,
the
third
level
being
if
you
install
the
agent,
it's
it's
It's
a
combination
and
there
are
scenarios
where
the
agent
won't
work
like
if
the
security
is
is
a
bit
odd
or
yeah.
There's
there's
lots
of
reasons
where
the
the
agent
doesn't
work,
sometimes,
whereas
the
SDK
will
always
work
and
in
addition,
the
SDK
will
also
always
work
in
a
in
a
natively
compiled
application
where
the
currently
the
agent
I
think.
G
G
I
think
all
that
makes
sense
to
me.
Yeah
the
agent
I
know:
I've
looked
at
in
some
cases,
I
get
nervous
about
things
like
exposing
a
Prometheus
endpoint,
socket
right
on
the
side
of
a
runtime
that
otherwise
has
its
own
sort
of
conventions
for
security
and
everything
else
that
sort
of
is
entailed
in
exposing
an
endpoint.
So,
personally,
the
preference
is
to
try
to
avoid
having
the
agent
do
things
that
overlap
with
the
runtime
and
that's
where
I
like
having
the
MP
telemetry
layer
handle
some
of
that
stuff.
G
D
In
general,
the
kind
of
architecture
of
open
Telemetry
and
the
separation
between
the
API
and
SDK,
the
kind
of
main
point
of
that
is
that
folks,
who
are
authors
of
libraries,
can
take
a
dependency
only
on
the
open,
Telemetry
API,
and
so
you
know
they
they
consume
the
API
and
make
the
calls
to
you,
know,
records
or
to
start
spans
and
record
attributes
and
to
record
metrics
and
so
on
and
so
forth,
and
by
default
all
that
Telemetry
gets
dropped
on
the
ground.
D
Nothing
happens
with
it
and
it's
once
a
user
plugs
in
their
own
SDK
that
they've
configured
in
their
application,
then
all
of
a
sudden,
this
library,
that
they
take
a
dependency
on
and
the
library
which
can
you
know,
uses
the
open,
Telemetry
API.
All
the
sudden
starts
producing
Telemetry
that
they
can
consume
and
Export
to
the
process
and
Export
to
you
know
whatever
solutions
that
they
have,
and
so
the
advantage
of
that
type
of
architecture
is
that
the
API
is
very
stable.
D
There's
it's
always
backwards
compatible,
and
so,
if
you
have
dependencies
on
many
libraries
that
have
you
know
differing
versions
of
transitive
dependencies
on
the
open,
Telemetry
API,
it
doesn't
really
matter
those.
Those
transitive
dependencies
can
all
get
resolved
to
the
latest
version
or
to
the
latest
version.
And
then
you
know
the
the
the
libraries
can.
You
know
call
them
all
the
same,
and
you
know
the
SDK
dictates
what
happens
with
the
Telemetry.
That's
collected
from
the
invocations
of
those
apis.
G
Yeah,
that
makes
a
lot
of
sense,
especially
for
the
backward
compatibility
of
it,
which
is
super
important
for
for
us
to
be
able
to
keep
stability,
as
as
we
sort
of
release
in
new
versions
of
micro
profile.
Telemetry
too,.
C
B
For
that
HTTP
client,
Library,
split
out
I
didn't
see
one
really.
A
B
F
Yes,
just
said
to
unmute,
so
I
had
a
discussion
with
the
spring
boot
maintainer
about
making
it
easier
to
configure
endpoints
in
Spring
and
currently
it's
possible,
but
it's
a
bit
different
than
in
the
SDK
and
I
think
can
also
be
more
difficult
for
users
who
are
not
experts,
so
I
suggested
to
add
the
SDK
Auto
configure,
but
it's
an
alpha
artifact
and
therefore
it's
not
possible
to
do
that.
F
So
now,
I
looked
up
what
the
definition
is,
and
my
question
is
concretely:
what
for
the
SDK
Auto
configure
needs
to
be
done
or
yeah?
What
is
stopping
it
from
being
graduated.
D
I've
thought
about
this
myself:
it's
there's
been
a
lot
of
work.
That's
happened
on
auto
configure
over
the
last
year
or
so,
and
you
know
just
concretely.
The
difference
between
Alpha
and
stable
artifacts
is
that
we
commit
to
not
make
breaking
changes
to
the
apis
for
stable
artifacts.
D
D
There's
one
kind
of
big
open
question
in
open,
Telemetry
right
now,
which
is
around
configuration
which
is
there's
a
working
group
and
I'm
part
of
it,
and
we're
trying
to
we're
trying
to
make
progress
on
a
file
based
configuration
scheme
so
rather
than
using
environment
variables
or
programmatically.
Invoking
the
imperative
apis
to
build
up
SDK
components.
You
could
specify
a
yaml
configuration
file.
We'd
interpret
that
and
build
up
an
SDK
from
that,
and
the
advantages
of
having
a
yaml
configuration
file
are
many.
G
D
And
all
these
things
that
don't
map
well
to
the
flat
configuration
scheme,
that's
available
in
environment
variables
and
system
properties,
so
that's
coming,
there's
an
Otep
out
for
it
right
now
and
it's
the
question
that
I
have
around
stabilizing
the
auto
configuration
module
is.
How
is
that
work
going
to
impact
Auto
configure?
D
You
know
I
think
we
can
make
it
work
with
auto
configure
without
changing
the
the
API
surface
area
at
all,
like
I,
think
the
API
surface
area
would
stay
the
same,
but
there
might
be
some
some
behavioral
changes.
That
would
be
somewhat
surprising.
You
know,
depending
on
how
things
shake
out,
and
one
that
comes
to
mind
is
like
suppose,
like
one
of
the
things
that
you
can
do
in
the
auto
configuration
module.
D
Is
you
can
provide
property
suppliers,
so
you
can
provide
your
own
sources
for
configuration
properties
and
they
layer
on
top
of
the
environment,
variables
and
system
properties
and
ultimately,
the
the
the
final
kind
of
they're
ultimately
flattened,
and
we
interpret
them
to
build
up
the
the
SDK.
But
what
happens
with
those
when
you
have
a
file
based
configuration
scheme
in
there?
D
Like
you
specify
hey,
you
know
like
reference,
this
file,
this
file
is
like
what
I
want
to
use
to
specify
how
I
want
my
my
Tracer
provider
and
meter
provider
and
logger
provider
to
behave
in
my
resource
like
all
of
a
sudden
one
solution.
There
is
that
property
suppliers
get
like,
they
don't
do
anything
anymore,
and
so,
if
something
like
like
a
vendor,
wants
to
be
able
to
layer
on
their
own
configuration
and
like
add
property,
suppliers
like
that
might
not
play
nicely
once
a
file
based
configuration
scheme
is
in
play
are.
F
You
saying
that
it
would
replace
the
environment
variables
and
you
could
not
pick
and
choose
so
like
have
a
file
and
then
also
pass
in
an
environment
variable
for
debugging
purposes
or
something
like
that.
Yeah.
D
So
the
way
that
it's
shaken
out
right
now
is
we
it's
one
or
the
other
so
like.
If
you,
if
you
specify
the
that
a
file
should
be
used,
then
that
file
is
the
is
the
source
of
Truth
for
your
configuration,
there's
no
attempt
to
try
to
interpret
the
environment
variables
and
try
to
layer
them
on
top
of
your
file
in
some
sort
of
way,
because
there's
all
these
unintuitive,
like
sharp
edges
on
how
that
layering,
would
work.
I.
D
Yeah
yeah,
so
it's
like
one
or
the
other,
but
you
know
the
tool,
a
tool
that
you
do
have
in
your
back
pocket
with
this
file
configuration
scheme
is
in
your
file,
your
yaml
file.
You
would
be
able
to
reference
environment
variables,
so
you
could
say
like
hey,
like
reference,
an
API
key
from
an
environment
variable,
so
I
don't
have
to
hard
code
that
in
a
file,
but
you
have
to
explicitly
opt
in
to
which
environment
variables
you
want
to
layer
on
top
and
exactly
where
so,
that's
kind
of
what
I
mean.
F
I
understand
yes,
actually,
this
is
what
spring
has
been
doing
for
years,
so
I'm
a
bit
surprised
but
I
think
it's
a
different
discussion
in.
I
I
Yeah
and
micro
profile
and
well
quercus
and
everyone
else.
So
if,
if
you
have
a
container
you
you
handle
configuration
you,
you
always
have
handled
them
and
there's
already
a
way
to
override
them
with
the
file,
so
isn't
open,
Telemetry
trying
to
create
yet
another
way
to
do
this
for
apps
that
don't
use
a
container
or
just
what's
the
purpose.
I
D
So
it's
not
possible
to
represent
it's,
not
practical.
Let
me
just
rephrase
it's
not
practical
to
replace
a
lot
of
the
complex
configuration
that
you
know
you
need
to
do
in
order
to
expose
all
the
configuration
surface
area
of
the
SDK
today,
like
just
a
couple
of
examples,
views
you
can't
configure
those
with
environment
variables
or
system
properties
and
another
example
is
processors.
So
we
support
allowing
you
to
add
multiple
processors,
each
one
with
their
own
exporter
attached
to
that
and
that
that
doesn't
map
well
to
a
flat
configuration
scheme
at
all.
D
Like
you
know,
right
now
we
just
say
export
my
data
via
otlp
and
Jaeger,
and
you
can
have
a
comma
separated
list
of
exporters
and
we
interpret
that-
and
we
say
you
know
you
have
two
exporters
that
are
desired.
You
translate
that
into
adding
two
batch
processors
to
your
Tracer
provider,
but
really
that's
that's.
That's
not
that's,
not
that's
not
as
expressive
as
the
as
the
SDK
really
allows
you
to
be.
You
know
you
can
add
other
processors
that
aren't
tied
to
exporters.
You
might
want
to
have
different
process.
D
B
F
As
far
as
I
understand
it's
a
policy
choice,
I
I'd,
want
to
know
more
about
it,
but
I
think
they
don't
do
that
for
stability
reasons,
because
they
want
to
always
be
backwards,
compatible.
B
F
Well,
it
would
not
change
anything
about
the
guarantees.
D
E
E
I
think
that
the
auto
goal
is
to
like
to
also
like
always
be
backwards
compatible,
and
perhaps
there
is
a
way
out
like
when
a
new
major
version
comes,
but
nobody
has
figured
out
like
what's
the
way
like
how?
How
are
you
going
to
break
the
back
Parts
compatibility
when
you
really
need
it
so
everybody's
really
careful
in
taking
on
the
responsibility
and
saying
like
this
is
the
final
thing.
This
is
going
to
be
backwards,
compatible.
F
Right,
it's
a
trade-off,
I
mean
being
Alpha,
is
holding
people
back
from
adopting
open,
Telemetry
and
I
mean
this
has
been
the
case
for
a
couple
of
years
now.
So
my
question
is
more:
when
do
we
when
are
we
finally
stable
because
being
always
unstable
is
defeating
the
purpose?
Because
then,
why
are
you
saying
it
at
all.
C
B
D
D
Well,
let's
just
say
this:
the
file
based
configuration
stuff
is
going
to
take
a
while
before
it's
stable
and
it
seems
unreasonable
to
gate
the
stability
of
Auto
configuration
on
this
kind
of
like
ethereal
sometime
in
the
future
thing,
which
is
file
based
configuration
I'm,
not
opposed
to
you
know
having
the
discussion
about
you
know:
can
we
just
Mark
Auto
configuration
configure
as
stable
now
and
figure
out
how
we
fit
file
based
configuration
into
it
like
in
a
in
a
backwards
compatible
way
in
the
future?
D
And
we
just
like
you
know
we
we
write
off
that
that
we
write
it
off
and
say
you
know,
we'll
have
to
solve
this
problem
sometime
in
the
future,
but
it's
not
worth
getting
stability
on
for
now,
because
it's
too
costly
to
get
stability,
I.
B
D
Honestly,
John
that
that's
been
the
the
kind
of
the
the
checkpoint
in
my
head,
it's
like
once
logs
are
stable.
Then
you
know
we
have
three
stable
signals.
That
seems
like
a
good
time
to
Mark.
Auto
configure
is
stable
as
well.
Yeah
I
think
that
probably
makes
sense,
and
that
should
be.
You
know
coming
around
the
corner
unless,
unless
something
crazy
comes
in
derails,
yeah
I,
don't
think.
A
D
All
right,
you
know,
Bruno
I
know
we
only
have
four
minutes
left
I
think
we,
let's
spend
the
last
four
minutes
talking
about
your
your
issue,
which
we've
talked
about
in
slack
a
bit,
but
if
you
could
bring
it
up
for
the
rest
of
the
group.
I
Yeah
so
I
also
have
some
questions
about
the
auto
configure
properties
and
the
file
base.
But
I
will
ask
the
questions
on
Slack,
so,
okay,
HTTP
3..
So
we
have
this
dependency
on
the
exporter.
Basically,
the
exporter
is
built
on
top
of
it
and
now
that's
causing
us
problems,
because
the
the
latest
version
depends
on
kotlin
and
there
there's
some
other
issues,
and
we
cannot
really
support
this
long
term
because.
I
And
the
maintain
maintainability,
because
we
ship
kotlin
and
if
some
other
dependency
has
some
other
unrelated
version
of
cotton.
I
And
we
don't
control,
what's
going
to
be
set
on
okay,
http,
3.,
and
up
until
now
it
has
been
okay,
but
we
really
need
to
move
away
from
this
and
we
are
even
considering
well,
maybe
creating
some
exporter
over
on
or
something
like
that.
But
before
that
I
I
would
like
to
discuss
with
you
guys.
If
he's
think
we
should
work
on
an
exporter.
That's
not
hard-coded
to
a
particular
implementation
like
this.
I
A
I
D
Bruno
would
it
work
if
how
how
much
of
your
problem
would
be
solved
if
we
provided
an
of
an
implementation
that
was
based
on
the
the
built-in
Java
HTTP
client
library,
from
java
11.
I
I
think
I
think
that
would
be
okay.
It
would
be
better
but
I'm
thinking
that,
because
we
have,
for
example,
our
if
we
want
if
a
user
wants
to
be
purely
reactive
and
wants
to
use
the
vertex
reactive
client
or
something
like
that,
and
we
we
are
stuck
with
the
the
jdk
client
that
won't
solve
the
case
for
them.
So
if
we
have
an
abstraction,
so
we
can
plug
the
the
client
according
to
what
the
application
actually
needs
would
be
much
much
better,
because
this
way
reactive
folks
will
always
have
some
kind
of
issue.
D
Yeah
designing
a
generic
API
that
you
know
supports.
You
know
the
reactive
and
non-reactive
versions
of
what
a
client
HTTP,
client
implementation
might
provide,
sounds
really
tricky.
D
You
know
it
seems
kind
of
possible
if
we
were
just
to
lock
into
one.
But
you
know
this
idea
that
clients
will
always
demand
some
sort
of
reactive
version.
I,
don't
know
I,
don't
want
to
rule
it
out,
but
it
seems
it
seems
really
hard
to
imagine
how
that
would
work
in
a
clean
way.
I
D
I
We
have
to
to
find
a
good
compromise
in
here,
so
I
I
think
we
can
explore
the
standard.
Http
client
I
know
that
took
HTTP.
3
client
provides
a
bunch
of
sugar
on
top
of
it
and
we
might
need
to
implement
that
sugar
to
have
a
party
implementation
with
the
standard
client.
D
Yep
I
think
it's
worth
doing.
It's
been
on
the
back
burner
of
my
list
to
do
to
provide
a
a
Java,
HTTP
client
based
implementation
forever.
You
know
obviously
I
haven't
gotten
around
to
doing
it
so
but
I
I
think
it's
worth
doing
and
eventually,
if,
if
somebody
has
the
capacity,
it
will
get
done.
D
Unfortunately,
we're
at
time
and
I
have
to
I
have
to
be
the
the
Trask
and
and
be
the
time
cop
and
so
Bruno.
Let's
talk
about
this
more
offline,
so
okay.