►
From YouTube: 2023-02-01 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
C
A
E
D
E
E
D
They
were
there
in
the
beginning
and
then
they
had
to
drop
saying
will
be
five
minutes
late.
Maybe
they'll
join
after.
E
E
Okay,
I,
then
we'll
move
on
to
the
next
topic,
which
is
the
unit
conversions,
PR,
so
I
think
there
are
still
two
threads
open
and
I'd
love
to
figure
out
how
we
want
to
close
those,
so
we
can
get
this
merged.
The
first
is
about
the
ratio
suffix.
D
D
I
can
double
check
with
him,
but
let's
assume
we
have
consensus
and
close.
That
and
I
will
shoot
him.
A
message
saying
you
know
if
he
has
anything
he
can
always
reopen
the
thread.
E
Converting
to
base
units
so
I
think
we've
discussed
this
before
and
there
was
potential
that
Prometheus
wanted
to
keep
the
naming
the
same.
But
that
doesn't
appear
to
be
the
case.
E
E
F
So,
let's
see
do
you
know
where.
C
He
is
yep,
I,
think
he's
running
late.
Another
call
if
you're
done
with
other
topics
like
I'm
happy
to
cover
for
Khan
I
can
kind
of
walk
through
the
dock.
I
have
some
context
on
that
as
well.
But
if
you
have
other
topics,
we
can
wrap
those
up.
C
C
Any
other
other
topics
why
don't
I
get
started
and
maybe
Khan
can
join
and
provide
more
context
as
needed,
but
yeah
so
the
main
problem.
Hopefully
everyone
has
a
talk
and
they
can
look
at
it,
but
yeah
the
main
problem
we're
trying
to
solve
for
right
now
so,
as
most
of
you
might
know,
with
prometheus's
handling
of
the
unknown
metrics
right
now,
everything
that
is
unknown
by
gets
converted
to
a
gauge
by
the
Prometheus,
receiver
and
I
believe,
like
we
have
the
code
exactly
what
it
does.
C
That
explains
that
in
the
current
behavior,
but
one
of
the
issues
is
for
one
of
our
agents
that
we
use
the
existing
behavior
is
that
we
drop
any
metrics
that
are
of
unknown
type,
because
some
of
these
are
like
internal
metrics
like
the
GC
stats
and
stuff
that
our
customers
typically
aren't
interested
in.
C
So
we
have
a
filter
mechanism
to
drop
anything
that
is
unknown
but
moving
to
Prometheus
receiver,
given
we're
trying
to
adapt
it
now,
it's
posing
as
a
challenge,
because
once
it's
converted
to
a
gauge,
we
don't
know
how
to
filter
on
those,
because
it
just
looks
like
any
other
gauge
to
us
if
we
were
to
use
a
filter,
processor,
so
I
think
what
this
talk
is
trying
to
tackle
is
it'll
be
good.
If
we
can
somehow
preserve
the
notion
that
this
was
this
metric
was
originally
of
type
unknown.
C
And
I
think
we
have
some
examples
as
to
why
we
would
want
to
do
this.
I
think
one
is
mainly
like
I
mentioned:
cost
savings
for
customers
that
don't
care
about
these
GC
stats
or
the
internal
metrics.
They
would
just
want
to
filter
it
out,
so
it's
mainly
cost
savings
for
them,
but
I
think
there's
also
some
other
future
use
cases
where
preserving
this
notion
of
the
original
metric
type
is
going
to
be
useful.
E
You
mentioned
log
ingestion
cost
is.
C
I
think
the
interesting
cost
is
both
in
terms
of
it
kind
of
depends
on
the
back
end
itself.
In
this
case,
we
are
using
cloudwatch
as
a
backend,
so
we
pay
for
both
the
log
industry
cost,
but
also
for
extracting
the
metrics
and
creating
metrics
out
of
those.
So
it's
a
cost
that
will
be
kind
of
twice
foreign.
C
E
C
That's
right,
so
our
immediate
requirement
is
mainly
to
achieve
backwards.
Compatibility
in
our
case.
That
would
be
filtering
it
out,
but
I
think
we've
have
some
ex
some
points
in
the
talk
backing
up
why
it
would
be
good
to
preserve
the
original
notion,
mainly
because,
if
someone
wants
to,
let's
say,
convert
it
to
a
counter
for
their
use
case,
because
a
gauge
may
be
good
for
most
use
cases,
but
not
for
every
single
use
case.
So
someone
might
want
to
do
it
as
a
counter.
A
Hey
so
the
the
the
Prometheus
behavior
is,
we
should
match
whatever
the
Prometheus
Behavior
native
Prometheus
behavior
is
right.
We
we
just
can't
just
build
for
like
one,
you
know
solution
where
you
know
we
will
just
simply
drop
it.
I,
don't
think.
That's
the
behavior
that
Prometheus
then.
F
F
C
Cool
see
we
have
Khan
as
well.
Can
we
be
just
going
over
like
the
intro,
with
the
background
and
like
the
problem
itself,
yeah
I
was
the
one
that
just
got
paged
Khan.
Would
you
mind
taking
over
with
like
the
current
behavior
and
going
over
our
proposed
Solutions.
A
A
A
A
C
B
So
yeah,
the
thing
that
we
are
we
are
thinking
right
now
are
just
yeah
at
the
that
upon
attributes
like
Anthony,
say
and
is
only
for
for
Signal,
the
difference
between
the
unknown
and
unknown
and
Prometheus
gosh.
So
that's
why
further
down
the
process,
we'll
have
like
different
use
case
for
different
use
case,
for
that
attribute,
so
example,
would
be.
B
One
of
the
use
case
we
currently
have
right
now
is
filter
by
using
future
processors
to
remove
other
attributes
that
original
originally
unknowns,
and
another
use
case
would
be
like
use
that
use
that
attributes
to
to
to
show
that
backends
need
to
be
aware
of,
because
some
of
the
backends
are
not
able
to
support
infinitive
value
or
outside
of
like
six
four
bit
values
for
yeah.
So
that's.
Why
that's
why?
It's
that's?
B
Why
we
it's
easier
for
us
to
use
that
that
approach
attribute
instead,
but
there
are
other
options
as
well,
but
the
most.
B
The
two
options
that
we
have
been
discussed
so
far
is
that
we
need
we
can
Trout
the
or
the
unknown
matrix
by
using
a
flag
as
well.
But
I.
Don't
think
that
is
a
referable
solution,
because
it's
not
helping
us
to
have
additional
opportunity
for
all
the
use
case.
So
for
all
the
type
of
metrics
like
you
want
to
do
when
something
is
a
stateful
set,
or
maybe
you
want
to
do
something
when
the
what
what
to
do
with
the
an
unknown
or
enforcer
info
yeah.
F
Another
to
kind
of
expand
on
that,
like
we
had
discussed
using
data
point
Flags
like
the
like.
We
do
for
to
stay
on
this
flag,
but
that's
kind
of
Boolean.
F
F
So
I
think
the
the
question
I
would
have
for
this
group
is
whether
anyone
here
would
have
any
concern
with
adding
to
the
specification
of
Prometheus
conversion
to
and
from
otlp
that,
when
an
unknown
or
unsupported
metric
type
is
encountered
and
converted
that
we
had
an
attribute
indicating
what
its
original
type
was.
E
So
my
only
concern
with
doing
that
by
default
is
that
it
changes
my
metrics.
So
if
I
just
run
like
a
regular
Prometheus
receiver
to
Prometheus
exporter
I'm,
going
to
end
up
with
an
extra
attribute
on
all
of
my
metrics
I
know
yeah.
What's
that
I
wonder?
If
do
you
think
the
attribute
is
still
needed
if
the
metric
comes
in
with
type
information
so
like
if
I
send
it
a
gauge?
Okay,.
E
I
I
think
that
makes
that
seems
like
the
least
bad
solution
to
me
as
well,
and
it's
at
least
straightforward.
F
F
We
could,
if
we
want
in
the
Prometheus
and
Prometheus
remote
Right
exporters
strip
that
attribute
back
off
if
it
exists
or
provides
examples
of
filter
configuration
to
strip
that
attribute
off.
If
you
know
it
doesn't
apply
further
down
the
pipeline.
E
B
A
not
only
concern
for
me
is
that
yeah
customer
needs
to
need
to
aware
of
these
issues
and
it's
a
setup
additional
processors
to
figure
out
attributes
if
they
are
not
wanting
to
so
yeah.
That's
the
only
concern
with
for
every
customers
are
using
permittest
receiver,
so
yeah.
B
B
B
Another
question
for
me
is
that
if
we
interrupt
this
intervals
in
the
same
con,
do
we
need
to
where
do
we
need
to
include
the
effort
with
the
release
cycle
of
the
same
con
as
well?.
E
I
don't
know
if
this
would
be
a
semantic
Convention
as
much
as
a
just
part
of
the
compatibility
specification.
F
Yeah,
that
was
one
thing:
I
wasn't
quite
sure
when
Kevin
and
I
were
discussing
this
yesterday
was
where,
where
the
specification
would
live,
if
that
goes
into
symmetic
conventions,
or
if
it,
if
it
just
goes
into
the
conversion,
spec
and
that's
sufficient
I,
think
either
way
works
for
me.
So
the
important
thing
is
that
it's
a
well-known
attribute
that
processors
and
receiver
and
exporters
can
react
to.
E
If
it
were
something
that
we
needed
to
use
or
that
we
wanted
to
use
in
per
language
exporters,
then
I
might
see
the
value
in
having
it
in
semantic
conventions
so
that
all
the
tooling
can
handle
it.
I,
don't
know
if
there's
as
much
value
in
doing
that,
if
it's
just
in
the
collector's
Prometheus
receiver.
E
F
Right
if
we
have
to
have
a
constant
to
identify
that-
and
we
want
to
put
it
in
one
place-
is
a
dimensional
place
to
put
it,
but
there
are
probably
other
ways
to
solve
that.
You
solve
for
that
as
well.
Within
the
collector.
E
F
F
E
Yeah
make
sure
we
update
the
spec
issue
with
the
outcome
of
the
discussion
here
and
then
yeah.
We
can
open
up
PR.