►
From YouTube: 2022-10-20 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
B
Not
very
much
no,
the
wind
is
has
already
started
to
shift,
though
so
fingers
crossed
it's
going
to
clear
out.
B
Yeah
the
Nakia
Creek
Fire,
which
is
just
north
of
what
the
heck
is,
that
paper
plant
Town
in
Washington.
It's.
C
A
A
B
But
with
the
winds
shifting
to
be
coming
from
the
ocean,
not
only
will
we
get
lots
of
rain,
hopefully
we'll
put
out
the
fires
and
also
get
rid
of
the
smoke
all
right.
A
few
more
hours.
B
Mitesh
I'm
reading
an
interesting
book
called
The
Widow
Queen,
set
in
like
10th
Century
Poland.
It's
a
historical,
historical
novel.
D
That
time,
yeah
I
mean
his
story
from
that
period
of
time
is
more,
like
you
know,
Legends
and
myths,
rather
than
the
actual
heart
history,
so
yeah
it
does
sound
interesting.
There's.
B
Lots
of
interactions
with
the
Vikings,
who
are
also
Allied
somewhat
allied
with
the
Polish
various
polish
Kings
anyway,
it's
interesting.
A
Right,
oh
I
have
a
couple
things
on
the
agenda.
A
Let's
see
what
this
link
goes
to,
I
forget:
oh
yeah,
just
thought
that
was
seen.
A
lot
of
users
are
in
this
repo.
A
lot
of
the
issues
we
get
are
around
people
creating
extensions.
A
And
trying
to
do
things
and
then
having
problems
talking
to
their
classes
and
their
application
because
they
have
to
go
through
the
bootstrap
class
voter,
and
so
we
had
sort
of
in
our
original
sort
of
design
and
implementation.
Here
we
had
intentionally
not
gone
with
putting
the
open,
Telemetry
API.
So
in
order
to
interrupt
on
the
one
option
is
just
putting
the
open,
Telemetry
API
and
the
bootstrap
class
loader,
and
then,
if
the
user
is
using,
that
they
would
get
that
copy
instead
of
their
copy.
A
So
they
would
be
talking
to
that
and
same
with
even
putting
the
SDK
and
the
bootstrap
class
loader
all
unshaded,
and
then
that
would
we
wouldn't
need
a
bridge
then,
because
the
agent
would
be
using
the
same
classes
as
the
user.
A
I,
don't
think
it's
a
a!
We
decided
not
to
do
that
because
then,
once
we
start
pinning
our
classes
into
the
bootstrap
class
loader,
then
you
can
start
having
version
conflicts
with
the
user
stuff
that
the
user
brings.
It
would
be
impossible
to
do
like
a
in
the
future
to
support
any
breaking
changes
in
the
open,
Telemetry
API.
So
if
we
do
ever
have
a
open,
Telemetry,
API
2.0,
we
couldn't
have
the
agent
sort
of
be
smart
and
interrupt
with
both
1.0
and
2.0.
A
A
You
know
I'm
kind
of
thinking
of
people
who
are
writing
extensions.
Then
they
could
just
put
that
into
their
class.
A
And
I
suspect
this
is
more
similar
to
how
other
languages
are
probably
doing.
Auto
instrumentation,
where
without
this
class,
loader
isolation
and
everything
then
becomes
available,
you
can
use
the
SDK
Auto
configure
directly
in
your
app.
D
Like
it
would
be
have
to
be
a
separate,
build
but
I'm
not
entirely
sure
yeah
we're
shading
things
right
now.
We
would
have
to
they're
not
shake
them
and
I
kind
of
say
them
dynamically
or
do
the
opposite
thing.
So
yeah.
D
A
C
C
C
A
A
If
it's
something
that
we
could
provide,
that
would
work
across
people
who
have
that
need
it
could
make
sense
and
yeah.
So
the
runtime
I
think
the
two
compelling
things
to
me
right
now
are
the
runtime
attached
potentially
seems
like
a
neat
in
neat
pairing,
and
the
other
is
just
the
number
of
issues
I've
seen
lately
that
matesh
and
Laurie
in
particular,
has
been
replying
to
helping
users
with
extensions
and
communication
between
their
extension
and
their
app.
A
Now,
I'm
not
sure
that
this
would
all
work
out
it's,
but
this
was
essentially
how
the
datadog
Java
agent
worked
previously
with
open
tracing.
A
So
there's
some
good
prior
art
there.
They
pinned
the
open
tracing
API
in
the
bootstrap
class
odor.
They
did
not
put
the
SDK
I,
don't
think
there
was
I
forget
with
open
tracing
I,
think
there
was
a
separate
SDK
or
they
implemented
I
think
they
had
their
own
implementation
of
the
API
internally.
B
A
D
So
I
think
it
probably
wouldn't
be
I
mean
it
still
would
be
hard,
and
it
would
be
a
lot
of
work
to
implement
that.
But
there
are
probably
like
very
little
crucial
points
that
we
have
to.
We
would
have
to
take
care
of.
We
just
powered
customer
implementations
and
I
need
the
age
and
then
extension
crossovers
and
the
grade
will
build
for
that.
D
You
probably
somehow
have
to
like
skip,
or
you
know,
have
some
kind
of
a
no
up
cost
holder
for
this
particular
build
and
yeah
then
package.
It
correctly.
A
So
for
the
what
would
be
the
NOAA
class
loader
for.
D
D
A
A
Okay,
just
so
I
don't
forget
foreign
yeah
I
just
wanted
to
kind
of
Start
Spreading.
That
thought
probably
won't
get
to
it
soon.
But
if
you
have
any
more
thoughts
about
it,
you
know
drop
them
on
the
issue.
A
B
E
So
yeah
the
question
is
kind
of
straightforward
here,
so
we
have
the
semantic
conventions:
module
and
the
semantic
inventions
are
unstable,
and
so,
as
we
upgrade
the
semantic
convention
module
from
version
to
version,
there
will
be
attributes
that
will
be
removed
or
whose
definition
changes,
but
for
those
which
are
removed.
The
question
is:
how
long
do
we
keep
a
deprecated
version
of
them
around?
For
what
you're
looking
at
here
is
an
example
of
changing
the
code
manually.
E
Changing
the
code
generation
script
to
include
manually
include
an
attribute
that
is
no
longer
in
the
semantic
convention,
yaml
that
we
generate
those
attributes
from
and
so
yeah.
How
long
do
we
maintain
this?
For
one
cycle,
two
cycles:
One
release
cycle,
two
release,
Cycles
three
release:
Cycles.
B
Here's
my
controversial
hot
take.
We
should
maintain
these
until
the
cementing
convention
stabilize.
A
D
B
E
So
so,
let's
talk
about
that
a
bit
so
when
the
semantic
conventions
aren't
going
to
stabilize
all
at
once,
they're
going
to
stabilize
in
chunks,
and
so
let's
take
HTTP
semantic
conventions,
for
example,
they
there's
HTTP
components
of
it
and
then
there's
common
components
which
kind
of
are
cross-cutting
concerns
and
like
the
the
net
family
of
of
attributes.
E
So
if
the
HTTP
semantic
conventions
reference
the
net
family,
then
that
is
kind
of
like
a
parent
family
of
those
and
the
HTTP
semantic
inventions
stabilized
to
are
we
kind
of
like
implying
that
the
net
family
is
stabilized
as
well.
At
that
point,.
B
I
mean
I
think
you'd
have
to
right,
I
mean
how
else
could?
How
else
could
it
work,
but
this
does
bring
up
a
really
good
point.
If
they're
gonna
I
mean
I
I,
don't
believe
at
this
point
we're
ever
going
to
stabilize
them,
but
assuming
that
we
do
stabilize
something
at
some
point,
if
we're
doing
it
in
chunks,
we
like
we,
don't
have
a
way
to
have
a
partially
stable
module
at
the
moment,
and
we
would
need
to
if
we
wanted
to
have
partially
stable
modules.
B
We
would
need
to
do
something
like
have
some
annotation
on
the
things
that
are
unstable
within
that
module.
I,
don't
I'm,
not
even
sure,
exactly
how
you
would
do
that
without
breaking
it
up
into
separate
modules
or
or
at
least
separate
files,
separate
classes.
E
A
Mm-Hmm
flip
them
out,
I
I
have
a
feeling.
This
may
be
a
topic
of
the
new
instrumentation
working
group
that
Josh
sharath
has
started
because
one
of
the
focuses
there
once
they
get
through
the
definition
of
stability
is
going
to
be
co-generation,
and
so
maybe
we
can
I'm
hoping
we'll
bring
that
up.
I
I
can
bring
that
up
over
there.
I
have
been
I'm
going
to
be
going
to
those
meetings.
A
B
This
is
I
think
this
is
intimately
connected
with
the
idea
of
the
schema
Evolution
as
well.
I
mean
the
idea
of
the
schema.
Evolution
is
great,
except
that
if
you
want
to
have
generated
code
for
the
current
version,
you
don't
have
a
way.
At
least
we
don't
have
a
good
way
at
the
moment
to
utilize
that
schema
to
convert
from
old
to
new
and
I.
B
A
Yeah,
so
if
you're
interested
in
these
kinds
of
questions,
I
highly
recommend
coming
to
this,
it
just
started
yesterday,
I
mean
Monday
was
the
first
meeting
and
it
is
specifically
tackling
that's
kind
of
the
first
issue.
They're
tackling
is
what
it
means
to
be
stable
and
how
does
how
can
can
we
leverage
those
those
automated
Transformations
or
not,
as
part
of
that,
there's
yeah
check
out
this
here.
This
is
the
proposal
that
Josh
wrote
up.
A
E
E
I
think
one
thing
that
would
be
nice
would
be
to
add
some
an
annotation
or
Java
doc
to
each
of
these
to
say,
like
the
version
when
these
were
removed,
so
I
guess
just
somewhere
in
the
back
of
my
head.
I
can
track
like
is
this
one
month
since
this
is
since
this
was
removed.
Is
this
two
years
that
type
of
thing.
E
And
I
guess
on
that
note:
John
I'm
wondering
if
you
remember
is
this:
the
first
instance
where
semantic
attributes
were
removed
or
no.
B
Well,
we've
had
a
couple:
you
could
look
at
the
history
in
the
in
the
in
the
template,
like
the.
B
B
C
B
It
doesn't
doesn't
bother
me
to
to
maintain
that
there
and
it
seems
like
it's
at
least
user
friendly
and
doesn't
harm
anyone
to
keep
that
to
keep
it
there
yeah,
but.
A
You
I've
heard
people
basically
they've
pinned
to
an
early
version
of
the
semantic
conventions
and
they're
like
I'm,
not
gonna,
update
along
the
ways
you
know
with
you
know:
I'm
gonna
wait
now
until
it's
marked
stable
and
then
do
a
one-time
jump.
A
So
I
think
that
is
a
We.
There
are
users
who
would
benefit
from
this
approach.
E
Yeah
and
I
don't
mind
this
approach,
either
just
kind
of
wanted
to
have
a
decision
on
it.
A
More
semantic
conventions
schema
URL,
so
this
is
basically
pointing
would
in
instrumentations,
you
can
say
which
version
of
the
open,
Telemetry
semantic
conventions
you're
following,
and
we
don't
populate
this
today,
but
I
was
thinking.
Maybe
we
should
start
populating
it
on
a
sort
of
a
best
effort,
saying
that
we
are
at
least
trying
to
follow
this
version
of
the
semantic
conventions
in
this
release.
B
I
mean
it
should
be
really
easy
right
because
we
published
the
schema
URL
in
the
generated
code.
So
it
should
just
be
a
matter
of
pulling
that
in
and
the
name
of
that
constant
doesn't
change
from
release
to
release.
So
it
should
be
pretty
simple
to
just
stick
that
in
there
from
the
resource,
attributes
or
semantic
attribute
classes.
D
Didn't
we
have
a
discussion
a
couple
of
months
ago,
the
populating
schema
URL
is
kind
of
equivalent
to
committing
to
like
stability.
A
A
I'll
ask
yeah
I'll
I'll
raise
this
in
the
next
instrumentation
working
group.
D
Yeah
because
like
if,
if
the
schema
I
mean
it's
like,
the
semantic
conventions
themselves
are
considered
unstable
and
if
we
point
to
a
schema
URL
for
the
Cinematic
elevations,
and
if
it
doesn't
mean
that
we
have
to
like
conform
to
these
unstable
semantic
conventions
forever,
then
it's
okay.
We
can
populate
that,
but
yeah,
it
kind
of
depends
what
it
will
mean
in
this
context,.
A
Oh,
this
was
the
same.
Yes,
awesome.
E
Yeah
I'm
drafting
a
response
to
this
right
now
and
so
to
summarize,
the
the
argument
was
a
or
the
the
initial
problem
was
that
it's
unclear
when
you
should
map
existing
log
and
event
data
models
to
open
Telemetry
events
like
when,
when
you're
bringing
something
in
from
dotnet's,
Event,
Source
or
kubernetes
events
mapping
an
existing
data
model
is
the
thing.
E
Should
the
thing
be
thought
of
as
an
open,
Telemetry
event
versus
a
regular
log
record,
and
you
know
the
there's
kind
of
arguments
around
the
fact
that
the
the
names
event
domain
and
event
name
have
are
like
overloaded
terms
potentially
so
event
name
appears
in
a
lot
of
other
data
models,
so
you
might
accidentally
think
that
your
other
data
model
has
open
Telemetry
events
but
be
mistaken
about
it
just
because
they
have
a
field
called
name.
E
Maybe
the
semantics
don't
match
up
to
open
Telemetry
event,
name
and
so
tigrin
proposed
changing
the
name
of
open
Telemetry
events
is
something
like
categorize
logs,
there's
schematized
logs
or
something
like
that,
give
it
a
name
that
is
unambiguous,
so
that
it
makes
it
very
clear
to
users
that
this
is
not
just
like
this
app.
This
notion
of
an
event
which
has
been
overloaded
and
overused
throughout
prior
Arc,
It's
Like,
A,
New
Concept,
and
that.
B
A
A
But
yeah,
that's
like
what
What
products,
Windex
Etc
yeah.
A
E
There's
categorized
logs
yeah
so
that
got
rejected
and
and
John
or
I
guess
tigran
gave
up
on
that
idea
and
I
think
John
and
others.
There
is
pretty
much
unanimous
that
we
want
to
keep
the
name
event,
because
it's
something
that
people
will
relate
to
for
the
most
part
and
now
tigrants
come
back
with
this
other
proposal.
E
That
is
linked
here
and
you
know
the
argument
is
that,
essentially,
that
the
main
driver
of
having
an
event
domain,
an
event
name
field
was
to
have
a
a
primary
key,
so
you
can
quickly
and
unambiguously
identify
the
class
of
thing
that
happened
like
this
was
a
click
in
a
browser.
This
was
a
pod
deployed
in
a
kubernetes
environment,
and
so
you
know
systems
processing.
Those
events
can
induce
you
know
conditional
processing,
based
on
the
class
of
thing
that
happened
and
on
a
similar
note.
E
You
know
folks
querying
for
those
events
can
unambiguously
query
for
this
specific
thing.
This
is
in
contrast
to
how
spans
work
today
spans
work,
it's
kind
of
like
duct
typing,
so
you
can
identify
the
class
of
spans
by
looking
for
certain
attributes
that
are
defined.
The
presence
of
certain
attributes
that
are
defined
in
the
semantic
conventions,
so
all
HTTP
spans,
are
required
to
have
an
HTTP
method
attribute
all
database
spans
are
required
to
have
a
database
type
attribute,
and
so
you
know
you
can
say
hey.
E
If
the
the
the
attribute
HTTP
method
is
present,
then
it's
an
https
ban.
If
the
attribute
database
system
is
present,
then
it's
a
database
span,
and
so
you
know
why
are
we
doing
something
different
for
events
like?
Why
can't
we
just
rely
on
that
same
type
of
duct,
typing
logic,
to
identify
the
class
of
things
and
so
get
rid
of
the
event
API
get
rid
of
these
semantic
attributes.
For
this
instead
rely
on.
You
know
people
inventing
their
own
semantic
conventions
to
describe
their
classes
of
things
and
systems
processing.
B
B
What
the
end
user
cares
about
is
the
API.
They
have
to
use
to
generate
things
and,
as
I
have
been
trying
to
say
from
the
very
beginning
of
when
logging
started,
we
do
not
need
another
Java
logging
API.
There
are
already
too
many
Java
logging
apis.
There
is
no
Java
event
API.
What
we
need
is
an
event
API,
so
that
users
can
can
generate
things
that
are
not
logs
because
they
want
to
use
log4j
or
they
want
to
use
log
back
or
they
want
to
use
slf4j
do
their
logging.
B
Those
things
don't
have
events,
they
don't
have
an
idea
of
this
kind
of
semantic
thing
called
an
event.
This
is
what
we
can
add
from
open
Telemetry
to
at
least
in
the
Java
world
to
the
community.
Is
we're
adding
a
new
thing,
we're
adding
a
new
signal
called
an
event?
It's
not
a
log,
maybe
it's
modeled
as
a
log
going
to
a
back
end
and
users
don't
give
a
crap
about
that
end.
B
Users
are
going
to
be
writing
code
using
an
API
to
try
to
accomplish
a
task
and
if
they
have
to
use
a
a
weird
logging
API
to
generate
events,
they're
docking,
it
like
why
do
I
like
why
they
need
two
logging
apis
they're
not
going
to
understand
this
I.
Don't
understand
this
like
how
would
I
know
like
how
would
I
try
to
communicate
to
the
the
developers
on
my
team
how
they're
supposed
to
generate
events
like
I'm,
like
oh
use,
this
other
logging
API,
that's
weird
that
no
one
uses
for
actual
logging,
but
we're
gonna.
B
Do
this
weird
thing
that
makes
it
turns
it
into
events
like
that's
ridiculous,
like
that's,
not
a
that's,
not
a
viable,
a
good,
a
quality
API
for
Java
users.
So
my
goal
is
to
generate
a
an
API
that
users
can
use
to
generate
things
that
are
semantically
events,
not
to
try
to
figure
out
an
API.
That
looks
like
the
data
model,
which
I
think
is
a
bad
idea,
because
users
don't
care
about
the
data
model.
E
Yeah
I
think
you
know
the
the
trouble
has
been
it
to
kind
of
sum
up
all
the
trouble
into
one
like
quick
thought,
it's
that
it's
pinning
down
what
the
what
an
event
actually
is
like
what
are
the
defining
characteristics
of
an
event
in
in
the
data
model.
I
think
you
know
you
have
to
answer
that
before
you
can
articulate
why
you
need
a
dedicated
event
API,
because
if
you
can't
say
what
this
thing
is,
what
it's
defining
attributes
are,
then
you
can't
create
an
API
for
it.
I
totally
disagree
with
that.
B
D
B
E
E
And
and
that's
kind
of
what
I've
tried
to
I've
tried
to
articulate
that
the
defining
characteristic
of
an
event
is
that
it
has.
It
has
kind
of
this
primary
key,
this
identifier
that
identifies
the
class
of
thing
that
it
is,
and
you
know,
there's
there's
nothing
else
that
really
matters
other
than
that.
It's
just
kind
of
this,
this
structured
record
that
you
can
attach
attributes
to
in
arbitrarily,
but
I
keep
coming
back
to
that.
That's
the
only
thing
that
really
sticks
is
that
it
has.
It
has
a
class
associated
with
it.
E
B
I
think
it's
super
important
to
say
what
it's
not
and
it's
not
a
log
like
we
might
model
it
in
the
data
models
log,
but
it's
not
a
log.
It's
not
what
an
application
developer
thinks
about
when
they're
thinking
about
logging,
they're
thinking
about
a
different
thing
and
I
think
it's
really
important
that
we
we
make
it
really
clear
that
from
an
end
user
instrumentation
perspective
we're
not
talking
about
logs
we're
talking
about
events,
they're
a
different
thing.
E
I,
don't
I
don't
disagree
with
that
as
a
Java
developer,
but
having
kind
of
been
exposed
to
some
of
the
prior
art
in
other
languages
in
ecosystems,
the
words
logs
and
events
are
used
interchangeably,
often,
and
it
kind
of
breaks
down
my
conventional
thought
about
what
is
an
application
log
versus
what
is
an
event
and
I'm
kind
of
left.
Trying
to
you
know
more
at
more
more
clearly
defined
what
is
an
event
in
a
like
language
and
platform
agnostic
way.
A
Jack,
you
mentioned
the
key
thing
for
your
events,
having
a
classifier
with
this
approach.
There's
not
really
a
way
to
get.
There
isn't
really
like
one
field.
That
is
the
classifier
exactly
that's.
E
Stands
today
right
so
spans
if
you
wanted
to
off,
have
and
I'm
I'm
writing
this
up
in
a
summary
right
now,
but
let's
say
you
wanted
to
have
a
discovery
mechanism
in
your
back
end
that
discovered
all
the
different
classes
of
spans
that
you
received,
and
so
you
want
to
say,
hey
I
saw
some
HTTP
spans
I
saw
some
database
spans.
I
saw
some
messaging
spans.
What
about
the
classes
that
aren't
well
known
like
what
about
you
know,
systems
that
are
generating
spans.
E
They
have
conventions
that
maybe
aren't
published
as
part
of
the
open,
Telemetry
semantic
conventions,
but
they're
well
structured.
Nonetheless,
you
can't
identify
those
with
spans
today,
because
you
know
because
of
this
duck
typing
thing,
it
relies
on
the
presence
of
certain
attributes
to
be
the
the
classification
mechanism.
A
B
C
C
B
D
Somebody
expect
the
observability
developers
to
know
that
events
are
transmitted
as
logs,
really,
whereas,
whenever
you
have
an
ordinary
user-
and
you
know
you
have
somebody
writing
a
library
and
they
want
to
have
it
an
event
so
when
they
need
to
get
a
logger
and
set
an
even
domain
and
then
remember
not
to
call
set
severity.
Because
you
know
events
don't
have
severity,
even
though
there
are
logs.
So
that's
really
confusing.
No.
C
B
Yeah,
well,
it
seems
like
tigrant
is
definitely
not
in
alignment
and
I.
Don't
know
whether
that's
he's
representing
the
whole
log
Sig,
but
definitely
what
I'm
hearing
here
is
not
you
not
like
user-centric
discussion.
This
is
back-end
observability,
developer,
Centric
discussion,
which
is
fine
and
important
because
you
all
need
to
implement
this
crap,
but,
like
our
end,
users
are
much.
There
are
many
more
of
them
and
the
end
users
are
going
to
determine
whether
this
whether
this
project
is
successful
or
not,
not
the
back
end
observability
Developers.
E
So,
to
take
Jason's
side
for
a
second,
so
you're
sending
you
know
you
you
adopt
this
open
source
solution
to
instrument
your
data,
to
collect
your
data
and
to
transmit
it
over
the
wire
called
open.
Telemetry-
and
you
know
you
choose
a
back
end
to
do
something
with
that.
E
You
know
you
might
choose
Splunk
or
New
Relic
or
an
open
source
solution,
and
each
of
these
back
ends
make
decisions
on
how
to
handle
the
data
that's
sent
to
them
according
to
the
data
model
and
so
the
so
the
users,
the
users,
are
kind
of
forced
to
understand
the
data
model
to
some
extent
because
and
you're
shaking
your
head.
B
I'm
disagreeing
because
that
that's
up
to
the
the
vendor
to
tell
the
users
how
to
look
at
their
events-
that's
not
on
the
user
to
figure
out
how
to
use
the
vendor
to
find
their
events.
The
vendor
should
tell
the
users
hey
you're,
generating
open,
flinder
events.
Here's
how
you
look
at
them
like
that's,
that's
not
the
user's
responsibility
to
figure
that
out,
but.
B
I
mean
that's
the
that's
again,
I
think
the
responsibility
of
the
vendor.
Well,
second,
so
if
you're
Splunk
and
you
want,
you
have
a
way
to
consume
events,
you
tell
users
or
you
provide
an
SDK
or
whatever
here's,
how
here's
the
things
you
hook
together.
This
will
make
the
day
to
go
to
Splunk.
Here's
where
you
find
your
events,
here's
where
you
find
your
fans,
here's
where
you
find
your
logs.
B
I
guess
I'm
I'm,
now
being
on
the
other
side,
being
an
actual
user
like
this
stuff
is
much
more
front
and
center
in
my
head.
Now,
that's
like
you,
you
all
and
I
all.
We
all
need
to
make
sure
we're
thinking
about
people
who
are
not
observability
vendor
Engineers,
because
people
don't
understand
this
stuff
and
we
need
to
make
it
really
easy
for
them.
E
So,
let's,
let's
buy
that
out.
So,
okay
in
the
easiest
scenario,
you
know
the
the
kind
of
the
thing
that
I
guess
would
be
the
most
clear
for
end
users.
E
The
least
ambiguous
would
be
if
there
was
some
sort
of
dedicated
event
API
that
was
distinctly
not
logged,
so
it
was
unambiguous
what
it
was
supposed
to
be
right,
and
then
you
know
when
you
use
that
API
you
can
generate
something
like
an
open,
Telemetry
event
somewhere
in
the
open
Telemetry
data
model
that
backends
can
unambiguously
interpret
as
an
event
so
that
they
can
produce
experiences
that
align
with
the
user's
expectation
of
the
API
it,
and
so
you
know,
I
think
you
know
the
API
and
data
model
then
kind
of
go
hand
in
hand
like
so
you
know
if
you
want
to
have
an
API
that
is
unambiguous
for
the
user
and
helpful
for
the
user.
B
I
absolutely
agree
with
100
of
everything
you
just
said:
okay
I
mean
clearly
the
the
designers
of
open
Telemetry
need
to
understand
both
ends
of
the
of
the
spectrum.
Right
I
mean
absolutely
and
observability
vendors
need
to
understand
both
ends
of
this
thing,
both
the
API
and
how
the
data
gets
transformed
into
something
usable
clearly.
B
E
A
My
my
biggest
problem
with
it
from
a
vendor
perspective
is
that
we'll
have
no
way
to
bucket.
We
have
have
an
event
concept
like
most
other
observability
products,
and
we
display
it
differently
in
different
experiences.
We
display
them
differently
from
logs
because
they
are
different
from
lugs
and
with
this
approach
there
would
be
no
way
for
us
to
identify
and
display
them
different.
B
Yeah,
this
is
something
that
I
had
I
brought
up
very
early
days
when
we
started
talking
about
an
event
API
for
specifically
for
mobile
and
web
for
rum
for
end
user
events.
Right
is
that
the
SDK
needs
probably
needs
a
way
to
distinguish
and
send
these
things
to
different
endpoints,
potentially,
like
the
exporters
like
it's
very
possible,
like
I,
know
for
New
Relic
exam,
for
example,
and
maybe
this
won't
be
true
in
the
future,
but
certainly
was
true.
B
I
don't
know
three
years
ago
that
the
event
API
was
a
different
ingest
of
the
log
API,
and
so
you
would
need
to
be
able
to
separate
those
two
things
in
the
SDK
or
in
a
collector
or
somewhere
somewhere.
You
have
to
be
able
to
separate,
and
do
that
like
this
is
going
to
my
event,
data
source-
and
this
is
going
to
my
log
data
source,
but
it
has
to
be
like
there
has
to
be
a
way
to
do
that
or
we've
got.
C
Yeah,
you
definitely
need
to
send
them
somewhere
else
or
at
least
be
able
to
discriminate
on
ingest,
and
that's
that's
required.
I
think
the
thing
I
keep
coming
back
to
is
that
I
mean
originally,
of
course,
I
thought.
There
was
a
difference
between
logs
and
events,
then
kind
of
kind
of
came
back
around
on
well
nah,
it's
all
just
logs
and
then
I
think
at
the
end
of
the
day,
I've
come
back
around
again,
which
is
they
are
a
different
thing.
C
Historically,
logs
are
just
free
form
text
right
and
maybe
you
have
a
severity
and
a
time
stamp
and
the
rest
is
just
like
whatever
and
that's
what
people
I
think
have
in
their
brain
when
they
think
of
logs
and
events
are
almost
always
key
value
with
a
namespace
or
that
that
identifier,
that
Jack
is
referring
to
so
I
think
that
if
you're,
if
they
are
separate
things
and
and
and
I,
believe
now
that
they
are,
then
it
does
warrant
a
separate
API.
B
E
We
and
we
have
examples
in
in
many
places.
We
have
examples
of
having
apis
that
are
syntactic
sugar.
So
just
you
know
where
the
API
isn't
a
raw
reflection
of
the
data
model.
The
API
reflects
ergonomics
for
the
user,
so
there's
a
record
exception
API.
That
translates
to
an
event
attached
to
the
span.
You
know
you
can
just
tell
users
to
create
a
span
event
with
the
name
exception
and
with
the
attributes
according
to
this
form,
but
we
don't
do
that.
We
have
record
except
option
because
it
improves
the
user
experience.
D
E
B
To
attend
more
of
the
meetings
in
this,
so
I'm
hoping
I
can
grant
it.
Jack
and
Jack
can
translate
my
rants
into
into
the
other
meaningful.
B
Yeah
exactly
I
mean
I
think
that
in
once
you
just
said
somebody
said
ergonomics
are
important.
I
would
say,
ergonomics
are
the
only
thing
if
we
want
users
to
adopt
open
Telemetry,
we
have
to
have
excellent
ergonomics,
otherwise
they're
not
going
to
understand
how
to
use
it
or
what
to
do
even
our
tracing
apis
people
have
a
hard
time
rocking
right
now
and
ergonomically
they're
about
as
simple
as
you
can
get.
If
you
want
to
do
context
propagation,
unfortunately,
and
it's
still
hard
for
people
to
wrap
their
head
around
how
to
use
it.
A
So
speaking
of
ergonomic
and
user
feedback,
so
we
yeah.
B
Last
topic,
so
here's
a
more
user
feedback
from
an
actual
user,
so
I've
been
I,
was
just
spent
some
time
updating
from
1.17
to
1.19,
because
just
didn't
have
didn't
bother
to
go
to
one
to
eight
18..
B
We
and
we
deprecated
things.
I
was
involved
in
the
deprecation
I
approved
PR's
that
did
this
and
then,
when
I
went
to
trying
to
find
The
Replacements,
it
was
very
difficult
for
me
to
figure
out
where
to
find
the
new.
For
example,
the
new
resources
module
like
wherever
the
main
Court
Maven
coordinates
for
that.
B
So
finding
that
was
actually
not
easy
and
also
upgraded.
I
just
worked
on
transforming
grpc
instrumentation
from
open
tracing
to
open
Telemetry
and
finding
the
correct
Maven
coordinates
for
the
grpc.
Instrumentation
was
also
non-trivial,
so
I
think
we
need
to
I.
Don't
have
an
answer
for
this.
This
is
more
just
some
feedback
like
we
need
to
make
it
easier
to
find
native
coordinates,
but.
D
A
B
Yeah,
there's
also
that
part
yes,
I
do
I
had
to
dig
into
the
source
to
figure
out
how
to
use
it,
also
which
wasn't
hard,
but
it
definitely
didn't
look
like
what
I
was
expecting.
It
was
super
easy
to
use
once
I
figured
it
out,
but
it
definitely
didn't
look
like
what
I
was
expecting.
B
Why
are
we
not
using
audio
Transportation
right
now,
because
we
had
manual
open
tracing,
instrumentation
and
I'm,
very
mentally,
converting
converting
over
from
one
to
the
other
I'm
hoping
during
our
hack
week
in
November
to
experiment
with
switching
over
to
Auto
instrumentation
and
to
actually
I
really
want
to
try
the
runtime
attached,
because
it'll
make
it
easier
for
us
to
transparently
not
have
to
change
our
a
whole
bunch
of
configuration
deployment
configuration
so
yeah
I'm
hoping
to
to
start
to
do
this
and
see
whether
it's
good
bad
I'll
probably
have
feedback
on
the
out
of
the
box.
C
B
But
honestly,
also
the
the
big
reason
I
want
to
go
to
auto
instrumentation
is
for
with
span
like
the
rest
of
it,
the
rest
of
it
I'm
like
we,
we
use
grpc,
we
use
some
HTTP
and
we
use
some
databases
like
that.
Stuff
is
pretty
easy
to
just
wire
in
some
manual
instrumentation,
it's
pretty
simple.
B
A
So
John
one
thing
that
I've
started
doing
in
the
instrumentation
release
notes
is
at
the
top
having
a
section
specifically
about
migration.
A
B
B
B
B
One
thing
that
would
have
really
would
have
probably
helped
for
me,
and
this
may
just
be
me:
I
don't
know,
is
we
have
the
deprecated
javadoc
and
it
says
it's
moved
over
to
this
repo.
It
might
be
helpful
to
put
the
maven
coordinates
of
where
it's
moving
in
that
javadoc
on
the
deprecation
like
in
the
deprecation
tag.
Did.
B
B
E
Well,
in
kind
of
taking
a
few
steps
back
about
Maven,
coordinate,
discoverability,
so
I
like
I
added,
the
maven,
coordinates
to
the
readme
of
open,
Telemetry,
Java
and
I.
Think
that's
been
a
good
thing.
I
think
it's
probably
it's
probably
a
bigger
maintenance
burden
for
open
Telemetry,
Java
instrumentation,
because
there's
just
so
many
darn
modules
and
they're
changing
kind
of
at
a
higher
rate,
so
it'd
be
cool
to
do
a
code
gen
thing
for
that,
so
to
generate
the
markdown
tables
programmatically.
So
you
don't
even
have
to
worry
about
it.
B
Anyway,
oh
good,
maybe
maybe
my
issue
is
I,
know
too
much
and
so
I
go
to
the
repo
in
the
instrumentation
directory,
find
the
instrumentation
I
want
click
in
there
and
look
for
a
readme
with
coordinates
and
that's
what
I
was
that's
where
I
didn't.
Maybe
that's
because
I
know
too
much
about
the
way
things
are.
B
A
I,
don't
think
there's
so
many
over
here.
That
I
mean
Auto
generating
would
be
cool
but
I
don't
mind
so.
B
D
D
A
It's
good
feedback.
Thank
you.
I
will
open
an
issue
to
and
correlate
this
information
there
and
I
think
the
low
hanging
fruit
has
probably
just
improving
this
table
of
contents.
D
Yeah
and
there's
like
lots
of
examples
on
how
to
use
that,
because
usually
javadocs
have
some
explanation.
If
not,
then
there
are
tests
that
almost
a
very
instrumentation,
so
it
should
be
yeah
a
lot
of
work
but
doable.
B
D
Yeah
so
I'll
talk
to
Fabricio
I'll,
ask
him
tomorrow
what
he
thinks
about
it
and
yeah
I
hope
he'll
find
some
time
awesome.
D
Well,
Trask,
if
you
have
some
time,
please
have
a
look
at
my
pull
request
for
Java
jmax
insight.
D
If
there
are
any
any
issues
problems,
let
me
know
privately
in
the
slack
Channel
we
can.
We
can
discuss
things
if
necessary,.