►
From YouTube: 2023-03-28 meeting
Description
Instrumentation: Messaging
A
C
A
C
A
C
Yeah,
okay,
so
I
haven't
seen
those
yet
but
but
I
don't
think
there
has
to
be
like
hundred
percent
following
the
spec.
You
know
like
a
full
spec
implementation
like
the
first
merge,
so
I
will
you
know
I
will
look
it
over
like
the
state.
That
is
that
it's
now
that
I
will
bring
it
up
at
the
js6
tomorrow.
C
A
A
So
this
is
some
in
our
write-up.
You
know
we
had
prepared
as
part
of
this
thing.
So
this
is
not.
This
is
a
in
a
private
Branch.
So
these
are
some
attributes
at
the
the
resource
level
that
we
believe
you
know
could
could
change
during
the
lifetime
of
an
SDK
half
a
single
SDK
instance,
and
some
examples
could
be.
Let's
say
you
know,
you're
you're,
using
a
browser
app
on
your
mobile
and
your
you
switch
from
portrait
to
landscape
or
you
you
in
a
in
a
desktop.
A
A
Okay,
okay
yeah.
Similarly,
in
the
case
of
a
single
page
application,
you
know
when
the
your
application
is
making
API
calls
using
the
you
know,
the
XML
HTTP
request
or
the
fetch
we
want
to
indicate
which
page
the
user
is
on
when
making
the
request
and-
and
that
again
we
believe
you
know
is-
is
better.
It
fits
in
to
the
resource
as
an
attribute
and
in
a
single
page
application,
the
the
page
you
are
on
or
any
any
web
application.
A
A
A
You
know
that
you
know
people
could
log
in
log
out
log
in
multiple
times,
within
the
same
instance
of
your
application
of
your
single
page
application.
So
there
are
these
few
attributes
that
we
believe
are
under
session
ID
session.
Id
is
the
important
one.
It's
it
AI.
It
fits
in
the
same
set
of
use
cases.
We
discussed
so
far
that
you
know
the
user
has
their
application
open
and
and
then,
after
a
while
the
session
expires.
A
The
definition
of
a
session
is,
is
a
little.
You
know
it's
not
so
standard,
but
so
far
all
I
think
most
of
the
rum
products
have
defined.
As
you
know,
a
contiguous
sequence
of
events,
from
from
a
certain
instance
of
the
browser,
application
and
and
the
sessions
could
end
because
of
a
timeout,
the
user.
You
know
just
switched
to
a
new
tab,
never
went
back
to
the
tab
or
you
know
they
close
the
browser
window
and
things
like
that,
but
it's
possible
to
resume
the
session
in
the
same
SDK
instance.
A
So
that's
the
use
case
for
session.
So
these
are
there
are
these
are
some
use
cases?
So
do
you
see
any
concerns
with
respect
to
the
requirements
itself
and
I?
Think
the
solution
is
I.
Understand
it's
it's
hard,
but
do
you
see
the
ask
that
you
know
this
fits
the
use
case?
If,
if
there
was
the
support
for
modifying
the
resource
attributes,
you
know
the
these
use
cases
fit
that
feature.
B
B
I
think
you
know
what
I
need
to
do
in
order
to
form
a
better
opinion
about
that
is,
you
know,
reread
the
sections
of
the
specification
about
a
resource,
and
you
know
about
what
it
actually
means:
semantically
and
then
catch
up
on
the
state
of
this
Otep
and
see
what
the
arguments
have
been
in
favor
and
against
ephemeral
resources.
You
know
I
think,
there's
pretty
strong
opinions
on
both
sides,
folks
that
think
that
resources
should
be
immutable
and
folks
that
think
that
you
know
it's.
It's
really
essential
to
include
these.
A
A
A
B
Well,
the
main
thing
you
want
to
do
with
metrics
is
you
want
to
reduce
the
amount
of
data
that
you
send
over
the
network?
So,
like
you
know,
if
you
have
a
bunch
of
discrete
events,
you
can
send
those
events
individually
over
the
network
or
you
can
aggregate
them
into
some
sort
of
into
some
sort
of
metric
yeah.
A
A
C
Yeah
I
mean
we
had
so
we
have.
We
had
these
discussions
before
and
I
think
we
kind
of
agreed
that
most
most
things,
that
the
client
measures
are
unique,
like
they're,
unique
events
and
they
they
it
doesn't
really
make
sense
to
aggregate
them
in
the
client
that
doesn't
mean
that
we
would
not
potentially
generate
metrics
from
the
events,
but
but
like
the
base.
Instrumentation
is
based
on
events.
C
It
is
possible,
it's
definitely
possible
that
we,
we
might
add,
instrumentations
based
on
metrics,
but
we
haven't
really
had
like
a
use
case
that
there
was
like
a
primary
use
case
for
that
all
the
primary
use
cases
that
we
have
considered
are
unique.
Events
that
are,
you
know,
doesn't
make
really
sense
in
the
client
SDK
to
to
generate
metric
support,
but
yeah.
It
is
true
that
it
is
still
you're
asking
about
the
identifying
attributes
you.
C
D
I
was
gonna,
mention
you're,
not
gonna
in
this.
In
this
case,
these
are
not
going
to
be
identifying
in
any
way.
No
because
in
most
cases,
I
mean
a
great
aggregation
you
want
to
do
is
going
to
be
very
attribute
specific.
For
example,
you
want
to
get
everything
from
One
browser
or
browser
family
like
all
compare
Chrome
values
to
Firefox
values,
or
you
want
to
compare
countries,
users
from
America
versus
users
in
Germany,
it's
kind
of
hard
to
find
just
one
way
to
group
this
Matrix.
B
Right
and
I
know
there's
been
some
work
in
the
spec
to
be
able
to
categorize
or
catalog
different
resource
attributes
as
either
identifying
or
descriptive.
You
know
do
they
identify
the
Telemetry
source
and
therefore
they're
part
of
like
a
metric,
a
metric
streams
Identity
or
are
they
just?
You
know
descriptive
attributes
that
shouldn't
be
considered
as
part
of
the
identity
and
I?
Don't
I,
guess
I
need
to
refresh
myself
on
the
status
of
those
conversations.
E
A
I
think
you're,
referring
to
there
was
one
issue
where
there
was
a
detailed
discussion
between
Josh,
Surat
and
tigran
I
guess
where
they
identified
adding
another
attribute
collection
and
and
call
it
as
a
descriptor
attributes.
But
do
you
is:
is
that
what
you're
also
referring
to
yeah?
That's
what
I'm
referring
to
okay,
okay,
I,
have
a
question
on
that.
You
know
in
in
that
issue.
It
I
did
not
see
a
requirement
for
modifying
the
attribute.
B
D
B
B
So
I
guess:
what
is
the
state
of
that
Otep
of
Ted's
Otep
I?
Guess,
since
can
anybody
summarize
that
there's
a
been
a
lot
of
conversation
there
and
it
seems
to
have
gone?
You
know,
stale.
There
hasn't
been
activity
in
in
several
months
like
what's
the
and
there's
a
lot
of
unresolved
conversations,
what's
the
general
feeling
and
what
are
the
general
critic
criticisms.
A
A
C
A
B
Think
I
think
you
all
need
to
be
careful
with
that
argument,
because
it
it
kind
of
proliferates
all
the
conversations
that
are
happening
with
the
specification,
and
you
know
you
need
to
find
a
way
to
decouple
data
modeling
from
how
it's
being
sent
over
the
wire.
Because
there's
you
know,
there's
there's
these
compression
there's
these
compression
conversations.
B
A
You
know
all
the
actions
start
from
there
and-
and
there
is
a
there
is-
there
is
a
requirement
where,
like
in
the
case
of
recession
or
the
browser,
so
you
have
a
resource
and
in
the
same
context
you
know
you're
you're
emitting,
you
know
the
the
Telemetry
and
then
the
state
of
that
object
in
a
good
change
and
and
and
and
that
that
Dimension
I
am
not
very.
There
are
not.
A
B
I,
don't
think
they
were
considered
during
the
the
design
of
otlp,
and
you
know,
I
think
the
the
reason
I
think
that
we
should
be
careful
about
letting
the
size
of
the
payload
over
the
network
being
a
primary
factor
in
the
design
is
that
you
all
may
not
end
up
using
otlp
in
its
current
form
forever
like
there
could
be
a
future
where
there
is
a
special
optimized
version
of
the
protocol.
That's
designed
specifically
for
client
situations
where
bandwidth
is
limited.
B
Like
imagine
imagine
you
know
if
there
is
otlp.
Is
this
stateless
protocol
right
now,
and
so
you
know,
there's
no
sort
of
initialization
or
handshake
phase,
that's
needed
between
clients
and
servers.
It's
like
clients,
just
fire
and
forget,
but
if
clients
could
have
some
like
an
initialization
phase
with
servers,
then
they
could
communicate
metadata
about
the
the
data
that's
going
to
be
sent
over.
That
would
allow
subsequent
payloads
to
be
smaller.
A
B
Well,
it's
a
kind
of
a
check-in
in
the
egg
problem,
so
you're
not
at
the
stage
where
we
can.
You
know,
consider
changes
to
otlp
because
there's
not
prototypes
built
and
there's
not.
You
know
you
know,
code,
that's
being
used
or
people
are
clamoring
for
smaller
payloads,
and
so
you
know,
do
you
try
to
solve
all
the
problems
at
once
or
do
you
just
you
know,
Focus
that
focus
on
one
thing
at
a
time
and.
B
With
that
said,
though,
I
think
there's,
like
I,
think
we
genuinely
need
to
tease
out
this
this
question
about
what
the
what
qualifies
as
a
resource
attribute.
You
know,
I
think
that's
probably
the
key
thing:
that's
that's
holding
this
up
is
or
one
of
the
key
things
that's
holding.
This
up
is
like
you
know.
The
the
other
resource
attributes
that
are
defined
in
this
magic
conventions
are
things
that
are
are
static.
B
Things
like
your
your
operating
system
and
your
architecture
for
devices,
your
your
device
name
and
your
device
brand,
and
so
on
and
so
forth.
These
are
all
static.
Things
and
I
think
it's
a
it's
a
bit
uncomfortable
to
to
think
about
things
that
describe
the
source
of
the
Telemetry
being
changeable
as
a
function
of
time-
and
you
know
is
that
is
that
acceptable?
B
If
we
can
think
of
examples
that
fall
outside
of
the
rum
use
case,
I'm
just
thinking
about
this
real
time,
I'm
just
spitballing
here,
but
if
there's
so
I,
don't
have
any
examples
that
come
to
mind
immediately,
but
maybe
there
could
be.
Maybe
there
could
be
things
about
like
you
know
a
server's
Telemetry
resource
that
change
over
time,
and
if
you
could
think
of
those
things,
then
I
think
it
would.
It
would
help
you
make
a
stronger
case
for
this
and
kind
of
kind
of
a
related
idea
to
that
is.
B
B
So
you
can
never
change
those,
but
maybe
like
the
descriptive
attributes
can
be
mutated
over
time,
and
maybe
that
would
like
allow
people
to
be
more
comfortable
with
this,
because
I
think
you
know
I
think
some
of
the
concern
is
is
about
this,
this
question
of
metric
stream
identity,
and
so,
if
you,
if
you
can
resolve
which
attributes
are
identifying
and
part
of
the
metric
stream
identity,
then
you
know
the
ones
that
are
not
part
of
the
metric
stream
identity.
The
ones
that
are
descriptive,
don't
seem.
B
A
B
Well,
yeah,
it
says
it's,
it's
pretty
vague
on
the
details,
and
this
is
something
that
I've
kind
of
encountered
with
I'm
involved
in
the
file
file
based
configuration
working
group.
We're
trying
to
like
have
a
yaml
file
that
you
can
use
to
configure
an
SDK,
and
some
of
the
criticism
we
received
with
that
is
that
you
know
whatever
we
do
should
be,
should
work
with
op
amp.
B
So
you
know
you
can
update
an
SDK
over
time
or
by
connecting
to
like
an
op-amp
server
and
having
you
know,
new
SDK
configuration
pushed
down,
and
you
know
so
like
as
part
of
trying
to
understand
that
criticism
and
address
it.
You
know
I
found
this
language
in
the
specification
that
talks
about
them:
being
providers,
Tracer
provider,
meter
provider
and
logger
provider
being
like
updatable,
but
there's
no
details
on
exactly
what
that
means,
like
you
know
like
which
parts
of
it
are
updated.
B
A
So
one
one
one
test
kick,
let's
maybe
I
don't
know
if
you
call
it
a
test
case,
but
one
scenario
that
booked
on
he
pointed
out.
You
know
that
could
be
problematic.
Is
that
you
know
imagine
you
know
you
are
you're
generating
multiple
spans
in
in
a
single
trace
from
from
the
same
SDK,
it's
possible
that
one
span,
the
parent
span
could
be
identified
with
one
resource,
and
you
know
the
child
span.
You
know
identifies
with
another
resource
and
that
yeah
there
are
no
guaranteed
semantics.
You
know.
A
B
Well,
that's
kind
of
that's
that's
an
interesting
point
and
that
kind
of
goes
is
related
to
what
I
was
saying
about
resource
descriptive
versus
identifying
attributes.
So
you
know
if
you
can
say
that
every
span
that's
emitted
is
always
associated
with
the
same
resource
from
an
identity
standpoint
like
all
the
resources
have
the
same
identity
like
the
same
identifying
attributes
but
they're
descriptive
attributes
are
subject
to
be
different.
Then,
like
you
may
have
a
way
around
that
criticism.
B
A
Okay,
maybe
yeah
I
think
you,
you
have
the
larger
context
and
your
part
of
multiple
all
these
working
groups
so
yeah
you
could
help
us
out.
I.
Think
I
also
buy
your
argument
that
we
should
you
know
we
could
take
baby
steps
where
you
know
we
could.
You
know
for
now
go
ahead,
put
these
into
the
individual
signals
rather
than
in
the
resource,
but
maybe
yeah
I
think
we
could
think
about
that.
A
B
C
Yeah,
so
so,
just
to
be
just
to
be
a
little
like
put
some
background
into
this,
like
we
did
create
prototype
a
long
time
ago,
but
it's
a
prototype.
That's
that
users
can't
really
use
in
their
applications
like
it's,
but
it
does.
You
know
it
does
show
the
concept
of
generating
these.
These
events
I.
Think
when
you
talk
about
prototype,
you
mean
something:
that's
part
of
the
like
published
packages
for
the
SDK
that
users
can
actually
deploy
into
their
applications
and
test.
B
Well,
there's
different
types
of
prototypes
and
so
I
think
you
know
both
what
you
did
before
and
and
kind
of
having
an
actual
artifact
that
folks
can
depend
on
can
qualify
as
one
and
they
they
serve.
You
know
different
purposes,
you
know
if
you
could
take
your
old
prototype
and
you
know
do
some
sort
of
performance
analysis
on
it
to
show
for
different
scenarios.
What
the
what
the
payload
over
the
network
looks
like
you
know,
I
can
think
of
a
couple
scenarios.
That
would
be
interesting
right.
B
You
know
successfully
argue
for
that
was
by
producing
you
know,
a
table
showing
kind
of
the
compression
results
for
all
the
different
signals
and
for
different
payload
sizes,
and
you
know
shown
output
like
the
the
compression
rate
per
second
and
the
yeah,
and
things
like
that
and,
like
you
know,
people
saw
that
and
they
were
like
great
this.
You
know
this
makes
a
lot
of
sense.
Let's
do
this,
and
so
having
hard
data
really
helps
argue
a
case.
C
So
I
do
think
that
we
can
definitely
do
that
kind
of
exercise,
and
maybe
we
have
done
to
some
extent.
I,
don't
recall,
but
I
also
agree
with
you
Jack
that,
like
I,
think
it
makes
sense
to
decouple
this
conversation
from
the
from
the
from
the
varying
attributes,
because
the
old
Tab
and
you
know
the
argument
that
that
was
making
in
the
otab
was
not
based
on
this,
not
on
the
size.
C
A
A
So
that's
one
constraint
so
compression
is,
is
not
an
option
and
the
attributes
you
know
the
the
way
or
semantic
conventions
are
they
have
a
you
know,
long
prefix.
So
it's
so
there's
a
lot
of
repetition.
So
it's
just
based
on
those
factors
we
felt
you
know
keeping
them
at
a
resource
might
be
a
good
idea,
but.
B
And
so,
if
you
take
that
data
and
then
you
also
coupled
it
with
data
about
modern
environments
and
the
and
you
can
break
down
the
percentages
of
where
compression
would
be
enabled
like,
if
you
can
say
compression
is
available
in
in
you
know,
in
40
of
use
cases
or
in
60
of
use
cases
or
ninety
percent
of
use
cases.
Then,
like
you
know,
you
start
to
create
a
really
compelling
picture
for
why
this
is
is
so
important.
B
You
know
if,
if
it
turns
out
that
compression
is
only
available
in
30
of
situations
and
the
in
the
performance
characteristics
are
just
absolutely
terrible.
If
you,
if
compression,
is
disabled
and
this
data
is
on
individual
signals
like
if
the
if
the
payload
size,
Balloons
by
10x
or
20x
in
in
you
know
that
would
impact
70
of
users,
then
that's
like
a
pretty
compelling
reason
to
do
something
about
this.
But
you
got
to
like
kind
of
stitch
together
the
picture.
B
B
You
know
if,
like
let's
say,
let's
say:
you're
configuring,
the
the
SDK
really
early
in
the
application
life
cycle,
but,
like
you
know,
one
of
the
contributors
of
resource
attributes
isn't
available
until
later
in
the
applications
life
cycle
like
in
that
case
it
would
be
great
if
that
could
contribute
its
resource
attributes
later
than
when
the
SDK
was
initialized
yeah,
but
I.
Don't
think,
there's
been
a
good
answer
to
that.
B
I
think
that
those
use
cases
have
just
been
like
rejected
right
now,
because
of
you
know
what
we're
talking
about
and
I,
don't
think.
That's
necessarily
correct.
I
think
we
we
do
need
to
find
a
solution
for
this,
and
you
know
again:
I
need
to
I
need
to
study
a
bit
more,
but
I
think
the
solution
could
be
focused
around
a
couple
of
things.
B
One
coming
up
with
that
or
trying
to
better
understand
like
what
the
definition
is
of
a
resource
attribute
and
like
what
qualifies
as
one
and
then
two
considering
which
resource
attributes
are
identifying
or
descriptive,
and
maybe
including
that
in
the
in
the
proposed
design
and
saying
something
to
the
effect
of
you
know,
descriptive
attributes
are
mutable.
Identifying
attributes
are
not.
C
B
I
was
just
going
to
say
that,
like
there's,
there's
other
attributes
that
are
extremely
high
cardinality
that
aren't
part
of
that,
like
you
know,
there's
like
a
the
command
line.
I
think
the
process
command
line,
which
is
it
can
be
thousands
of
characters
long.
You
don't
want
that
part
of
your
metric
identity
for
sure
it
may
contain
secrets
too.
C
Yeah
so
I'd
like
to
understand
at
some
point-
maybe
not
now,
but
the
kind
of
the
relationship
between
the
resource
attributes
and
the
metric
identity,
so
so
I
I
do
remember.
We
had
conversations
around
this
old
tab
where,
like
we
were
trying
to
understand
why
there
are
people
pushing
back
on
resources
in
general
being
immutable
and
the
the
only
thing
that
you
could
come
up
with
is
that,
like
maybe
some
back-ends
do
like
a
hash,
all
the
resource
attributes
to
uniquely
identify
the
source
of
the
telemetry
right?
C
So
if
you
defined
yeah,
like
you
were
saying
like
if
you,
if
we
in
the
spec
like
if
we
said
like
these
attributes,
use
only
these
attributes
for
that
purpose,
right,
identifying
then,
but
I
guess
maybe
there
are.
There
are
now
backends
or
systems
that
are
you
know
that
would
have
to
that
would
break.
You
know
if
you
were
stressed
if
you
started
to
send
different
resources
like
in
the
same
lifetime
of
the
SDK.
B
Yeah
and
I
I
guess
I
would
push
on
that
a
bit
like
if,
if
that's
a
real
argument,
because
you
know
there's
all
sorts
like
applications
can
start
and
stop
pretty
quickly
in
some
situations
like
imagine,
you
have
a
Telemetry
emitted
for
a
kubernetes
job.
Jobs
are,
can
be
run
on
a
schedule
or
you
know
initialized
by
other
things,
and
they
can
run
with
really
high
frequency.
B
With
the
exception
of
you
know,
service
instance
ID,
which
is
is
subtly
different,
like
a
back
end,
should
be
able
to
accommodate
that,
and
so
I
would
want
to
know
what
the
real
world
situations
are,
where
a
back
end
breaks
as
a
result
of
like
you
know,
descriptive
attributes
changing
you
know,
even
if
we
haven't
like
you,
know,
defined
what
descriptive
attributes
and
identifying
are
right
now
I
would
want
to
know.
Like
you
know
it
shouldn't
just
be
academic.
B
C
B
It
doesn't
look
like
there's
semantic
inventions
working
group,
but
somehow
you
know
he
ends
up
with
like
a
four-hour
block
of
meetings
consistently.
If
he
attends
this
and
he
doesn't
have
time
for
lunch,
he
has
meetings
from
like
ten
to
two
straight
his
time,
and
so
he
would
prefer
not
meeting
at
this
time
and
Wednesday.
He
has
a
conflict
because
of
the
TC
meeting,
so
I'll
bring
up
a
conversation
in
the
slack
channel.
Is
there
a
slack
channel
for
this
working
group.