►
From YouTube: 2022-10-31 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
B
A
Yeah
so,
while
everyone's
joining
feel
free
to
add
topics
as
needed
and
everything.
C
A
A
A
A
All
right:
well,
let's,
let's
get
started,
it's
been
it's
five
after
thanks
everybody
for
joining,
especially
on
Halloween
day,
okay,
so
first
I
wanted
to
do
some
time
back.
Some
project
status
and
triage
project
status
is
the
set
of
work
that
we
kind
of
outline
for
this
group.
You
can
see
the
link
here,
please
let
me
know
if
you
don't
have
access
to
that
project.
Board.
I.
Think
I
tried
to
open
it
like
three
times
and
people
kept
not
being
able
to
see
it.
A
So,
if
you're
unable
to
see
it,
take
a
look.
The
only
issue
that
came
in
over
the
past
week
was
this
semantic
convention
for
rabbit
mq.
Let
me
pop
this
open
and
see
share
this
tab.
Instead.
Is
this
working?
A
So
specifically,
this
is
a
new,
a
new
bug
around
adding
a
message.header
attributes
to
semantic
conventions,
so
the
idea
would
be
if
you
get
a
rabbit,
mq
message.
We
add
message
header
key
as
an
attribute
that
you
would
fill
out
and
I
believe
this
is
a
tracing
semantic
convention.
So
the
question
that
was
opened
here
was
whether
this
is
something
that
should
be
message
wide
or
something.
That's
specific
to
rabbitmq
the
question
I'm
posing
to
this
group
is:
how
can
we
help
this
PR?
A
This
issue
make
progress
so,
for
example,
do
we
do
we
want
to
recommend
that
this
goes
to
say
a
message,
semantic
convention
group
to
be
a
generic
thing?
Do
we
think
we
should
chime
in
in
any
way.
B
I
think
we
can.
We
should
just
redirect
him
to
the
the
person
to
the
messaging
group.
I've
been
attending
that
for
a
while,
okay,
so
I
I
think
it
will
be
available
if
either
the
person
joins
the
meeting
or
posts
on
flag.
So
we
can
discuss
or
or
either
I
can
add
to
the
agenda
next
week
after
the
meeting
next
weekend.
A
That
would
be
awesome.
Let's
do,
let's
do
all
of
the
above.
So
do
you
have
a
link
to
the
calendar?
Invite
for
that
meeting.
I
wish
there's
a
better
way
to
to
link
those
yeah.
Would
you
mind
taking
the.
B
B
A
B
I'm
not
sure
if
this
fits
here,
I
still
have
a
couple
of
pull
requests
open
on
the
some
somatic
conventions
of
the
specifications,
repositories
that
haven't
been
looked
at
or
aren't
accepted,
or
neither
rejected
or
accepted
I'm,
not
sure.
What's
what's
the
status
and
do.
A
B
B
A
We
usually
try
to
release
every
month,
so
if
we
want
to
get
stuff
in,
we
should
probably
try
to
get
it
in
by
tomorrow
is
usually
when
we
get
all
of
the
pull
requests
in
prior
to
cutting
the
release
and
understanding.
If
there's
any
issues
and
that
sort
of
thing.
B
I
mean
the
last
one
process
up
time:
I,
don't
really
care
that
much
about
this
one.
It
doesn't
it's
not
blocking
for
us,
but
the
other
ones
would
be
really
nice
too.
A
That's
the
start
time
well
this.
This
is
the
one
that
kind
of
walks
into
some
of
the
issues
with
resource,
which
is
why
that
one
is
blocked
for
now
until
we
actually
identify
there's
a
there's,
an
open
question
around
what
what
semantic
conventions
need
to
look
like
in
the
presence
of
metrics
that
we
need
to
answer
before.
We
can
merge
that
so
I
don't
actually
think
that
one's
going
to
go
in.
A
B
B
B
Yeah
we're
basically
coming
from
the
telegraph
world
where
we're
trying
to
use
open
Telemetry
instead
of
Telegraph,
and
there.
E
A
Okay-
and
so
this
is
basically
the
equivalent
of
we
have
CPU
time,
CPU
utilization
versus
memory,
so
I
guess
what
I
would
say
is
from
my
standpoint,
I
understand
that
argument
and
I
think
I
can
approve
this,
given
that
but
you're
going
to
need
at
least
one
more
person
to
be
an
approver
before
we
can
merge
it.
So
that's
that's!
What's
blocking
that.
A
A
A
Want
to
make
sure
I
give
it
the
give
it
a
quick
once-over
of
some
other
things.
This
is
interesting,
though,
so
the
utilization,
by
the
way
I
again
I,
can
comment
after
this
meeting,
because
I
think
we
should
just
focus
on
we're.
Not
the
process
of
anti-convention
group.
That
is,
the
physical
memory
used,
not
the
amount
of
virtual
memory
right.
Okay,.
A
Interesting,
okay,
cool
yeah:
what
was
the
what's
the
next
one,
so.
E
Any
ideas
who
would
be
most
attentive
or
or
receptive
to
giving
that
merge
before
the.
A
Release
from
a
spec,
metrics,
approvers
I
think,
let's
see
I,
think
Jack
Burke's.
Actually,
a
pretty
reasonable
person
to
ask
for
this.
Riley
is
also
a
good
one
to
to
bug
trying
to
think
anyone
else
have
any
other
suggestions
of
folks
that
are
in
metric
specs
approvers.
Let
me
actually
just
take
a
look
at
who
this
is
don't
look
at
my
screen
for
now.
A
Find
a
team
all
right:
let's
see,
yeah
Jack,
Berg
Riley,
maybe
even
Tyler,
although
I
think
they're
a
bit
busy
with
implementing
their
own
metrics
back
right
now,
those
those
are
all
good
people
to
add,
maybe
see
Joe
as
well.
A
A
A
A
A
Is
there
any
other
any
other
ones?
We
know
that
are
blocked
related
to
that.
A
Okay,
interesting
I
think
the
context,
by
the
way
that
all
of
these
are
related
to
moving
from
Telegraph
to
hotel
is
also
kind
of
important.
If
there's
like
a
macro
bug
that
you
want
to
track
Telegraph
to
Hotel,
friction
that
could
actually
be
pretty
interesting
and
useful.
B
E
I
don't
know
if
there's
like
a
fundamental
like
meta
kind
of
issue,
on
on
the
translation,
it's
more
just
the
nitty-gritty
of
of
naming
and
conventions
right.
A
A
B
A
Much
yeah
yeah,
the
there
is
a.
There
is
a
meta
issue
that
we
should
talk
about,
which
is
like
for
those
process.
Metrics
right.
Do
we
want
to
give
people
a
consistent
experience
and
say
like
if
Telegraph
only
has
utilization
and
like
the
Oto
collector
has
both
when
we
make
one
required
in
one
optional.
You.
B
A
Our
seven
minute
time
box
we're
a
little
bit
over
okay.
Let's
move
on
to
Telemetry
definition,
stability,
I,
actually
so
we're
talking
about
what
constitutes
a
breaking
change
in
metrics
and
I
have
three
questions
to
ask
here.
So
just
for
FYI
there's
there's
a
few
sections
that
I
didn't
have
a
chance
to
write.
Let's
see
so,
click
on
the
bug
here,
I
created
an
intersection
in
our
document,
which
are
the
three
sections
I
need
to
write
around
metric
stability
definition.
A
I
have
an
evaluation
sheet
where
we
walked
through
the
entire
set
of
attributes
that
are
available
in
the
protocol,
things
that
could
change
and
then
trying
to
understand
like
what
types
of
changes
we
could
allow
or
not
and
I,
took
the
approach
of
let's
be
as
flexible
as
possible
and
try
to
have
the
most
amount
open
for
change
and
then,
let's
take
anything,
that's
sort
of
on
the
edge
and
discuss
it
in
this
group,
and
then
I
can
take
this
and
turn
this
into
specification.
A
Changes
on
the
stability
portion
of
the
specification,
so
we'll
open
a
PR
based
on
what
we
discuss
here,
but
basically
metric
changes
that
we
would
consider
Unbreaking
and
I
thought
this
was
kind
of
non-contentious,
so
I'll
just
throw
them
out
quickly.
Changing
the
metric
description
should
be
something
you
can
do
in
any
release,
because,
theoretically,
the
description
doesn't
really
affect
how
you
use
it.
A
That
said
like
this
is
not
assuming
you're
changing
the
actual
semantics
of
it.
You're
just
changing
how
you
describe
it.
A
Changing
an
instrument
kind
is
actually
also
something
I
think
we
should
allow
if
it
doesn't
change
the
actual
metric,
that's
generated.
So
if
we
say
right
now,
we
say
this
is
like
up
down
counter
or
a
counter
right.
The
notion
of
whether
you
do
async
or
not,
it
should
be
irrelevant
to
the
metric
itself.
So
if
I
calculate
this
with
an
async
operation
versus
I,
calculated
by
sending
individual
values
and
summing
them
that
shouldn't
matter
in
the
semcon
I'm,
actually
throwing
that
out
there,
the.
A
So
I
do
mean
async
versus
sync
effectively,
but
in
practice
this
would
be
so
if
I,
if
I'm
saying
that
this
is
a
histogram
I,
can't
then
say
it's
a
gauge.
Those
are
actually
different
metric
types
right,
but
if
I
say
this
is
a
counter,
it
means
it
could
be
an
async
counter
or
a
regular
counter.
It
doesn't
matter.
B
A
B
A
Yeah,
so
that's
one
thing:
we
have
to
talk
through
adding
attributes
that
don't
add
new
time
series
is
also
something
we'll
explicitly
allow.
So,
if
I
add
a
new
attribute
to
the
metric
time
series,
it's
the
same
for
all
previous
versions
of
that
of
every
existing
time
series
that's
actually
allowable.
So
we
can
do
that
if
we
think
there's
some
additional
defining
thing
that
we
need.
A
We
should
allow
that
so
this
actually
kind
of
opens
some
doors
around
resource
that
we'll
talk
about
when
we
get
to
the
resource
discussion
later
but
effectively.
This
should
not
break
existing
thresholds
of
alerts
and
existing
queries.
C
C
On
the
counter
versus
async
counter
I
think
a
few
months
back,
we
stopped
even
specking
whether
it
was
async
or
not.
B
B
Semantic
conventions
do
we
refer
to
it,
because
I
was
reviewing
this
there's
this
VR
for
for
defined
ammo
for
for
metric
semantic
conventions
and
there
I'm
pretty
sure
that
there
it's
not
defining
the
the.
If
it's
asynchronaut
is
just
it's
just
counter
or
right
and
there's
a
there's,
a
section
specifically
saying
there
that
the
author
added
that
it
could
be
either
async
or
async.
So
this
doesn't
matter
for
the
semantic
convention.
C
A
I'm,
actually
thinking,
if
we
add
timers,
which
I
really
really
want
to
add
that
they
will
be
indistinguishable
from
histograms,
got.
C
A
So
that's
why
I
wanted
to
explicitly
call
out
like
instrument.
Kind
changes
are
totally
allowed
and
not
as
important
as
the
resulting
metric
stream,
which
gets
into
some
fun
some
fun
other
things,
so
things
that
are
considered
breaking
right.
The
metric
name,
the
metric
unit,
the
instrumentation
kind
like
going
from
counter
to
histogram.
Now,
additionally,
there's
when
we
come
to
instrument
kind.
A
If
we
look
at
this
eval
sheet,
I
probably
need
to
actually
list
this
out,
but
we
just
went
through
all
the
particular
pieces
of
data
and
things
that
you're
allowed
to
modify
aggregation.
Temporality
and
cumulative
Behavior
are
also
things
that
we
are
explicitly
disallowing
to
change
from
a
semantics
convention
standpoint.
A
A
That
means
that
we
can
enforce
it
from
a
stability
standpoint.
Exporters
need
to
not
change
their
aggregation.
Temporality
right.
A
This
notion
of
cumulative
sums,
though,
is
the
other
thing.
So
this
is
you
can't
switch
from
an
up
down
counter
to
a
counter.
A
And
I
think
I
think
that's
kind
of
captured
elsewhere.
I
did
want
to
call
this
out.
We
can
talk
through
that
later.
If
we
need
to,
but
just
as
an
FYI
I,
don't
think
we
should
change
this
on
users
without
them.
Knowing
it's
changed
and
that's
a
limitation
not
on
the
metric
stability
specification
but
kind
of
on
the
exporters
like
they
should
not
switch.
What
aggregation
temporality
they
use
without
a
breaking
version
number,
but
we
can
anyway,
okay,
I'm
getting
sidetracked,
sorry
a
little
scattered
rain.
A
Okay,
so,
first
off,
should
we
allow
changing
the
value
type
between
integer
and
float
I
believe
so
you
know,
if
you
look
at
say
a
Prometheus
model
right.
A
number
is
a
number
is
a
number
the
way
I
write,
queries.
The
way
I
write
alerts
are
all
in
string
fashion.
A
A
We
did
our
best
in
open
Telemetry
to
actually
at
one
point
in
time.
Integers
and
floats
were
like
incredibly
divorced
within
our
API
and
we
unified
them
down
into
one
little
point
where
in
the
protocol
there's
a
single
one
of
that's,
either
an
integer
or
a
float
and
effectively
the
whole
process
is
supposed
to
treat
them.
Is
you
know
it
doesn't
matter
if
it's
an
integer
float
inside
of
the
hotel
data
model?
A
A
I'm,
pretty
sure
back
ends
can
always
convert.
Let
me
let
me
switch
to
the
Note
Tab,
so
I
can
actually
take
notes
of
what
we're
saying
that
was
Ted
or
what's
what's
your
name
today,
there's
an
app.
B
A
So
I'm,
what
I've
been
thinking
about
is
like
conceptually
in
hotel.
We
could
say
that
our
data
model
enforces
numbers
and
numbers
can
be
represented
as
integers
or
floating
points,
depending
on
what's
a
more
optimal
presentation
on
the
computer,
but
we
actually
don't
enforce,
which
one
it
is
at
all
and
any
back
end.
That
assumes
that
integers
will
always
be
integers
and
floats
will
always
be
floats,
needs
to
be
updated.
A
That's
like
one
way
we
could
approach
this
and
we
treat
it
as
like
a
Precision
problem.
The
other
way
we
can
approach.
This
is
actually
you
know
the
stream
is
guaranteed
to
be
integer
instead
of
just
numeric
I.
Think
so
part.
Why
do
we
have
this
distinction
between
inflow
anyways,
instead
of
just
numeric
I?
A
Think
it's
because
some
back
ends,
Google
is
included,
actually
does
make
a
distinction,
and
so,
in
my
back
end,
I
can
actually
write
integer
points
and
it's
more
efficient
than
writing
floating
Point
numbers
and
will
my
back
end
break
if
you
switch
between
it
and
float
in
a
major
version,
number
kind
of
it's
weird
it's
hard
to
describe
so
basically
it
won't
and
it
will
but
like
80,
of
what
you
do
should
work
just
fine,
because
we
don't
run
on
JavaScript
but
IEEE
floating
point.
Isn't
the
only
float?
A
Yeah
and
from
an
Hotel
standpoint
we're
a
protocol
buffer
right
yeah.
So
our
floating
point
is
the
protobuf
floating
point
has
limits
too?
If
we
really
care
about
backends
I,
think
we
do
what's
what's
the
AWS
cloudwatch
limit,
anyone
know
like
Max
values,
less
than
max
value
of
float,
yeah,
that's
true!.
A
Okay,
so
so
not
in
my
experience,
sorry,
my
mic
is
busted.
Today,
no
worry
James
I'll,
just
read
what
you
say
out
loud
Okay.
So
let's
take
a
quick,
a
quick
vote
and
we
can
go
to
the
spec
committee
with
us,
possibly
as
a
proposal
do
we
feel
like
it's
important,
to
distinguish
between
inflow
in
our
data
model
and
preserve
that
or
do
we
think
we
should
push
to
not
preserve
it
in
hotel
for
the
flexibility
like?
Do
we
see
this
flexibility
as
something
we
need
in
instrumentation.
A
B
But
that
is
problematic
because,
like
how
do
I
look
at
the
Proto
message,
there
is
so
there's
get
get
float,
Get
Inked
on
the
on
the
on
the
Proto
and
then,
if,
if
it
changes,
then
I
mean
how
do
I
know
which
one
for
this
United
conventions
do.
A
D
We
haven't
exercised
this,
but
we
were
proposing
that
in
general,
if
you
can
create
a
schema
translator
that
will
successfully
identify
the
version
of
the
data
you're
getting
and
the
version
you
want
and
translate
it
for
you,
then
that's
not
breaking
stability,
so
this
would
be
an
example
of
that
right.
A
So
I'm
actually
I'm
proposing
that
this
would
be
cool,
regardless
of
schema,
so
I
think
all
of
our
notion
sustability
need
to
ignore
the
schema
translation
stuff
to
begin
with.
So
the
question
here
is:
do
we
think
the
otel
community
today
is
treating
int
and
Float
as
it
could
change
any
particular
message
point
because
from
the
protocol
standpoint
it's
actually
okay,
we
don't
actually
make
any.
A
If,
if
you
look
in
the
details
of
the
data
model-
and
you
look
in
the
details
of
how
things
are
specified,
we
actually
make
no
guarantees
of
whether
or
not
something's
an
integer
or
a
float
and
in
some
languages
it's
impossible
for
us
to
have
one
versus
the
other
right.
A
A
If
we
I
I
I
I'm
on
the
fence
here
myself
again,
like
I,
said
I
think
I'm
80,
okay
and
20
broken.
If
this
Behavior
shifts
for
a
given
time
series
in
like
our
internal
storage,
if
I
look
at
Prometheus
Prometheus
is
totally
fine,
it
doesn't
give
a
crap.
We
have
to
turn
everything
into
floating
Point
anyway
right.
A
If
we
look
at
other
back
ends,
I
think
the
story
might
be
nuanced.
If
I
look
at
JavaScript,
though
right
and
I
say
like
can
I
enforce
this
from
a
send
conf
perspective
in
JavaScript
I
think
the
answer
is
no.
A
So
what
kind
of
experience
do
we
want
to
give
to
otel
users,
and
what
does
that
need
to
look
like
I
am
totally
on
the
fence
here
personally
of
whether
we
should
say
yes,
switching
between
integer
and
Float
is
breaking
or
no
that's
outside
the
scope
of
what
we're
going
to
enforce
and
that's
an
allowable
change.
That's
an
implementation
detail.
We
won't
even
encode
it
in
semantic
conventions.
Right,
I
think
those
are
the
two
options
we
could
go
with
quick
vote,
though,
because
we're
running
out
of
time
on
on
some
of
this
time
box.
A
B
We're
almost
saying,
maybe
we
could
take
the
easier
option
which
is
I,
suppose
enforce
it
for
now,
and
then
change
it.
If
someone
came
comes
and
says
that
we
really
need
to
not
enforce
it,
yeah
I
think
we
should
probably
bring
this
to
a
broader
group.
Okay,.
D
C
The
most
compelling
argument,
I
heard,
is
the
that
some
languages
can't
differentiate
anyways.
So
how
can
we
differentiate
in
the
spec
require
differentiation
in
the
spec.
B
D
There
just
throwing
this
out
there.
Is
there
a
downside
to
just
saying
for
all
of
the
metrics
we're
defining
as
semantic
conventions
we
just
use
flukes.
A
A
Also
totally
acceptable,
honestly,
like
I,
think
that's
fine
too,
like
yeah
so
hold
on.
A
All
everything
else
is
a
dub
right,
so
we
could
also
go
with
that
as
as
a
thing
where
we
say
in
languages
where
it
matters
like
assume,
counters
or
integers,
and
but
that
doesn't
make
sense
when
you're
measuring
megabytes
right,
like
for
network
network
usage,
okay,
I
think
so
for
for
in
terms
of
action
items,
I
think
what
we'll
do
is
we'll
take
this
feedback.
Let's
come
to
the
spec
meeting
tomorrow
with
a
proposal.
A
I
think
the
proposal
that
I'm
going
to
throw
out
there
because
it'll
create
the
best
discussion
is
the
most
aggressive
proposal,
which
is
we're
not
going
to
enforce
this,
and
then,
let's
see
how
many
people
complain
and
what
the
what
the
arguments
are
against
it.
Does
that
sound
good,
yeah,
cool
Okay
so
effect
when
you
suspect
meetings.
A
Okay,
we
have
two
more
things
to
talk
about
here,
but
I
think,
given
time
box
I'm
just
gonna
quickly
highlight
them.
One
is
explicit:
bucket
boundary
changes
on
histograms,
whether
we
consider
the
use
of
breaking
change.
One
thing
I
want
to
show
I'm
just
going
to
show
this
real
quickly.
This
is
my
Prime
ql
cheat
sheet
reference
that
I
always
use
every
time.
I
write
prompt
ql
because
I
hate
the
language,
but
it's
also
the
only
one
that
like
is
common
anyway.
A
When
you
look
at
histogram
quantiles
right,
what
we've
done
is
we're
trying
to
move
people
off
of
summaries
and
histograms.
If
you
look
at
how
a
histogram
is
computed,
it's
basically
hey
give
me
a
quantile
where
you
grab
a
rate
from
bucket
and
those
buckets
are
this
Le
label
in
Prometheus?
So
it's
actually
true
that
for
the
most
part,
if
we
change
the
buckets,
this
query
does
not
change
at
all
and
would
remain
the
same
and
still
compute
the
same
quantile.
A
The
question
here
is
for
us:
do
we
want
to
consider
explicit
bucket
boundary
changes?
Breaking
we
heard
from
Prometheus
that
some
people
actually
look
at
specific
buckets.
I
cannot
confirm
or
deny
that
I
haven't
seen
evidence
of
it
myself,
but
from
an
Oto
standpoint,
I
think
we
could
take
a
harder
stance
here
around
keeping
histograms
kind
of
flexible.
A
So
that's
that's
an
open
question
we'll
get
back
to
that
in
a
second,
the
next
one
to
think
about
we'll
get
back
to
that
after
we
get
through
all
the
other
items
agenda
items
last
one
is
around
attribute
types
is:
should
we
allow
the
types
of
attributes
to
change,
and
that
has
the
same
debate
that
we
just
had
around
types
but
for
attributes
and
I
think
this
one's
actually
more
significant?
A
D
Yes,
so
we
don't
have
to
solve
this
today.
I
think
it's
a
big
topic,
but
something
I've
already
experienced.
If
we
want
to
stabilize
all
these
conventions,
we
need
to
actually
review
them
with
subject
matter
experts.
First,
those
subject
matter.
Experts
often
are
not
already
involved
in
open
Telemetry,
because
they're
experts,
in
like
databases
and
things
not
experts
in
you,
know
Telemetry
systems.
So
there's
a
bit
of
a
process
around
going
to
member
organizations
and
saying
like
hey,
you
know:
can
you
bring
some
mongodb
experts
to
come?
D
Look
at
this
with
us
or
whatever,
and
usually
so
far.
The
response
I
get
is
yes
totally
at
our
next
planning
cycle.
You
know
we
can
like
talk
about
this
and
then,
if
they
do
say
yes
in
a
planning
cycle,
you
know
were
agreed
to
give
people
some
of
their.
You
know
work
time
to
look
at
this.
We
kind
of
have
to
then
be
ready
to
do
it,
because,
if
we're
not
prepared,
then
like
they
just
disappear,
and
it's
very
hard
to
get
them
to
come
back
after
that.
D
So
I
just
want
to
throw
that
out
there
as
I.
Don't
know
if
we
need
to
spill
that
value
and
talking
about
it
today,
but
getting
some
kind
of
thing
where
we
put
this
stuff
on
the
calendar.
Maybe
this
is
different
from
how
we
normally
work,
we're
usually
kind
of
reactionary
but
yeah.
We
can
instead
be
like
so
here's
how
we're
going
to
deal
with
all
the
semantic
conventions.
A
Yeah
yeah
so
right
now
we
have
the
three
working
groups
or
what
database
HTTP
and
messaging
right.
Yes,
yes,
okay,
database,
HTTP
and
messaging.
How
close?
How
close
would
we
say
are
each
of
these
in
the
sense
of
does
it
make
sense
for
us
to
go?
A
For
example,
HTTP
I
know,
has
a
good
group
of
of
experts.
I
know
we're
going
to
talk
about
the
database
stuff
now.
Does
it
make
sense
for
us
to
preemptively
go
reach
out
to
them?
Get
a
group
together.
Here's
my
thinking,
okay!
This
is
this
is
how
otil
tends
to
work.
We
do
something
once
and
it's
high
friction.
High
discussion,
High
touch
and
we
figure
out
how
the
hell
it
looks
and
how
and
how
to
like
go
from
A
to
B
and
then,
after
that,
we
turn
it
into
a
repeatable
process.
A
So
I
would
like
to
pick
one
of
those
three,
whichever
one
we
think
is
going
to
be
able
to
make
the
most
progress
quickly
and
we
and
we
figure
out
how
to
get
the
subject,
matters
to
come
in,
evaluate
things
and
get
the
things
through
and
Mark
stable.
D
So
yeah,
so
we've
done
that
with
HTTP
and
metrics
is
in
process.
Database
is
kind
of
the
thing
that
fell
on
the
floor
because
we
didn't
have
this
in
place,
so
my
experience
from
HTTP
and
messaging
is
one.
We
need
to
get
the
technical
Committee
involved
actually
like
in
the
working
group,
so
we
don't
have
this
process
where
we
like
relitigate
everything
twice
or
three
times
we
we
plan
ahead
of
when
we're
going
to
do
it
and
then
make
sure
we
actually
do
it
at
that
time.
D
So
we
I
went
into
the
actual
spec
and
added
like
a
kind
of
project
management
section
to
kind
of
help,
facilitate
this
that
it's
actually,
these
specific
working
groups
where
that
came
out
of
but
databases
is
like
the
example
of
the
thing
where
we
haven't
started
on
it
yet
because
it
turned
out
to
be
hot
hurting
to
try
to
get
the
subject
matter,
experts
here
and
then,
like
everyone
else,
paying
attention
to
them.
A
D
Think
HTTP
is
at
the
stage
where
we
can
work
in
the
stable
I
should
double
check
whether
the
we've
actually
closed
out
the
final
set
of
issues
but
I
believe
we
went
through
our
Charter
with
that
group
and
and
we're
done
you
know,
I've
been
out
for
a
couple
months,
but
I'm
pretty
sure
that
that
one
is
is
that
group
is
satisfied
with
it.
We
don't
need
to
to
review
it
if
you've
closed
out.
All
the
issues
that
are
been
made
messaging,
I
think
is
still
still
ongoing
messages.
D
D
A
Yeah,
what
can
we
take
the
HTTP
group
and
get
metrics
and
logs
stabilized
if
or
or
say,
we're
not
going
to
do
anything
with
logs
or
we're
not
going
to
do
anything
with
metrics,
either
one
and
then
and
then
flush
flush?
You
know
flush
that
a
lot
get
that
marked
as
stable
and
then
kind
of
use
that
to
figure
out
the
next
process,
I'd
like
to
like
get
one
thing
done,
I
am
concerned
with
the
being
able
to
get
enough
of
the
attempt.
So
again
we're
always
fighting
an
attention
battle.
A
This
is
an
open
source
problem
right.
Can
you
get
the
approvers
attention
in
time
to
pay
attention
to
what
you're
doing
in
all
the
various
things?
So
if
we
go
Broad
right,
we
saw
we
have
that
one,
the
set
of
PRS
where
it's
like
person
approved,
but
we
need
four
right.
Let's
make
sure
that
we
have
the
attention
of
everybody
at
the
right
time,
so,
let's
get
HTTP
through
then
next,
let's
take
on
it
sounds
like
messaging's,
the
next
active
one,
and
then
databases
is
the
third
active
yeah.
A
So
if
we're
going
to
order
them,
that
seems
reasonable
right,
but
let's
try
to
get
the
HTTP
one
kind
of
through,
including
metrics
or
maybe
we
just
Mark
the
trace
as
part
of
stable.
And
then
we
come
back
to
metrics
later
I,
don't
know
I,
just
I
don't
want
to
lose
those
smes
that
we
have
now
if
we
can
get
them
to
finish
the
metrics
part
two.
D
Yeah
On
a
related
note,
I'm,
trying
to
organize
product
manager,
slash
project
managers
to
get
involved
in
the
spec
like
to
to
help.
You
know
not.
We
have
like
a
way
to
define
these
projects
and
whatnot,
but
we
need
people
to
help.
You
know
organize
PC
and
the
approvers
and
everyone
else.
So
we've
got
I've
got
a
couple
candidates
who've
expressed
interest
from
lightstep
and
dynatrace
I.
D
Believe
so
far,
but
maybe
that's
a
you
know
a
to-do
item
for
people
on
the
call,
if
you
know
go
back
to
your
member
organizations
and
if
you
have
someone
who's
like
an
open
source,
related
PM
or
project
person,
see
if
they
can
help
help
with
that
spec
process.
A
B
Okay
definitely
look
focusing
on
my
side
great.
A
All
right,
let's,
let's
get
on
to
this
Advanced
convention
process
thing
so
DB
resources
for
metrics
I-
think
this
is
probably
related
to
the
database
movement
Sean.
Do
you
want
to
yeah
so.
E
A
little
bit
of
context
here,
so
this
is
similar
to
our
other
PRS
that
we
kicked
off
diving
into,
but
we're
coming
from.
Like
Telegraph,
we
specifically
around
the
MySQL
metrics
receiver.
We
identified
some
gaps
there
in
terms
of
what
was
collected,
but
now
we're
on
to
okay.
Well,
now
we
need
to
group
and
query
and
filter
this
data.
E
I
think
that
the
my
sequel
receiver
is
still
in
beta,
so
we
have
some
freedom
in
terms
of
what
we
can
do
there
and
experiment
with
and
see
what
makes
sense,
but
I
think
we
we
have
some
fairly
strong
beliefs
in
in
you
know
what
what
attributes
you
would
like
to
have
on
a
resource
and
I
found
it
interesting.
How
currently
the
only
semantic
conventions
around
metrics
for
databases,
around
client,
specifically
client
connections
and
I,
was
wondering
kind
of
what
the
process
should
be
like.
E
How
should
I
approach
this
in
terms
of
you
know
proposing
a
DB
resource
for
metrics,
specifically
because
right
now
for
Trace,
there's
I
think
like
DB
name,
but
that's
kind
of
where
it
falls
off
like
specifically
we're
thinking
these
ones.
We
use
internally
with
a
number
of
our
Sumo
apps,
around
identifying
specific
databases
to
groups
of
them
so
by
clusters.
E
That's
why
we've
got
like
DB
cluster
name
address
Port
kind
of
a
way
of
collecting
these
things,
so
we
think
they're
they're
relevant
to
pretty
much
any
database
outside
of
my
sequel,
so
I,
just
wanna
I
wanna,
understand
how
to
move
forward
here
and
and
how
we
can
land
on
yeah
the
right
looking
resource.
A
E
A
The
reason
the
reason
I
ask
is
I
know,
for
example,
like
the
Java
instrumentation
folk
do
not
want
to
have
anything,
that's
not
in
the
spec
in
their
repo,
like
semcon
wise,
so
they
rely
on
things
hitting
some
conf
before
getting
added.
Instrumentation
I,
don't
know
how
true
this
still
is.
Trask
I
just
remember
that
was
like
a
policy
previously
and
my.
C
Fear
yeah,
we
do
allow
it,
we
just
hide
hide
it
behind
an
experimental
flag.
E
I
think
that
makes
sense,
I
think
one
one
hesitation
that
we
have
is,
if
we're
going
to
make
those-
and
you
know
immediately
adopt
this
MySQL
receiver-
is
our
new
way
of
suggesting
our
users
ingests
they're,
my
SQL
data.
If
we
start
building
out
experiences
on
these
things,
you
know
I
guess.
The
hesitation
internally
is
like
what.
If
we
build
our
experience
around
this
and
then
ultimately,
we
have
to
change
or
gets
rejected
when
we
try
to
go
to
semantic
conventions.
D
I
think
this
gets
back
to
what
I
was
just
talking
about.
We,
we
need
to
have
like
an
organized
pipeline
of
getting
the
subject
matter.
Experts
together
to
Hash
this
out,
because
I
think
there's
a
big
question
about
what
is
like
a
generic
DB
convention
versus
like
database
specific
conventions
having
duplication.
There
is
really
annoying
and
then,
after
that
group
gets
a
pass
at
it.
We
we
need
to
have
potentially
a
separate
group,
but
somebody
to
actually
go
out
there
and
update
the
instrumentation.
D
We
have
on
file
to
actually
do
this
stuff
and
I'm
a
little
concerned
about
like
I
to
some
degree.
It
doesn't
matter
if
we're
not
stable
yet,
but
this
stuff
is
in
such
wide
use.
D
That
I
am
a
little
concerned
about
is
just
kind
of
like
like
picking
at
these
things,
without
rather
than
kind
of
trying
to
like
take
one
pass
at
it,
get
it
done
and
and
and
move
on.
If
that
makes
sense,.
C
A
I
I
absolutely
agree
with
that.
By
the
way,
the
until
things
are
considered,
stable,
you're,
probably
going
to
run
into
that
friction
of
building
any
kind
of
experience
on
things
right
now,
like
I
I,
feel
that
pretty
hard
there's
been
a
few
experiences
we've
built
where
semcom
changes
have
really
dramatically
hurt
us
because
they
are
drastic
and
kind
of
like
large
swings
in
terms
of
you
know,
thinking
like
oh
we're,
gonna
move
very
dramatically
from
one
style
of
labeling
to
another
right
and
I
want
to
avoid
that
as
much
as
possible.
A
I
think
the
cost
of
US
changing
is
rather
high
in
hotel
right
now,
given
the
adoption
we've
already
seen
just
in
general,
so
one
thing
we
could
do
in
this
group
is:
we
could
actually
make
a
make
a
principle
that
existing
semcon,
regardless
of
how
ugly
you
think
they
are,
need
a
high
pain
factor
to
be
changed
going
forward
right.
A
Maybe
we
just
pulled
that
and
say
everything
we
have
today
is
stable
right
everything
just
the
way
it
is,
and
then,
if
you
want
to
make
changes,
you
have
to
go
through
like
a
V2
kind
of
a
thing
and
when
something
makes
it
into
the
spec,
it's
considered
stable,
which
puts
a
very
high
bar
on
things
going
forward,
but
it
also
prevents
the
bleed
in
terms
of
anyone
who
depends
on
these
things.
Having
churn
oh.
E
Okay,
so
even
now
we're
in
that
kind
of
scenario,
what
can
I
do
so?
Why
I
wanted
to
raise?
This
now
is
kind
of
I'm
hoping
to
like
hedge.
My
bet
a
little
bit
right.
So
if,
like
what
process
can
I
start
like
basically
like
if
I,
if
I
get
the
sense
that
things
are
moving
in
the
favorable
direction,
we're
not
getting
like
immediate
pushback
on
the
semconv.
If
we
can
get
the
subject
matter,
experts
involved
in
that
that's
perfect.
E
Basically,
I
want
to
start
building
experience
now
just
kind
of
hedge,
my
bed
a
little
bit
knowing
that
things
are
going
to
land
that
way
and
then,
if
I
can
say
that.
Okay,
now
that
they've
landed
in
semantic
convention,
I'm
safe
to
further
invest
in
this
experience
kind
of
thing,
so
I'm
just
I
wanted
to
get
this
out
here.
It's
kind
of
like
a
case
study
of
like
how
can
I
navigate
this
so
that
I
I
want
to
do
stuff
on
OT
in
this
specific
receiver
now,
but
like
safely
navigate,
if
that
makes
sense,
yeah.
A
Yeah
I,
so
I
am
like
I
think
this
is
the
right
direction
to
go.
I
think
there
needs
to
be
a
database
semantic
convention,
resource
I,
think
having
having
that
specifically
for
The
Collector
makes
a
hell
of
a
lot
of
sense.
There's
two
things
that
I
would
encourage
you
to
do
going
forward.
A
So
to
it.
This
isn't
the
only
thing.
So
one
is
collect
the
smes
so
go
find
people
you
don't
have
to
find
people
who
actually
know
databases.
You
have
to
find
the
people
who
are
monitoring
the
databases
or
designing
the
connect
like
who
wrote
the
receiver
to
begin
with
right,
pull
them
in,
for
example,
right
so
get
them
together.
Get
that
Coalition
of
people
to
say
here
are
common
conventions.
We
see
across
databases,
you
know
put
that
document
together
around
resource,
so
we
know
what
belongs
in
the
resource.
A
The
second
thing
which
I'm
going
to
call
out
as
important-
and
this
is
a
little
bit
of
politics
and
a
little
bit
of
technical
things,
but
figure
out
Prometheus
and
resource
attributes
so
going
forward
right
Prometheus,
is
in
cncf
they're.
The
big
metric
data
store
we're
the
instrumentation
component
of
cncf
right
now,
we're
labeled
kind
of
as
a
trace,
only
solution
to
be
a
metrics
Only
Solution.
A
We
have
to
be
compatible
with
Prometheus
when
we
move
these
labels
into
resource,
they
don't
show
up
to
Prometheus
in
the
way
that
today's
specification
is
written.
This
is
one
of
the
things
I
want
this
group
to
try
to
fix
a
little
bit
because
I
think
that's
problematic.
We
need
our
experience
on
Prometheus
to
be
first
class.
I
want
there
to
never
ever
be
a
reason
why
there
would
be
contention
between
Prometheus,
instrumentation
and
hotel.
A
You
should
always
pick
a
hotel,
because
it's
better
right
wholesale
and
because
it
does
everything
Prometheus
would
do
anyway
right.
So
that's
that's.
Actually.
One
of
my
concerns
here
is,
if
you
look
at
the
way
the
specifications
written
for
these
things
going
into
Prometheus
Prometheus
would
not
have
access
to
these
labels,
and
that
would
be
that
is
problematic.
A
So
I
think
we
need
to
kind
of
address
that
in
some
fashion,
I
have
a
couple
open
bugs
around
this,
like
what
resource
labels
are
important
to
Prometheus.
The
answer
is
just
these
four
and
nothing
else.
It's
like
okay,
any
case,
if
you,
if
you
want,
we
can
have
a
discussion
elsewhere
about
that,
but
I
think
like
let's,
let's
make
sure
that
experience
is
also
solid
and
then
let's
pull
together
the
smes
I
think
those
are
the
two
things
we
should
do
here
and
that
will
alleviate
a
lot
of
the
friction.
E
A
So
Step
One
is
take
your
collector
receiver,
fire
it
to
the
Prometheus
exporter
and
just
look
at
what's
scraped
and
you'll
see
the
state
of
today
and
you
know:
do
those
do
those
attributes
show
up
then
I
can
let's
follow
up
in
chat
because
I
can
walk
you
through
the
areas
of
the
specification
that
are
problematic.
A
Metric
data
model
spec
defines
the
the
Prometheus
exporter
Behavior,
so
that's
kind
of
what
we're
targeting
and
then
I
can
show
you
all
the
other
bugs
we've
opened.
A
I
think
we're
running
out
of
time.
I
don't
want
to
hold
everyone
over.
That
was
incredibly
useful,
meaning
next
meeting
I
think
we're
going
to
dive
into
probably
the
histogram
bucket
boundaries.
So
if
you
want
to
refresh
yourself
on
that,
whether
or
not
we
should
consider
that
a
breaking
change,
we
can
also
take
that
offline.
A
The
attribute
one
is
also
one
I
want
to
hear
from
people.
If
we
can
grab
expertise
here,
should
changing
the
type
of
an
attribute
be
considered
breaking.
B
A
B
A
B
Right
but
here's
this
is
going
to
be
talk
about,
for
example,
I
have
an
INT
and
then
I
stringify.
It
is
this
allowed
or
or
more
more
convoluted
scenarios
like
is
this
or.