►
From YouTube: 2022-05-10 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
let's
start
thank
you,
everybody
for
joining.
Okay,
let's
go
over
the
agenda
items,
so
the
first
item
is
I
put
that
that
myself
and
it's
about
metric
semantic
conventions.
There
is
a
pr
there.
I
can
quickly
share.
My
screen
show
what's
happening.
A
Basically,
it's
adding
four
metrics.
As
you
can
see,
say,
requests
connections,
accepted
connections,
handle
connections
current
and
there
was
a
good
call
out
by
tyler
about
abstracting
them.
A
B
Nginx
is
in
pretty
deep
in
the
process
of
integrating
open
telemetry
into
it.
I
don't
think
this
contributor
works
at
nginx.
It
might
be
wise
to
give
them
a
heads
up
and
make
sure
we
aren't
defining
something
here
that
they
haven't
already
defined
natively
within
nginx.
A
Yeah,
that's
a
good
call
this
one.
Actually,
this
is
just
reflecting
the
existing
there's,
an
existing
receiver
in
the
call
you
know
in
the
collector
country,
repo-
and
this
is
just
bringing
those
metrics.
So
it's
so
yeah.
So
on
that
front,
that's
interesting!
I
didn't
know
that
they
were
working
to
instrument
this
by
themselves.
I
wonder:
what's
the
path
forward
there
we
can
probably
discuss.
We
can
just
touch
base
with
them.
Yeah.
B
I
I
know
I
know
some
of
the
people
at
internets
I'll,
send
them
an
email
pointing
them
to
this
this
thread
and
asking
for
their
their
input.
A
Sounds
good
other
than
that,
as
as
I
was
mentioning
before,
I
think
that
we
should
try
to
abstract
things
that
are
similar
enough.
Like
requests,
let's
say
that
we
forget
about
this,
but
still
this
question
stays
around
yeah.
I
think
that
for
other
components
like
kafka,
it's
very
it's
very
straightforward,
like
partitions
the
notion
of
very
specific
stuff,
but
a
lot
of
things
I
think
we
can
try
to
share.
But
what
I'm
trying
to
say
is
that
there
will
be
times
when
items
like
connections
handles
which
don't
have
a
representative
thing
in
others.
A
C
Yeah,
I'm
thinking
about
it.
Sorry,
I
didn't
respond
yesterday.
It
was
out,
but
yeah
I
mean
this
is
something
I
think
that
we've
talked
a
little
bit
about
before
as
well.
C
The
connections,
one,
I
think,
is
a
good
call
out
for
just
how
we
want
to
handle
metrics
like,
and
I
think,
in
tracing
having
spans,
you
know
very
specifically
targeted
is
useful,
but
like
the
connections,
one
like
all
three
of
these,
the
first
thing
that
comes
to
my
mind
is
that
they
should
probably
be
a
single
metric
and
then
have
labels
associated
with
accepted
handles
and
current.
C
The
other
thing
that
kind
of
stands
out
is
like
there's,
this
question
mark
for
environment
proxy,
for
the
handled
connections
and
it
kind
of
says,
like
are
our
semantic
conventions
defined.
I
think
this
is
probably
where
we're
going
in
the
next
topic,
but
like
are
they
defined
in
a
way
where
you
have
to
provide
those?
Or
is
it
something
that
if
you
provide
them,
they
should
be
named
in
an
appropriate
way,
and
I
think
it's
the
latter
so
like
if
envoy
and
a
proxy
don't
have
the
concept
of
connections
handled?
C
I
don't
think
that
they
need
to
provide
it.
I
think
it's
just
something
that
you
know
it
can
be
blank
and-
and
I
think
the
other
ones
where
there
is
a
common-
you
know
scheme
or
a
common
semantic
for
for
something
that
like
they
do
provide.
I
think
we
should
try
to
unify
it
or
a
common
term.
So
I
like
this
approach.
I
would
break
down
the
connections
a
little
further,
but
I
don't
think
that
it
not
having
a
common
representation
in
each
one
of
the
languages,
necessarily
a
problem.
A
Yeah,
like
optional
one
interesting
thing
is
what
would
happen
if,
for
example,
boy
actually
had
a
connections
handle
metric,
but
it's
semantically
different,
because
you
know
whatever
should
we?
What
should
we
do?
I
mean
I
am.
I
guess
I'm
trying
to
say
that
there
may
be
cases
where
the
semantics
may
be
a
little
bit
different,
even
though
they
have
the
same
name.
C
Yeah-
and
I
think,
if
that's
important,
that
we
need
to
make
it
clear
that
our
semantic
conventions
are
meaningful
enough,
that
if
there
is
a
similarly
named
thing,
but
it
has
different
semantic
meaning
it
should
not
be
overloaded
and
used
with
that
different
semantic,
meaning.
I
think
that
it
is.
It
is
critical
that,
like,
if
handled
I,
don't
I'm
sorry
it's
early
in
the
morning,
I
don't
know
if
another
interpretation
of
handle
would
be
but
like
say,
there's
another
interpretation
of
handles
it
shouldn't
be
used.
C
If
that's
the
case,
so
I
would
read
it
yeah.
A
Make
sense
anybody
else
has
an
opinion.
You
know
that
we
can
continue
the
discussion
there
and,
first
of
all,.
D
While
we're
on
this
topic,
just
things
that
are
going
through
my
mind
as
I'm
trying
to
figure
out
the
best
way
to
represent
this,
is
that
I
feel
like
there
are.
Maybe
three
approaches
that
we
could
probably
take.
One
is
that
you
could
have
semantic
conventions
per
per
proxy
and
that's
kind
of
what
the
original
approach
was.
D
The
second
would
be
to
kind
of
introduce
like
a
kind
of
proxy
namespace,
where
we
try
to
kind
of
have
generic
and
kind
of
define
what
potentially
proxies
could
produce
for
for
metrics
there
or.
Thirdly,
you
could
try
to
kind
of
like
fall
back
to
something
even
more
generic.
Just
like
you
know,
network
semantics
and
I
feel
like
yeah,
just
trying
to
figure
out
how
this
would
actually
be
used
from
the
user
perspective,
because
I
think,
there's
always
like
a
more
generic
representation.
D
D
The
way
that
you
want
it
and
is
is
that
what
we
want
for
the
end
user
in
some
of
these
situations,
are
those
roll-ups
convenient
or
are
those
roll-ups
kind
of
inconvenient,
and
are
you
going
to
have
to
kind
of
group
by
three
or
four
labels,
just
to
kind
of
forget,
like
the
engine
x,
requests
and
separate
those
out
from
many
of
the
other
requests
that
could
be
rolling
up
under
something
more
similar?
If
that
makes
any
sense.
C
So
matt,
if
I
understand
you
correctly,
you're
saying
like
if
two
proxies
are
running
side
by
side
of
different
flavor
and
they're,
going
to
the
same
end
point.
How
do
you
distinguish
between
the
two.
D
Yeah,
as
as
we
apply
an
abstraction
either
like
a
proxy
namespace
or
a
network
namespace,
I
think,
depending
on
how
detailed
you
are
with
your
labels,
your
query,
like
those
could
be
like
a
a
roll
up
of
sorts.
C
Yeah,
I
can
see
that
I
can
also
see
annotating
these
metrics
with
the
the
proxy
origin
source
so
having
nginx
or
a
proxy
or
envoy
being
a
a
label
that
we
that
we
include
here.
That
needs
to
be
annotated
similar
to
what
we
do
like
databases
or
something
like
that.
D
Yeah,
I
think
if
we
want
this
route,
you
would
definitely
want
the
the
source
as
a
label.
C
But
I
also
think
that,
like
the
the
worry
of
too
generalized
is,
is,
I
think,
a
good
thing
because
maybe
not
necessarily
stated
like
that.
But
just
the
idea
is,
you
know,
at
the
end
of
the
day,
the
the
operator
who's
running
this
code
and
who's.
Looking
at
this
in
some
sort
of
ui,
they
really
don't
care.
C
If
it's
a
proxy
with
envoy,
nginx
or
a
proxy,
they
they
want
their
service
to
run
right,
and
so
I
think
we
need
to
make
sure
that,
like
keep
that
in
mind
that,
like
what
these
need
to
produce
are
things
that,
like
communicate
to
the
user,
that
things
are
running
and
they're
running
in
a
you
know
a
way
that
they
they
want
them
to
run
so
like
having.
C
You
know,
I
think
three
different
metrics
for
each
one
of
these
back
ends
is
not
that's
not
going
to
achieve
that
right,
like
they're,
going
to
have
to
have
some
sort
of
domain
knowledge
for
each
one,
but
having
something
that
says
like
you
know,
okay,
the
request
counts
getting
way
too
high
or
the
connections
accepted
is
not.
You
know
rising
at
the
same
rate
that
the
the
connections
handled-
that's
those
are
critical
things
that
they
need
to
be
going
and
taking
a
look
at.
C
D
C
I
I
don't
have
a
strong
opinion.
I
think
it
needs
to
be
more
general
than
a
web
framework,
or
you
know
some
sort
of
like
code
proxy
sounds
good.
Server
also
is,
is
related
rolling
up
to
a
network
level.
I
think
it
could
make
sense,
but
I
mean
these
metrics
don't
necessarily
relate
on.
You
know
the
metric
or
the
network
level
I
mean.
Maybe
they
do
you
know,
because
you
could
have
a
router
with
very
similar.
So
I
don't
know.
A
B
Yeah,
you
have
to
think
about
how
a
proxy
is
different
from
an
http
client
and
an
http
server
glued
together.
You
know
I
do
want
to
call
it
one
other
thing
I
think
tyler
mentioned
in
here
around.
We
should
maybe
also
be
careful
of
cherry
picking
conventions
like,
for
example,
system,
network
connections.
B
That
might
be
semantically
correct
in
terms
of
the
meaning
of
that.
But
do
we
want
to
be
do
we
want
to
think
about
something
like
this
system
network
namespace
as
like
a
coherent
block
of
information
coming
from
a
particular
source,
and
should
we
be
wary
about
about
cherry
picking
from
like
here
and
there
from
different
conventions
to
construct
something
like
a
a
proxy
name,
space.
B
And
I
don't
have
a
strict
answer
to
that.
I
do
know
that,
like
I
think
some
of
our
conventions,
you
know
it's
somewhat
expected
that
that
you're
sending
that
whole
block
of
instrumentation
some
of
them
are
optional,
but
some
of
them
are
required
and
it's
expected
to
represent
a
certain
kind
of
source.
A
But,
for
example,
if
you
are
instrumenting
with
a
collector
and
you
have
like-
let's
let's
say
in
an
envoy
receiver,
that
is,
you
know,
get
generative
metrics
from
an
envoy
and
you
have
requests
and
or
or
something
that
also
or
io.
You
know
bytes
going
out
or
coming
in
and
then
you
are
also
doing
the
system
metrics.
A
E
I
I
start
to
see
a
problem
here
as
some
of
the
concepts,
for
example
the
concurrent
connections
or
like
the
memory
usage,
whether
it's
a
system
or
process.
There
should
be
many
common
description,
like
the
the
guidance
liquid
people,
for
example.
In
this
case,
you
must
use
a
counter
instead
of
a
gauge
or
something,
and
do
we
intend
to
duplicate
that
in
like
10
different
places,
or
maybe
we
should
just
have
one
place
and
then
having
all
other
places,
pointing
to
the
same
place,
which
makes
it
easier
to
update
the
document.
A
A
E
Yeah,
I
understand,
and
by
the
way,
why
would
we
have
this
hotel.http
prefix
like
what's
the
actual
value,
that
old
health
dot
is
added.
C
Yeah,
that's
a
good
question
riley.
I
I
think
there's
value
in
distinguishing
metrics
that
come
from,
or
I
guess,
metric
constructions
that
come
from
something
that
is
defined
by
otel
rather
than
something
say
like
what
ted
was
talking
about
earlier,
where
nginx
defines
it
directly.
I
don't
know
if
having
the
hotel.
Prefix
really
is
useful,
though
you
could
just
say
the
default.
Prefix
of
nothing
is
hotel
and
then,
if.
C
F
G
Yeah,
I'm
here
hi
yeah,
so
the
first
thing
I
want
to
discuss.
We
sorry
we
had
a
conversation
with
stigran,
but
he's
not
here
about
what
their
required
attributes
should
go
with,
must
or
should
yeah.
Thank
you
for
opening
it.
So
was
this
pr,
I'm
trying
to
define
more
stricter
requirement
levels
and
just
provide
the
terminology,
so
it
seems
the
conversation
there
is
around
that.
G
We
are
not
sure
that
when
we
write
semantic
conventions
that
every
implementation
of
every
instrumentation
will
be
able
to
follow
must
requirement
and
for
in
order
to
work
with
this
we
have
to
use,
should
I
would
not
still
agree
with
it.
If
we
look
into
existing
semantic
conventions,
the
things
that
are
required,
we
are
quite
sure
that
they
can
be
provided,
for
example,
the
http
method
right
or
url
their
partner
of
rfc,
and
if
some
http
client
doesn't
have
notion
of
it,
then
it's
not
an
http
instrumentation
right.
G
H
Hi,
let
me
know
I
I
do
agree
with
your
motivation
for
for
this,
but
I
think,
based
on
the
rfc,
where
masters
should
are
defined,
I
think
must
is.
If
I'm
not
mistaken,
must
means
with
no
exception
you
should
you
you
have
to
have.
That
thing
should
is
if
there
is
an
edge
case,
you
can
avoid
having
that
thing,
but
otherwise
you
sh,
you
must
have
that
thing
based
on
that
description
on
and
that
understanding,
I
think,
should
makes
more
sense,
but
I
may
be
mistaken
and
understanding
the
the
two
definitions
in
the
rfc.
G
So
there
is
well,
we
have
also
a
conditional
conditionally
required
attributes
defined.
So
if
semantic
conventions
octors
envision
that
there
will
be
a
condition,
there
is
a
condition
they
should
put
it
in
the
conditional
attribute.
Sorry,
a
conditional
level,
it
just
makes
them
work
more
and
they
can
initially
put
everything
into
conditional.
H
Correct
I
understand
that,
but
now
now,
let's
imagine
there
is
a
framework,
let's
assume
http,
and
there
is
a
one
http
framework
where
one
of
the
required
fields
is
not
present,
for
whatever
reason
does
that
mean
that
they
will
never
be?
It
means
that
they
will
never
be
hotel,
compliant,
correct.
G
Right
yeah
and
they
they
can
totally
be
non-compliant.
Imagine
then
we
put
here
and
they
will
be
auto
compliant.
Then
somebody
who
visualizes
this
http
request.
It
will
visualize
it
incorrectly
because
they
assume
the
attribute
is
there
and
they
can't
work
without
it
right
they
use
it
to
detect.
For
example,
that's
an
http
instrumentation.
I
H
Understand
now
your
motivation
and
I
understand
how
how
you
are
coming.
Maybe
the
names
conditional
in
my
opinion
is
not
the
best.
Maybe
we
can
add
a
different
term
for
the
conditional,
because
I
think
conditional
was
not,
in
my
opinion,
was
not
as
suggestive
as
you
explained
to
me
and
as
kind
of
the
default,
the
default
master
or
whatever
it
is
called
and
what
is
really
required.
H
H
H
G
G
But
yet
there
are
a
few
places
where
we
say
it's
required
without
any
conditions,
and
maybe
I
can
yeah,
I
can
go
through
them
and
see
how
critical
they
are,
for
example,
that
I
don't
know
the
db
dot
system
is
required
and
it's
fine,
because
every
db
system
should
be
able
to
know
what
it
is
and
I'll
see
if
there
are
complicated
cases
and
I'll
send
prs
to
address
them
and
switch
to
conditional.
First.
G
H
We
I
mean
personally,
that's
a
personal
opinion.
Probably
I
will
start
with
all
of
them
being
conditional
and
then
upgrade
them
one
by
one,
but
we
can
do
your
opposite
as
you
suggested.
It's
fine!
Okay
for
me.
For
me,
these
are
the
the
feedback
that
I
have.
I
think
now
I
understand
better.
I
would
write
my
my
feedback
in
the
in
the
pr
within
the
naming
part
for
conditional
and
and
yeah.
That's
it.
F
Yeah
one
thing
worth
mentioning
is
that
having
some
at
least
somewhat
strongly
must
defined,
attribute
per
convention
like
db
system
for
everything,
dp
db
will
also
help
for
the
problem
to
identify
the
kind
of
convention
by
the
presence
of
attributes.
I
think
tigran
drafted
something
there,
but
then,
but
then
converted
it
back
to
a
draft,
but
that
relied
on
on
something
like
in
order
to
be
able
to
tell
that
this
is
a
database
call.
F
F
A
A
G
Yeah,
so
this
pr
is
where
we
do
more
substantial
change
to
remove
multiple
supported,
attribute
sets
for
http,
and
I
think
I
had
a
question
to
josh
stewart
who
said
it's
breaking
but
he's
not
here,
so
we'll
take
it
offline
with
him.
So
what
happened
here
thanks
to
riley?
I
also
updated
http
metrics
to
be
consistent
with
what
we
have
here
and
what
I'm
asking
is
more
reviews.
A
G
Yeah
it's
somewhere.
I
think
one
of
the
last
comments
I'll
take
it
offline
with
him
and
now
see
he's
blocking
on
his
feedback.
B
And
just
to
reiterate
it,
it
would
be
great
if
we
could
get
this
slipped
into
the
next
release
of
the
specification.
B
In
other
words,
if
you
could,
hopefully,
if
this
thing's
about
to
get
get
finished,
make
sure
we
don't
release
the
spec
a
version
of
the
spec
before
putting
this
in
or
like
right,
I
think.
A
But
actually
I
wonder
if
we
should
start
playing
in
a
very
informal
fashion
with
the
github
project
that
you
mentioned.
Remember
the
boards
like
having
that
we
want
this.
Like
informally,
you
say
this
one
like.
I
can't,
for
example,
co2
json
being
another.
You
know
important
item,
for
example.
Anyway,
we.
A
A
Okay,
let's
talk
about
that
offline,
maybe
okay!
Next
one
santosh
request
for
review
log,
api,
spec
or
tipdraft.
Are
you
here
yeah.
K
Yeah,
I
just
wanted
to
bring
it
to
folks
attention
here
that
I'm
working
on
this
apis,
I
mean
specification
for
an
events.
Api
based
on
the
log
record
data
model.
A
Could
you
summarize
for
people
who
are
not
familiar
with
this?
What
this
is
about.
K
Sure
so
this
is
mainly
intended.
I
mean
at
this
point
initially
intended
for
use
with
the
client-side
telemetry
for
the
browser
and
mobile
application
instrumentations.
They,
you
know
they.
There
is
a
requirement
to.
K
You
know,
emit
events
based
on
the
log
record,
and
there
is
currently
no
standard
api
for
that
and
for
the
we
have
agreed
to
use
the
log
signal.
But
the
log
signal
you
know
doesn't
have
a
standard
api
that
could
be
used
for
the
purpose
of
creating
events,
and
you
know
I
was.
It
was
recommended
that
we
don't
create
a
another
logging
api,
but
restrict
the
api
only
for
the
purpose
of
events,
but
use
the
lock
record
as
the
underlying
data
model.
K
So
this
is
essentially
the
it's.
It
takes
the
same
log
emitter,
sdk
and
I
have
I
have
created
an
api.
You
know
out
of
that
following
the
log
emitter
sdk
and
some
taking
a
few
things
from
the
you
know,
the
traces
trace
apis.
K
There
are
a
couple
of
open
questions
that
I
have
towards
the
end.
I
I
don't
know
if
we
have
time
here
in
this
call,
I
can
go
over
it,
but
otherwise,
if
people
have
any
questions,
we
can
discuss.
K
Yeah
and
the
lock4j
actually
does
support
events,
but
the
problem
is
log4j
is
not
commonly
used
in
android
application
development
and
the
the
initial
use
case
for
for
this
api
is
to
use
in
in
the
client-side
instrumentation
the
in
the
in
the
mobile
apps
and
the
browser
apps.
So
for
android
it.
You
know,
I
don't
think
people
commonly
use
lock4j
and
the
android's
native
logging
api.
You
know
that
doesn't
support
events.
L
So
we've
talked
about
this
in
the
java
sig
and
our
take
is
that
an
event?
Api
would
be
a
good
idea.
So
we
don't
want
to
recreate
reinvent
the
wheel
with
another
application.
Log,
api,
log4j,
logback
and
java
utility
logging
already
do
a
good
job
at
those,
but
they
are
awkward
to
use
in
an
event-driven
manner.
L
And-
and
so
we
think
that
you
know
having
a
dedicated
event.
Api
would
be
a
good
idea.
E
That's
it
so,
I
imagine
on
the
mobile
device,
there
are
lower
level
events
that
you
want
to
get
from,
maybe
like
the
the
android
runtime
or
even
like
the
lower
c
plus
level
or
even
the
operating
system
level.
Events
like
I
know
in
microsoft,
we
do
have
like
minutes
of
device
driver
events,
and
do
we
envision
that
those
lower
level
components
will
eventually
take
dependency
on
open,
parametry
events,
api
and,
if
that's
the
case,
what's
the
position
between
this
event,
api
versus
a
general
logging
api.
L
So
the
difference
that
we
see
between
an
event,
api
and
a
log
api
is
that
is
kind
of
the
nature
of
the
shape
of
the
data
you're
collecting.
So
events
and
logs
use
the
same
data
structure
in
otlp,
so
they're
the
same
on
transport,
but
they
they
have
slightly
different
shapes,
so
application
logs
are
typically
comprised
of
a
severity
and
a
message,
and
then
you
know
sometimes
they
have
a
bag
of
attributes
and
they
they
have
a
time
stamp
as
well.
L
Events
are
not
characterized
by
having
a
severity,
so
events
have
a
type,
some
sort
of
classification
and
and
structured
attributes.
That's
that's
the
nature
of
their
shape,
and
so
you
know,
if
you're
doing
things
that
you
know
are
shaped
like
application
logs,
where
they
have
a
severity
and
a
string
message.
L
E
K
Actually,
the
in
in
future,
you
know
this.
This
api
could
be
extended
for
for
logging,
use
cases
too.
It's
it's
not
meant
to
be.
L
Needed
so
like
my
thoughts
on
that,
you
know
just
to
go
back
to
what
you
were
saying:
riley,
what
what
happens
if
an
event
wants
a
severity
associated
with
it
so
severity
in
the
log
data
model
is
a
top-level
field,
and
so
you
know
it
depends
on
how
we
shape
an
events
api.
So
you
know
one
rendition
of
an
events.
L
Api
might
only
have
the
name
of
the
event
and
a
set
of
attributes
as
the
as
the
inputs,
and
in
that
scenario
there
wouldn't
be
a
good
way
to
add
severity,
and
so
you
know,
maybe
maybe
that
is
a
distinguishing
feature
between
events
and
logs.
Maybe
we
say
that,
like
you
know,
events
do
not
have
a
severity.
L
E
I
I
can't
see
a
potential
turn
like
people
started
by
putting
some
like
events
and
eventually
to
realize.
Oh,
like
I
thought
it's
all
coming
from
device
driver,
it's
they're
just
events,
but
later
I
realized
that
certain
events
would
trigger
the
operating
system
to
fail
like
just
to
crash
or
something
so
I'd
rather
put
critical
or
something
there.
And
then
I
have
to
follow
the
model
and
and
reinstrument
all
the
events
by
using
other
logging
apis.
L
Yeah,
so
that's
something
we
should
consider
when
designing
an
event
api
is
that
type
of
eventuality.
So
what
was
I
going
to
say?
So?
E
Package,
so
it
seems
from
from
my
position,
I
I
think
the
pr
is
almost
ready,
but
there
are
two
experts.
I
I
remember.
One
from
dynasty
is
another
one
I
can't
remember
like
they.
They
gave
some
suggestions
on
how
to
handle
the
corner
cases
specifically
how
to
handle
positive
infinite
and
not
a
number
and,
and
that
part
I
I
haven't
seen
any
update
from
gmacd,
so
so
maybe
like
we
can
follow,
follow
up
offline
but
in
case,
like.
J
J
That
pr,
a
week
and
a
half
ago,
just
adding
a
sentence
to
address
the
concern
that
those
two
had
had
given.
So
I
was
actually
just
waiting
and
I
feel
that
those
are
resolved.
The
the
statement
that
we
have
made
in
the
pr
is
that,
because
exponential
histograms
need
to
look
at
the
actual
value
that
infinite
infinite
and
not
a
number
values,
do
not
map
into
buckets.
J
J
This
is
taking
a
slightly
harder
line
for
exponential
histograms
than
any
of
the
other
data
types,
because
we
can
because
there's
because
in
exponential
boundaries
you
cannot
describe
infinity
and
not
a
number
is
a
non-starter
as
well.
So
I'm
comfortable
with
the
answer
there.
If
you
do
get
another
number
or
infinite,
what
is
it
it's
an
error
or
warning
just
like
any
other
condition
in
open
toiletry.
E
I
I
agree
so
so
my
my
worry
with
this
pr
is
when
I
look
at
those
two
experts
they
they
are
the
ones
who
really
understand
like
this
algorithm.
There
are
the
guys
who
initially
proposed
this.
I
try
to
pin
them
and
see
if
we
can
get
their
sign
off.
Currently
we
don't.
J
I
actually
think
they're
done
paying
attention.
We
finished
this
protocol
last
last
fall
and
the
statements
here
are
actually
just
talking
about
the
sdk
handling
of
the
data
type
that
that
they
helped
to
standardize,
and
these
are
sdk
behaviors
in
the
corner
cases
that
I
don't
think
they
care
about.
To
be
honest,.
E
Okay,
so
so
how
about
we
do
this
so
I'll
ping
them
again
on
the
pr
and
by
clarifying
like
if
they
don't
block
this
pr.
We
treat
it
as
they
implicitly
approved
and
emerged
by
another
week.
L
C
L
K
Also,
I
think
ted
you
might
want
to
add
further.
There
is
a
belief
that
eventually,
the
events
in
spans
will
be
deprecated,
and
you
know
the
separate
event
records
will
be
favored,
so
yeah.
B
Yeah
yeah
we
want
to
at
minimum
define
a
translation,
a
one-to-one
translation
between
span
events
and
logs
that
have
span
context
attached
to
them.
Essentially,
we
we
have
two
ways
of
recording
the
same
information.
B
Now
there
might
be
practical
reasons
why
a
telemetry
stream
wants
to
attach
logs
that
have
a
span
context
in
in
one
place
or
another
or
both
just
given
the
fact
they
may
be
teeing
off
to
multiple
systems
that
only
support
one
kind
of
data,
but
I
think
this
is
the
only
place
we've
hit
so
far
where
we
have
like
a
literal
duplication
in
in
our
data
model.
So
we
just
want
to
make
sure
that
it's
clear
how
you
record
the
same
information
in
both
places.
C
B
B
B
B
Yes,
the
the
key
thing
there
was
making
sure
we
have
a
clearly
defined
name
field,
name
attribute
that
that's
the
only
special
thing
that
that
span
events
have
that
that
logs,
don't
is,
is
their
named
events
beyond
that
there
aren't
there
isn't
anything.
It's
just
a
bag
of
attributes.
C
B
Well,
for
backwards
compatibility
reasons,
we're
never
gonna
get
rid
of
span
events
from
our
data
model.
What
we
do
have
in
our
logging
model
is
there's
a
explicit
data
structure
called
a
span
context,
so
any
log
that's
emitted
when
a
span
is
active,
should
automatically
get
the
span
context
attached
to
it.
So
it's
it's
equivalent
but
yeah
for,
but
for
backwards
compatibility
reasons.
B
We
don't
want
to
eliminate
this
other
older
span
event
data
structure
and
then
also
because
you
still
have
you
know
existing
or
legacy
systems
that
are
just
a
tracing
system
or
just
a
logging
system.
There's
going
to
be
a
need.
You
know
at
some
point
in
the
telemetry
pipeline
for
for
some
operators
to
to
shove
all
the
data
into
one
data
structure
or
another,
depending
on
what
kind
of
data
the
back
end
actually
accepts.
J
J
J
B
Yeah,
I
mean,
I
think
there
is
a
subtle
thing
in
there,
which
is
you're
like
what,
if
someone
is
recording
some
events
using
the
span
events
api,
but
they've
they've
installed
a
no
op
tracing
system.
I
I
think
in
that
edge
case
they
would
not
be
recording
events
that
were
installed.
That
way.
I
think.
F
J
F
J
B
And
there's
also
no
just
to
also
really
hammer
the
point
out:
there's
no
difference
between
logs
and
events
in
our
data
model.
It's
just
really
like
some
people
like
what
is
the
big
difference
between
logs
and
events
and
from
open,
telemetry
standpoint.
All
we've
settled
on
is:
if
it
has
a
name,
then
it's
an
event.
B
So
if
it
has
a
name,
the
same
way
spans
have
names
where
you're
saying
this,
this
log
should
be
should
have
this
primary
index
called
a
name
that
you're
going
to
use
to
automatically
compare
them
across.
Then
that's
that's
what
we're
calling
an
event,
and
that's
really
the
the
only
thing
we
we
mean
by
something
being
an
event.
As
far
as
our
data
model
is
concerned,
it
also
may
not
have
some
of
the
optional
attributes
that
you
would
expect
on
a
log
like
severity
level
and
stuff
like
that.
K
So
my
understanding
was
a
little
different,
so
I
used
to
think
that
you
know
if,
if,
if
users
want
the
events
to
go
based
on
the
log
record
data
model,
they
have
to
use
the
the
new
events
api
if
they
continue
to
use
the
trace
api
for
recording
events
and
if
tracing
is
turned
off,
then
you
know
those
events
won't
be
recorded.
So,
but
there
is
no,
you
know
case
where
the
trace
apis
event
methods
you
know,
would
create
log
records.
B
No,
we
we
can
do
that.
It's
it's
straightforward
to
have
span
events
be
recorded
as
logs
I
mean
this
is
a
thing
people
do
today.
They
translate
spam
events
into
logs,
but
in
order
to
do
that,
you
need
to
install
like
a
span
processor,
for
example,
that
that
puts
it
into
the
the
logging
system.
B
So
it
just
wouldn't
that's
totally
fine
if
you've
installed
something
it's
just
if
you
install
literally
nothing
as
a
trace
provider,
so
it's
a
no
op,
then
there's
not
gonna
be
a
place
for
the
logging
system
to
intercept
any
of
those,
and
we
should
probably
once
we
have
this
baked
in
as,
like
you
know,
a
default
part
of
once
logging
becomes
a
default
part
of
the
the
sdk.
We
have
a
logging
provider.
B
We
do
want
to
make
sure
when
people
do
kind
of
like
a
stock,
install
of
open
telemetry
that
that
this
is
easy
to
do
like
it's.
Not
it's
not
some
complicated
setup.
They
have
to
do
if
they
want
those
span.
Events
recorded
as
logs
so
so
there'll
be
a
little
bit
of
work
there,
but
but
conceptually
it's
not
it's
not
difficult.
K
And
and
what
what
was
your
sorry,
I
missed
that.
What
was
your
response
to
josh's
concern
about
you
know
being
careful
about?
If,
if
let's
say
tracing
is
turned
off,
then
would
the
trace
api's
events
be
turned.
B
Off
as
well
or
not
just
that,
you
would
have
to
install
something
like
you
could
install.
You
could
install
a
a
log
like
a
log
tracer
or
something
something
that
if
you're
saying
like
I,
I
literally
don't
care
to
admit
tracing
data.
I
just
want
to
capture
these
these
events.
In
my
logging
system.
B
You
you
would
you
would
have
to
install
something
that
did
that
if
you
literally
installed
no
trace
provider
and
it's
a
no
op,
I
don't
think
we
want
to
complicate
how
the
no
ops
work
to
say
that
no
ops
sometimes
do
something
other
than
drop
the
date
on
the
floor.
But
but
I
don't
think
that's
like
hard
for
for
application
owners
to
do.
You
know
they
just
have
to
intentionally
state.
They
want
this
information
captured
in
the
logging
system.
J
Another
outcome
that
might
happen
is
it
if
you
start
logging
your
spam
events
as
simple
log
events,
you
could
also
log
your
span
start
and
your
span
end
as
simple
events
like
we
might
even
be
able
to
come
up
with
semantic
conventions
to
correlate
or.
F
J
B
M
B
We
something
that
comes
up
in
these
spec
discussions
from
time
to
time
is
we
we
encounter
some
new
concept
and
we
start
saying:
oh,
you
know,
a
zero
duration
span
would
would
cover
this
concept
well,
and
I
think,
having
done
that
several
times,
we've
kind
of
learned
that
the
zero
duration
span
is
like
a
bit
of
a
smell
when
we
start
thinking
about
that
thing,
and
that's
part
of
the
driver
for
having
an
official
events
concept,
because
that
that
seems
to
be
something
that's
a
little
more
what
we
what
we
want,
we
might
come
up
with
other
things
in
the
future,
but
I
just
want
to
call
that
out
that
so
far,
every
time
we've
we've
come
across,
we
started
proposing
a
zero
duration
span.
J
But
just
to
add
to
that
sentiment
ted,
I
think
another
option
in
the
future
for
open
telemetry
users
with
spam
instrumentation
is
to
turn
off
spans
and
turn
on
histogram
measurements.
So
that's
the
case
where
you
don't
want
the
events
you
just
want
span
timing.
You
don't
need
to
record
a
span
to
record
timing,
in
fact,
much
more
efficient
to
record
histograms.
F
E
Will
you
clarify
josh
when
you
mention
burn
off
the
trace,
just
use
histogram
to
mean
the
context
propagation.
Those
things
would
be
stopped.
So
it's
just
a
timing
thing.
J
J
E
J
Well,
things
are
already
complicated
when
you
begin
sampling
independently
at
each
node,
so
it
would
look
a
lot
like
an
unsampled
span
if
you
were
to,
for
example,
emit
a
histogram
timing
which
would
which
would
create
an
incomplete
trace
and
there's
a
lot
of
discussion
about
incomplete
traces
in
the
sampling
documents.
B
But
just
the
overhead
of
propagating
generating
and
propagating
trace
context
will
be
something
that
is
just
acceptable
for
most
systems
to
be
doing,
regardless
of
what
else
they're
doing
and
the
value
of
it
being
there
for
will
probably
for,
for
almost
all
systems
will
outweigh
the
the
cost
of
of
generating
it.
B
Maybe
I'm
wrong
about
that,
but
I
I'm
suspicious
that
that
is
going
to
turn
into
just
a
constant
cost
that
that
people
are
willing
to
pay,
but
but
it
is
nice
with
open
telemetry
that
it's
it's
well
organized
enough
that
that
people
we
should
be
able
to
provide
flexibility
on
that
front.
You
know
for
for
the
edge
cases
where
that
cost
really
is
too
much.
A
We
are
on
time,
but
let's
continue
with
this
offline.
Let's
have
notes
by
the
way
the
things
we
discussed
there
and
open
an
issue.
Please,
okay,
thank
you!
So
much
everybody
stay
safe,
talk
to
you
online
bye.