►
From YouTube: 2023-04-06 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
E
A
A
A
C
A
A
F
A
G
H
B
A
A
A
A
A
A
A
C
E
E
F
E
G
A
A
A
A
Yeah,
so
what
is
it?
The
hotel
Lambda
Sig
has
hosted
recently
in
slack
that
they
are
starting
to
incorporate
like
triage
jeans,
stack,
Overflow
questions
and
oh
I.
Remember
they
told
people
in
slack
that
to
not
ask
questions
in
slack
in
general,
I
mean
you
know,
questions
which
are
applicable
for
stack
Overflow
should
be
posted
there
in
order
to,
because
slack
is
just
like
a
black
hole
of
from
a
searchability
perspective.
So
you
can
answer
a
question
there
and
never
be
able
to
find
it
again.
A
G
C
A
A
So
I
was
curious.
There's
a
I
wanted
to
ask
folks.
I
was
kind
of
trying
to
under
hey
look
I
got
some
rap.
Is
that
what
that
means?
I,
don't
know.
I
gotta
understand
the
stack
Overflow,
workflow
and
I
was
trying
to
like
so
I
was
going
through
these
and
you
know
adding
some
answers,
but
then
I
wasn't
sure
how
to
track
like
which
ones
we
as
a
community,
have
triaged
or
tried
to
answer
some
of
them.
I
asked
follow-up
questions
on.
C
Not
more
familiar,
but
they
kind
of
like
used
to
serious
typological
questions
or
no
parametry
until
maybe
like
a
month
or
two
months
ago,
where
I
completely
forget
about
it,
and
there
I
mean
when
I
tried,
searching
for
open,
Telemetry
and
and
Java
they're,
usually
weren't
that
many
questions
anyway.
So
if
I
open
that,
like
once
a
week,
it
usually
was
enough
to
see
if
there's
anything
that
I
can
answer.
A
A
D
You
know
centralized
recommendations
for
the
open,
Telemetry
community
on
this
front
and
I
think
they're
leaning
towards
stack
Overflow,
they're,
Gathering
kind
of
input
from
maintainers
at
this
point,
but
I
think
the
idea
I
think
the
preference
for
stack
Overflow
comes
from
It
generally
appears
to
be
better
index
than
GitHub
discussions.
So
when
I
search
for
Stuff
stack,
Overflow
shows
up
and
GitHub
discussions,
rarely
do
and
I
I
guess.
Just
preference
like
it's
stack.
D
C
Yeah,
so
one
problem
that
I
just
came
up
with
with
struggle
and
flow
is
that
we
have
to
rely
on
the
users
to
properly
tag.
The
question
like
they
have
to
actually
add
open
Telemetry
and
it
would
be
like
nice
if
they
added
at
least
Java
or
spring,
or
something
that
like
suggests,
that
it's
a
Java
related
question.
A
C
C
E
A
B
D
Call
it
yeah
Let
me:
let
me
bring
that
up,
so
the
stabilization
of
the
logs
Bridge,
API
and
SDK
at
the
specification
is
right
around
the
corner.
Basically,
all
issues
have
been
resolved
at
this
point,
and
so
those
docs
are
going
to
become
stable
and
I.
Have
a
draft
Pro
up
in
open
Telemetry
Java,
which
kind
of
lays
the
groundwork
for
promoting
our
logs
API
and
SDK
artifacts
is
stable
and
you
know
I
think
it's.
D
It's
prompted
some
good
discussion
between
between
John
and
I
and
and
others
about
how
to
appropriately
provide
accessors
or
where
to
put
the
log
API
with
respect
to
the
other
API
components
and
how
to
provide
the
accessors
for
it
and
documentation
in
a
way
that
makes
it
very
clear
that
this
is
not
meant
for
end
users.
This
is
not
a
replacement
for
slf
for
J
or
Joule,
or
log
back
or
log4j.
D
So
there's
like
you,
know,
helper
functions
for
accessing
tracers
and
Tracer
Builders
and
Tracer
provider
and
same
with
meter
provider.
You
know,
in
contrast
with
with
the
logger
provider,
what
you'd
have
to
do
is
you'd
have
to
call
Global
open,
Telemetry,
you
know
get,
and
then
you
know
that
gives
you
access
to
an
open
Telemetry
instance
and
there's
a
new
method
that
I'm
proposing
adding
here
which
allows
you
to
access
the
logger
provider
or
no
op.
D
If
none
has
been
configured
and
what's
interesting
about
this,
is
that,
in
contrast
to
the
other
signals,
metrics
and
traces,
the
name
of
this
accessor
is
it's
a
bit
strange.
You
know
it
returns
a
logger
provider,
but
it's
not
called
get
logger
provider,
it's
called
get
logs
bridge
and
you
know
that
breaks
the
the
normal
pattern
of
getter
naming
specifically
to
make
it
abundantly
clear
that
this
is.
This
is
a
bridge
API.
This
is
something
that's
meant
to
be
used
by
appenders
and
not
by
end
users.
D
So
you
know
you
really
have
to
overlook
a
lot
in
order
to
access
this
thing
and
think
that
this
is
a
good
idea
for
you
to
use
in
your
application.
You
have
to
overlook
the
javadoc.
You
have
to
ignore
the
naming
you
have
to
ignore,
like
the
lack
of
symmetry
with
the
you
know,
this
API
and
the
other
apis
for
tracing
in
metrics
I
think
this
is
a
reasonable
compromise,
because
you
know
what
it
allows
us
to
do.
D
Is
you
know
it
allows
us
to
have
some
symmetry
between
logs
and
the
other
signals
like
there?
There
is
some.
You
know
surface
area
in
our
open
Telemetry
instance
that
where
you
know
you
can
access
all
three
signals
and
that
allows
us
to
you
know
not
have
to
introduce
a
separate
Global
open,
a
separate
Global
specifically
for
managing.
You
know
the
global
shared
logger
provider.
We'd
have
to
do
that.
D
If
we
didn't
do
this
and
you
know
yet
I
think
it
does
a
pretty
good
job
of
discouraging
use,
and
so
you
know
I'm
open
to
other
thoughts
on
this
I
guess.
Another
thing
I'll
say
is
that
I
think
documentation
is
going
to
be
really
important
with
the
log
signal
I'm
working
on
writing
some
documentation
right
now
for
open
telemetry.io
to
describe
our
log
story
in
Java
and
the
different
ways
that
you
can
use
this
with
and
without
the
the
Java
agent.
So
yeah,
that's
where
we
stand
on
this.
D
B
D
B
E
D
The
Dominoes
fall
that
that's
a
direction.
You
know
we
can
reopen
the
conversation
in
the
spec
I
I
personally,
I
I,
don't
agree
with
that
direction.
I
think
you
know,
there's
sufficient
between
documentation
and
some
naming.
We
can
sufficiently
dissuade
users
and
avoid
confusion,
but
that's
just
my
point
of
view.
So.
B
D
D
B
G
G
G
D
Like
a
user
may
actually
have
to
access
this
and
like
let's
say
they're
using
the
auto
configure
module
and
they
you
know
they
use
that
to
configure
their
SDK
and
then
they
want
to
programmatically
access
their
log
back
or
log4j
configuration
and
add
an
appender
in
the
code.
Then
they
have
to
like
access
this
open
Telemetry
instance
and
get
an
instance
to
their
logger
provider
and
plug
it
into
their
appender.
And
so
it's
not
like
the
user
is
not.
This
whole
thing
is
hidden
from
a
user.
D
C
I
think
we
do
like
in
most
or
all
normal,
like
normal
instrumentations
I,
think
we
always
Pass
open
Telemetry
to
the
public,
API,
so
I
think
it's
a
great
idea
to
change
the
appenders
so
that
they
follow
that
pattern
too.
I
was
like
either
way,
I
think,
like
the
the
good
dogs.
Bridge
method
is
that's
it's
a
good
name
to
me.
At
least
it
conveys
the
like
that
it
is
a
bridge.
It's
not
meant
to
be
used
directly.
A
D
A
G
I
have
one
small
additional
thought
that
might
be
terrible,
but
since
we're
kind
of
hacking
around
with
naming
and
stuff,
if
the
logger
provider
name
is
required
by
spec,
which
it
is,
would
it
be
improper
to
subclass
that
interface
with
a
one
called
logger,
Bridge
or
logging
Bridge?
Is
that
does
that
violate
the
spirit
of
the
spec?
There.
G
G
D
But
if
we
do
like
it
would
be
extremely
confusing
if
there
was
a
logs,
Bridge
API
and
a
log
API
like
and
so
you'd
want
to
naturally
evolve
this
logs
Bridge
API
into
your
user-facing
log
API,
and
so
you
know,
including
the
the
names
Bridge
or
Pender
in
the
interfaces,
works
against
you
there.
All
of
a
sudden,
a
user
is
going
to
be
using
like
a
logs
Bridge
or
a
log
append
or
API
component.
But
you
know,
subclassing
logger
provider
does
not
get
in
the
way
of
that.
D
G
A
A
D
D
You
know
these
conversations
have
been
circular
and
exhausting,
as
is
so
that
that's
one
thought
so
I
don't
necessarily
have
an
appetite
to
go
back
to
the
drawing
board
there.
Maybe
somebody
else
does
another
thought
that
I've
had
just
in
the
back
of
my
head.
Is
that
our
apis
in
several
places
you
know
they
require?
They
require
a
lot
of
understanding
about
how
things
work.
They
were
putting
a
foot
gun
in
the
hand
of
our
users.
You
can
mess
up
tracing
pretty
easily.
D
If
you
don't
do
things
right,
it's
pretty
tricky
to
get
right.
That's
why
we
have
this
like
this
higher
order.
Api
the
instrumentation
API
metrics
are
the
same
way.
You
need
to
very
carefully
choose
your
instrument
and
be
aware
of
how
those
instruments
aggregate
by
default,
and
you
need
to
be
aware
of
of
cardinality
and
how
that
impacts.
Like
your
data
footprint,
that's
being
exported,
and
so
like
not
not
being
aware
of
those
things
can
get
you
into
trouble
pretty
fast
in
the
log
space.
D
The
thing
they
can
get
you
into
trouble
and
I
think
it's
comparatively
less
trouble.
But
the
thing
that
can
get
you
into
trouble
is
misinterpreting
this
logs
Bridge
API
as
something
that
you
should
use
and
replace
in
place
of
slf
for
J
or
Joule,
and
so
there's
always
something
that
can
get
you
into
trouble,
but
I
think
the
consequences
of
getting
it
wrong
and
logs
are
relatively
small
compared
to
the
other
signals.
A
D
No
I
think
so,
there's
a
chance,
there's
not
an
event
API,
but
if
there
wasn't
an
event,
API
I
think
the
most
likely
thing
would
be
that
we
advocate
for
using
existing
log
apis
and
provide
documentation
on
how
you
can
emit
like
blog
records,
that
are
shaped
like
events
using
existing
apis,
and
so
what
that
would
mean
in
practice
for
us
is
saying:
hey.
We
recommend
using
slf
for
J2
as
your
event.
Api
here
is
how
to
admit
an
event.
You
know
using
the
semantic
inventions
that
you
know.
G
G
D
A
D
D
Api
and
I
wanted
to
include
more
details
in
the
specification
on
when
it's
actually
appropriate
to
use
the
event
API
and
use
cases
for
events,
and
the
reason
was
was
because
that
there
was
continued
calls
on
like
you
know
what
are
the
actual
use
cases
for
this?
Should
we
have
this
thing
and
so
I
thought
you
know
in
order
to
cement
its
position.
D
Collecting
the
set
of
use
cases
would
be
helpful
for
that
and
I've
tried
to
lay
out
some
here,
but
if
you
have
additional
use
cases,
I
would
encourage
you
to
include
them
on
this
issue
and
I'll
link
to
this
and
some
other
ones.
That
kind
of
indirectly
talk
about
whether
the
event
API
should
exist.
You
know
in
the
notes.
A
E
A
A
C
A
H
C
H
C
H
G
A
G
A
A
A
C
A
A
E
C
Not
even
sure
like
what
would
this
show
here,
because
the
code
is
not
it's
not
like.
There's
like
a
single
place
that
clearly
shows
what
it's
about
so
maybe
I'll
just
I'll
talk
about
it
a
little
bit
so
I've
implemented
two
like
pocs,
probably
at
this
stage
of
the
HTTP
recent
spec
for
okay,
HTTP
and
for
reactor
net
e-reactor
net
is
kind
of
a
little
bit,
not
finished
because
for
Navy
and
react
to
nappy.
C
There
can
be
like
application,
recents
or
several
errors.
I,
don't
think
we
have
tests
for
those
anyway
and
yeah.
I
chose
these
two
because
they
both
both
of
these
Frameworks,
allow
us
to
like
get
kind
of
deep
into
their
internals.
So
we
can
capture
the
actual
HTTP
send
attempt,
unlike,
for
example,
the
jdk
HTTP
client,
which
I
think
trasky
posted
the
JD
jdk
should
be
client
as
one
of
the
kind
of
regulated
instrumentations
that
we
should
prepare
for
the
upcoming
HTTP
conventions.
But
there's
like
nothing
to
be
done
there.
C
C
C
I
think
at
this
spec
level
there
is
this
clarification
VR
that
I
opened
a
month
ago,
but
with
regards
to
spec,
it's
like
right
now,
it's
perhaps
a
bit
unclear
when,
in
what
situations,
the
recent
counter
should
be
used
and
maybe
like
how
even
we
should
Implement
and
HTTP
client
instrumentation.
So
I
submitted
a
PR
with
clarification
that
there
basically
are.
B
C
Two
ways
of
estimated
HTTP
clients,
the
HTTP
classes
that
allow
us
to
like
Venture
deeply
into
their
like
internals.
We
can
capture
every
single,
actual
physical,
scent
attempt,
and
in
this
case
we
can
track
the
number
of
reasons,
but
for
some
HTTP
clients,
like
the
jdk,
is
decline
that
I
mentioned
the
API
of
the
librarian
just
doesn't
allow
pretty
much
anything,
and
the
only
thing
that
we
can
do
is
like
create
the
the
end
span
for
the
topmost
operation,
so
yeah.
C
So
these
two
PRS
implement
the
like
the
implementation,
the
instrumentation
idea
number
one,
which
is
like
a
low
level
instrumentation
that
captures
as
much
details
about
about
what's
happening
inside
the
Library
as
it
is
possible
and
yeah.
So
one
like
interesting
thing
is
that
our
current
version
of
the
ACP
client
tests
are
totally
not
compatible
with
respect.
They
all
expect,
like
a
single
client
span
for
all
retries,
so
well
that
yeah
I
wanted
to
show
like
the
the
test,
because
they
kind
of
reflect
what
it
will
be
once
we
merge
it.
C
There's
the
second
example
with
student
redirects
and
there's
a
third
one
with
I
think
like
the
circle,
Arrow,
Direct
and
I
want
to
oh
yeah.
There
is
also
like
somewhat
badly
implemented
again,
something
that
is
supposed
to
look
like
an
authentication.
Api
authenticated,
endpoints
and
I
will
probably
like
if
we
decide
to
merge
this
and
I'll,
probably
just
remove
that
and
create
a
separate
issue
to
implement.
Like
a
actual
basic
of
scenario
in
our
tests
for
HTTP
clients,.
C
I
think
it
was
the
clarification
that
we
like
for
the
oh
yeah,
there's
also
the
matter
of
the
connection
errors.
So
the
one
of
the
problems
with
our
current
spec
was
that,
if
you're
supposed
to
create
a
spam
for
every
like
physical
set
attempt,
then
what
happens
if
the
connection
is
not
established
in
the
first
place.
So
if
you,
you
don't
even
arrive
in
the
sand
phase,
and
this
was
one
of
the
things
that
the
clarifications
like
PR
is
supposed
to
clarify.
B
C
C
So
the
spec
PR
and
tries
to
propose
a
way
to
handle
that
and
that,
if
there's
something
that
fails
just
creates
a
kind
of
like
a
mortgage
PPP
span
or
something
that
resembles
an
HTTP
span.
And
this
is
like
the
whole
implementation
of
that,
where,
if
there
weren't
any
sent
attempts.
So
if
the
ACB
client
failed
before,
like
anything,
was
sent
over
the
wire,
actually
then
we
created
just
contains
the
favor,
because
that's
probably
a
very
useful
piece
of
information
for
the
users
of
the
instrumentation
yeah,
see
ya
so
yeah.
E
C
C
It
works
in
a
way
that
if
this
is
disabled,
it
still
emits
like
a
connect
spam
if
a
connection
fails
or
like
a
social
handshake
span,
FPS
or
handshake
files,
and
instead
we'll
want
to
create
this
kind
of
like
a
mock
HTTP
span
instead
of
this
so
yeah.
This
is
like
a
half
of
like
entire
solution,
but
it's
like
full
implementation
of
the
actual
recent
spec.