►
From YouTube: 2021-07-27 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).
C
C
D
Of
us,
could
I
put
this
list
of
three
open
pr's
at
the
top
for
the
spec
reviewers
to
consider
these
are
important
for
the
metrics
project,
but
I
think
are
important
enough
that
they
should
be
reviewed
by
anyone
with
an
interest
in
open
telemetry.
D
D
The
third
is
the
result
of
a
lengthy
discussion
and
debate
and
design
iteration
on
histograms,
and
it
is
roughly
speaking
exactly
the
protocol
that
the
prometheus
group
wanted,
and
we
are.
We
have
it
up
for
review
now.
Please
take
a
look
at
those.
B
Yeah,
so
the
I
would
say
that
the
first
two
that
have
been
open
for
a
while.
We
actually
had
lengthy
discussions
in
the
sig.
I
think
there's
some
commentary
that
maybe
possibly
wasn't
discussed
in
the
sig
due
to
like
vacations
and
things
that
if
we
have
a
chance
to
hash
out
here,
that's
that's
totally
acceptable
but
yeah.
So
all
three
of
these
have
had
lengthy
discussion.
The
third
one
has
had
the
most
and,
if
you
haven't
read
it,
I
highly
recommend
it's.
B
It's
enlightening
to
see
the
the
design
space
of
this
new.
D
Thank
you.
I
hadn't
intended
to
have
a
technical
discussion
here
about
any
of
them,
but
it's
just
that
they
need
more
attention
and
please
review
if
you
feel
able
to.
E
Yeah
josh,
just
to
if
I
just
let
you
know
I
have
actually
there
is
an
internal
discussion,
that's
ongoing
on
the
histograms
and
also
I've
been
working
with
the
cloudwatch
team
to
also
you
know,
submit
the
proposal,
as
we
had
discussed
on
on
compatibility,
so
we'll
be
also
commenting
on
this.
E
D
I,
in
in
before
I
put
up
that
pr.
There
was
an
issue
number
1776
that
I
called
the
referendum
on
histogram
formats
and
it's
lengthy
enough
that
I
think
it
should
close.
It
did
produce
quite
a
lot
of
discussion,
but
it
did
mostly
produce
discussion
from
the
same
people
who
had
contributed
the
original
design.
So
there's
more
to
read
on
that
thread,
and
when
I
came
to
the
end
of
this
sort
of
design,
I
finally
decided
that
I
had
probably
been
incorrect.
D
At
the
end
of
that
discussion,
I
no
longer
felt
that
was
true.
I
feel
that
the
the
trouble
of
handling
more
than
one
histogram
is
relatively
minor,
considered
with
the
trouble
of
forcing
everyone
in
the
world
to
use
your
one
histogram,
and
so
I
am
definitely.
I
personally
am
open
to
a
third
histogram
option
that
captures
log
linear
histograms.
If
everyone
else
is,
it
would
be
able
to
carry
an
open,
histogram
or
an
hdr
histogram
very
nicely.
So
we'll
see
if
there's
enough
interest
in
in
that,
I
think
that
can
move
forward
independently.
D
It
may
or
may
not
go,
and
then
the
histogram
that
we've
settled
on
is
just
a
simple
exponential
histogram,
and
I
think
that
we
should
approve
that,
no
matter
what
given
the
research
and
study
that
was
done
in
prometheus.
C
D
C
Yeah
before
we
move
on
on
before
we
move
on
on,
I
have
a
small
question.
I
see
that
two
of
these
mentioned
prs
have
already
reviews
the
instagram
one
needs
more
review
for
sure,
but
the
other
two
ones
have
three
reviews
each.
So
it's
looking
good.
What
are
we
exactly
waiting?
Are
we
waiting
simply
more
reviews.
B
There's
an
open,
an
open
comment
that
was
not
resolved
from
a
cc
member,
so
I
I'm
what
for
one
of
them?
I
know
I'm
having
a
discussion
later
today
on
that
to
try
to
see
if
we
can
get
that
resolved,
but
we
we're
not
in
the
habit
of
submitting
prs
that
have
open
questions
that
are
unresolved,
so
they
quite
I
I'm
fine.
Actually,
if
we
say
you
know
what
like
we
have
enough
approval,
we
can
merge
it,
but
that's
why
they're
not
merged
today.
B
So
I'm
not
sure
exactly
what
the
process
is
here
around
those
open
questions,
but
I'd
like
to
try
to
at
least
get,
if
not
consensus,
someone
to
agree
that
it's
okay
to
merge
if
they
have
concerns
yeah.
D
C
D
Right
this
will
be
me
as
well
and
I'll
try
to
make
it
quick.
So
I
have
two
two
documents
open.
This
is
part
of
the
sampling
conversation
there's
a
whole
other
part
of
the
conversation,
that's
about.
How
do
you
set
up
these
configurations
for
sampling
and
so
on,
especially
the
jager
remote
work?
This
is
just
about
how
we
encode
and
transmit
probability
information
when
we
are
sampling.
D
I
am
nervous
that
otep148
here
is
maybe
longer
than
its
own.
Then
it's
good
own
good.
D
I,
it
ended
up
being
a
repository
for
all
sorts
of
background
information
that
I
feel
is
helpful
sometimes,
but
is
probably
turning
people
away
from
the
document
at
this
point,
so
I'm
not
sure
whether
I
should
open
a
new
copy
of
that
or
just
delete
some
stuff
and
move
my
text,
I
don't
know
it
doesn't
matter
where
it
moves,
but
somewhere
since
we
had,
since
I've
recorded
some
of
the
things
that
dapper
did
as
as
part
of
discovery
here.
D
So
148
is
mostly
ready
for
either
people
to
review
or
to
start
over
again,
but
the
very
end
of
that
document
does
propose
a
small
amount
of
specification
text
for
two
span:
attributes
one
would
be
the
sampler
name
and
one
would
be
the
sampler
adjusted
count
and
if
you
agree
with
those
two
attributes,
I
think
you
should
approve
this
otep
and
then
we
can
move
that
into
the
spec.
That
is
a
way
for
both
head
and
tail
sampling
information
to
be
encoded.
It
doesn't
restrict
you
to
powers
of
two
or
anything
like
that.
D
It's
just
you
know
you
can
put
the
effective
count
into
your
span,
so
if
you've
already
seen
otep148
open
it
again
and
scroll
to
the
end
and
look
at
the
proposed
text.
That's
what
we're
trying
to
approve
at
this
point
or
tell
me
that
I
need
to
open
a
new
pr
because
no
one's
looking
at
it.
The
second
one
of
these
otep
168,
is
new
and
still
open
needs.
More
discussion
needs
more
input.
This
is
probably
too
too
image,
not
mature
enough
for
the
abroad
audience.
D
But
if
you
care
about
the
details
of
propagating
head
sampling
probability
or
you
care
about
the
w3c
trace
context,
format
trace
parent
trace
date,
stuff,
like
that
it's
worth
reading,
because
we
are
proposing
to
change
the
w3c
trace
context
to
solve
this
problem.
I
think
that's
all
I
have
on
this
topic.
Thank
you
all
is
that
possible.
F
D
Change
w3c
yeah,
or
does
it
work?
Well,
that's
that's
the
question
and
and
that's
what
this
document
will
will
discuss.
So
there
are
roughly
seeking
two
aspects
of
this
proposal
at
the
moment
that
are
still
being
hashed
out
one
is,
I
was
proposing
that
we
propagate
probability
in
order
to
do
parent
sampling
and
know
the
probabilities
in
the
same
thread.
Atmar
at
dynatrace
has
proposed
that
we
propagate
a
random
number
to
facilitate
the
trace
id
ratio
sampler.
D
So
there
are
kind
of
two
conversations
happening
here.
Both
involve
updating,
w3c
trace
context,
but
one
of
them
is
to
fix
parent
sample,
or
one
of
them
is
to
fix,
trace
id
sampler.
The
one
about
trace
id
sampler
is
a
little
bit
trickier
and
and
a
lot
harder
to
reason
about.
As
far
as
I
can
tell,
but
and
also
is
an
area
where
the
question
comes
up,
why
don't
we
just
put
randomness
into
our
choice
id?
That
is
a
topic
for
the
broader
conversation
for
the
community.
D
Here
is,
if
you
can
put
randomness
in
your
choice,
id
there's
really
no
reason
to
put
another
random
number
together,
and
so
there's
some
debate
about
that
as
well
yeah,
but
my
vendor
relationship
here.
We
really
want
to
fix
the
parent
sampler
so
that
you
can
just
say:
follow
your
parents
guidance
and
use
their
probability
and
that's
what
we're
looking
for,
which
is
what's
in
168
and
as
you
see
there
are
some
other
ideas
present.
G
A
D
A
reason
so
that
part
of
the
reason
I
came
up
with
this
proposal
after
reading
all
the
input
was
that
you
know
the
cost
of
this
is
going
to
be,
admittedly,
not
zero
and
we're
asking
the
group
to
make
some
changes
to
facilitate,
essentially
interoperability
of
tracing.
If
we
force
this
to
be
a
trace
state
with
otel
as
our
as
our
key
we're
saying,
this
is
just
an
hotel
thing
and
it's
optional
as
soon
as
it's
optional.
It
doesn't
do
any
good
for
us.
D
So
if
it
was
mandatory
in
the
trace
state,
that's
fine,
but
then
it
costs
like
9
or
10
bytes
per
request,
because
the
the
format
of
trace
data
you
have
these
text
keys
and
you've
got
to
put
a
sub
key
and
so
on.
So
the
proposal
I
have
is
three
bytes
per
request
unconditionally
and
then
there's
no
more.
It's
it's
easier
that
way.
D
A
Yeah,
so
I
think
that's
that
it's
just
to
be
clear.
I
think
it's
worthwhile,
just
having
like
bogdan
having
been
through
a
lot
of
w3c
stuff
around
this,
that's
gonna,
be
it's
gonna
be
slog.
So
if
this
is
a
thing
that
we
want,
you
know
like
in
2022,
we
can
start
by
having
it
in
trace
state
and
then
prove
it
out
there
and
move
it
up.
A
D
So
you
can
imagine
compatibility
with
like
either
you
use
the
version,
one
w3c,
which
includes
three
bytes
to
convey
sampling
stuff
or
you
use
the
10
or
16
byte
version
that
uses
trace
date
and
it's
considered
optional
as
a
transition,
maybe
yeah
that
doesn't
sound
great.
But
it's
practical,
yeah.
A
I
actually
have
one
question
by
the
way
I
do
think
we
need
more
eyes
on
these
sampling
proposals.
Josh
has
done
a
lot
of
good
work
here,
but
there's
a
lot
of
ramifications.
A
I
think
for
adding
a
probabilistic
sampling
like
this
to
open
telemetry,
and
it
would
be
great
if
we
could
get
more
expertise
looking
at
this
stuff.
I
think
part
of
the
reason
why
people
haven't
been
looking
at.
It
is
maybe
a
little
bit
like
scared
or
feel
like
we
don't
have
the
the
right
background
to
evaluate
this
stuff,
but
I
do
think,
if
that's
the
case,
we
need
to
to
find
some
more
experts
to
kind
of
help.
Otep148.
D
Was
my
effort
to
at
least
kind
of
document
the
background
here
and
that's
why
it
got
so
long?
And
then
you
know
we
found
ourselves
earlier
having
this
discussion
of.
Why
aren't
using
the
dapper
inflationary
tracing
like
approach
and
the
answer
is
nobody's
ever
documented,
the
dapper
inflationary
tracing
sampling
approach,
so
there's
a
bunch
of
information
to
try
and
help
bring
you
up
to
a
basic
understanding
of
sampling.
I'm
not
sure
it's
successful,
but
that's
what
it
was
there
for
and
so
maybe
consider
a
read
through
148.
B
B
The
sampling
bit
yes
in
terms
of
it's
better,
just
to
not
use
it
than
even
touch
it,
because
it
leads
to
hell.
I'm
just
curious
if
other
vendors
have
experienced
this
or
not.
D
B
G
B
B
That
is
not,
would
you
like
it
to
be?
We
would
like
it
to
be
kind
of
zero.
Do
whatever
the
hell
you
feel
like,
or
one.
D
So
you
should
definitely
check
in
on
168,
because
I'm
running
into
the
same
question
is
that
like
omar
made
a
proposal
and
there's
still
no
way
for
me
to
say
just
please
sample
this,
I'm
not
telling
you
the
probability.
I'm
just
asking
you
to
sample
this,
and
we
need
to
keep
that
facility
as
well
and.
B
Well,
what
I'm
suggesting
is,
I
actually
kind
of
want
to
go
into
specifically
that
bit
anyway,
so
I'm
going
to
I,
I
I'll
read
the
the
pr's
and
follow
up
with
you
later.
D
I
agree
that
it's
inflexible
we
are,
I
was
at
the
end
of
yesterday.
I
was
still
thinking
about
omar's
proposal
and
I
came
to
the
conclusion
that
to
do
what
he's
asked,
we
need
another
bit
anyway.
There's
another
bit
to
say
probability,
sampling
is
different
from
just
is
sampled
and
it
might
include
extra
bytes
of
information,
but
I've.
This
is
a
super
fresh
conversation.
I
haven't
thought
through
at
all.
G
The
other
thing
josh
surred
is
there
was
a
discussion
about
delayed
bit
and
we
said
that
if
we
really
need
that
we
can
add,
we
can
use
another
beat
from
the
flags.
Let's
say
the
second
to
the
to
the
left
to
the
right.
Sorry,
because
that's
what
we
use
being
indian
anyway,
it
doesn't
matter
so
we
use
the
other
beat
to
to
say
delay,
and
I
think
you
have
that
problem
in
a
in
a
load.
G
Balancer
situation,
that's
that's
where,
where
the
most
common
problem
is
because
if
you
have
the
load
balancer
as
the
first
entry
into
your
system,
you
want
to
delay
that
that
decision
for
the
application
to
tell
you
what
to
do
is
that
where
you
have
the
problem,
that's.
B
That's
a
portion
of
the
problem.
Yes,
that's
that
yeah,
that's
in
the
right
area,
yeah,
that's
one
of
the
set
of
problems.
There's
two
problems
to
it.
That's
one
of
them!
Yes,.
A
Yeah,
I
will
say
more
time
was
spent
discussing
that
sampling
bit
than
like
the
rest
of
the
spec
collectively
when
it
came
to
making
that
it
seemed
like
an
incredibly
challenging
area
to
to
find
something.
A
D
C
D
A
I
think
the
direction
you're
proposing
is
is
the
beginning
of
like
some
standardization
in
the
area
of
sampling,
which
I
think
is
helpful
part
just
to
be
clear
that
the
sampling
bit
is
difficult
to
deal
with
when
it
is
set
by
someone
outside
your
trust
boundary
where
it's
been
set
by
potentially
another
tracing
system
or
just
in
general.
Well,.
D
It's
also
that
you
don't
problematic,
that's
where
you
have
it.
When
you
have
a
load
issue,
you
just
can't
honor
the
sampling
decision
and
that's
why,
like?
What
we're
seeing
right
now
is,
is
a
tug
of
war
between
two
viable
mechanisms:
the
parent-based
sampling
and
the
trace
id
sampling,
and
it's
like
both
are
good
and
one
is
better
when
you
have
trust-
and
one
is
better
when
you
don't
have
trust
and
we're
trying
to
make
both
work
right
now,
and
I
think
that
there
will
still
be
left
some
standardization
question
of
how
do
you?
D
How
do
you
choose
what
you
want
and
how
do
you
mix
them
together
and
that's
what
we
need
to
discuss
in
this
168.?
I
can
believe
a
lot
of
debate
went
in,
but
I
I
we
also
failed
to
get
probabilities
for
the
users
who
the
vendors,
who
are
accounting
fans.
We
just
don't
have
that
right
now,
yeah,
so
I'm
sure
there
more
could
have
happened.
H
Yeah,
I
want
to
agree
with
stats
that
saying
that
discussing
sampling
was
a
big
part
of
a
specification
work
for
wjc,
and
I
mean
ultimately,
we
need
to
make
sure
that
we
have
we
don't
like.
I
don't.
I
don't
want
to
concentrate
how
we
change
specification
to
fit
some
like
trace
id
assembly
or
some
other
stamping.
I
want
to
make
sure
that
we
have
an
agreement
of
what
everybody
will
be
using.
H
So
when
open
telemetry
sdk
will
all
install
the
same
sampler
and
it
just
works,
then
it's
time
to
change
the
specification
and
adjust
like
whatever
bits
we
want.
I
think
it's
more
important
to
get
like
specifics
of
implementation.
D
D
Got
to
be
a
way
to
do,
trace
id
sampling
right
now
and
we
don't
there's
a
big
to-do
in
the
hotel,
spec
saying
we
can't
do
this
yet
like
we
have
not
finished
sampling.
So
I
think
we
should
finish
it
and
whether
you
put
random
id
in
your
choice,
id
or
you
add
another
random
number.
Those
are
two
solutions,
but
I
think
we
don't
have
any
other
solutions.
So
it's
time
to
pick
and
it's
going
to
be
hard
work
to
get
everyone
to
have
random
numbers.
D
H
I
think
we're
in
agreement
I'm
just
saying
that
in
specification
work,
we
couldn't
even
agree
on
putting
random
randomization
into
trace
id
so
like
we
discussed
it
at
length
so
that
we
we
have
a
for
sampling,
we'll
also
be
in
the
same
realm
of
discussions.
There'll
be
people
who
wouldn't
want
to
do
that.
Extra
work
or
extra
propagation.
F
A
D
A
I
think
we
should
move
on
to
other
topics,
but
I
do
think
this
is
critical
and
if
we
can
come
to
consensus
within
the
world
of
open
telemetry,
that
will
be
a
big
step
forwards.
I
think
so
again
everyone
please
please
review
this
stuff
or
grab
someone
from
your
company
who
you
think
can
can
actually
review
it,
because
because
it's
important,
I
have
some
questions
by
the
way.
I
don't
think
we
need
to
continue
here.
A
D
A
D
Okay,
yeah:
let's
move
on
please.
C
Yes,
please
do
okay!
Moving
on
the
next
point
is
mine.
It's
about
distro,
I'm
very
happy
that
walkdan
is
here
glad
to
have
you
here.
Basically,
this
is
a
small
pr.
I'm
gonna
share
my
screen
for
for
two
seconds.
If
you
don't
mind
so
basically,
this
is
what
I
have
now.
It's
basically
adding
two
two
fields
to
resources,
to
the
resources
set
of
information.
It's
basically
telemetry
destroy
name
and
distro
version.
C
This
is
specifically
for
detecting
if
you
are
using
a
custom
distro
like
amazon,
one
or
the
lightsaber
one
or
the
splunk
one
and
there's
a
comment.
Interesting
comment
from
bogdan,
mentioning
that,
what's
like
you
know,
you
already
have
the
sdk
language
and
version,
and
nikita
was
saying
that
maybe
you
need
both.
So
basically
it's
about
that.
I
think
in
general
there's
agreement
but
yeah
walton,
since
I
have
you
here,
maybe
you
can
you
can
have
additional
information.
G
Yeah,
I
I
do
feel
that
we
are
adding
too
many
fields,
and
this
is
one
of
the
clear
examples
for
me
where,
where
I
don't
think
this
is
necessary,
even
though
nikita
said
that
you
may
have
to
do
a
join
between
your
distro
version
and
what
sdk
version
is
using
sure.
That's
true.
But
but
you
have
that
information
and
if,
if
you
want
that
information
can
be
consumed
by
a
machine,
because
you
you
build
that
distribution,
that
distribution
has
a
clear
dependency.
G
C
Yeah,
the
first
one
is
that
it's
optional,
but
I
guess
that
still
good.
You
could
still
oppose
that.
The
additional
thing
is
that
we
actually
at
least
from
lightsaber
perspective,
we
want
to
identify
who's
there.
C
What's
the
agent
or
client,
you
know
producing
this
information
specifically
in
case
we
have
to
differentiate
different
things,
and
this
is
important
is
for
example,
if
you
have
a
distribution
that
includes
extra
plugins
and
then,
of
course,
maybe
you
are
using
the
same
version
of
the
sdk
and
let's
imagine
that
that
set
of
versions
is
stable
one
day.
But
then
you
still
have
may
have
different
versions
of
your
distribution
because
you
are,
you
are
trying
to
use
different
clients,
different
plugins,
sorry,
and
you
still
know.
G
That
that's
not
your
major
does
not
have
any
language
no
works.
Unless
you
do
some
kind
of
shading
or
something
you
will
end
up
with
only
one
version
correct
like
as
long
as
I
know
the
way
how
compiler
works.
G
If,
if
you
are
depending
on
two
artifacts,
that
depends
on
version
one
and
version
1.1,
most
likely
you'll
end
up
with
version
1.1
in
the
final
binary
or
whatever
algorithm
it
is,
but
you
will
not
end
up
with
both,
even
in
java
with
the
class
loaders
and
everything,
I
don't
think
you
will
end
up
with
both
and
if
you
end
up
with
both,
they
are
seeing
as
two
different
provider,
two
different
things,
because
there
are
different
instances
of
that.
So
so
that
being
said,
I
still
don't
understand
the
problem
of
multiple
plugins.
C
No,
this
is
just
in
case
just
imagine,
and
probably
this
is
a
different
thing
we're
talking
about.
Let's
imagine
that
let's
say
that
there's
a
company
called
acme
and
then
basically
this
company
has
a
distribution
right
and
then
basically
they
were
trying
to
use
a
specific
plugin
internally
and
they're
using
this
one,
and
then
they
want
to
replace
it
because
it's
not
working
fine,
so
they
are
doing
a
patch
release
and
then
for
the
next
one
they
are
using
internally
a
different
plugin.
They
went
from
this
loader
to
this
login
system.
C
To
that
other
login
system,
the
rest
is
the
same.
The
sdk
is
the
same,
the
the
name.
The
version
is
just
that
internally
there's
some
an
additional
component
that
is
changing
and
it's
not
specific
to
the
java
agent
or
the
python
agent.
You
know
it's
something
additional,
so
you
need
to
identify.
What's
the
exact
version
that
you're
using.
G
So
I'm
a
bit
lost
because
if
it's
a
plugin
we
have
instrumentation
library.
So
I
think
that's
where
you
have
the
identification
of
that.
G
E
G
It's
nothing
gonna
be
the
same,
and
if
you
use
the
the
sdk,
you
know
that
if
I'm
at
version,
1.71
or
1.73
is
the
same
hotel
behind
the
scene.
But
at
that
point
I
would
ask
if
you
are
using
a
distro.
Is
it
still
useful
to
know
that
the
distro
is
based
on
a
specific
sdk
version
or
or
the
other,
because
that's
more
or
less
an
internal
information
and
is
not
is
not
necessarily
useful
for
anyone.
G
C
C
G
Problem
we
have
now
right
now.
If
we
add
this,
we
will
have
three
places.
We
have
auto
distro
and
sdk,
like
I
said
really
like.
Do
we
really
need
three
things
there?
Is
it
that
important?
I
I
maybe
I'm
missing
something
but
but
for
me,
when
I
see
three
things
for
for
the
same
thing,
it
feels
like
what
the
heck
should
I
put
in
all
of
them.
How
do
I
interpret
it
all
of
them?
Okay,
I
I
would
like
to
understand
better
some
use
cases.
G
C
So
taking
one
instant
one
one
step
back:
what
about
if
we
were
to
add
only
the
district
name,
only
that
not
the
version
that
way.
At
least
you
know
who
is
the
you
know,
what's
the
distraught,
this
is
splunk
or
lightsaber
or
amazon.
You
at
least
know
that
and
then
you
have
the
rest
of
the
version,
but.
G
Why
the
is
the
key
name
so
so
so,
first
of
all,
if
you
are
not
based
on
open
telemetry
sdk,
that
is
a
very
good
candidate
for
your
distribution
or
your
implementation
name
correct
that
that
is
the
right
candidate
for
that
if
you
are
using
open,
telemetry
based.
So
so
you
are
basing
your
stuff
based
on
open,
telemetry.
Sdk
then
does
it
matter
to
know
that
is
based
on
open
telemetry
you,
if
you
just
put
that
this
is
the
light
step
thing
you
know
that
is
based
on
open
telemetry.
C
C
E
E
G
I
still
don't.
I
still
fail
to
understand
carlos.
Why,
in
your
distro,
you
don't
replace
the
two
values,
sdk
name
and
auto
name
with
lightstep,
sdk
and
livestep,
auto.
G
C
G
You
are
replacing
the
name
so
so
so
your
data
would
look,
would
look
like
telemetry.sdk
that
name
equals
live
step,
dash,
sdk
telemetry.name
equals
livestep.auto,
or
something
like
that
or
servicenow
or
whatever
you
want
to
call
it
doesn't
matter.
But
if
you
have
that
information,
do
you
really
need?
G
C
Yeah
I
could
personally
would
rather
keep
that
information
which
is
original
from
the
from
the
original
agent.
Clear,
just
add
something
on
top,
but
sometimes
trying
to
take
one
step
back
by
the
way.
The
original
proposal
we
had
the
lightsaber
was
to
actually
just
add
a
custom
resource
field,
and
I
was
curious
whether
this
would
be
of
interest.
If
it's
not.
If
it's
not
of
interest,
we
can
for
sure
no
problem.
We
can
add
these
ourselves
like
stuff.
F
One
scenario
where
I
could
see
it
being
important
to
know
the
original
sdk
version
is,
if
you
have
some
downstream
processor
that
doesn't
know
anything
about
any
distributions
that
wants
to
take
action
based
on
the
version
of
the
sdk
that
was
used
upstream.
Maybe
some
version
had
a
bug
in
in
the
way
it
produced
resource
attributes
that
need
to
be
adjusted
and
if
you're
going
to
replace
that
original
sdk
version
information
with
the
distribution
information,
then
every
processor
downstream.
That
wants
to
do
that
needs
to
keep
a
mapping
of
distribution
versions
to
original
sdk
versions.
B
I,
like,
I
sorry,
do
they
like
the
other
thing
is
you
can
put
the
open,
telemetry
version
in
like
you
can
have
both
of
these
in
the
string
name
of
the
sdk?
If
you
want
like
this,
is
this
is
kind
of
what
we
do
in
our
exporter?
B
To
account
for
this
is
I
mean
we're
tracking
with
user
agent
right
now,
but
we
shove
a
crap
ton
of
information
in
there
in
one
label,
and
I
I
understand
bogdan's
concern
around
overloading
labels
and
instrumentation
like
there's,
there's
this
question
with
metrics
that
I
we
need
to
tease
into,
and
I
think
we're
gonna
have
discussion
a
little
later
on
this,
of
what
labels
are
identifying
and
necessary
and
which
are
informational
and
and
extraordinary
and
with
the
instrumentation
library.
B
There's
an
open
question
in
my
mind,
if
I'm
posting
to
a
metric
solution,
should
instrumentation
library
labels
make
it
onto
metric
labels
and
prometheus?
Is
that
a
thing
that
we
want,
or
is
this
like
purely
informational?
If
you
assume
this
is
purely
informational,
which
is
the
case
mostly
for
tracing
solutions
great
as
soon
as
it
starts
to
impact
identity,
which
is
true
for
metrics,
possibly
I
mean
we've
specced
it
out
right
now.
You
you
need
to
be
very
careful
about
how
many
of
these
things
you
have
yeah.
C
Okay,
I
would
like
to
call
time
on
these.
I
think,
there's
no
agreement
and
we
still
have
to
disclose
some
items.
So
I
guess
that
let's
discuss
a
little
bit
more
on
the
issue.
If
we
don't
find
an
agreement,
let's
close
that
and
at
least,
as
I
said
we
in
likes,
if
we
are
interested
in
this,
we
can
always
add
our
own
stuff
yeah.
You
want
to
say
something
I.
A
Just
say
I
think
it
sounds
like
there's
an
alternative
proposal
here,
which
is
to
to
overload
the
existing
fields
right
like
by
saying
the
distro
name
should
be
put
in
there
and
if
we're
going
to
go
that
direction,
that
that
seems
workable,
provided
it
doesn't
cause
the
kind
of
problems
anthony's
talking
about
like
there's
a
balance
to
be
had
there.
But
it
sounds
like
that's
an
alternative
proposal
that
could
get
get
written
up.
If
we
do
go
that
way,
we
should
put
it
in
the
spec.
A
I
don't
think
people
should
start
overloading
those
field
names
without
getting
that
into
the
spec.
G
That's
fine,
but
again
I
want
to
make
a
bit
more
due
diligence
before
applying.
Let's
have
another
label,
let's,
let's,
let's,
oh
all
the
time,
let's
look
over
all
the
things
that
we
have
and
figure
out.
Are
we
just
adding
more
complexity?
Can
we
reuse
things?
Can
we
can
we
do
a
better
work
just
because
otherwise
I
feel
that
we
have
a
tendency
to
keep
adding
things
without
looking
at
the
the
big
picture
and
see
how
things
are
interacting
with
each
other.
G
Yeah,
if
you
also,
let's
apply
the
rule,
if
somebody
else
has
the
same
problem
and
at
one
point
we
discussed
to
have
kind
of
a
voting
thing
like
if
at
least
two
or
three
people
need
some
feature.
Let's
add
it
just
one.
G
G
So
right
now
we
were
arguing
about
the
technical
solution,
but
I
think
the
first
question
that
we
did
not
feel
is:
do
we
really
need
this
feature?
Is
it
something
that
we
really
need,
and
probably
we
need?
I
am
not
I'm
not
arguing
that
we
don't
need.
I'm
just
saying
that
we
should
have
documented
the
need
of
this.
C
Make
sense,
okay,
I
will
call
time
again
for
this
took
a
lot
of
time.
I
will
add
the
comments
we
had
today.
Okay,
thanks
so
much
going
to
the
next
one
is
fast
like
metrics
conventions.
This
is
just
a
call
out.
This
pr
has
been
standing
forever.
There
I
mean,
did
a
review.
Look
it's
looking
great,
but
we
need
reviews
from
the
metrics
group.
Please
do
so
it
kind
of
feels
wrong
that
there's
a
pr
waiting
there
forever.
C
So
if
it
looks
good,
just
approve
that,
if
not
just
let
the
author
knows
yeah,
that's
all
I
can
say
from
that,
then
the
next
one
updates
from
metrics
do
we
have
something
else
from
what
was
mentioned
or
that's.
I
think
that
sounds
like
that.
All
the
important
things
were
said
already,
but
I'm
not.
C
B
So
the
I
I
do
want
to
just
since
we
have
the
opportunity
in
the
screen
time
those
two
proto
things
are
big
on
the
data
model
side,
each
all
three
of
those
one
thing
I
wanted
to
kind
of
get
get
a
feel
for
this
is
probably
the
wrong
forum,
but
just
so
people
know
the
metric
specification
is
a
bit
ahead
of
the
collector.
B
So
if
you
have
switched
from
labels
to
attributes
on
metrics,
you
should
hold
and
still
produce
labels
for
now
until
that's
until
the
collector's
fully
up-to-date
just
as
an
fyi.
That
was
an
issue
that
the
javascript
ran.
G
Into
yeah
on
the
collector,
we
are
almost
0.008.
I
think
we
have
like
five
or
six
prs
left
to
to
be
fully
on
zero,
eight
which,
which
is
not
the
label.
It's
just
the
end
values,
because
java
ran
into
another
issue
that
the
the
counters
was
zero
because
they
were
sending
the
new
format.
I
think
we
made
a
small
mistake,
josh
in
our
documentation
in
the
proto,
because
we
said
that
the
senders
should
send
only
the
new
things
they
should
have
sent
both
the
new
and
the
old.
G
That's
the
right
deprecation
process.
We
we
try
to
be
a
bit
full
speed
on
that,
but
maybe
this
is
a
lesson
that
we
need
to
learn
from
from
the
future
for
future
yeah
totally.
B
B
C
G
The
other
thing
is
somebody
I
remember
somebody
promised
me.
I
think
was
said
that
we
will
approve
the
change
to
attributes
for
metrics
labels.
Only
if
you
give
me
the
stringification,
the
string,
the
two
string
methods,
I
think,
was
ted
or
george,
who
promised
to
me
that
we
will
have
this
before
approving
the
metrics
attributes,
change.
B
Nothing
so
now,
so
no,
what
we
said
was
we're
going
to
define
this
as
part
of
defining
the
prometheus
exporter
spec,
which
we
are
currently
all
of.
Our
attention
is
on
defining
our
own
sdk,
and
I
don't
want
to
take
it
off
of
that
to
start
working
on
how
to
string
attributes
right
now.
B
For
now,
if
you
look
at
a
lot
of
the
implementations,
what
we've
been
recommending
people
is
just
do
a
naive
to
string
for
going
to
prometheus
and
that's
that's
what
I
would
continue
to
recommend
until
we
have
a
chance
to
formally
specify
what
things
will
look
like
in
prometheus
and
how
to
handle
tight
versus
string
overlap,
but
I
like
we
have
way
bigger
fish
to
fry
at
this
point,
and
I
think
the
the
value
that
we
got
out
of
being
able
to
take
attributes
and
move
them
between
metrics
and
resources
is
also
critical
for
that
same
thing.
B
G
But
we
have
problems
on
switching
the
collector
because
of
this.
If
I
want
to
do
the
right
thing
and
emit
the
labels
still
emit
the
labels
in
the
collector,
I
need
to
know
how
to
to
transform
them.
B
I
see
yeah
so
again
right
now,
I
would
say:
do
it
naively
and
treat
treat
any
kind
of
disjoint
issue
where
you
see
the
same
string
twice
as
an
error
for
now?
That's
that's
effectively
what
what
we
haven't
specified,
but
what
we're
actively
doing
in
prototypes.
B
If
I
would
also
say
that
you
should
raise
a
bug
about
this
and
we
can
have
a
more
formal
discussion,
but
again
I
I
want
to.
I
don't
want
to
take
the
metric
sig
meeting
time
away
from
the
sdk
at
this
point
until
we
have
a
stable
spec.
These
are
issues
I
think
we
can
handle
right
after.
C
C
Sense:
okay.
Moving
on
then
updates
from
the
instrumentation
team.
A
Sure,
just
to
keep
this
brief,
there's
a
proposal
for
like
kind
of
a
road
map
for
how
to
tackle
the
instrumentation
work
and
in
the
process
stabilize
the
semantic
conventions
for
resources
and
tracing
we'd
like
to
stabilize
metrics
too,
but
obviously
metrics
not
done.
A
I
think
the
main
thing
I
would
love
to
have
help
with
is
people
willing
to
help
build
prototypes
for
some
of
the
stuff
in
languages
other
than
josh
java
honorag's
got
a
java
prototype,
but
you
know
it's
very
java
ish,
so
we
would
like
to
see
prototypes
in
other
languages,
so
I'm
trying
to
get
some
resources
from
lightstep
to
help
with
that
I'll
be
helping
with
that,
but
the
more
people
who
can
prototype
this
work,
the
better.
A
A
I
Yeah,
so
hopefully
we
are
ready
to
merge
that
one.
There
were
many
comments
if
you
still
have
something
to
add.
I
it's
probably
the
last
moment,
but
it's
hopefully
everything
is
clear
now,
so
we
have
extracted
two
issues.
One
is
messaging
to
the
users
that
attributes
were
truncated
or
deleted.
That's
1787..
I
I
We
extracted
attribute
limits
for
metrics.
So
again,
if
you
have
comments
or
thoughts
on
that,
please
head
over
to
1830,
that's
it.
C
Perfect
jakub,
I
only
have
a
small
question,
but
we
can
take
it
offline
again.
I
think
that
there's
one
new
attribute
called
or
environment
variable
sorry
called
hotel,
attribute
count
limit,
which
seems
to
supersede
the
other
one.
So
probably
we
need
a
clarification.
What
happens
when
you
specify
both
other
that
looks
great,
but
let's
take
it
offline.
G
I
also
want
to
propose
something
around
this.
I
think
we
are
doing
wrong
by
defining
environment
variables
as
our
ways
of
configuration.
I
think
we
should
aim
for
defining
the
yaml
file
for
configuration
or
a
protofire
for
configuration
instead
of
using
environment
variables
and
just
have
environment
variables.
Refer
to
that.
So
I
would
prefer
to
to
have
a
serializable
way
of
doing
configuration,
not
environment
variables.
G
Environment
variables
can
be
one
option
of
doing
the
same
thing,
but
I
think
we
should
use
a
proto
or
yaml
file
or
or
json
or
whatever
we
want
doesn't
matter
to
to
define
all
these
configuration
things
and
then
from
there
derive
environment
variables
to
to
to
do
that,
we
have.
I
look.
B
B
You,
oh
sorry,
yeah
the
proposal
for
like
making
this
configuration
file
and
have
it
and
be
consistent
across
sdks,
and
then
I
I
also
when
it
comes
to
environment.
I
I
I
do
like
the
idea
of
a
actual
serializable
structure,
that's
easy
to
identify
with
a
common
convention
of
how
environment
variables
can
override
it.
I
think
yeah,
but
I
look
forward
to
that
otep.
I
want
I
really
I'm
looking
forward
to
reviewing
it
should
should
it
be
an
authentic.
B
A
G
An
issue
for
this,
and
it's
also
very
hard
to
follow,
because
there
are
so
many
environment
variables,
you
don't
have
a
structure
between
them.
You
don't
see.
Okay
here
are
configurations
for
exporters.
Here
are
configurations
for
for
process
whatever
it's
it's
a
mess
right
now.
Personally,
even
though
I
know
the
the
the
specs
and
everything
I
still
cannot
cannot
digest
all
the
the
environment
variables
and
again,
I
I
can
only
imagine
how
is
that,
for
a
user
reading,
all
these
random
environment
variables
without
understanding
the
structure
a
bit.
C
G
Sure
we
will
figure
it
out,
but
at
least
everyone
agrees
that
we
need
to
to
have
a
proto
or
yaml
most
likely
proto,
because
we
want
to
to
keep
it
this
consistent
with
the
data
that
we
produce
and
then
proto
has
a
way
to
do
yaml
to
proto
and
stuff.
So
we
can
even
support
yammer.
C
Yeah:
okay:
let's
discuss
the
rest
of
line
alolita.
At
least
you
have
four
minutes
to
tell
us.
E
Yeah
again,
I
just
wanted
to
call
everyone's
attention.
This
is
you
know
around
client,
my
events,
client
monitoring
events
and
again,
as
many
of
you
know,
real
user
monitoring
is
an
area
that
you
know
again
is
trying
to
intersect
with
open
telemetry
we've
had
several
discussions
and
and
they're
also,
obviously,
proprietary
implementations
that
you
know
we'd
like
to
actually
intersect
as
an
open
implementation
on
open
telemetry
and
several
vendors,
including
us,
are
interested
in
this
area.
Where
you
know
this
could
go
either
way
right.
E
It
could
actually
go
towards
you
defining
an
event
type
that
handles
real
time.
Events
coming
in
from
client
components
or
client
clients,
whether
those
are
iot
clients
or
others,
but
also
it
could
intersect
with
trying
to
leverage
log.
The
log
data
you
know
model
as
as
the
baseline
data
structure
right
so
again,
this
is
a
discussion
that
needs
to
be
had
in
more
detail
and
we
have
filed
a
notep
based
on
you
know,
really
taking
this
discussion
forward.
E
We
are
proposing
events
to
be
a
separate
data
type
in
this
specific
use
case.
But
again,
you
know:
I've
had
several
conversations
with
splunk's
team,
with
the
new
relics
team,
with
other
teams,
and-
and
there
is
an
implementation
splunk
has,
for
example,
where
they
have
implemented
an
a
you
know,
an
and
rum
event
model
on
there
reapers,
but
are
interested
in
also.
E
You
know,
intersecting
that
work
with
open
telemetry.
So
again,
you
know,
I
propose
that
I'd
like
to
get
comments
from
folks.
You
know
on
this
call
as
well
as
other
feedback.
This
is
a
new
area.
It's
it's
really
opening
up.
You
know
telemetry
from
clients
coming
in
and
and
we
definitely
want
to
see
this
being
supported
in
open
telemetry.
So
please
take
a
look
look
forward
to
any
comments
here.
G
Yeah,
but
I
think
there
were
there
was
a
pushback
on
that.
Maybe
maybe
yeah
maybe
try
to
understand
that.
Second,
please,
please,
when
you
talk
about
this,
don't
call
them
just
events,
call
them
rum
events,
because,
okay,
if
you
talk
about
events,
we
will
go
into
another
beast
of
a.
C
Perfect,
thank
you.
Sadly,
we
are
on
time.
Thank
you.
So
much
everybody
stay
safe,
talk
to
you,
offline
ciao,.