►
From YouTube: 2023-02-07 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
D
C
Thanks
so
yes,
so
as
part
of
the
ongoing
HTTP
semantic
convention
stability
group
again,
we
are
targeting
trying
to
have
a
final
recommendation
from
the
group
five
weeks
from
now
so
and
then
there
will
be
a
four
week
period
after
that
for
a
community
to
review.
C
C
So
we've
got
three
issues
I'd
like
to
discuss
today,
bring
to
everybody's
attention
and
get
you
know,
initial
feedback
on
the
call
and
then
follow
up
on
the
issue.
C
So
this
one
came
from
motivated
by
seeing
how
the
elastic
comment
schema,
does
URL
attributes
and
Riley
and
so
not
even
related
to
whether
we
align
with
ECS
or
not.
This
seems
like
something
we
should
consider
and
I
think
from
the
working
group.
We
are
recommending
at
this
point,
which
is
create
a
new
top
level
URL
group,
so
there
would
be
like
url.schem,
url.path,
url.queryurl,
dot
full
and
then
the
different
semantic
conventions
would
reference
those
kind
of
the
way
that
they
reference
today.
C
Net
attributes
that
are
common
across
semantic
conventions
and
so
Riley
kind
of
gives
an
example
of
you
know
why
this
is
important
to
have
a
common
one
instead
of
having
URL
under
many
different
semantic
convention
prefixes,
which
is
where
you
know
you
want
to
say,
report
across
you
know
multiple
things,
multiple
URLs.
C
Otherwise
you
end
up
with
your
HTTP
URL
FTP
URL,
maybe
RCP
URL
messaging
URL,
different
things
making
stuff
up
so
yeah.
We
love
kind
of
you
know
initial
thoughts
from
this
group.
E
Yeah,
that's
that's
a
comment.
I
just
made
so
I
I
think
we
can
discuss
the
specifics
of
the
change
and
whether
they
make
more
sense
than
what
we
have
now.
That's
that's
fine,
but
before
we
do
that,
I
want
to
understand
whether
we're
ready
for
for
this
right
or
for
breaking
the
HTTP
conventions.
I
know
they
are
experimental
right,
but
I
also
know
that
a
lot
of
people
rely
on
this
already.
E
Do
we
think
that
it
is
still
important
to
make
these
changes,
knowing
that
we
will
be
breaking
people
technically,
we're
allowed
right
formally
we're
allowed
to
do
that
personally.
For
me,
I
would
be
reluctant
to
do
this
right
unless
there
is
a
very
good
reason
to
do
that.
So
I'd
like
to
understand
what
this
group
thinks
about
it
do
we
do.
We
think
it
is
important
enough
that
we
break
people
and
and
are
ready
to
face
the
the
possible
consequences.
F
F
Do
we
think
going
after
a
common
convention
where
we
have
kind
of
unified
semantic
convention?
So
if
we
look
at
this
in
relation
to
merging
with
ECS,
which
is
a
discussion
we've
been
having,
if
we
look
at
that
more
Global
issue
like
what's
the
gain
in
making
the
change
versus,
what's
the
cost,
the
cost?
Is
we
churn
a
lot
of
existing
users
of
our
current
instrumentation,
which
has
been
marked
as
unstable?
F
The
gain
is
if
we
gain
more
users
via
conventions
that
work
with
logs
I
think
there's
there's
enough
Merit
in
there
at
approaching
it.
If
the
only
reason
we're
doing
this
is
consistency,
then
I
think
you're,
absolutely
right,
Tigger
and
I
don't
think
churning
everybody
who
uses
our
existing
conventions
is
the
cost.
If
the
gain
is
actually
there's
a
whole
new
set
of
users
and
use
cases
and
out
of
the
box
systems
that
we
can
interact
with
in
our
instrumentation
via
aligning
with
ECS,
then
I
think
it's
worthwhile
to
entertain
it
right.
F
That
doesn't
mean
that
we
should
absolutely
do
it.
It
just
means
I
think
it's
absolutely
worth
the
discussion
in
light
of
that
as
what
we
could
gain.
E
F
Yeah,
so
we
would
have
the
same
attributes
whether
or
not
it's
a
log
or
a
span
or
a
span
event
right,
the
same
attributes,
and
so
when
we
instrument
any
logging
use
case
that
relies
on
instrumentation.
We
would
then
kind
of
automatically
kind
of
support,
so
there's
existing
solutions
that
rely
on
ECS
semantic
conventions.
If
you
will
or
just
elastic
common
schema,
so
we
would
kind
of
gain
those
usages
in
hotel
by
aligning
so
yes,
we
break
our
existing
HTTP
users,
but
we
gain
a
lot
of
like
logging
type
use
cases.
E
G
G
I
think,
in
addition
to
what
George
mentioned
I
see,
other
two
points
number
one
is
ECS
is
more
established,
it's
kind
of
proven
by
the
community
and
you
can
see
from
the
ECS
page.
There
are
many
other
vendors
adults
in
the
same
schema
which
I
I
feel
it
gives
us
better
confidence
about
the
open
climate.
Semantic
convention
has
been
running
for
years
and
nothing's
unstable,
yet
so
I
I
feel
I'm
more
confident
on
GPS
or
anything
that
is
more
established
than
us
trying
to
explore
a
new
thing.
G
The
number
two
thing
is,
as
Charles
mentioned
in
the
example
I
guess.
There
are
many
practical
scenarios
where
I
I
try
to
apply
the
current
open
climate
treatment
commission
and
had
no
idea
how
that
worked.
All
right
look
at
ECS.
It
makes
a
lot
of
sense
to
me
so
My
worry.
Is
they
don't
make
that
change
right
now
going
down
the
path
at
some
point
will
hit
a
like
a
blocker
and
then
we'll
realize.
Oh,
we
really
screwed
up,
let's
just
screw
that
off
and
change
100
of
the
Direction.
G
E
So
I
just
I
just
want
to
be
clear
about
the
consequences
of
what
we
do
here
right.
We
we
make
the
semantic
convention
changes
the
instrumentations
adopt.
These
changes
end
users
who
rely
on
these
instrumentations,
upgrade
to
the
newer
version
of
instrumentation
and
their
Telemetry
now
starts
sending
data
in
a
different
format.
It
will
likely
result
in
this
data
being
no
longer
usable
with
whatever
package
they
are
using.
G
Right,
not
necessarily
the
implementation
can
still
do
some
schema,
translation
and-
and
this
is
one
Crystal
thing
because
schema
will
always
evolve,
because
the
word
is
changing,
but
the
way
how
you
model
has,
even
if
you
define
it
perfectly
at
a
point
of
time
later,
it
will
change.
So
there
must
be
a
way
for
people
to
evolve
and.
G
E
So,
are
we
saying
that
we
will
stick
to
the
changes
which
are
only
possible
to
model
using
the
current
schema
files?
Are
we
going
to
rely
on
schema
declarations
to
do
that?
Job
for
us,
I
would
say
that's
the
case.
Then
we
will
be
constrained
by
what
is
what
we
are
allowing
to
change
right,
because
schema
files
don't
allow
everything
to
be
changed.
There
is
only
a
set
of
possible
changes
that
that
we
can
make.
F
So
we've
already
we've
already
made
changes
to
these
span
names
which
are
outside
the
context
of
the
schema
file.
So
like
to
answer
your
question:
are
we
going
to
limit
ourselves
to
only
things
in
the
schema?
I
think
the
answer
is
already
no.
However,
I
will
caveat
that
I
think
we
will
take
every
effort
we
possibly
can
to
make
sure
the
schema
file
accounts
for
every
possible
change
where
a
change
has
and
again
I
believe.
F
Did
we
discuss
the
Spanish
name
here
last
week,
I
think
I,
don't
know
if
you
remember
that
discussion,
but
basically
we
agreed
that
there
was
a
significant
benefit,
usability
benefit
to
changing
spending,
which
is
why
we
were
willing
to
break
it
without
schema
URL
and
there's
there's
a
contextual
thing
here
right
like
if
we're
going
to
change
something
like
that,
there
needs
to
be
a
significant
benefit
to
doing
so
before
we're
willing
to
do
it,
even
though
things
aren't
marked
stable
yet
right,
we're
not
just
gonna,
go
break
things
so
for
these
kinds
of
changes
that
traffic
is
proposing,
I'd
argue
almost
every
single
one
of
these
attribute
changes.
F
We
should
be
able
to
account
for
in
the
schema
URL
change,
and
that
mitigates
some
of
the
concerns
around
breaking,
because
we
should
be
able
to
have
schema
URL
conversions
in
The
Collector
and
that
sort
of
thing
I'm
not
going
to
say
yes,
that
we're
only
going
to
allow
skinny
oil
changes
because
we've
already
violated
I.
Don't
expect
it
to
happen
again.
But
we
have
already
violated
that
okay,
so.
E
A
A
E
E
E
Okay,
I
wanted
to
raise
this
warning
if
the
entire
open,
Telemetry
Community
thinks
this
is
a
good
idea.
Then
fine,
let's
entertain
that
idea,
but
I'm
not
sure
about
myself.
I.
F
No
no,
this
is
it
there's
going
to
be
an
evaluation
that
occurs.
For
example,
you
know
ECS
the
they
have
this
notion
of
an
orchestrator,
whereas
we
have
a
notion
of
Kate's
I.
Don't
think
it's
worth
us
removing
a
notion
of
Kate's,
because
ECS
uses
orchestrator
I,
don't
think
that's
actually
a
valuable
change,
for
example.
F
So
the
idea
here
is
actually
we
look
at
ECS
and
we
align
and
then
we
do
our
best
to
align
and
make
sure
things
are
consistent,
but
they
don't
have
to
be
exact,
and
so
that's
going
to
be
kind
of
a
discussion
between
us
and
ECS
of
what
that
looks
like.
E
If
it's
not
exact,
then
what
you're
saying
we're
not
going
to
achieve
that
right?
That
correlation
is
not
going
to
work
all
the
time.
F
We're
we're
currently
talking
to
them,
so
there's
a
threat
open
like
I,
talked
to
them
previously
about
six
months
ago
or
so
Riley
reopened.
The
discussion
lately
they're
they're
amenable
and
they
understand
that
changes
will
need
to
occur
and
what
what
this
might
look
like?
F
What
were
my
expectation
is
there
will
be
pieces
of
ECS
that
are
more
malleable
than
others
and
those
are
where,
where
you
can
entertain
changes
and
there
are
pieces
that
are
somewhat
strict
and
somewhat
kind
of
tied
to
various
product
level,
things
that
people
rely
on
from
that
convention,
so
they're
they
are
ahead
of
us
I
think
it
makes
sense
for
us
to
kind
of
adopt
what
they
have
and
kind
of
take
that
in
where
we
kind
of
have
different
Notions.
Or
you
know,
things
have
changed
like
the
example.
F
I
brought
up,
I
think
there's
room
for
negotiation,
but
we're
still
in
active
talks
with
them.
So
it's
still,
you
know
again,
there's
pros
and
cons
here,
I
think
there's
pros
where,
if
we
pull
in
ECS
as
a
a
logging
specification,
that
gives
us
a
lot
of
footing
into
the
logging
world
and
I
think
there's
a
lot
of
compelling
reasons
for
us
to
investigate
it.
F
C
In
the
interest
of
time,
let
me
just
I
want
to
give
another
example.
There
were
two
other
examples
here
of
the
proposed
changes
that
were
initially
motivated
by
well.
This
one
was
motivated
by
ECS,
but
again
it
seems
like
to
me
something
that
would
be
beneficial,
anyways
short
of
the
breakage
issue,
although
in
this
case
we
do
have
schema
translation
support.
C
C
With
four
Fields
here
original
is
the
unpar
string
and
potentially
other
things,
but
we're
we're
not
proposing
to
pull
in
these
other
things
at
this
point,
but
just
aligning.
C
And
then
the
other
this
one,
these
changes,
I
think
are
less
compelling
from,
like
probably
I,
don't
see
any
benefit,
whereas,
like
the
URL
one,
you
know
there
is
a
benefit
of
centralizing
that
having
a
common
URL
fields,
whereas
this
one
is
just
renaming
things
essentially
to
match
ECS.
C
It's
kind
of
nice,
it
you
know,
gives
a
scope
like
okay,
it's
the
request
method,
it's
the
response
status
code
and
some
nesting,
it's
the
request.
Resend
count
so
I
think
they're,
I
kind
of
like
the
proposed
names.
But
again
this
is
I.
Think
just
about
this
is
purely
about
naming
no
structure,
improvements.
C
So
yeah
so
we're
having
very
active
discussions
about
this.
So
please,
you
know,
would
love
to
have
async
discussions
on
these
issues.
Any
comments,
thoughts
you
have
and
we
will
I
think
the
takeaway
Josh
is
that
we
need
to
better
outline
the
benefit
of
alignment.
The
true
for
the
open,
Telemetry
community.
D
Okay,
perfect,
so
in
that
case,
let's
move
to
the
next
item:
a
pair
of
PRS
around
thematic
conventions.
You
hear.
I
Hi,
yes
I'm
here
hi,
so
I
hope
you
can
hear
me
because
I'm
on
my
way-
and
this
is
raining,
can
you
hear
me
well
yeah,
okay,
so
my
name
is
Ada
and
I
have
two
issues:
I
wrote
in
the
agenda?
I
The
first
one
is
about
DB
those
values,
I
think
we
talked
about
it
two
weeks
ago,
I
think,
and
it
is
decided
in
this
issue
to
change
the
name
to
dd.bind,
dot,
values
and
I
wanted
to
know
if
there
are
any
rejections
to
these
names
and
because
I
I
have
one
approval
for
this
and
I
need
one
more
to
to
merge
this
Dr
I
wanted
to
ask.
If
someone
has
the
other
thoughts
about
this
naming.
I
Okay
does.
I
The
bind
word
is
because,
if
the
stuff
that
the
okay,
the
thinking
was
that,
if
we,
if
we
call
it
only
DB
dot
values,
it
is
a
bit
ago
and
you
don't
know
what
is
what
what
is
the
saying
and
we
wanted
to
call
it
bind
values
like
Oracle
and
Microsoft
causes
in
their
databases,
and
so
we
decided
to
call
it
don't
find
those
values,
because
we
wanted
to
treat
it
like
a
namespace,
like
maybe
those
values,
sorry
DB
dot
finds,
will
be
a
namespace
for
all.
I
The
attributes
will
come
in
the
future,
like
maybe
find
values
DB
binds.
Keys
DB
bind
type
this
while
they're
thinking
Beyond
these.
F
Right,
that's
not
what
I'm
asking
so
like
if
I
have
these
are.
These
are
template
parameters
that
you're
providing
right
to
a
template
query.
So
my
question
is,
if
you
know,
there's
two
ways
of
providing
template
parameters.
One
is
like
by
by
index,
and
the
second
one
is
by
name
where
I
say
like
you
know
here
is
here:
is
the
user
field
that
I'm
going
to
fill
out?
F
B
Okay,
I
think
the
idea
would
also
be
that
it's
positional
for
now
with
DB,
bind
values
and
then
later
on,
one
could
add,
DB
bind
keys
and
then
those
two
areas
will
be
like
synchronous
with
the
same
index
and
then
it
would
also
allow
us
for
named
attributes
yeah,
okay,.
D
I
Okay,
so
the
next
issue
is
about
a
full
name
in
metrics
in
metrics
of
databases
we
should.
We
should
also
write
the
name
of
the
pool,
but
in
many
cases
we
don't
have
the
name
of
the
pool.
So
there
was
a
suggestion
to
build
it
to
build
it
by
the
house
for
a
database
and
user.
I
The
thing
is
that
connection
your
the
connection
string
is
not
implemented
in
most
of
the
databases
in
JavaScript,
at
least,
but
still
I
wanted
to
to
ask
you.
What
do
you
think
and
what
should
be
the
goal?
Name
in
case
we?
We
don't
have
a
name
of
the
tool
that
the
user
gave
us
if
we
should
extract
it
or
we
should
use
the
connection
string.
D
D
Just
to
be
clear,
the
good
thing
about
this
PR
is
that
it
already
exist,
so
it's
just
basically
what
to
do
if
it's
not
present,
so
it's
more
of
an
extension
yeah,
so
it
hopefully
sees
here
to
review
foreign.
D
You
not
a
problem.
Yeah
I
was
saying
that
the
the
good
thing
about
this,
the
second
PR,
is
that
it
already
exists.
So
we
are
not
adding
anything
new.
We
are
just
publishing
what
like
a
fallback
case.
D
Perfect,
if
there
are
no
comments,
thank
you
so
much
for
that.
Let's
go
to
the
next
one
can
thank.
I
D
Can
other
tribute
to
specify
unknown
metrics
in
primitive
receiver,
yeah.
J
Desktop
so
I
think
that
we
I
have
been
discussed
with
the
permit
test
work
group,
including
dashboard,
and
also
like
kaushik
and
Anthony
as
well,
and
we
upgraded.
We
can
like
adding
an
attribute
to
specifies
that
in
to
differentiate
between
the
cause
and
unknowns
in
parameters
receiver,
so
because
right
now,
currently
contact
parameters.
Metrics
are
correct
to
Magic
type
gosh.
So
that's
why
we
want
to
add
additional
use
case
by
adding
a
attribute
to
differentiate
between
these
two,
these
two
parameters
type
and
to
identify
some.
J
Some
troll
vaccines
that
to
replace
some
UK.
K
J
Information,
first
is
that,
if
like,
if
any
customers
are
sending
permitters
issues
with
the
with
that
attributes
name,
it
would
not
override
that
attributes
and
also
like
because
the
parameter's
name,
the
parameters
attribute
to
name
that
signal,
the
metric
type
gaussian
metric
type
known,
is
unique
enough,
so
that
it
will
not
be
able
to.
You
know
to
be
utilized
by
adding
other
attributes
to
avoiding
it.
So
yeah.
L
L
That's
not
what
we're
tackling
there's
a
type
in
Prometheus
called
unknown,
which
is
where
you
literally
just
provide
a
point
and
a
time
stamp
and
nothing
else,
and
maybe
some
attributes
I
suppose,
but
these
can
be
in
reality.
These
may
be
counters.
These
may
be
histograms,
so
they
they
may
actually
be
different
types,
but
for
whatever
reason,
the
user
hasn't
included
type
information
and
then
Prometheus
that's
totally
something
you're
allowed
to
do,
although
obviously
including
it's
not
recommended.
L
So
the
question
is
for
us:
how
do
we
handle
this
today?
We
convert
everything
to
a
gauge,
but
that
means
that
in
Prometheus
exporters,
for
example,
we
can't
get
back
the
fact
that
it
was
unknown
and
that
someone
may
want
to
treat
it
as
a
counter
or
something
else.
L
L
We
considered
adding
it
to
the
unit
I
think
that
was
one
suggestion
and
considered
adding
it
to
the
description,
but
we
felt
that
the
the
clearest
way
to
allow
someone
to
use
the
type
information
was
to
add
it
as
an
attribute,
and
only
in
the
case
when
the
metric
has
an
unknown
type.
If
there
is
type
information
which
is
generally
the
case,
we
won't
add
this
particular
attribute
to
metrics.
L
L
Oh
I
I
think
we're
still
working
on
wording
that
I
I
have
to
look
at
it
again,
but
I
asked
for
the
scope
to
be
expanded
slightly
I'd
like
us
to
specify
how
to
reverse
the
change
in
Prometheus
exporters
and
I
think
we
were
working
through
that
and
some
of
the
other
details,
but
I'd
like
attention
on
more
the
general
idea
of
using
an
attribute
which
is
a
data
point
level
field
to
communicate
a
metric
level
piece
of
information
and
whether
people
feel
that
that
is
too
much
of
a
hack
to
be
allowed
or,
if
we'd
rather
make
a
larger
change
like
adding
it
to
the
unit
or
something
like
that
that
maybe
is
a
better
representation
of
that
information.
D
L
L
H
Info
info
we
have
resource
and
other
things
correct,
like
info
info,
is
a
bit
different
in
my
opinion,
for
for
for
for
the
State
I
think
state
is
interesting.
I
always
thought
that
we
may
end
up
supporting
that,
because
it's
it's
kind
of
useful
metric
to
have
I
know
you
can
emulate
that
with
a
with
a
gauge,
but
but
that
may
be
an
interesting
point
to
have
back
to
this
another
option
that
I
thought
is
maybe
add,
because
India
I
mean
what
is
the
difference
between
gauge
and
unknown.
L
Unknown
could
be,
for
example,
a
series
and
a
histogram
like
a
bucket
like
I,
guess.
The
way
it's
meant
to
be
used
isn't
really
clear
like
the
way
you
would
normally
use
a
gauge.
Is
you
would
just
graph
its
current
value?
You
may
want
to
take
a
rate
over
it
like
a
counter,
or
you
may
want
to
right,
like
the
behavior
of
using
it
as
different
I.
Suppose.
H
It
signals
you
something
like
I
I'm
struggling
a
bit
when
you
see
this
in
Prometheus
with
the
server.
H
L
In
Prometheus
I,
don't
actually
think
Prometheus
makes
use
of
type
information
today.
So
if
you
write
prom
ql,
you
write
the
same
statement
regardless
or
you
can
write
the
same,
prompt
ql
statement,
regardless
of
whether
you're
accessing
the
bucket
series
of
a
histogram
or
a
gauge
or
a
counter
right
type.
Information,
no
doesn't
actually
matter
for
Drawing.
The
Line.
A
L
It's
more
of
just
like
some
added
flavor
that
maybe
you
want
to
display
in
your
UI
or
maybe
you
want
to
use
to
help
users.
My
personality
go
Josh
David,.
F
I
think
I
think
it's
important
to
call
out
that
other,
like
people
in
the
Prometheus
ecosystem
that
have
typed
metrics
this
matters
to
them,
because
they
might
need
to
care
what
the
type
of
the
metric
is.
The
fact
that
open
Telemetry
doesn't
have
untyped,
metrics
I
think
has
been
a
benefit
to
all
of
us,
because
we
have
clear
identity
on
the
type
and
I
think
that's
one
area
that
Prometheus
is
trying
to
fix
with
forcing
types
with
open.
F
Metrics
is
to
make
sure
that
that
you
know
the
the
behavior
between
a
typed
data
store
and
an
untyped
data
store.
It
becomes
better,
it
doesn't
affect
Prometheus
itself,
but
it
does
affect
kind
of
the
ecosystem
of
which
we're
apart.
H
L
Yeah
I,
don't
think
I
think
supporting
an
unknown
type
would
be
the
best
possible
solution
to
this
problem.
I,
don't
think
it
would
make
things
worse.
It
just
means
that.
H
Yeah,
it
kind
of
make
things
worse
because
we
carry
forward
this
problem
like
if,
if
you
see
open
Telemetry
as
being
the
next
gen
or
future
of
these,
we
are
carrying
forward
this
problem.
So
that's
that's
where
I
feel
like
we
are.
We
are
making
the
problem
worse
because
we
we
we
carry
it
to
the
next
level.
Maybe.
H
Okay,
maybe
maybe
we
do
it
as
a
transport,
only
untie
this
unknown
thing
and
yeah
we
just
we
should
probably
do
that.
I
I,
think
it's
and,
and
the
type
will
be
number
in
this
case
or
the
type
can
be
anything
so
so
is
the
sorry.
The
value
of
this
thing
is:
is
this
number
only?
Can
it
be
string,
for
example,.
L
Think
keeping
it
as
a
number
works
for
Prometheus
I
I'd
be
curious
if
there
are
any
other
systems
that
have
a
notion
of
a
metric
without
a
type.
H
H
Yeah,
okay,
now
look
up
that
and
if
we
see
if
we
see
any
any
other
unknown,
we
may
want
to
to
come
up
with
the
most
generic
one
that
supports
them.
Okay,
perfect,
so
I
I
think
it's
fine
to
to
go
with
that
proposal.
I
personally,
I,
like
it
I
think
it's
the
most
nicer
to
the
community
in
a
way
that
we
we
support
better
Prometheus.
Now
there
is
still
the
discussion
David
about
state
which
we
may
want
to
have
the
stateful.
The
state
metric.
H
And
there
is
an
enum
metric
as
well
in
Prometheus
which
I
I
remember.
These
are
kind
of
useful
compared
with
the
info
info.
For
me,
it's
more
or
less
the
our
resource
I
may
be
wrong,
and
people
probably
will
start
using
it
differently
than
that,
but
I
would
not
try
to
encourage
something
else
in
our
system.
For
the
moment.
H
H
I'm,
brainstorming
again
I'm,
not
saying
that
this
is
very
well
thought
so
I'm
just
saying
what
I
I
have
in
my
mind
now,
no,
it
seems
cool,
think
about
it.
I
mean
you.
You
come
up
with
a
proposal.
I
think
these
are
kind
of
my
ideas
about
this
I'm
I'm,
supporting
of
all
of
them,
I
kind
of
like
that
idea
of
subtype
on
gauge.
Maybe
it's
it's!
It
reduces
the
the
surface
of
the
API
a
bit,
but
but
may
not
be
the
the
clear
Rose
one.
K
D
But
for
the
sake
of
time,
can
we
move
to
the
next
item?
We
still
have
a
few
items
and.
D
Perfect
yeah,
looking
forward
to
that
the
progress
from
the
other
one
and
yeah
actually
David,
when
you
feel
like
satisfied
with
this
PR,
please,
you
know
approve
that
so
that
signals
everybody
that
you're
happy
with
this
and
then
other
people
can
review
that
sweet.
D
D
If
there's
no
comment
on
that,
the
next
one
is
is
mine.
Basically,
this
is
about
adding
links.
After
spam
creation,
I
pointed
there
to
Niche
one
to
a
PR.
D
This
is
something
we
discussed
many
times
and
I
work
just
wanted
to
resurrect
that
in
the
messaging
group
we
have
been
discussing
more
bringing
that
up
like
resurrecting
this,
because
it's
coming
often-
and
some
people
have
been
asking
about
this-
like
people
specifically
writing
instrumentation,
so
I
just
wanted
to
resurrect
that,
and
just
basically
warn
people
that
we
will
be
creating
a
PR.
There
was
one
by
Johannes
which
was
closed
because
there
was
no
activity
on
there.
D
You
know
on
the
front
yeah
I
don't
want
to
ask
to
take
the
the
remaining
13
minutes,
because
there
are
still
things
to
you
know
there,
but
basically
the
summary
is
that
one
of
the
main
arguments
against
this
was
how
sampling
would
interact
with
this.
D
Then
again
we
have
attributes
that
are
added
at
the
start
span
time
and
only
for
sampling.
So
we
could
have
the
same
for
links
if
we
just
say
that
we
will
ignore
them.
After
and
just
put,
a
big
warning
probably
will
be
helpful.
D
Some
people
in
this
community
think
that
it
could
be
good
to
have
this
otherwise
we'll
end
up
with
fake
or
dummy
in
response.
Just
because
you
know
you
cannot
do
this,
so
you
will
do
that
later.
D
There
was
aforementioned
about
the
fact
that
when
you
have
these
asynchronous
scenarios,
you
have
any
messaging
there's
no
direct.
You
know
a
relationship
like
child
of
relationship
and
probably
we
should
have
something
to
Signal
decent
links,
which
would
be
totally
fine.
D
This
in
case,
for
example,
when
you
are
pushing
a
message
to
broker
and
it's
there
and
it
can
be
there
forever
and
then
at
some
point
in
the
future,
a
consumer
will
come
and
fetch
that
message
from
there
from
the
broker.
So
there's
no
like
direct
child
of
relationship.
This
could
be
model
with
links,
probably
needs
extra
information
to
signal
that
this
is
No
Child
of
relationship.
That
could
be
fine.
We
can
add
that
yeah.
That's
basically,
what
I
wanted
to
say
any
comments
on
that
front.
D
Okay,
I
I,
think
there's.
There
are
no
comments
and,
as
I
said
before,
the
the
previous
PR
got
closed
because
of
lack
of
activity.
I
think
we
we
had
started
getting
some
agreement
in
general,
so
yeah.
Please
take
a
look
at
that
and,
as
I
said
before,
this
is
has
been
very
important
for
the
messaging
working
group
and
more
users
have
been
coming
specifically
writing
instrumentation
for
Lambda
and
for
sqs
at
least.
D
Okay,
based
on
the
fact
that
there's
no
feedback
on
that
one
for
now,
let's
go
to
the
next
items:
okay,
Asaf!
Please.
K
K
K
Thank
you
David
for
a
clarifying
A
lot
of
things,
but
I
guess
the
main
question
I
have
is
that,
as
you
mentioned
David
that
you
were
missing
the
explanation
about
considering
reset,
because
the
idea
here
is
that
you
said
what
happens
if
that
attributes
after
you
removed
an
attribute
set
and
and
suddenly
we're
back
reporting
for
that
attribute
set
and
by
the
user,
what
would
the
start
time
should
be
and
I
I
guess
I
Tried
reading
the
two
links
that
are
relevant
here,
the
async
cumulative
guidelines
and
the
other
ones
about
the
gaps
and
resets
I
have
to
admit
I.
K
Read
it
twice
and
I
didn't
understand
it
fully.
I
guess
there
are
like
hidden
contexts
in
there.
That
is
simply
not
mentioned,
and
so
I
would
love.
If
you
can
like
explain
briefly
why
we
couldn't
just
place
the
start
time
to
be
now
as
if
it
was
a
completely
new
attribute,
because
everything
was
explicit,
I
removed
the
attribute
set
explicitly
and
after
X
amount
of
time,
I've
decided
to
do
it
again
and
resume
reporting
the
measurement.
L
Actually
I
think
you're
correct.
There.
I
was
thinking
of
async
instruments.
I
I
haven't
read
your
comment
yet,
but
I
can
respond.
There.
F
That's
I
think
the
important
thing
there
is
if
you
want
to
reset
the
timeline
to
be
now
when
the
measurement
comes
in,
it
means
that
we
actually
need
to
track
start
time
in
that
fashion.
Not
all
if
you
look
at
how
sdks
are
tracking
start
time,
it's
not
guaranteed
that
that's
how
they're
going
to
track
start
time.
F
I
think
a
lot
of
them
are
using
process
start
time
for
some
of
the
metrics,
so
there's
actually
a
a
flavor
of
start
time,
tracking
that
this
will
require
where
before
it
was
kind
of
implicit,
and
so
you
could
get
away
with
a
few
things
around
start
time
previously
that
this
will
kind
of
force
us
to
directly
track
when
measurements
come
in
and
so
I
think
it's
you
need
to.
You
know
we
need
to
call
it
so
reset
and
GAP
guidelines
are
basically,
if
you
restart
the
stream.
F
So
that's
actually
probably
the
most
important
part
of
your
suggestion
here
is.
We
need
to
add
that
tracking,
on
the
ad
events,
in
addition
to
adding
remove
events,
does
that
make
sense.
K
I
need
to
be
very
clear
in
The
Proposal
about
that.
Okay,
so
who?
Who
do
you
recommend?
I
can
talk
to
or
read
somewhere
to
gain
the
the
missing
context
that
I
have
in
that
reset
and
GAP
guidelines,
because
I
failed
to
understand
it
fully.
Unfortunately,.
A
F
F
Terms
of
of
walking
you
through
this
I
think
if
you
I
know
that
you're
targeting
Java
so
actually
talking.
D
F
I
think
talking
to
Jack
Berg
around
this
would
actually
be
another
really
good
option.
I'm
happy
to
help
too,
but
I
think
those
two
will
be
more
valuable
to
you
same
as
same
with
David.
It
depends
on
what
which
language
you're
trying
to
Target
and
then,
if
you're,
targeting
the
specification,
you
have
to
make
sure
that
you're
applying
it
to
all
possible
languages
so
but
I
think
Jack
would
be
a
good
person
to
talk
to
David's.
G
G
K
Chat,
yeah,
okay,
I
will
take
the
link;
okay
thanks,
okay,
so
the
second
topic
is
this
suggestion.
Sorry,
this
question
that
I
had
I'll
try
to
explain
it
briefly.
K
K
It's
the
current
approach
is
giving
you
essentially
a
collection
and
the
approach
it,
and
that
proposing
is
doing
it
more
in
a
I
would
say
in
a
streaming
fashion,
and
the
main
point
is
is
to
read
to
flatten
the
memory
that
is
required
from
an
open,
Telemetry
SDK,
specifically
the
Java
SDK,
because
if
you
have
a
lot,
a
very
large
amount
of
attributes
and
instruments,
then
the
memory
allocated
for
it
on
each
collection
can
be
very
intrusive,
especially
for
latency
sensitive
systems.
K
So
essentially
it's
like
a
XML
versus
a
dome
versus
socks
if
you're
familiar
with
the
XML
parsing.
So
it's
the
basic
the
main
idea:
you
get
simply
a
callback,
and
this
is
the
way
you
get
the
data
you
you
get
the
same
data,
but
simply
in
a
different
way,
and
so
what
I
asked
here
was
if,
if
I
can,
if
that
change,
Falls
within
the
spec,
so
can
this
change
be
made
in
specifically
the
Java
SDK
with?
K
Does
it
conform
with
the
spec
I
got
one,
and
thank
you
Riley
right,
so
it
gave
me
a
really
a
good
response,
and
but
I
I
don't
understand,
I,
don't
know
the
process.
How
to
continue
like
how
many
people
do
I
need
to
gain
a
yes
for
that
before
I
can
continue.
If
somebody
can
help
me
with
that.
F
So
yeah
the
I'll,
add
I'll,
add
two
things:
one
is
the
process:
Riley
actually
was
the
one
who
documented
the
process
for
how
do
I
get
my
spec
merged
it's
in
the
contributing.md
one
thing
bringing
it
to
the
here
to
kind
of
talk
through
and
understand
that
the
palatability
and
the
community
around
it
is
important
if
you
need
kind
of
sponsorship
and
understanding
for
the
implications
with
the
spec
I
think
that's
important
to
know.
One
thing:
I
I
want
to
call
out
with
this
particular
change.
F
The
more
I
thought
about
it,
I
like
what
you're
trying
to
do,
but
it
really
targets
an
otlp
exporter.
If
you
think
about
our
export
or
specification
now,
though,
it's
about
going
to
several
different
formats,
so
otlp
is
one,
but
we
also
allow
you
to
say
go
to
out
Prometheus
exporter
style.
We
allow
you
to
go
out.
You
know
to
specific
vendors,
for
example.
So,
like
the
targeting
of
a
sax
like
you
know,
writing
might
not
be
ideal
for
some
of
those
other
scenarios.
So
a
Second
Avenue
to
investigate
that
might
be
implementable.
F
Today,
in
Java
is
actually
re-implement
the
data
classes
in
Java
and
if
they
are
not
exposed
as
pure
interfaces,
I
think
that's
a
discussion
we
can
have,
but
you
might
be
able
to
re-implement
the
the
entire
data
class
hierarchy
so
that,
instead
of
it,
you
know
storing
the
memory
itself
when
you
call
a
method
on
it,
it
actually
does
the
reflection
and
kind
of
looks
at
wherever
your
met
your
data
stored
originally,
which
would
achieve
the
same
result.
F
We
can
talk
about
that
more
specifically,
if
you
want
kind
of
offline,
but
I
would
I
would
suggest
that
might
be
a
way
to
get
around
the
issue
today
in
terms
of
creating
like
metrics
data,
so
that
it's
not
stored
in
the
current
memory
format,
that's
provided
by
default
from
the
SDK,
but
still
be
able
to
access
it
in
a
way
that
exporters
look
at.
The
second
thing
you
know
know.
The
first
thing
I
should
say
is:
if
you
want
to
do
this
as
a
spec
change
right.
K
F
Okay,
if
you
want
to
do
it
as
a
like
Java
specific
kind
of
extension,
then
I
think
we
go
going
to
the
Java
Sig
and
kind
of
discussing
what's
palpable
there
and
how
to
make
that
happen.
We
can
go
through
like
technological
details
in
that
sick,
I.
K
Mean
the
the
question
actually
was
triggered
by
a
request
from
Jack
to
bring
it
to
to
make
sure
that
the
Sig
here
says
it's
conforms
with
the
spec
before
trying
to
implement,
because
the
idea
was
that
it's
okay,
let's
try
it,
but
before
you
try,
it
just
make
sure
that
it
confirms
the
spec
I
think
it
is,
but
Riley
think
it
is.
But
I
I
wanted
to
understand.
If
I
need
more
people
to
say
it
is
or
it
isn't.
A
H
Think
it
it
is
confirming
with
the
spec
in
a
way
that
it's
exposing
access
to
the
data,
but
but
it's
a
bit
it's
a
bit
harder
to
use
than
others.
To
be
honest,
it's
it
is
more
performant.
K
M
Let's,
let's
talk
offline
I've
recently
made
a
bunch
of
changes
that
dramatically
reduce
the
memory
allocation
and
I
I.
Think
and
I
have
one
additional
prototype:
that's
unmerged
that
could
get
it
down
to
like
a
98
reduction
and
I
guess.
I
I
want
to
hear
your
thoughts
on
that
and
and
figure
out
kind
of
what
what
is
a
tolerable
amount
of
memory
allocation
for
your
use
case?
Maybe
we
can
get
that
with
with
the
current
interface
design,
so.
H
Dark,
okay,
Jack,
I,
think
I.
Think
the
answer
from
this
kind
of
request
will
be
zero,
so
I
I,
don't
I,
don't
think
you'll
ever
please
that
with
the
interface,
if
if
they
really
believe
that
iterator,
which
is
zero
allocation,
almost
would
help
them.
K
Don't
you
think,
and
just
general
quick
question:
don't
you
think
that
in
in
a
memory,
memory,
sensitive
system
or
latency,
sensitive
system,
I
guess
again,
Apache
pulsory,
just
one
but
I?
Guess
if
you
want
to
make
it
like
in
a
standard
type,
would
be
everybody
will
adopt
it.
Many
many
systems,
including
even
mobile
devices,
do
they
think
that
the
the
goal
of
such
sdks
would
be
to
promote
that
I
mean
that
the
memory
footprint
implementation
would
be
almost
zero.
M
I
have
this
prototype
and
I
I
did
some
analysis
on
it
and
the
only
memory
that's
being
allocated
at
this
point
and
if
this
prototype
were
to
be
merged,
is
in
the
iterator
itself,
and
you
can't
really
get
around
that.
So
it's
like
pretty
close
to
zero.
If
like,
if
we
were
to
go
with
this
prototype,
you
know
if
you
want
to
iterate
through
data,
you
have
to
use
some
memory
like
iterating
through
a
map
iterating
through
a
list
that
that
causes
allocations
itself.
So
you
can't
get
to
zero.
H
Not
not
really
Joy
Jack.
There
are
wigs
Works
around.
If
you
already
have
these
objects
created
somewhere
that
you
updated
them,
you
don't
necessarily
need
to
expose
them
as
a
different
object,
the
iterators
themselves,
but
but
you,
if
you
don't
use
iterator,
you
use
some
like
Range
Loop
thing
that
you
pass
along
that
then
you
don't
like
if
you
pass
a
Lambda
to
to
to
to
a
class,
and
you
pass
the
objects
to
that
Lambda,
you
don't
need
to
create
the
the
iterator.
H
M
Okay,
well,
let's,
let's
take
a
look,
you
know:
I
I
ran
this
through
with
a
like
a
sample
app
that
had
a
million
unique
Series
in
it,
and
it
was
only
allocating
I
think,
like
30
megabytes
or
something
like
that
on
each
collection.
It
depends
on
which
type
of
instrument
you're
using
too.
So
it's
getting
kind
of
low
I.
Think
if
you're
using.
If
you
have
an
SDK
that
has
millions
and
millions
of
series
you
have
to
accept
some
amount
of
memory
allocation.
K
The
current
implementation
that
we
have
currently
in
in
Apache
poll
sound
is
zero
allocations,
because
we
simply
read
the
data
from
memory
and
write
it
straight
to
to
the
output
essentially
or
right.
So
we
don't
allocate
anything
we
it's
it's
equivalent
to
again.
As
I
said,
you
have
many
Lambda
or
a
callback
functions,
and
you
just
use
one
data
transfer
object,
which
is
simply
references,
the
other
things
that
you
already
have
in
memory.
That's
I
think
the
basic
idea.
K
Okay,
so
I
would
I
I
would
contact
you
on
slack.
I
would
really
love
to
to
talk
to
you
about.
It
sounds
good.
Okay,
thanks.
K
That's
that's
it
for
my
side,.