►
From YouTube: 2023-01-11 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
Andrew,
you
may
want
to
mute
your
microphone.
Oh
sorry,
not
that,
although
I
don't
think
well,
I,
don't
understand
the
language,
but
still.
D
B
Okay,
let's
start
so
I
created
this
new
issue,
questions
based
on
the
discussion
that
we
had
on
already
closed
pull
request
and
based
on
the
pull
request
that
is
open
in
Java
repository,
the
one
that
you
created
Jack,
so
I.
Don't
think
this
is
a
surprising
proposal
there,
but
I'd
like
to
have
people's
opinion
on
this,
and
whether
this
is
the
direction
we
want
to
move
team
I
posted
a
link
to
the
zoom
chat.
B
I
see
you
replied,
check,
I,
see
your
reply,
so
I
think
essentially
you're
confirming
that
this
is
the
desirable
approach
from
a
list
from
Java's
perspective
and
and
the
answer
to
the
ultimate
question
that
I
had
also
about
whether
the
logging
API
is
necessary.
Is
yes,
it's
necessary
for
the
reasons
you
listed
I
don't
know
if
you
want
to
add
anything
there.
E
Just
that
in
the
JavaScript
we've
talked
about
this
quite
a
bit
and
the
other
maintainers,
Trask
and
and
John
and
mitesh
are,
are
pretty
aligned
pretty
strongly
aligned.
With
this
point
of
view,.
B
Yeah,
so
I
am
personally
also
more
and
more
convinced
that
this
is
the
desirable
approach,
and
this
also
decouples
the
events
API
sufficiently
such
that
we
can
work
on
it
independently.
I
mean
if
I
delete
it
from
this
picture.
Everything
is
still
fine
right
and
it
can
be
an
additive
change
later
and
even
if
we
stabilize
the
log
API
log
SDK,
that's
all
fine
event.
Api
can
be
added
later,
so
I
think
it's
it
matches
what
we
discussed
earlier,
but
anyway
I'd
like
more
maybe
more
feedback
from
others.
What
do
you
guys
think.
F
Yeah,
the
only
slight
modification,
if
you
go
to,
if
you
look
at
your
picture
at
the
top,
is
if
we
change
the
event
API
to
use
the
login
API,
rather
than
logging
SDK
directly,
just
to
decouple
any
event
implementation
so
that
your
applications
can
can
consume
the
event
API
without
taking
dependencies
on
the
logging
SDK.
B
F
Like
it
depends
how
to
implement
it
at
the
end
of
the
day,
but
there
could
be
bad
coupling
created
by
having
the
event
API
linked
directly
to
the
logging
SDK.
F
If
someone
wants
to
just
use
the
event
API
from
version
one,
someone
wants
to
use
it
from
version
10
it.
It
just
gets
a
little
bit
painful.
The.
E
Science
API
doesn't
take
a
dependency
on
the
log
SDK.
The
event
API
is
implemented
by
the
log
SDK.
So
if
you
just
take
a
dependency
on
the
event
API,
it's
a
no
op
until
you
plug
in
an
implementation.
Yeah.
B
B
So,
if
you
don't
have
you,
you
don't
take
a
direct
dependency
on
log
SDK
log
SDK
is
pluggable
at
by
the
end
user,
essentially
like
it
is
for
everything
else
all
the
sdks
like
they
are
today.
F
G
E
E
I
think
this
picture
accurately
represents
how
my
how
I
would
like
to
see
things
end
up.
E
E
Yeah
so
I
think
I
think
both
are
I,
think
both
are
viable.
What
you
just
described,
Anthony
is
what
is
essentially
the
case
today.
E
So
the
event
API
specification
says
you
know,
does
exactly
what
you
said
it's
described
in
terms
of
the
log
API,
so
you
plug
in
a
logger
to
create
an
instance
of
an
event.
Emitter-
and
you
know
you
have
the
event.
Emitter
just
calls
the
the
logger
and
its
apis
to
produce
log
records
to
the
SDK,
the
Java
folks.
E
The
Java
folks
feel
that
this
alternative,
that's
pictured
here,
where
a
log
SDK
implements
two
distinct
apis
would
be
preferable
and
one
of
the
there's
a
couple
of
reasons
that
they
talk
about.
But
one
of
them
is
that,
by
having
a
separate
event,
API
like
an
event,
emitter
provider
and
a
event,
emitter
interfaces,
you
could
you
can
provide
a
separate
implementation
for
those
that
isn't
just
a
separate
implementation
of
the
logger
provider.
B
F
Version
so,
if
someone's
gone
and
created
their
own
logging
SDK,
they
could
in
theory,
grab
the
open,
Telemetry
emit
event
emitter
portion
and
then
run
on
top
of
their
own
logging
at
SDK.
If
it
was
using
the
log
API
as
opposed
to
saying.
Okay
I've
got
the
log
of
the
event
emitter,
but
that's
always
going
to
use
my
the
open
Telemetry
version,
not
their
own
version.
That
makes
sense.
E
I
think
so,
one
of
the
other
reasons
that
I
think
the
the
JavaScript
prefers
having
a
separate
event,
emitter
Provider
from
a
logger
provider,
is
that
you
know
the
the
scenario
you
talked
about
Anthony,
where
the
event
emitter,
you
know,
takes
a
dependency
on
the
log
API,
which
is
the
current
case
today
in
the
specification
that
requires
users
to
use
the
log
API.
E
So
one
of
our
Express
goals
is
to
is
that
the
logger
API
is
not
user
facing,
so
it's
just
meant
for
penders
and
by
building
the
event
API
directly
on
top
of
the
log
API
users
have
to
be
aware
that
the
logger
that
a
log
API
exists.
G
Yeah,
but
is
isn't
that
the
case
with
users
who
want
to
configure
an
appender
like
a
log
for
jpender,
but
that
thing
is
still
using
the
logs
API
I
would
view
the
event
API
as
equivalent
to
an
appender.
That's
using
the
API.
It's
it's
something!
That's
using
that
API
as
a
mechanism
for
communicating
information
Downstream
without
knowing
about
the
implementation.
E
B
F
Yeah
like
it
can,
yes.
E
So
I,
essentially
so
if
it
goes
left
to
the
log
API,
that's
what
we
have
today.
So
there's
not
a
lot
of
work
needed.
We
would
just
need
to
essentially
confirm
that
what
we
have
today
is
what
we
want
I
proposed,
making
that
change
that
would,
you
know,
make
make
that
so
in
the
Java
implementation,
where
the
event
API
takes
the
dependency
on
the
log
API
and
essentially
got
a
bunch
of
thumbs
down
like
no.
This
isn't
what
we
want
to
do,
and
so
you
know
if
the.
E
If
the
specification
like
in
the
log
Sig
like
affirms
that
direction,
I
think
you
know
the
the
javasig
would
would
ultimately
that
they
comply.
But
you
know
I
think
one
of
the
sticking
points
is
that
is
end
users
that
want
to
use
the
event
API
having
to
be
aware
of
the
logger
API.
In
order
to
do
so.
So
that's
folks
are
uncomfortable
with
that.
Yeah.
B
F
E
F
B
F
E
So
the
way
that
I
would
describe
it
is
that
you
know
we've
been:
we've
had
reservations
about
introducing
a
logger,
a
log
API
at
all,
because
we
don't
want
to
duplicate
the
functionality
of
existing
log,
apis
and
Frameworks.
We
don't
want
to
reinvent
the
wheel,
and
so
you
know
we
kind
of
capitulated
and
we're
introducing
the
log
API,
because
it's
useful
to
write
appenders
but
appenders
are
a
pretty
narrow
situation.
E
There's
not
many
appenders
that
are
going
to
be
written,
there's,
probably
a
couple
handfuls
per
language
ecosystem,
and
so
you
know,
if
you're
writing
in
a
Pandora.
You
have
to
be
aware
of
the
log
API,
but
otherwise
we
can.
We
can
have
documentation
that
says
hey
this
log
API
isn't
meant
for
end
user
consumption.
It's
not
meant
to
replace
your
existing
log
framework
like
log
project
or
log
back
or
slf
or
J
in
the
Java
ecosystem
and
so
yeah.
E
We
can
make
those
types
of
statements
as
soon
as
the
event
API
depends
on
the
log
API.
Then
you
know
we're
kind
of
saying
two
things
at
once.
You
know
you're
not
supposed
to
use
the
log
apis
and
end
user,
but
you
have
to
be
aware
of
its
existence
and
plug
it
into
your
event,
API.
In
order
to
use
that.
G
But
wouldn't
you
need
to
be
aware
of
its
existence
and
plug
it
into
your
appender
as
well?
I
think
if
I
could
restate,
you
know,
appenders
are
using
the
log
API
or
the
log
API
is
intended
for
use
by
appenders.
I
would
restate
that
as
a
log
API
is
intended
for
use
as
a
mechanism
for
constructing
an
otlp
representation
of
logs
that
can
be
emitted
by
the
SDK,
in
which
case
I
think
the
events
API
Builds
on
top
of
that
cleanly,
because
it's
syntactic
sugar
over
constructing
of
representations
of
events
as
otlp
logs.
E
G
B
Don't
think
you
can
you
have
to
supply
the
instrumentation
name
and
version
when
you're
creating
a
logger
and
for
the
events
API
when
you're
meeting
events
you
want
to
be
in
control
right
of
what
instrumentation
name
and
version
you
want
to
use
for
your
events,
so
you
have
to
somehow
interact
with
the
logger
in
that
case,
for
the
for
the
bridges
for
the
offenders.
That's
not
the
case.
You
don't
care
about
that,
so
that
can
be
hidden
from
the
end
user.
B
It's
probably
a
small
numerals
I
understand,
but
I'm
I'm
with
with
Jack
here
right
I
think
we
should
try
to
discourage
as
much
as
possible
the
usage
of
the
interaction
of
the
end
user
and
with
the
logic
API.
So
even
in
the
documentation.
Let's
say
you
have
a
documentation
which
is
for
the
end
users.
B
There
will
be
nothing
about
the
logging
API.
There
will
be
a
section
about
the
bridges
about
the
vendors,
about
the
events,
API,
nothing
about
the
loggers
and
and
if
we
make
the
events
API
dependent
on
the
log
API,
you
can't
do
that
anymore
right.
You
have
to
have
some
sort
of
documentation
which
explains
the
end
user,
how
they
obtain
the
logger
using
the
logger
provider,
how
they
they
create
the
event
emitter
using
the
logger,
and
only
after
that
they
can
use
the
events
API.
G
Or
the
the
thing
that
constructs
the
event
emitter
can
be
a
pass-through
to
obtaining
a
log
emitter
as
well
right
if
the
information
that
needs
to
be
provided
to
create
a
log
emitter
is
this
rotation
Library
name
inversion,
and
that
is
an
input
into
the
event
API
to
create
an
event
emitter
that
becomes
passed
through
through
the
log
API.
You
get
a
logger
using
that
information.
E
E
You
know
the
scope
name
and
the
scope
version
those
types
of
things,
but
you
know
ultimately
you
need
to
have
you
need
to
have
a
logger
provider
that
you're
going
to
interact
with
that
you're
going
to
delegate
to
from
the
you
know,
event
emitter
provider,
which
is
going
to
create
event
emitter
instances,
and
so
you
know,
don't
you
have
to
pass
that
logger
provider
to
your
event,
emitter
provider
as
like
as
an
argument.
So
you
have
something
to
delegate
to.
G
Yes,
unless
there's
a
global
that
can
be
used,
but
I
don't
see
how
that's
any
different.
If
the
event
emitter
comes
out
of
the
SDK
you're,
just
then
providing
a
separate
set
of
configuration
to
the
SDK
to
do
the
exact
same
thing
like.
Are
you
providing
a
logger,
a
a
logger
provider,
or
are
you
providing
the
configuration
that's
used
to
construct
a
logger
provider.
E
So
if
you're
instrumenting,
if
you're
instrumenting
an
application
or
if
you're,
instrumenting
some
library-
and
you
want
to
start
emitting
events
from
this
library
and
this
library
is
an
independer-
you
have
to
take
a
dependency.
E
B
Event,
emitter
provider
either
this
or
you
obtain
a
specific
one,
and
then
from
that
you're
paying
the
the
emitter
Builder
the
emitter
and
then
you
meet
events
right.
That's
that's
exactly
what
you
do
for
traces
for
metrics
right,
so
that
would
be
very,
very
consistent
with
what
we
do
with
other
signals,
and
we
want
that
experience
to
be
like
that
right.
E
Yeah
I'm
just
trying
to
think
about
if
there's
any
practical
way
to
provide
that
event,
emitter
provider
or
the
API
and
the
event
emitter
API,
you
know
and
have
those
apis
delegate
to
the
log,
the
logger
apis
under
the
covers
such
that
the
user
is
never
aware,
and
the
user
never
has
to.
You
know.
B
G
B
Yeah
I
guess
we
probably
need
to
see
the
code
to
understand
this
better.
Would
someone
be
interested
in
maybe
showing
a
sketch
of
what
it
would
look
like
just
just
the
usage
right?
We
don't
need
an
implementation
of
that
particular
alternate
where,
where
essentially
the
the
dependency
goes
left
here
instead
of
partly,
does
anybody
have
an
appetite
for
trying
to
do
that.
E
E
So
if,
if
somebody
you
know,
can
you
know
write
this
in
in
Java,
preferably
where
the
a
lot
of
the
prototyping
work
has
been
done
and
has
a
really
clear
idea
on
how
that
would
work,
I'm
open
to
it?
If
not
I,
you
know
I'll
have
to
struggle
through
this
and
try
to
see
what
I
can
come
up
with
that
may
not
align
with
what
you're
thinking.
G
I,
don't
know
that
I
can
write
Java,
it's
been
probably
a
decade
since
I've
written
any
Java
I.
G
Jack,
can
you
point
me
at
some
log
of
Pender
implementations
or
things
that
use
the
blog
API
currently
in
in
Java
yeah
I
can
can.
B
We
do
this
track.
You
can
show
what
it
looks
like
with
your
proposal.
What
the
calls
look
like,
like
those
10
lines
of
code,
that
the
user
needs
to
execute
before
they
start
emitting
the
events,
assuming
that
we
go
forward
with
your
proposal
and
then
we
we
show
next
to
it.
The
alternate
that
that
Anthony
proposes,
which
then,
which
which
uses
the
other
approach
right
without
the
logger
being
exposed
directly.
B
E
That
sounds
like
a
good
idea
and
I
can
comment
that
directly
just
on
this
issue
because,
like
you
said
it
doesn't
have
to
compile
as
long.
A
A
So
hello,
everybody
just
a
a
question
and
I
apologize
in
advance
for
the
potentially
uninformed
question,
but
so
and
for
so
for
Green
Field
applications
right.
You
have
Greenfield
Java
applications,
let's
say
for
example,
spring
boot.
Java
applications
for
Greenfield
for
applications
that
are
being
newly
written.
Would
the
recommendation
be
to
directly
interact
with
the
event
API
or
to
use
the
existing
Avenue
on
the
left,
with
like
say,
slf
for
J
log
for
J2
and
then
a
Json
layout
to
to
create
open,
Telemetry
compliant
Json.
B
A
Well,
thanks
for
that
I
mean
because
we
also
have
the
issue
where
we
have,
like
everybody
else,
I'm
sure
have
gabs
and
gads
of
code
that
that
are
using
the
implementation
on
the
far
left
right
and
we're
gonna
we're
gonna
be
forced
to
provide
guidance
to
say:
okay,
if
you're
already
doing
that,
you
know
how
do
you
generate
open,
Telemetry,
compliant
log
data
if
you're
starting
from
scratch,
maybe
use
a
different
approach.
So
that's
really
the
background
for
my
question.
So
thank.
B
You
yeah
yeah
I,
think
so
the
reason
this
thing
exists,
the
event
API
is
because
the
the
client-side
instrumentation
wardrobe
felt
that
the
API
that
is
available
through
the
existing
logging
libraries
is
not
sufficient,
not
expressive
enough
to
to
to
represent
the
data
that
they
want
to
represent
in
the
events
that
they
want
to
make.
A
I
And
to
augment
that
just
a
slight
bit
with
your
spring
boot
example,
you
know
there's
also
a
really
good
chance
that
the
spring
boot
framework
is
also
a
login.
So
there's
a
good
chance
that
you
care
more
about
integrating
with
spring
boots
logging
framework
than
you
do
with
open
Telemetry.
So
logging
is
pretty
easy
that
way
that
you
know
generally,
the
login
libraries
are
what
we
should
use,
but
the
event
event
stuff
is
new
and
that's
a
little
bit
different.
H
Yeah
I
added
it.
This
is
appear
from
Nev
it
it
is,
it
is
closed,
so
can
somebody
you
know
reopen
it
I
I,
you
know
we
cannot
open
it,
and
this
I
put
it
here
just
to
get
some
attention
and
comments
into
it.
The
guy
I
don't
see
much
happening
there.
This
is
based
I
mean
this
applies
once
the
nested
attributes.
Pr
goes
through,
because
this
event.data
is
an
attribute
which
will
be
a
of
type
map.
F
Topic,
this
also
triggered
the
discussion
around
Cloud
events
as
well,
so
like
right
now
as
part
of
the
Proto
nested
attributes
are
nested
attributes
where,
with
Cloud
event
data,
it
can
actually
be
in
any
a
crew
any
not
on
any
as
defined
by
prior
buff.
So
that
would
be
a
potential
extension
that
this
could
lead
to.
If
we
want
to
go
down
to
the
cloud
event
path.
F
But
generally
you
know
this
PR
is
just
saying:
event.data
is
a
nested
map
of
attributes,
while
not
ideal
in
the
Json
representation
that
will
work
for
our
needs.
B
C
Yeah
everyone
I
realize
I,
haven't
been
amazingly
active
here,
the
last
several
months,
but
we
have
a
new
member
of
my
relatively
new
member
of
my
team
Andre
who's
working
on
how
Splunk
observability
customers
get
data
in
which
uses
open,
Telemetry,
so
he's
a
product
manager
for
all
of
our
language,
libraries
in
open
Telemetry,
and
rather
all
of
our
contributions
to
Splunk
to
the
hotel
language,
libraries
and
he's
also
internally
picking
up
some
responsibility
for
log
collection,
and
so
Andre
is
going
to
be
joining
these
meetings
and
participating
and
contributing
to
otel's
logging
efforts
and
I
just
wanted
to
introduce
them
to
everybody.
D
Hey
guys
nice
to
nice
to
meet
you
all
thanks,
Morgan
for
for
that.
Yeah
I've
been
with
Splunk
for
a
couple
of
months
now,
like
quite
almost
six
and
well
before
being
a
product
manager.
I
I
kind
of
like
spend
most
of
my
career
as
a
software
engineer,
and
software
architect,
like
building
all
types
of
different
systems
from
from
from
a
kind
of
large
kind
of
on-premise,
Enterprise
Solutions
through
distributed
systems
and
eventually
ending
up
in
the
cloud
space
right
which
actually
meets
meets.
D
The
the
observability
needs
quite
well
and,
like
Morgan,
said,
I
will
be
kind
of
making
sure
that
we
we
keep
our
contributions
to
the
open
Telemetry
and
we
expand
on
this
as
possible,
and
then
we
also
use
the
open
television
across
the
different
products
in
Splunk
right.
D
One
of
them
would
be
the
specifically
the
logs
collection
and
making
sure
that
we
we
can
use
our
kind
of
the
logging
capabilities
of
the
open
Telemetry
in
in
various
ways
in
Splunk
right
so
nice
to
meet
you
all
and
yeah
I
I
hope
to
work
with
you
a
little
bit
more
going
forward.