►
From YouTube: 2022-06-02 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
Metrics
event
versus
log
api.
A
Yeah
I'll
just
bring
that
forward
so
yeah
it
just
it
occurred
to
me.
I
think,
like
last
week
that
this
contrib
thing
that
scrapes
jam
x
has
some
names
that
differ
from
this.
The
spec
that
got
approved-
and
I
just
I
was
thinking.
Maybe
we
would
chat
about
what
we
think
we
ought
to
do
about
it.
If
anything.
C
A
In
fact,
he
was
that
was
kind
of
what
drove
some
of
these
spec
changes.
Okay,
yeah
and
that
that
issue
that
I
linked
to
is
a
carlos
instigated
one.
But
maybe
I
didn't
see
any
aprs
and
contribute
about
it,
but.
A
Yeah
so
which
were
there
specific
ones
that
you
noticed,
I
think
I
didn't
take
the
time
to
call
them
out,
but
yeah
I
mean
we've
only
got
a
few
things
merged.
So
I
don't
remember
because
it's
early
and
it's
not
fresh
in
my
brain
yeah,
so
I'm
not
really
sure,
but
the
idea
is
to
change
him
in
the
scraper.
A
Okay,
yeah-
and
I
should
ping
folks
on
these,
because
these
have
been
out
for
a
month
now.
A
A
A
On
the
event
versus
log
api
jack,
I
was
just
kind
of
curious.
I
had
seen
there
was
tigran
posted
that
there
was
in
the
big
discussion.
I
don't
know,
were
you
at
a
log
sick.
C
Yeah
and
let
me
grab
a
do,
you
want
to.
C
Okay,
so
the
the
the
conversation
was
focused
around
the
relative
strengths
and
weaknesses
of
the
the
two
approaches
that
have
been
discussed
for
an
an
api,
and
those
two
approaches
just
to
recap
are
whether
there
are
separate
api
entrance
entry
points
for
events
and
for
you
know
the
log
appender
use
case
or
whether
we
have
a
single,
a
single
api
that
performs
both
of
those
use
cases.
C
And
you
know
I,
there
there's
kind
of
been
a
bit
of
a
split
in
terms
of
who
supports,
which
I
think
you
know.
Last
last
time
we
spoke
in
this
group
and
then
later
in
office
hours.
C
I
think
the
java
group
was
kind
of
forming
a
little
bit
of
a
consensus
around
having
two
different
apis,
one
for
events
and
one
for
logs,
but
you
know,
and
some
other
folks
outside
of
java
share
that
opinion,
but
tigran
and
and
others
have
made
some
what
I
think
are
strong
arguments
for
having
a
single
api
and
yeah
there's.
There's,
there's
no
kind
of
fatal
flaw
in
either
approach.
C
That
would
make
the
other
the
obvious
choice
and
so
we're
trying
to
figure
out
what
exactly
to
do,
and
so
what
tigran's
done
in
this
document,
that
is,
you
know
this
is:
where
does
this
come
from?
Where
did
he
link
this.
C
There's
this
events,
api
otap,
and
there
is
a
kind
of
long
conversation
here.
You
know
where
I
initially
posted
a
couple
of
prototypes
outlining
these
two
different
approaches,
and
you
know
the
last
comment
here:
tigran
posts
this
this
document,
that
kind
of
summarizes
the
arguments
and
so
yeah.
A
C
Yeah,
that's
that's
the
point
that
resonates
with
me
the
most
consistency
across
the
other
signals
with
the
api
design.
The
the
thing
that
I
think
is
most
contentious
about
having
a
single
api
versus
the
split
approach.
Is
that
the
naming
of
things
it
feels
strange
to
have
a
logger
that
you
use
to
create
and
emit
events?
A
As
there
did,
tigran
propose
any
way
or
mechanism
for
handling
kind
of
domain
specific,
because
that
seems
to
be
the.
The
main
point
is
that
if
you're
emitting
logs,
it
should
be
log
data
and
not
anything
else,
but
I
mean
we
know
that
it's
going
to
contain
other
stuff.
A
Even
if
that
other
stuff
is
events
is
there
has
he
talked
about
or
addressed
any
way
of
allowing
events
to
exist
outside
of
the
logging
domain?
Then.
A
So,
if,
like
I'm
reading,
the
line,
that's
like
less
specific
api
for
events
does
not
help
prevent
this
more
consistent
with
data
model
ideology.
Right,
like
you,
have
a
logger
and
what
you
emit
is
a
log
record
and
not
an
event,
although
it
is
an
event
right
in
the
case
of
events,
it
would
be
an
event.
It's
just
still
masked
within
a
log
record.
C
Right,
yeah
yeah,
sorry
to
continue.
A
That's
all
right,
it's
still
early
in
portland,
so
is
I
mean
I
guess
is-
is
the
single
api,
then
just
it's
good
enough
like
there
doesn't
need
to
be
anything
that
makes
or
strengthens
the
domain
specific
data
model
within
logs.
It's
like
the
one
api
is
good
enough.
C
Well,
so
going
with
two
separate
apis
is
is
confusing
in
some
ways,
because
it
suggests
that
the
two
things
are
separate,
but
then
they
get
joined
at
the
data
model
level.
I
hear
that
and-
and
so
that's
like
an
argument
in
favor
of
of
having
a
single
api,
but
on
the
other
side
having
a
single
api
is
confusing
in
its
own
way,
because
we
have
made
this
distinction
between
events
and
logs.
You
know
they're
both
log
records,
but
an
event
has
a
name
and
a
domain
and
a
log
has
a
mandatory
severity
field.
C
So
there
there
is
a
distinction,
even
though
they
use
the
same
data
model
to
represent
them,
and
you
know
it's
confusing
in
in
a
different
way
to
have.
You
know
the
same
api
used
to
create
and
emit
those
those
different
things
so
one
way
or
another,
I
feel
like
you're
gonna
you're
gonna
find
that
some
people
are
confused.
C
A
It's
pros
and
cons
is
that
distinction
between
logs
and
events
in
the
spec
somewhere.
C
So
it's
not
in
the
spec
yet,
but
we
are
going
to
codify
it
in
as
a
part
of
this
otep
and
and
in
this
and
in
the
spec.
So
I
think
that
the
place
that
we're
leaning
is
that
that,
like
I
said,
logs,
have
a
mandatory
severity
field
or
traditional
application
logs
and
then
events
would
have
a
mandatory
like
a
must
on
on
a
name
attribute.
A
So
event
is
going
to
be
an
official
official
data
type.
It's
just
going
to
be
transmitted
via
the
log
signal.
C
A
C
Are
log
records
always
so,
and
so
I
don't.
A
Almost
seems
like
the
signal
should
be
called
blob,
transmitter
or
some
like
blob
format
and
then
like
both
logs
and
events
can
sit.
On
top
of
that,
happily,
like
I
wish
there
was
a
better
name
for
that
underlying
thing.
Then
it's
just
it
happens
to
be
logs
because
that's
what
everyone's
familiar
with
and
we
need
a
parent
class
yeah
yeah,
I
mean
that's
kind
of
what
we're
talking
about
yeah
all
right.
Well,
that's
not
gonna
change,
I'm
not
dying
on
that.
C
A
Is
there
any
thought?
Was
there
any
discussion
about
allowing
this
to
be
a
language
specific
decision.
C
I
think
what
there
was
a
discussion
yesterday
about
that
specific
topic.
What
has
been
discussed
in
the
past,
just
to
reiterate,
is
that
if
there
there's
a
desire
to
allow
languages
where
it's
appropriate
and
where
they
have
the
desire
to
do
so
to
have
a
a
log
api,
that's
used
for
more
than
just
appending
from
in
bridging
from
existing
logging
frameworks.
C
A
But
not
no,
not
when
this
decision,
the
goal
is
for
this
decision
about
whether
to
have
a
single
api
or
two
apis
that
the
goal
there
is
for
that
to
apply
to
all
languages.
That
decision,
I
would
assume.
C
So
because
it
hasn't
been
like
stated
that
that
would
be
a
language
specific
thing,
so
I
think
that's
a
safe
assumption.
A
All
right
it
just
it
seems
to
me
like
if
we
go
with
the
one
api
approach
that
everyone
using
that
is
going
to
just
build
their
own
api
right.
Why
is
that?
Well,
if
I'm
a
user
of
that
and
I'm
doing
a
bunch
of
event,
eventing
and
those
things
are
required
by
the
like
those
those
fields,
the
event
domain.
A
If
that's
required,
then,
on
all
of
these
logs,
I'm
going
to
put
an
api
in
front
of
that.
That
will
force
that
to
happen.
C
Right,
no,
no!
So
the
the
idea
is
this,
so
you
have
one
thing:
a
logger
or
a
log
emitter
and
the
name
can
be
hashed
out
later,
and
this
log
emitter
has
a
specific
api.
That's
like
syntactic
sugar
to
create
events
that
forces
you
to
specify
its
required
field
name.
B
C
And
then
you
emit
it,
here's
a
version
where
you
include
some
additional
fields
as
well
in
this
case
attributes,
but
this
same
log
emitter
has
an
additional
api.
Where
you
can.
C
This
is
kind
of
the
lower
level
api
that
appenders
would
use
where
you
build
a
specific
log
record
and
you
can
set
whatever
fields
you
want
and
so
from
most
users
would
just
use
this
like
the
event
portion
of
this
api,
because
the
lower
level
api,
where
you
can
directly
build
and
emit
log
records,
is
we
would
advertise
that,
as
only
intended
to
be
used
by
log
appenders.
A
C
So
that
requested-
and
we
could
we
could
hash
this
out
for
us
and
so
what
what
I've
done
is.
I
have
a
an
interface
called
event
builder
and
event.
Builder
is
well
what
I've
done
for
simplicity's
sake
is,
I
have
it
extend.
It
just
extends
this
log
record
builder,
which
is
the
lower
level
interface
with
all
the
setters.
So
you
know
it
is.
It
is,
for
all
intents
and
purposes,
the
same
interface
as
you.
You
have
for
building
logs.
It's
just
called
an
event
builder,
so
that.
A
Log
emitter
is
what
contains
the
second
api
yeah.
Okay,
so
that's
where
the
two
are
yeah.
So
then
what
does
having
a
single
api
versus
two
apis
really
mean,
because
I
was
when
I
saw
that
discussion.
I
thought
a
single
api
meant
like
really
just
a
single
way
to
send
a
single
set
of
methods
versus
if
we're
already
splitting
out.
C
Yeah,
let's,
let's
break
that
down
a
bit
so.
C
Here,
exactly
okay,
so
this
this
prototype
indicates.
C
This
is
for
two
separate
apis,
as
this
called,
and
you
know,
I
think
in
both
cases
there's
there's
two
different
apis,
it's
just
the
extent
to
which
they're
split
and
where
they're
split,
and
so
in
this
case
they
are
split
up
at
the
you
know,
this
kind
of
the
scope
level,
so
you
know
in
in
tracing
and
metrics,
we
have
a
tracer
and
we
have
a
meter,
and
so
in
this
case
it's
split
here.
So
you
have.
C
C
You
know
down
here
in
this.
In
the
example
where
they're
the
combined
api,
you,
you
only
have
one
thing:
a
logger
or
a
log
emitter
which
is
equivalent
to
a
tracer
or
meter.
You
know,
but
that
that
emitter
still
has
two
different
things.
You
know
one
two
different
methods,
one
for
building
events
and
one
for
building
the
lower
level
log
records
in
it.
Just
you
know,
you
talked
about
artifacts.
How
are
these
publishers
artifacts
so
long
term?
These
would
all
be
in
the
same
artifact,
because
that's
how
we
do
it
in
hotel
java.
A
C
Well,
that
that
that's
what
I
don't
necessarily
like
about
the
single
api
or
that's
one
of
the
arguments
against
it
is,
it
makes
it
easier
to
to
omit
that
the
required
domain
field,
and
so
the
way
that
you
would
have
to
include
the
domain
is,
you
know
we
have
these
scope,
attributes
coming,
and
so
that's
going
to
be
coming
to
tracers
and
meters
and
whatever
comes
in
out
of
the
log
space,
and
so
when
you're
building
your
tracer
or
your
meter-
and
you
you
have
this
required
argument,
which
is
the
scope
name
and
you'll,
have
this
optional
argument,
which
are
the
scope
attributes,
and
so
here
we
build
a
a
logger
and
we
set
the
scope
attributes
and
we
say:
hey
set
the
event
domain
to
be
in
this
case.
C
Hotel.Jfr,
and
you
know
this
is
optional,
and
so
you
can
omit
this,
and
so
we
would
rely
on
documentation
to
to
tell
users
like
you
know
if
you're
emitting
events
this
is
this
is
this
is
something
you
really
should
do
yeah,
but.
A
A
Cool
well
yeah.
Keep
us
posted
the
good,
interesting.
C
So
so
two
two,
I
guess
kind
of
final
thoughts.
So
one
is
that
you
know
in
talking
in
the
log
said
yesterday.
I
think
people
have
different
opinions,
but
nobody.
C
Nobody
was
really
taking
like
a
hard-line
stance
on
their
opinion,
and
I
think
you
know
what
we
said
out
loud
was
that
reflects
the
fact
that
we
think
that
either
one
of
these
would
be
okay.
You
know
it's
not
the
end
of
the
world
if,
if
one
or
the
other
option
gets
chosen
and
both
will
probably
work
out,
because
I
don't
think
either
of
them
have
any
fatal
flaws.
C
So
that's
one
comment
and
then
the
other
comment
was
so
you
know
we're
trying
to
circulate
this.
We're
trying
to
gather
more
opinions
on
this
outside
of
the
logs
thing,
specifically
because
we've
talked
about
this
a
lot
amongst
each
other
amongst
ourselves,
and
you
know
we
need
some
some
fresh
eyes
to
an
extent
and
so,
but
but
we
do
want
to
make
some
sort
of
decision
and
make
progress.
C
And
so
I
think
what
tigran
has
suggested
is
that
we
try
to
take
a
vote
for
lack
of
a
better
word
gather
opinions,
express
those
opinions
and
and
make
a
decision
he
suggested
by
next
week.
And
so,
if
you
have
thoughts,
I
I
do
encourage
you
to
go
comment
on
this.
C
C
Yeah,
so
this
is
a
pr
that's
been
open
for
a
while,
and
I
like
that,
I,
like
the
thought
behind
it.
I
just
I
I
haven't
seen
the
implementation.
I
don't
know
how
it's
going
to
be
implemented
and
this
is
getting
proposing
getting
merged
to
a
stable
artifact,
and
so
we
can't
get
out
of
it
once
we
once
we
merge
it,
and
so
you
know
I
have
two
questions
that
relate
to
this
one.
Is
this
repository
the
best
place
to
keep
this
this
annotations
artifact,
given
that
the
implementation
lives
in
instrumentation?
C
And
you
know
if
it
is-
and
you
know
we
can
go
back
to
that.
If
it
is
the
right
place,
you
know,
I
suggest
that
we
move
it
to
the
incubator
artifact
instead
of
this
stable
annotations
artifact,
so
that
we
can
work
out
the
implementation
and
gain
confidence.
A
A
Yeah,
I
guess
the
case
to
be
made
is
that
this
is
manual
instrumentation
right.
It's
not
it's
likely
that
somebody
isn't
using
the
auto
instrumentation
agent
or
they're
supplementing
it,
but
certainly
there's
a
use
case
for
people
that
aren't
using
the
instrumentation
agents
to
use
these
annotations.
A
A
A
B
Question
for
the
for
the
time
the
annotation.
Does
this
mean
that
the
open
elements
to
each
other
sdk
will
also
have
a
timer,
because
the
metric
specification
doesn't
have
one,
and
I
find
it
very,
very
sad
that
there
is
no
timer,
because
measuring
time
is
hard
and
the
people
are
usually
I
get
it
wrong.
But
to
me,
if
you,
you
provide
a
timed
annotation,
it
would
be
evident
to
also
provide
a
timer
abstraction.
C
A
Yeah,
that's
a
really
good
point.
It
could,
and
even
if
we
see
it
being
used
elsewhere,
like
the
width
span,
you
can
use
with
the
we
have
spring
aop
instrumentation
also
for
that.
A
But
that
also
lives
in
the
instrumentation
repo
and
we
could
still
make
it
a
standalone
artifact
in
the
instrumentation
repo
that
other
people
say
like
a
corkus
could
leverage
yeah.
This
feels
more
like
an
api,
though
like
if
it's
just,
if,
if
it's
just
the
annotation
definitions,
that
feels
like.
A
So
one
of
the
distinctions
that
I
like
when
I
think
of
the
core
repo
is
like
spect
components,
living
in
the
core,
repo
and
non-spec
components
living
elsewhere,
whether
it's
instrumentation
or
contrib.
A
Yeah,
so
core
is
like
only
spec
components.
Is
that
kind
of
the
that's?
Not
the
consensus.
I
mean
it's
not
the
reality
today,
but
I
mean
that's
conceptually,
that's
the
the
ideal.
That's
what
I
have
in
my
brain.
Okay
and
we've
discussed
a
little.
We've
discussed
that
idea.
It
came
up
a
little
bit
with
when
we
brought
in
to
the
contrib
repo.
A
We
brought
in
the
consistent
sampling
that
omar
contributed
because
those
implement
the
spec,
and
so
I
was
suggesting
that
we
should
land
those
in
the
core
repo,
but
anurag
and
john
wanted
to
incubate
them
in
contrib
at
least
initially,
but
eventually
agreed
that
they
would
move
to
the
core
repo
because
they
are
specked.
A
So
I
think
at
least
anything
specked
should
live
in
the
core
repo,
but
whether
non-spec
things
should
live
here
or
not
as
an
open
question.
A
So
let's
definitely
bring
that
up
with
john
and
honorag
later
today.
C
Yeah
it'd
be
good
to
have
that
discussion
and
I
guess
more
generally
come
up
with
some
some
guidelines
for
once
something
lives
in
the
core
repo
versus
instrumentation
versus
contrib,
so
that
we
can
avoid
rediscovering
our
past
decisions.
C
You
know
away
from
its
implementation
and
I
don't
really
see
it
being
a
problem
that,
for
this
thing
that
looks
like
an
api
to
live
in
instrumentation,
given
the
existence
of
the
instrumenter
api,
which
is
very
much
something
we
expect
folks
to
use,
but
I
do
feel
stronger
about
like
if
this
is
gonna
live
in
the
core
repo.
It
should
be
incubated
first.
So
that's.
D
A
So
laurie
are
you
saying
that
I
mean
that
they
should
live
in
the
same
place
as
with
span
and
should
all
of
them?
Do
you
think
all
of
them
should
live
in
the
core
repo
or
the
instrumentation
repo.
D
B
A
Yeah,
I
thought
the
good
point
is
that
I
mean
I'm
not
sure
if
we
can
even
really
move
the
width
span.
At
this
point,
at
least
from
a
package
an
artifact
naming
perspective,
I
mean
we
could
publish
it,
of
course,
out
of
the
instrumentation
repo,
but
it
would
be
a
different.
C
So,
just
just
to
quickly
go
talk
through
that,
so
we
for
stable
artifacts.
We
have
in
the
past,
changed
the
group
or
not
the
group,
but
we've
changed
the
artifact
that
they're
published
under
the
artifact
id.
So
an
example
that
we're
doing
right
now
is
the
the
otlp
grpc
and
http
exporters.
C
C
A
No,
I
was
just
thinking
that.
A
Yeah,
it's
not
the
word,
it's
not
the
worst
thing.
I
don't
think
it
would
cause
any
real
problems.
A
So
yeah
I
mean
we
could
certainly
make
that
as
an
exception
and
I'd
be
so
you're
saying
that
we
have
changed.
Artifact
ids
in
stable
artifacts
is
okay.
A
Cool
well,
let's
get
john
and
anarag's
thoughts
later.
A
Sounds
like
we
have
some
some
basic
consensus
here
that
but
jason
were
you
still,
preferring
it
in
core
repo?
That's
my
instinct!
Well,
my
real
instinct
is
to
make
a
separate
repo
just
for
the
annotations,
but
I
know
we're.
D
A
D
Know
if
jason
got
his
way,
he
probably
would
split
that
point
too.
A
D
C
Yeah,
we
have
an
incubator,
an
api
incubator
in
the
in
the
main
project,
and
it's
marked
as
alpha,
and
so
you
know
if
we
do
decide
to
put
it,
keep
it
in
the
main
repository
I
I
would
be
a
proponent
of
incubating
it
in
that
artifact.
First.
A
Yeah
and
even
if
we
move
it,
we
would
probably
want
to
do
something
similar
so
that
that
might
be
worth
just
proposing.
A
All
right
anything
else
that
anybody
wants
to
chat
about.
C
I
I
guess
I
have
one
thing
so
I've
been
working
on
kafka,
client,
metrics,
instrumentation
and
so
there's
semantic
conventions
that
got
merged
for
this,
but
I
don't
think
they're
meant
to
to
be
the
type
of
instrumentation
that
I've
been
writing.
C
I
think
it's
like
meant
to
you
know,
connect
to
a
kafka
broker
and
collect
those
metrics
from
the
broker,
but
funny
enough
there's
a
lot
of
exact
overlap
with
what
you
can
get
from
the
kafka
client
itself,
and
you
know
my
employer
is
really
big
on
using
kafka
and
his
instrument
interested
in
having
instrument
like
metric
instrumentation
of
kafka,
which
is
kind
of
what's
driving
this
and
yeah.
I
just
I
guess
I
wanted
to
get
you
your
thoughts
on
this
is.
C
Is
this
something
that
the
instrumentation
repository
would
be
like
interested
in
generally?
And
you
know,
there's
there's
places
where
the
instrumentation
that
that
I
have
access
to
is
overlapping
with
these
semantic
inventions.
But
it's
also
like
by
limiting
us
to
where
the
overlap
occurs.
We're
leaving
a
lot
of
useful
data
on
the
table,
and
so
you
know,
I
guess
I
was
thinking
you
know,
overlap
where
possible,
and
then
you
know
try
to
discern
what
the
other
useful
metrics
are
and
include
those
in
some
sort
of
experimental
fashion.
C
So
that
that's
kind
of
what
I
was
thinking,
guard
them
with
a
flag
and
use
the
existence
of
you
know
this
prototype
code
to
try
to
move
the
semantic
inventions
forward
at
the
spec
level
to
include
any
additional
useful
metrics.
C
Yeah,
this
is
all
broker
stuff,
not
all
of
it.
There's
if
you
go,
if
you
scroll
down,
there's
a
section
on
clients
and
consumers
and
producers,
so
there's.
A
And
is
that
what
you're,
adding
metrics
around.
C
C
B
C
And
in
the
way
that
we
access
the
metrics
or
that
I'm
accessing
the
metrics
is
kind
of
interesting
too
you
can,
you
can
add,
like
a
hook,
you
know,
there's
a
property
that
you
can
add
when
you're
configuring,
your
kafka,
client,
that
you
know
you
register
a
reporter
interface,
and
you
know
when
you
register
this
reporter
when
kafka.
When
the
client
registers
new
metrics
its
own
internal
notion
of
metrics,
it
will,
you
know,
call
a
callback
that
you
can
use
to
observe
those
metrics.
A
Yeah,
so
I
think
these
were
primarily
driven
by
what
the
jmx
scraper
was
is
capturing
today,
and
I
I
was
assuming
it
was
just
pointing
at
your
cough
at
your.
You
know:
kafka
broker
your
kafka
server,
but
yeah,
probably
these
are
coming
from
the
individual
nodes.
A
Also
but
yeah
I
agree
with
I
mean
what
laurie
said
makes
you
know,
is
the
make
sense
of
just
hide
anything:
that's
not
in
here
already
behind
an
experimental
flag
and
then
once
we
have
an
implementation,
I
think
that's
a
good
baseline
for
proposing
new
metrics
to
the
spec.
Then
great.
D
D
Yeah
and
oh
actually,
there
is
a
poor
request
for
some
chinese
framework
that
has
been
open
for
a
long
time,
but
we
haven't
accepted.
C
A
C
C
B
A
Nick
next
up
is
laura:
laurie
have
jonathan's
pr
was
the
oldest
vr
in
the
spec
repo.
Let's
see
if
lori's
pr
has
made
it
to
the
oldest,
oh
you're,
not
the
you're,
not
the
oldest,
there's
one.
Oh
somebody
beat
you
by
one
day,
older.