►
From YouTube: 2022-09-14 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
B
A
C
Yeah,
but
we
usually,
we
wait
one
more
minute
or
two
more
minutes
for
people
to
come.
We
can
start
that.
C
Okay,
so
first
first
thing
we
are
getting
very
close
to
data.
C
A
A
A
That's
that's
the
final
goal,
isn't
it,
but
I
mean
for
right
now
so
for
this
purpose
here
okay
sounds
sounds
good
to
me,
who
is
consuming
p
data?
A
I
mean
who
do
we
want
to
test
those
frequent
vertices.
A
E
The
the
one
worry
I
would
have
with
that
is
that
if
this
is
intended
to
get
more
releases
out
to
accelerate
breaking
changes,
we're
compressing
the
timeline
which
I
think
is
part
of
why
we
wanted
to
ensure
we
had
multiple
releases
between
announcing
a
change
and
affecting
it.
So
while
I
I
see
this
could
move
us
forward,
it
could
also
move
us
forward
faster
than
people
who
are
taking
dependencies
on
us
might
be
comfortable
with
so
make
sure
everyone's
aware
of
that.
C
C
B
Google's
perspective,
I'm
happy
to.
C
B
C
A
C
C
We
can
have
that
debate
if
it's
okay,
what
happened
there,
but
I
think
we
should
wait
for
the
release
of
the
specification
because
before
we
start
implementing
things
from
specification
as
any
any
rfc
any
documentation
until
is
released,
it's
a
work
in
progress
for
that
time.
So
taking
a
dependency,
it's
it's
not
good
anyway!
Yes,
anthony
can
be,
can
be
a
new
rule
for
all
the
sikhs.
But
I
I
I
don't
influence
all
this.
I
mean
we
are
here
discussing
about
collector
and
the
contrib.
So
let's,
let's
focus
on
that.
C
I
I
would
prefer
for
us
to
to
have
this
new
rule
in
mind
that
we
don't
accept
changes
that
are
not
released
yet
in
the
specification.
D
You
does
this
need
to
be
added
to
the
contributing
doc.
E
C
B
I
was
going
to
are
semantic
conventions
considered
stable
now
because
I
don't
know
if
we
can
prevent
people
from
using.
I
don't
know
house
dot,
name
or
service
dot,
name.
B
C
So
so
the
there
is
a
effort
to
to
stabilize
them,
and
even
if
they
are
not
stable,
the
way
how
it
works
right
now
we
we
have
that
schema
url
the
the
version
of
the
the
semantic
conventions
and
we
produce
they.
They
have
that
schema,
transform,
processor
or
whatever,
which
is
capable
of
transforming
from
from
one
version
to
another.
So
even
if
may
change,
we
we
have
a
mechanism
to
upgrade
to
back
and
forward
between
different
versions
and
stuff
like
that,
may
not
be
ideal,
but
that
mechanism
is
in
place.
B
C
It
is
you're
right
pablo,
but
but
if
that,
if
we
have
to
deal
with
that,
we
have
to
deal
with
that,
and
probably
it
will
happen
once.
But
let's
not,
let's
not
cause
more
troubles
for
us
by
implementing
unreleased
things,
because
those
are
more
likely
to
to
change
than
the
other
one.
B
F
C
So
so,
who
wants
to
take
a
lead
on
documenting
this,
and
maybe,
as
part
of
the
documentation
david?
We
should
also
say
these
kind
of
things
like
you
should
use
a
feature
git
for
these
things.
If
you
really
want
to
have
it
implemented
to
prototype
and
stuff
like
that,
so
maybe
we
we
define
better
the
rule.
E
Oh,
I
can
take
a
stab
at
some
language.
We
want
to
put
it
in
the
contributing
talk,
so
we
said
alex.
C
C
Next
one
is
a
request
coming
from
a
gc
member
who
got
confused
about
our
query
language
so
so
yeah.
The
history
here
is
ben
somebody
went
to
ben
who,
who
is
a
ceo
of
a
company
lifestep
which
has
bunch
of
users
in
in
tracing
matrix
world,
and
because
somebody
went
to
him
and
asked
him
hey.
Look.
You
have
a
query
language.
You
should
support
this
on
your
back
end
and
then
we
we
got
the
confusion
that
oh,
this
is
not
the
query
of
the
telemetry.
C
Is
it's
a
language
that
we
are
using
to
to
manipulate
the
data
on
in
our
pipeline?
So
because
of
that,
I
think
there
is
a
good
good
point
coming
from
him
that
I
think
we
should
not
name
this
query
language
and
maybe
transform
language
or
or
something
like
that.
There
are
a
bunch
of
proposals.
C
So,
let's,
let's
make
sure
oh
jurassic
good
point,
so
you've
seen
this
confusion
as
well,
so
so
yeah,
let's,
let's,
let's
take
a
stab
and
and
maybe
clarify
the
name
now
that
is,
is
not
to
we
are
not
too
far
away
like.
I
think
we
can
still
change
the
name.
So,
let's,
let's
do
it
and
I
would
like
to
hear
opinions
about
the
name.
I
saw
a
bunch
of
people
voting
one
or
the
other.
Do
we
have
an
agreement.
F
So
I
think,
I'm
okay
with
either
telemetry
transformation,
language
or
telemetry
expression,
language.
F
If
this
is
a
telemetry
generic
package
which,
right
now
it
is
so
bogdan,
you
had
mentioned
open,
telemetry
transformation,
language,
and
I
like
that
one
if
we
lock
this
down
to
only
open
telemetry
data,
but
right
now
nothing
in
the
grammar
makes
it
specific
to
well.
I
guess
the
only
thing
that
makes
it
specific
is
the
transform
context,
but
it
doesn't
have
to
be
like
we
could
update
the
transform
context,
remove
the
concept
of
resource
and
instrumentation
scope
and
then
it
would
be
completely
generic
and
there
would
just
be
a
item.
F
Correct
the
contexts
are
definitely
specific
to
open
telemetry,
but
the
grammar
itself
could
take
any
type
of
context.
We
just
happen
to
provide
some
for
users
to
make
it
easier.
F
Most
functions,
we
split
the
functions
between
common
and
open,
telemetry,
specific
functions,
yep
so
right.
C
B
A
Yeah,
so
before
moving
forward
so
hooking
on
on
the
point
that
you
had
before
tyler,
do
you
see
that
language
being
implemented
by
other
folks
if
they
want
to
like
seeing
the
language
as
generic,
I
feel
like
the
same
engine
could
be
implemented
by
some
other
project
and
keeping
the
grammar
so
that
users
could
move
configuration
from
one
place
to
another?.
F
Yeah
I
mean
that
was
kind
of
the
original
vision
that
honor
rock
had
was
just
like
generic
telemetry.
He
called
it
telemetry
queer
language,
telemetry,
processing,
language,
whatever
the
goal
was
to
use
it
in
the
transfer
in
the
collector
and
specifically
in
the
transform
processor,
but
I
think
he
had
ideas
that
it
could
be
used
anywhere.
F
That's
why
it
was
moved
into
a
package
versus
internal
with
the
intention
of
like
hey.
This
could
be
used.
You
know
by
anybody
anywhere
who's
interested
in
this
type
of
transformation.
A
And
so
that
yeah
that
that
was
going
to
have
my
second
question
I
mean:
do
we
get
better
user
experience
if
we,
if
we
focus
on
open
telemetry
set-
and
I
think
your
answer
is
based
on
what
it
is.
F
I
think
the
answer
is
yes,
especially
when
we
start
so
evan
just
contributed
a
a
logger
kind
of
like
str
rapper
for
the
grammar
allowing
components
to
pass
in
loggers.
Essentially,
if
we
make
it
open,
telemetry
specific,
we
can
go
one
step
further,
which
is
what
bogdan
had
suggested
and
start
passing
in
the
entire
contacts
and
then,
like
the
processor,
has
access
to
more.
C
F
B
I
came
into
this
pretty
agnostic
and
now
I'm
feeling
like
the
value
of
letting
anybody
use.
It
is
there's
value
there,
but
probably
more
value
in
having
a
good
high
quality,
good
user
experience
for
open
telemetry
users,
specifically
in
this
language,
rather
than
kind
of
forcing
this
separation
being
able
to
make
this
language
more
robust
and
more
useful
across
more
processors
is,
I
think,
probably
the
the
win
here.
So
I'm
kind
of
in
favor
of
that
direction
and.
F
C
Because
I
believe
I
believe
we
want
to
build
a
large
ecosystem
with
the
processors
and
stuff
and
and
we'll
we.
We.
I
think
it's
going
to
be
very
useful
to
have
this
very
powerful.
F
Yeah
and
then
leaving
it
in
package
so
that
that
you
could
like
the
people
that
are
using
it,
can
be
any
custom
processor.
That's
the
generality
that
we,
like
it
value
from
that'll,
have
if
we
do
go
with
that
way,
that
that
solution,
which
I
feel
like
we
are,
that
has
some
pretty
major
implications
for
context.
We
we
might
honestly
be
able
to
like
integrate
context
more
natively
into
language,
but
whatever.
If
we
go
that
way,
my
vote
for
the
name
is
definitely
ottl.
The
open,
telemetry
transformation,
language.
F
A
Right
exactly
so,
I
think
expression
makes
it,
I
think,
easier
to
digest
when
within
other
within
other
components
like
the
routing
processor.
So
if
we
say
like
transformation
language
within
the
broaching
processor,
it
really
is
just
a
read-only
path
there,
so
we're
not
doing
any
transformations
in
there.
So
I
think
I'd
prefer
expression.
Instead.
F
I
really
enjoyed,
I
really
enjoyed
alex's
hotel
squared
the
hotel.
E
C
Let's,
let's
make
a
poll
between
transform
so
so
we
all
agree
that
we
will
prefix
it
with
open
telemetry
now
yeah
the
the
question
for
the
vote
we
have
is
between
expression
or
transform
or
transform
expression.
I
think
I
saw
one
option
so
let's
have
these
three
options
and
have
three
multi
cons
on
a
somebody
has
to
add
a
comment
with
three
emoticons
and
everyone
can
vote
there
using
the
three
emoticons
alex.
Can
you
do
that?
Because
you
are
good
on
drawing
already.
B
G
Yeah
thanks,
hey
everyone.
My
name
is
jake
baranov,
I'm
the
tech
lead
of
the
telemetry
pipeline
team
at
lightstep,
and
today
I
wanna
to
bring
this
proposal
to
everyone
about
some
work
that
we're
gonna
be
doing.
Would
it
make
sense
to
share
screen
as
I
go
through?
The
proposal
is
that
is
that
good
cool.
G
I'm
also
on
a
big
monitor,
so
I'm
going
to
increase
the
display
size
with
the
zoom
like
this.
G
So
I'll
read
through
the
proposal
and
then
we
can
maybe
have
some
discussion
from
it.
So
the
overview
is
the
collector
has
a
vision
for
what
observability
it
should
be
emitting
that
vision
is
sort
of
from
2019
and
as
more
people
run,
the
collector's
scale
in,
like
you
know
as
many
configurations
as
exists,
there's
definitely
a
need
to
make
it
easier
to
operate
and
understand
the
collector
in
any
environment
that
is
running
and
whatever
telemetry.
G
It's
collecting
we're
doing
this
right
now
on
at
like
adelaide
step,
we're
running
it
in
kubernetes,
primarily
and
running
lots
of
tests
with
lots
of
different
pipeline
configurations
and
starting
to
get
very
difficult
to
understand
which
pipeline
is
doing
what
where
data
may
be
getting
dropped
and
what
data
is
actually
getting
processed.
G
So
with
the
ga
of
the
gometrix
sdk
planned
for
the
fall
and
with
a
lot
of
the
work,
that's
already
been
done
to
integrate
otel
into
the
collector,
which
is
already
behind
the
gate.
G
So
this
whole
document
is
sort
of
the
place
to
add
comments.
If
anyone
has
comments,
I'd
love
to
keep
those
comments
on
document,
but
obviously
we'll
talk
about
it
in
this
call
as
well.
The
audience
for
this
is,
for
you
know
any
sre
or
devops
that
is
actually
running
the
collector
in
their
environment
and
wants
to
have
some
way
of
observing
the
telemetry
data
that
the
collector
may
be
emitting.
G
As
part
of
this
proposal,
we
have
three
milestones.
The
first
one
is
actually
migrating
to
the
otel.
Go
metrix
sdk
for
collector
observability,
then
will
be.
The
second
milestone
is
the
enhanced
configuration
options
right
now?
The
collector
can
only
emit
prometheus
data,
which
is
then
scraped
by
a
prometheus
receiver.
G
G
We
have
an
idea
of
a
few
metrics
that
we
think
could
be
really
valuable
here,
we're
essentially
proposing
adding
each
metric
for
each
component
in
a
pipeline,
so
receiver,
processor,
exporter
and
extension,
adding
suite
of
metrics
for
each
one
of
those
components
with
the
goal
being
that
it's
ultimately
a
non-breaking
change
that
just
you
know,
gives
more
observability
to
anyone
operating
a
collector
in
order
to
actually
get
this
done.
G
All
these
milestones
done
our
team,
my
team
is,
is
going
to
be
working
on
this
and
is
hoping
to
work
on
this
in
fall
of
this
year.
With
sort
of
you
know
going
forward,
we're
happy
to
continue
maintaining
and
adding
features
as
well.
G
There
are
a
few
risks
that
we
called
out
here,
the
main
one
being
the
ga
instability
of
the
geometric
sdk
right
now
there
is
a
blocking
issue
on
using
the
open
census
bridge
which
is
sort
of
blocking
the
full
use
of
hotel
in
the
collector,
but
other
than
that.
That's
sort
of
the
main
thing
that
we
noticed,
I'm
happy
to
add
any
more
risks
that
people
might
might
know
and
then,
in
the
future.
G
There
is
also
the
idea
of
emitting
a
similarly
formed
group
of
metrics
in
the
s
in
the
sdks
themselves,
so
that
you
could
pretty
easily
correlate
data.
That's
going
from
an
sdk
to
a
collector
and
then,
ultimately
to
some
you
know,
data
store,
telemetry
store
to
get
that
full
pipeline
observability
so
that
that's
sort
of
the
summary
or
the
I'm
not
looking
at
chat.
I
don't
know
if
there's
been
any
questions,
but.
C
So
I
think
I
think
I
want
to
correct
some
of
the
assumptions
in
this
doc.
First
of
all,
ops
report
is
actually
the
implementation
of
that
vision.
Document
is
not
separating
so.
The
misconception
here
is
that
we
will
get
rid
of
the
ops
report.
I
think
that's
that's
not
what's
going
to
happen
or
unless
there
is
a
good,
better
proposal
the,
and
why
should
we
do
that?
C
And
I
think
that
was
one
of
the
thing
that
we
did
with
that
was
to
to
be
able
to
standardize
the
metrics
across
components
by
having
some
standard
metrics
across
all
these
components.
So
I
I
don't
know
how
you
explain
it
or
why
you
think
that's
a
better
idea
to
get
rid
of
that
and
use
the
gold
sdk,
the
the
open,
telemetry
goal,
which
I
don't
think
it
is.
But
anyway
we
can
debate
that
the
other.
G
Side-
that
is
that's
a
mistake
on
my
part:
it's
not
to
actually
remove
obs
report
in
its
entirety.
It's
more
to
migrate,
ops
report
to
use
hotel,
that's
okay,.
C
But
that's
already
that
was
already
our
plan.
We
just
hit
a
lot
of
blockers
from
what
will
go
like
we.
We
tried
to
do
that
for
an
year
and
a
half
and
we
cannot
get
it
there
because
hotel
goal
is
not
ready.
It
doesn't
give
us
a
bridge
and
doesn't
give
us
a
way
to
migrate.
So
yeah,
that's
it's
it's
not
that
we.
We
didn't
have
that
goal.
A
Yeah
there
are
a
few
items
that
you
mentioned
here
that
I've
opened.
I
was
really
expecting
to
get
into
a
state
where
we
could
add
observability
to
the
collector.
I
think
I
was
mentioning
to
someone
else
that
it
was
kind
of
ironic
that
observability
for
the
collector
is
really
poor.
A
You
know
we
should
know
a
thing
or
two
about
observability
and
it's
bad
that
the
collector
cannot
be
observed
in
a
in
a
sufficiently
in
a
good
way
today.
The
problem
is
that
indeed
we
cannot.
We
still
do
not
go
as
the
case
already
and
anthony's
here,
and
he
can.
He
can
confirm
that.
A
I
know
you
know
I
ping
him
every
week
or
every
couple
of
weeks
asking
what
is
the
state
of
the
go
sdk
and
we
have
someone
that
griffin,
also
trying
to
help
on
the
usdk
either
is
helping
already
or
is
planning
to
help.
I
guess
the
point
is
we
do
have
that
on
our
radar
and
I
think
it
is
a
it's
great
to
see.
You
know
you
offering
help.
A
I
think
it's
something
that
we
actually
need
some
help
in
there
once
we
get
unblocked,
because
there
is
a
lot
of
of
work
that
we've
planned
to
do
over
the
past.
I
don't
know
three
years
so
2019
2022,
so
there's
a
lot
of
things
that
we
have
to
do
and
we
appreciate
any
help
we
can
get.
A
I
and
I
speak
for
myself
here,
I'm
just
before
the
project,
but
one
thing
that
I
would
add
here
on
your
milestones
is
a
milestone,
4
and
perhaps
change
the
milestone
3,
so
that
we
instrument
a
few
components
and
then
we
prepare
all
of
the
documentation
for
component
developers
based
on
milestone.
Three
and
milestone.
Four
will
then
be
convince
component
owners
to
improve
the
observability
of
their
own
components,
because
we
cannot
be
expected
to
you
know,
instrument
all
of
the
components
out
there.
A
I
I
will
myself,
you
know
just
look
at
the
components
that
we
have
on
contrib.
I
just
wouldn't
instrument
everything
by
myself,
so
we
should
have
a
very
good
documentation
for
component
owners
to
instrument
their
components
and
perhaps
have
a
milestone
for
for
that
something
else
that
we
talked
about,
and
I
don't
think
that
you
are
covering
that
here
at
least
not
explicitly
is
perhaps
it
is
the
final
part
of
the
milestone
one
or
most
on
t,
and
it
is
to
configure
the
optel
sdk
to
on
how
to
export
this
data.
A
I
think
bogdan
has
mentioned
a
I
don't
know
a
year
ago
or
so
that
we
could
have
a
different
type
of
configuration
on
the
collector
so
that
we
can
configure
what
is
the
pipeline
for
the
internal
telemetry
that
we
generate,
because
we
we
probably
want
is
a
different
type
of
pipelines
for
the
internal
telemetry
data
than
the
external
telemetry
data
external.
Here
being
you
know
the
ones
that
you
receive
through
the
regular
receivers,
so
I
would
suggest
going
through
the
perhaps
the
meeting
notes
or
the
recordings.
A
I
don't
know,
what's
the
best
way
to
find
that.
But
there
was
a
discussion
on
this
topic
a
year
or
so
or
so
ago.
E
Yeah,
I
I
think
that's
an
important
thing
to
call
out
here
too
is,
but
I'm
not
sure
I
see
keeping
the
internal
telemetry
pipeline
separate
from
the
pipelines
that
are
normally
processed.
I
think
we
we've
also
talked
at
points
past
about
being
able
to
connect
pipelines
to
each
other.
You
know
to
have
the
output
of
one
go
as
the
input
of
another.
A
That,
well,
I
think
we
we
discussed
that
all
on
on
that
call
that
I
mentioned,
and
I
think
that's
a
good
starting
point,
but
I
remember
one
of
the
arguments
back
then
that
it
would
be
inefficient
to
send
hotel
p
on
an
internal
receiver
just
to
export
somewhere
that
we
know
it's
external
already.
So
if
I
want
my
metrics
my
collector
metrics
to
get
to
promise
use,
for
instance,
then
why
should
it
go
through
hlp
and
then
be
converted
again
into
promises.
C
E
C
E
E
Yeah
we
have
one
issue
left
to
go
before
we
release
a
go
sdk
alpha
that
blocker
is
going
to
disappear
very
rapidly.
I
think
okay.
D
No
sorry
so
hi,
I'm
david
I've
been
driving
the
open
census
bridge
work
in
the
spec,
as
well
as
in
the
go
api
and
sdk.
D
C
D
I
was
going
to
say
as
soon
as
we
have
the
spec
pr
that
I've
been
working
on
in,
like
the
bridge
is
trivial
to
implement
all
the
logic
is
implemented.
We
just
haven't
plugged
it
in
because
there's
no
place
to
plug
it
yet
so
we
should
keep
our
options
open.
I
think,
but
yeah
you're
right,
maybe
if
the
bridge
is
still
stalled.
When
we
want
to
do
this,
we
can
work
around
it
a
different
way.
A
I
think
there's
another
aspect
to
that,
and
I
think
I
did
use
this
argument
before
that.
A
We
we
have
a
great
opportunity
here
to
be
the
role
models
for
adopting
hotel
hotel,
sdk
hotel
apis,
so
using
the
bridge
would
not
help
on
that
and
as
much
as
I
appreciate
the
bridge,
I
mean
I
think
the
bridge
is
great
for
for
legacy
applications
in
general,
but
I
think
we
we
have
the
opportunity
here
to
tell
people
how
to
use
how
do
how
we
see
the
open
launch
api
to
be
used,
so
we
could
tell
them
we
can
show
them.
A
This
is
how
it's
supposed
to
be
used,
and
I
think
a
lot
of
people
here
are
part
of
the
specs
api,
specs
and
and
the
sdks
and
apis
and
so
on.
So
people
can
actually
implement
their
vision
here
and
tell
people
you
know.
So
we
have
an
example
that
you
can
use,
and
it's
here
in
the
collector.
D
C
A
Well,
if
we
get,
if
we
get
one
one
release
only
to
work
on
that,
we
can
get
that
done
and
we
can
assign
this
task
to
the
component
owners
and
whatever
components
not
done
is
not
migrated.
We
can
just
I
don't
know,
remove
the
metrics
from
them.
A
E
Just
to
interject,
which
is
also
worth
considering,
is
at
this
point.
I'm
sure
people
have
lots
of
custom
processors
and
exporters
and
receivers
so
yeah.
The
more
this
could
be
done
with
like
a
bunch
of
resources,
all
at
once,
with
lots
of
runway
or
and
notice
ahead
of
time
would
be
helpful.
I
know
for
our
use
cases
it's
yeah
metric
collection
and
observability,
and
some
of
the
custom
stuff
is
just
like
all
over
the
place.
The
navy
spaces
are
all
over
the
place.
E
It's
been
a
hassle,
so
we
definitely
appreciate-
and
I
think
it's
a
really
great
proposal
and
I'm
a
big
I
can
jacob-
was
it
like
happy
to
connect
you
with
the
folks
who
are
experiencing
pain
points
here?
For
my
end,
if
you
want
more
like
user
stories,
but
yeah
just
also
consider
that,
like
yeah
people
at
this
point
have
been
running
collectors
for
a
while
and
they
have
custom
stuff
so
try
to
keep
them,
and
you
know
try
not
to
do
a
piecemeal,
basically,.
G
Yeah,
the
sorry
dimitri
go
ahead.
H
I
just
want
to
say
if
we,
even
if
we
are
going
without
the
bridge,
we
should
introduce
like
some
like
record
compatible
option
and
in
terms
of
like
we
need
to
give
some
time
for
for
users
to
bind
great.
So
it
will
be
like
a
feature
gated
or
somehow.
So
we
still
need
to
support
old
way
of
metrics
for
significant
amount
of
time.
I
would
say
like
even
up
to
a
year
because,
like
it's,
this
is
pretty
important
part
and
a
lot
of
users
really
build
their
dashboards
on
the
open
diameter,
metrics,
etc.
C
But
I
I
was
not
suggesting
to
change
the
the
emitted
telemetry,
so
the
we
can
change
the
the
the
library
that
we
are
using
in
a
one
shot
like
just
change
to
hotel,
but
keep
the
same
names
exactly
like.
If
you,
if
you
don't
change
anything,
you
get
exactly
on
slash
metrics
in
prometheus,
you
get
exactly
the
same
output,
it's
it's
just
yeah
library
and
that
library
can
be
done
in
one
go.
H
C
We
should
decouple
them.
I
I
think
I
think
the
the
the
library
that
we
use
to
emit
telemetry
not
to
produce
telemetry
is
if
it
has
to
be
decoupled
from
the
telemetry
that
we
produce.
C
I
think
there
are
two
different
efforts
and
then
they
have
to
be
treated
differently
in
terms
of
how
we
and
what
are
the
graceful
period,
the
deprecation
period
and
stuff
like
that,
just
to
change
the
library
we
may
be
able
to
do
it
in
one
go
or
whatever,
because
it's
just
engineering
effort
that
is
not
that
hard,
but
but
changing
all
the
dashboards
and
stuff
is
going
to
be
harder
and
we
need
to
to
have
a
different
story.
There.
G
C
G
Added
context
here
I've
made
like
I
am
one
person
who
has
made
a
lot
of
dashboards
for
the
collector,
so
I
don't
want
my
dashboards
to
break
for
those
either.
I
think
that
the
thing
that
that's
sort
of
the
experience
that
I
was
hoping
was
migrating
from
the
open
senses
with
prometheus
exporter
to
o'sell
with
the
prometheus
exporter.
G
That
way
it
is,
you
know,
a
direct
one
to
one
as
sort
of
the
first
step
and
then
once
that's
done
and
we
can
introduce
we're,
also
able
to
introduce
more
configuration
options,
specifically
like
sending
otlp,
which
will
decouple
us
from
prometheus's
naming
scheme
as
well,
so
we'd
actually
be
able
to
have.
You
know
the
naming
scheme
that
we
ultimately
want.
G
We
might
we'd
probably
have
to
figure
out
what
that
migration
path
would
look
like,
but
that
is
also
so
that's
what
milestone
like
two
and
three
are:
is
you
know
first,
we
migrate
so
that
we're
able
to
use
hotel
then
we
migrate,
so
that
we're
able
to
export
hotel
and
then
finally,
we're
able
to
figure
out
what
metrics
are
actually
going
to
be
valuable.
H
I
actually
have
a
request
in
in
the
core
to
make
sure
that
this
namespace
hotel
call
that
we
have
moved
to
the
matrix,
and
now
I
I
that
was
like
put
on
hold
because
of
the
because
we
thought
that
we
can
change
the
naming
once
we
migrate
over
to
open
telemetry,
metric
names,
etc.
So
in
that
case,
like
probably
that
one
should
should
be
merged,
I
believe
I
can.
I
can
post
it
here.
G
G
G
The
our
our
team
has
been
doing
hotel
migrations
for
basically
the
past
year
at
this
point
in
like
three
different
environments
with
very
high
scale,
using
the
hotel
go
sd
case,
and
so
at
this
point
we're
very
confident
in
our
v
and
our
ability
to
do
this
type
of
one
to
one
migration,
especially
given
that
it's
not
a
matrix
format,
migration,
which
is
what
we
have
been
doing.
G
So
I
I
think
that
that's.
This
definitely
makes
a
lot
of
sense
to
me.
A
So
there's
been
a
discussion
here
on
a
chat
from
josh
mcdonald
and
anthony
added
a
couple
of
comments.
I
added
a
couple
of
comments
myself
and
I
guess
my
my
question
is:
are
we
ready
are
we?
Is
it
okay
to
start
using
the
goal?
Auto
go
sdk,
metrics,
sorry,.
A
Api
to
instrument
things
is
that
right,
so
I
I
don't
know
if
I
get
the
right
message
here,
so
it's
not
clear
whether
it
is
ready
to
be
used
or
what
this
table
means
here.
In
this
context,.
E
Yeah,
so
the
api
is,
we
believe,
spec
conformant,
and
we
don't
expect
it
to
change
significantly
before
we
ship
a
1.0
metrics
api,
but
it
is
not
currently
1.0.
We
haven't
changed
it
since
we
did
our
re-implementation
of
the
api.
We
don't
expect
to
change
it,
especially
now
that
the
sdk
is
being
solidified,
but
we
wanted
to
keep
it
pre
1.0
until
the
sdk
was
also
ready
just
to
keep
our
options
open
as
far
as
collector
components
and
being
able
to
use
the
api
all
of
the
component
create
settings
include
a
meter
provider.
E
It
is
currently
a
no-op
meter
provider.
I
believe,
but
it
can
be.
That's
the
entry
point
to
the
api.
It
can
be
used
to
get
a
meter
and
start
creating
instruments,
and
I
expect
that
component
authors
could
start
using
the
api
at
this
time.
I
As
a
vendor,
I'd
like
to
use
the
exponential
histogram
right
away,
so
that
should
be
an
option
and-
and
I
think
we
might
not
yet
have
a
way
for
what
I've
called
api
hints,
and
there
are
issues
in
the
spec
about
after
post
1.0
for
metrics
doing
api
hints,
which
gives
you
the
way
to
programmatically
in
the
same
declaration
set
those
boundaries
or
those
preferences
inside
of
a
histogram
instrument.
But
but
you
do
have
once
we
get
to
this
alpha
a
view
api
on
spec
that
lets
you
name.
I
E
Importantly,
though,
that
is
part
of
the
sdk
and
not
the
api,
so
it
won't
be
available
through
the
meter
provider.
I
don't
know
if
that
needs
to
be
made
available
to
instrumentation
creation
points
or
if
we
have,
I,
I
think
in
our
current
open
senses.
Implementation
as
well,
there's
just
a
centralized
view,
definition
that
gets
used
by
everything.
So
we
may
need
to
stick
with
that
pattern.
A
Right
but
I
guess
so
let
me
refresh
the
question
so
if
I
start
instrumenting
today
would
I
get?
Would
I
be
able
to
use
just
to
have
like
a
histogram
type
of
measurements
for
my
components,
because
I
think
counters
and
gauges
and
so
on?
They're
not
they're,
absolutely
necessary
as
well.
A
But
if
I
can't
see
how
long
a
specific
component
took
to
perform
a
specific
operation
and
and
plot
that
in
a
histogram,
whether
it
is
exponential
or
not,
you
know
if,
if
it's
missing
for
a
user
from
a
user
perspective,
not
from
I
mean
as
component
developers,
we
can
navigate
through
the
api
and
sdk.
That's
fine,
but
we
have
to
provide
users
the
capability
of
seeing
how
it
is
performing
and
they
couldn't
cure
us
about
whether
it
is
sdk
api.
I
From
the
api,
for
that
I
mean
you
can
record
histogram
measurements
and
the
only
part
which
I'm
admitting
is
like
still
a
challenge
is,
if
you
have
a
specific
desire
to
configure
specific,
explicit
bucket
histogram
boundaries
because
of
legacy
concerns
or
because
of
prometheus
concerns,
which
means
that
you
have
very
specific.
I
I
Well,
I
don't
quite
know
what
type
of
variability
is
existing
today
in
the
collector
like
do
you
have
100
histogram
metrics,
or
do
you
have
five
and
what
boundaries
are
being
used
today?
Matters
because
you
know
if
right
now,
when
you
set
up
a
hotel,
sdk
you're
going
to
have
to
say
the
defaults
for
for
the
histogram
instrument,
which
might
be
applicable
across
your
five
or
100
instruments
or
you're
going
to
have
to
set
on
a.
I
believe
this
is
true
and
anthony
can
confirm
or
not,
or
we
can
check
with
the
sig.
I
You
know
that
I
believe
the
sdk
spec
says
you
must
implement
a
way
to
but
give
a
name
and
provide
explicit
boundaries.
So
so
we
can
solve
this.
I
believe
this
is
also
the
model
that
open
sense
is
used.
You
have
a
view
definition
and
you
have
instrumentation.
A
Excuse
me
so
right
now
we
have
at
least
two
components,
I
think
the
load
balancer
exporter
and
the
routing
processor,
where
they
use
different
boundaries
for
different
metrics
within
the
same
component
like
things
like
queue,
time
or
thing
at
amount
of
time.
That
an
item
was
only
a
specific
queue
and
the
time
that
something's
took
to
be
delivered
to
to
exporter
or
whatever.
So
I
I
can't
say
whether
we
have
five
or
500.
I
So
you
might
have
a
view
definition
that
has
a
match:
a
matching
clause
that
has
a
regular
expression,
ending
in
queue
size
and
for
cue
size,
metrics.
You
have
these
boundaries
and
then
you
might
have
a
different
pattern
for
latency
metrics,
which
end
in
duration
or
something
like
that
and
those
use
these
metrics
these
boundaries,
for
example.
That
might
be
how
you
solve
the
problem.
A
Okay,
so
we
are,
I
guess
we
have
two
more
items
here.
So
what
I
would
propose
is
an
action
item
here
to
jacob
is
then,
you
know,
take
a
look
at
those
two
components:
perhaps
the
routing
processor
and
the
load
balancing
exporter
see
if
you
can
implement
the
metrics
that
we
have
in
there
with
the
current
state
of
the
goal
is
go
api
and
sdk.
A
If
we
can,
if
you
can
implement
that,
then
I
think
it's
quite
representative
of
the
other
usage
for
the
collector
and
then
we
can
move
forward
with
this
one
here.
Otherwise,
we're
still
blocked
by
the
os
go
api.
B
C
A
I
think
that's
fine,
not
nice,
it's
better
than
not
having
that
at
all.
So
I
think
we
can,
if
that,
if
that
means
that
we
are
not
blocked
anymore,
then
we
should
just
go
forward
and
then
improve
the
situation.
C
E
G
A
Sounds
good,
so
I
think
it's
okay
to
move
to
the
next
one.
What
should
we
do
with
the
feature?
Gate
direction?
Changes
in
contrib
question
from
alex.
D
Yeah,
so
we
currently
have
this
a
bunch
of
feature
gates
around
a
bunch
of
components
where
we
implemented
the
the
changes
that
were
pulled
back
from
the
spec,
and
I
just
wanted
to
ask
the
group
here:
should
we
leave
this
where
it
is,
do
we
leave
those
feature
gates
that
may
never
be
implemented
in
the
spec
around
to
confuse
users,
or
do
we
just
go
and
remove
them.
H
D
Yeah,
I
mean
there's
an
open
discussion
around
in
the
spec,
but
I
I
mean
to
be
honest,
I
don't
imagine
this
change
will
come
back
because
I
feel,
like
we've,
already
gone
back
and
forth
on
the
same
change
multiple
times
and
doing
it
one
more
time
will
just
dishearten
users.
So
I
would,
I
would
just
go
and
delete
the
code.
That's
there.
If
that's,
okay
with
everybody
else,
I
can
do
that.
D
I
know
this
sounds
a
little
conservative,
but
would
it
be
possible
to
deprecate
the
feature
gate
and
then
remove
it
at
a
later
time.
E
C
Okay,
can
we
just
then.
C
E
C
Yeah,
so
I
would
like
to
to
have
that
log
message.
Maybe
maybe
we
also
can
add
a
concept
of
deprecated
or
something
something
like
that
in
the
future
gate,
and
we
automatically
whenever
somebody
sets
it.
We,
we
love
the
message
on
on
the
collector's
side
like
in
the
in
the
future.
So
essentially
we
add
the
capability
of
saying
feature:
gate
is
being
removed
or
whatever
it
is
called.
D
A
I
guess
a
final
question:
if
you're
done
with
it
with
this
topic
here,
I
guess
the
next
question
is
whether
we're
ready
to
move
forward
with
go
workspaces
after
this
release.
A
I
know
that
alex
had
a
couple
of
comments
on
my
pr
for
for
go
workspaces
for
the
core
and
I've
seen
that
you
open
a
go
workspaces
pr
as
well
for
contrib,
I'm
just
wondering
I
mean
we
did
touch
this
topic
a
month
or
so
ago,
as
a
poc,
very
proof
of
concept,
and
I
think
that
I've
I
forgot
who
from
aws
was
going
to
work
on
the
trolling
side
of
things.
Perhaps
unto
me
brian
right
yeah.
So
do
we
have
anything
pending
or
is
it
ready
to
go
or
is
it?
B
B
It
would
be
a
pretty
big
design
change
to
try
to
find
a
way
around
that,
but,
like
I
think,
obs
report
doesn't
use,
go
mod,
go
modules.
C
A
We
can,
I
think,
the
pr
that
I
sent
is
kind
of
a
poc
for
that.
B
And
I
may
have
just
missed
that
part
and
been
looking
at
it
in
the
lens
of
like
a
bunch
of
directories
they
all
that
could
just
be
I
missed
by
me
and
then
in
that
case,
then,
if
the
packages
are
defined
already,
then,
if
we
wanted
to
automate
the
workspace
build,
then
we
should
probably
at
least
start
with
an
issue
on
go
control
tools
or
go
build
tools.
I
think
the
repo
is
called.
A
Okay,
I
guess
there
was
one
one
painting
question
on
whether
we
should
check
in
the
go
work
file,
and
but
I
think
that
that
point
is
clarified
right
I
mean
it
is.
It
is
the
case
that
we
should
be
checking
in
that
file
in
our
situation.
In
our
case,
I
think.
B
I've
read
the
proposal
a
few
times
and
I
think
other
people
have
also-
and
I
feel
like
our
situation-
may
be
the
exception.
That
does
check
it
in
and
I
that's
probably
my
only
comment
on
that
because
I
I
think
we
fall
into
that.
A
Okay,
I'm
I'm
just
kind
of
lost,
so
is
there
anything
that
I
have
to
do,
or
is
it
depending
on
something
on
your
side,
brian
or
someone
else's?
I
don't
know.
C
Durancy
after
we,
we
we
checking
in,
have
you
updated
the
main
files
to
to
allow
us
to
continue
to
to
do
all
the
upgrades
and
all
the
things
that
we
have
to
do
or
who
is
going
to
do
that
like
we?
We
we
have
to
follow
up
on
this.
A
C
A
All
right,
I
would
list
what
I
understand
as
everything,
but
then
I
would
need
you
all
to
chime
in
and
say
you
know
it's
missing
x,
y
and
z,.