►
From YouTube: CNCF SIG Observability 2021-03-09
Description
CNCF SIG Observability 2021-03-09
A
Hey
steve,
how
are
you
in
hilarious
apocalypse
news?
The
landlord
has
said
that
they
need
to
do
an
inspection
of
my
apartment
for
fire
safety
issues.
So
therefore,
I
am
wearing
an
anti-clothing
mask
sitting
at
my
desk
waiting
for
the
person
to
show
up,
because,
after
that,
my
air
will
be
contaminated
for
a
little
while.
B
C
C
D
C
F
G
Hello,
oh
there,
he
is
perfect,
perfect!
Okay,
so
are
the
I
are
perfect,
so
the
ardor
moved
his
thing,
so
we
can
start
right
in
just
one
point
of
order.
I
I
read
recently
that
most
people
are
at
the
year
of
of
being
locked
in
the
pandemic
for
one
year
now
or
close
to
that
point,
and
that
a
lot
of
people
are
are
hitting
mental
and
emotional
wars.
G
G
G
But
at
some
point
sick
observability
should
be
done
with
with
the
due
diligence
document
by
one
call
we
are
now
at
the
record
of.
Of
course,
it
took
to
to
get
through
the
intelligence.
So
let's
try
to
not
let
it
oh,
no
actually,
there's
the
third
call
then
we're
at
then
we're
on
par,
doesn't
matter
so.
G
So
please
put
that
in
at
some
point,
so
so
people
can
see
for
now
unless
there's
there's
something
which
needs
to
be
actively
discussed
which
is
not
covered
in
that
statement,
then
obviously
speak
up
else,
we'll
just
refer
to
that
statement.
So
the
first
comment
which
is
still
open,
is
also
from
bartik
about
forked
distributions
versus
core.
I
think
we
can
close
this
unless
fish
is
on
the
call
and
wants
to
actively
object,
but
I
don't
think
that
is
the
case.
C
G
G
G
G
E
Richard
I
can,
I
can
address
that
steve
if
you're,
it's
okay,
again,
that
this
is
based
on
that
specific
phase
of
the
data
model
and
the
specification
being
completed,
and
you
know
for
that
phase.
Work
is
already
in
progress.
You
know,
as
as
you
can
see,
your
drafts
are
available,
but
you
know
the
final
is
not
done
yet,
and
you
know
we
are
again.
There
are
different
teams,
aws
included,
who
are
adding
more
engineering
to
this
effort,
so
hence
the
expectation
of
an
earlier
completion.
G
Okay,
so,
for
the
intents
and
purposes
of
the
main,
due
diligence
document,
basically,
we
can
assume
where
stuff
was
written
before
that
logging
is
currently
not
a
focus
area
for
this
year.
That
this
is
retracted
and
replaced
with
more
resources
are
being
put
against.
The
logging
signal
and
component
correct.
E
I
G
G
G
E
G
D
C
So
I
guess
one
initial
comment
I'd
make
is
especially
when
it
comes
to
things
like
not
reinventing
the
wheel.
That
goes
counter
to
the
cncf
principles.
So
I'm
wondering
how
we
resolve
some
of
that
counter,
like
it's.
Okay,
for
people
to
have
different
opinions,
that's
fine,
but
blocking
when
it
goes
directly
against
the
cncf
principles.
C
Yeah
there's
no
king
making
in
yeah,
then
the
no
king
making
rule
and
the
cncf
principles
state
that
you
can
have
two
conflicting
things
and
that's
okay.
If
I'm
reading
this
suggestion
right,
it
seems
to
indicate
that,
like
they
can't
like,
you
have
to
use
open
metrics,
you
have
to
use
fluent
bit.
Do
you
have
to
use
something
else?
C
To
support
the
specification,
but
using
it
internally
or
not
having
another
alternative
to
implementation
of
it.
That
seems
counter
like
I
guess,
I'm
trying
to
understand
how
that
meets
the
criteria
for
incubation.
I
can
understand
that
that's
kind
of
an
opinion,
but
the
cncf
principles
don't
allow
do
allow
don't
allow
for
king
making
in
the
in
the
sense
that
there
doesn't
have
to
be
one
solution
to
a
problem.
H
H
So
it's
not
like
mandatory
for
me,
however,
that
you
know
compatible
with
primitives
was
something
that
was
mentioned
by
open,
telemetry
and
overall
would
be
nice
for
users,
and
so
that's
why
you
know
it
fits
kind
of
in
this
rule,
but
also
the
no
kinks
making
rule
is
yeah.
It's
a
rule
that
says
that
you
know
conflicting
solutions
can
be
passed
to.
You
know
further
stages,
but
it
doesn't
mean
they
have
to
be
conflicting
right
and
they
cannot
work
together.
L
And
I
think,
and
just
mentioned
that
in
case
it
hasn't
been
clarified
like
open
telemetry,
is
super
super
intent
on
being
fully
compatible
with
prometheus
and
we're
we're
actively
working
with
tom
wilkie
and
richard
hartman
and
others
to
ensure
that
the
metrics
work,
we're
doing
is
going
to
be
something
that
prometheus
users
would
would
want
to
use.
So
yeah.
H
Right
but
like
you
asked
me
to
get
involved
into
adding
yet
another
api
to
overly.
You
know
kind
of
complex
collector
already
that
I
personally
would
you
know
not
recommend
and
I'm
not
sure.
If
that's
you
know
what
I
can
you
know
do
I
can
make
sure
to
not.
You
know
we
can
you
can
import
promote
use
code?
So
it's
you
know.
We
are
not
reinventing
everything
but
like
yeah,
I'm
kind
of
conflicted
here,
I'm
not
sure.
How
should
I
behave
and
that's
why
I'm
putting
this?
H
Very,
maybe
a
blunt
sorry
for
that,
but,
like
I
don't
feel
this
is
a
moment
a
good
moment
for
incubation
and
by
the
way,
all
the
things
you
mentioned
about.
Yes,
you
started
working
with
this
with
from
q's
openmetrics
to
make
it
compatible.
So
I
think
that's
a
great
progress.
However,
I
would
see
let's
meet
when
done
that
is
done
and
then
we
can,
you
know,
discuss
you
know
incubation,
maybe
that
that's
my
proposal.
H
A
A
Okay,
oh
sorry,
so
it
offers
significant
benefits
to
end
users
as
far
as
you
know,
being
able
to
route
telemetry
easily,
and
you
know
yes,
I
do
have
concerns
over.
You
know
code
increase
in
terms
of
size
and
complexity
as
far
as
memory
footprint,
but
the
collector
team
has
shown
willingness
to.
You
know
create
performance,
metrics
right
to
make
sure
that
people
are
not
adding
too
much
stuff
that
causes
the
memory
footprint
to
increase.
A
I
think
you
know
that
kind
of
addresses
to
me.
You
know
items
number
number,
four
and
five
and
in
terms
of
thinking
about
you
know
who
is
the
collector
serving?
What
purpose
does
it
serve?
Is
it
fit
for
purpose?
I
feel
like
that.
You
know
the
end
user
adoption
and
people
successfully
using
the
open,
telemetry
collector
to
route
telemetry
to
multiple
providers
to
internal
open
source
back-ends,
as
well
as
to
vendors.
I
A
Sure,
but
I
think
it's
hard
to
disentangle
these
things
right,
like
people
want
a
collector
that
is
configurable
with
emel
right
that
they
can
basically
configure
at
right
like
or
write
a
configure
with
a
config
file
right
rather
than
having
to
make
code
changes
right.
That
is
the
weakness
of
the
sdks
is
that
you
have
to
make
code
changes
to
change
where
the
telemetry
routes
right
and
the
collector
addresses
that
fairly.
A
A
Are
you
going
to
insist
that
we
rewrite
the
collector,
as
our
you
know,
as
an
incubation
criteria?
Right,
like
you
know,
I
appreciate
the
feedback
right
like
number
one
right
like
you
know.
Yes,
if
there
are
some
reports
from
users
of
saying
you
know,
we
have
to
move
back
to
open
tracing
and
we
can't
use
otel
go
because
of
memory,
leaks
and
performance
issues
right
like
okay.
A
This
is
kind
of
the
first
that
I've
heard
of
this
right
like
it's,
something
that
I
will
take
back
to
the
hotel
go
team
and
that
will
investigate
seriously
right
like
if
you
can
link
us
some
specific
reports
and
issues
that
have
been
filed.
I'm
happy
to
look
into
this
right,
but
that's
at
least
a
little
bit
more
specific
feedback
than
kind
of
you
know
the
we
don't
like
the
hotel
collector
design.
Well,
you
know
we
need
something
to
fill
that
gap
right
like
that,
that
it
works
in
practice
at
production.
A
I
Right
so
I
think
I'll
just
say
this
and
I'll
butt
out
completely.
I
think
the
one
thing
that's
underlying
a
lot
of
these
conversations
is
this
like
more
core
and
abstract
thing,
which
is
that
I
think
a
lot
of
people
think
the
scope
of
hotel,
collector
and
really
all
of
hotel
is
simply
too
large
and
that
anything
produced
in
the
scope
is
not
going
to
be
ideal
for
anyone
right,
and
so
everything
flows
out
of
that.
If
you
don't
believe
that,
then
nothing
makes
sense.
C
I
I
D
So
I
just
want
to
jump
in
for
one
I'll,
stop
raising
my
hand.
So,
like
it's
a
little
ironic
in
my
mind.
Well,
actually
I
don't
want
to
be
too
confrontational.
I
see
your
point
peter
and
actually
in
some
ways
in
a
past
life,
I
agreed
with
it
in
the
sense
that
creating
open
tracing
specifically
was
meant
to
be
a
narrower
scope.
D
So
we
did
that
and
then,
ironically,
the
cmcf
like
brokered
the
process
literally
to
create
a
broader
scope,
because
that
is
absolutely
what
we
heard
from
people
out
there
like
not
like
vendors
to
end
users
that
they
wanted
to
have
a
single
surface
area
for
telemetry
integration.
I
would
absolutely
agree
that
the
scope
of
open
telemetry
is
extremely
broad,
and
I
think
one
of
the
founding
principles
of
the
project
is
to
try
to
be
modular
about
it
as
much
as
we
can.
D
So
I
guess
I
would
argue
that
for
people
who
don't
like
the
fat
dependency
in
the
collector,
don't
use
it.
The
open,
telemetry
project
does
not
require
the
use
of
the
collector,
and
I
think
that
seems
to
be
the
focus
of
a
lot
of
these
discussions.
The
idea
of
a
single
instrumentation
api
that
just
describes
the
process
of
what's
going
on
in
the
software
and
then
emits
relevant
telemetry,
is
what
actually
really
led
to.
I
think
the
realization
from
folks
in
the
open
tracing
side
that
something
like
this
was
necessary.
D
So
the
I'm
not
saying
that
your
opinion-
which
I
assume
is
your
opinion-
I
mean
you
phrase
it
as
a
question,
but
I
think
you've
made
your
opinion
clear.
I'm
not
saying
it's
invalid
and-
and
I
actually
as
I
I
think,
the
point
I'm
trying
to
make
is
the
times
I've
agreed
with
it.
I
think
that
what
I
learned
from
the
open
tracing
project
primarily
was
that
it
actually
isn't
what
people
want.
D
They
actually
don't
want
to
think
about
instrumentation,
which
means
like
having
the
fewest
number
of
projects
they
depend
on
in
order
to
instrument
their
software
and
that's
what
led
to
open
telemetry.
So
I
just
want
to
help
people
understand
the
history
of
the
project,
including
going
back
to
2015..
So
that
is
important
context.
Are
you
like,
for?
Should
the
observability
stick
absolutely
unequivocally
approve
this
no
like,
and
I
think
it's
fine,
if
you
don't
frankly,
we'll
just
keep
on
working,
I
mean
this
project
is
going
to
be
adopted
regardless.
D
The
cncf
actually
encouraged
us
to
incubate
the
project,
because
you
know
it
would
be
a
good
thing
or
whatever,
and
that
was
kind
of
the
goal.
But,
honestly,
like
I'm,
pretty
convinced
this
is
the
right
overall
direction
like
a
broad
telemetry
project.
That's
decoupled!
That's
those
seem
like
the
two
important
pieces
tightly.
Coupling
is
bad
narrow.
Will
be
hard
to
adopt
and
that's
what
led
us,
the
current
design,
I
think
a
lot
of
the
issues
I'm
hearing
here
have
to
do
with
interop
with
other
observability
projects,
certainly
including
prometheus.
D
I
would
a
second
what
ted
said:
we're
extremely
committed
to
figuring
that
out,
it's
just
going
to
take
work
and
then
the
collector
per
se,
which
I
just
don't
want.
You
know
I
personally
like
the
collector.
You
might
not
that's
totally
fine.
I
just
wouldn't
want
to
throw
the
baby
out
of
the
bath
water.
If
you
don't
like
the
collector,
because
it's
one
part
of
a
much
larger
project
and
I
don't
think
it
makes
sense
to
split
it
off
into
its
own
thing,
because
it
has
so
many
dependencies
itself
out
of
inflammatory.
D
Nor
do
I
think
it
makes
sense
to
reject
open
telemetry,
because
you
don't
like
that
part
because
you
just
don't
need
to
use
it.
So
that's
my
two
cents.
I
don't
know
if
that's
useful,
but
just
from
like,
I
feel
like
we're
talking
about
existential
charter
stuff,
and
that
is
the
context
of
how
the
project
was
created
and
the
irony
in
my
mind,
of
spending
two
years
to
basically
comply
with
the
cncf
guidance
to
create
a
broader
surface
and
then
being
rejected,
because
it's
too
broad
is
sort
of
beyond
description
but
like.
D
A
And
on
the
flip
side,
right,
like
honeycomb,
sat
out
right,
like
we
sat
out
open
senses
in
open
tracing
right,
because
there
is
not
convergence
right,
because
there
is
not
a
clear
road
map
for
which
of
these
few
projects
is
going
to.
You
know
be
the
future
way
that
everyone
is
going
to
want
to
internet
with
right
and
when
open
telemetry
came
along
right,
like
that
was
a
sign
to
us
of.
We
should
be
developing
and
converging
our
sdks
in
that
direction.
A
Right
like,
I
think
that
that
has
a
huge
amount
of
power
as
opposed
to
people
duplicating
work.
You
know
writing
their
own
proprietary,
sdks
in
terms
of
people
developing
against
open
census
or
open
tracing
right
and
having
to
maintain
these
two
parallel
implications.
Right,
like,
I
think
that
there
is
a
lot
of
value
in
what
ben
is
describing
as
kind
of
the
unified
sdk
for
instrumentation
and
then
right
like
the
problem.
The
collector
is
solving
is
the
separate
one,
which
is.
How
do
you
configure
that
right?
A
How
do
you
route
the
instrumentation
once
it's
generated
right
and
that's
kind
of
the
separate
problem
that
is
being
solved
is
once
you
start
doing
this
at
scale.
You
want
to
configure
multiple
points
that
you're
writing
to.
You
want
to
be
able
to
do
it
at
runtime
and
suddenly
that
that
becomes
a
new
set
of
considerations
right
that
is
now
that
is
unlocked
from
having
the
first
set
of
you
know.
A
Let's
get
the
baseline
instrumentation
standard
taken
care
of,
let's
have
a
protocol
for
communicating
that
instrumentation
and
that
telemetry
and
then
let's
have
a
routing
layer
right.
Those
are
kind
of
the
various
layers
of
the
stack
that
arise
from
each
other
right
like
that,
that
are
that
are
empowered
by
each
other,
but
are
not
necessarily
you
don't
have
to
deploy
it.
If
it
does,
you
know
if
you
have
a
simple
app
that
only
needs
to
write
to
one
to
eleven
percent.
You
don't
need
the
open,
telemetry
collector
right.
F
E
And
and
and
just
to
reiterate
again,
you
know
from
aws
with
the
distribution
that
we've
rolled
out
based
on
you
know
all
the
work
that
we
are
doing
in
open,
telemetry
and
the
whole
community
is.
There
is
a
tremendous
amount
of
interest
in
adoption
from
the
customers.
You
know
large
and
small,
so
it
really
is
an
exciting
time
and
and
and
that's
what
you
know-
customers
are
looking
at.
L
Yeah
I
would
like
to
point
out:
the
project
does
have
clearly
defined
boundaries
like
we're
not
attempting
to
create
a
back
end
or
database.
Specifically
we're
entirely
focused
on
solving
this
tricky
problem
of.
How
would
you
let
open
source
libraries
natively
instrument
themselves,
and
how
do
you
let
operators
have
control
over
that
telemetry
pipeline,
and
so
I
don't
know
it
to.
L
From
my
perspective,
the
the
project
is
pretty
well
scoped
and
we
have
had
to
do
a
lot
of
design
work
up
front
to
make
sure
that
we're
actually
meeting
these
requirements,
because
on
the
telemetry
side,
they
are
deeper
requirements
than
if
you
were
just
trying
to
talk
to
one
system,
but
that
work
feels
like
it's
actually
been
going
very
well.
So
I
just
want
to
point
that
out
that
it
it
feels
like
it's
been
going
well
to
me
having
been
involved
in
all
this
stuff
from
the
beginning.
B
Maybe
also
some
feedback
on
like
project
reviews
in
general.
I
think
we're
mixing
you
two
things
when
it
comes
to
incubation.
One
thing
is
whether
you
like
the
design
of
a
certain
project,
or
not
I
mean
that's
personal
taste
and
people
take
different
directions
on
how
they
build
things.
I
mean
at
four
out
of
six
really
projects
as
well,
where
I'm
not
necessarily
100
on
board
with
the
design,
and
I
might
have
taken
different
design
decisions.
I'm
not
saying
I'm
doing
this
here,
but
like
in
general.
B
One
topic,
though
that
comes
up,
but
the
thing
that
can
be
addressed
by
the
open,
telemetry
people
is
like.
Are
there
performance
tests
that
exist?
What
are
the
current
performance
considerations
and
considerations
regarding
stick
stability
or
the
test,
suites
and
so
forth?
I
think
that's
a
valid
point
to
make
and
also
something
to
be
answered
by
the
project
team,
which
I
assume
exists
or
can
be
made
available.
B
So
that's
the
fear
point,
but
also
you
can't
force
a
project
to
interact
with
other
projects.
Necessarily
you
don't
have
this
situation
where,
like
one
approach
to
move
them
all,
you
can
make
a
recommendation
honestly
or
you
can
make
a
recommendation.
You
should
work
with
those
other
projects
in
in
the
industry
investor
provider
industry.
B
I
think
that's
also
when
I
look
at
some
like
especially
the
first
one.
Okay,
if
they
go,
libraries
are
supposed
to
be
not
stabled,
and
I
think
it's
up
to
the
open
telemetry
team
to
show
like
proper
test
screen,
prop
performance
testing
of
those
libraries.
If
they
exist
fine,
but
they
would
have
to
sign
it
differently.
It's
an
entirely
different
question.
G
G
So
we
can
finally
have
a
statement
in
the
finished
document
which
we
can
submit
to
the
toc,
and
I
yeah
no
doesn't
matter
so.
I
agree
with
steve's
point
that
mandating
from
the
outside
of
the
project
that
any
particular
data
model
must
be
used
internally
seems
seems
overly
broad,
and
I'm
saying
this
as
someone
who,
like
literally
the
founder
of
openmetrics,
but
yet
I
agree
with
my
chair
head
on
that
this
seems
overly
broad,
so
I
would
suggest
simply
removing
this
or
moving
this
to
a
different.
C
Yeah,
I
think
my
general
comment
would
be
many
of
these
make
claims,
but
I
don't
see
anything
to
back
it
up
like
this
one.
I
don't
know
where
this
data
is
coming
from
or
or
even
this
one
like
the
go.
Sdk
right
now
is
not
stable.
So
if
that
was
true
for
like
go
for
java
or
net
which
both
are,
maybe
that
would
be
a
bigger
concern,
and
some
of
these
I'm
assuming
you're
not
tracked
in
like
github
issues
or
what
have
you
where
most
of
the
work
is
happening.
C
C
We're
trying
to
do
this
all
in
open
source
everyone's
welcome
to
participate.
If
you
find
that's
not
the
case,
then
there
are
code
of
contact
violations.
Let's
go
address
those
but
otherwise
like.
Ideally,
this
should
all
be
on
github
tracked
in
issues
and
if
there
are
beliefs
that,
like
users
are,
are
dominating
over
vendors
or
what
have
you
like?
Let's
go
have
that
conversation
and
go
address
it,
but
otherwise
it's
I'm
not
sure
what
we
can
tangibly
do
with
some
of
this
feedback.
Given
that
there's
nothing
to
back
up
the
claims
right.
I
K
I
L
I
think
the
issue
is
more
that
this
was
seen,
or
at
least
told
to
us
that
this
was.
This
was
a
technical
review
of
the
project
and,
as
steve
is
mentioning,
it
feels
like
a
number
of
the
things
here
are
more
like
opinions
or
things
that
don't
feel
like
act
actionable
from
a
technical
perspective.
That's
that's
why
we're
kind
of
circling
back
to
that?
I
think
that
we
can
definitely
have
like
a
broader
discussion,
but
it
feels
weird
to
have
that
broader
discussion
in
the
context
of
like
a
technical
review.
G
That
sorry,
no,
that
statement
feels
a
little
bit
unfair.
So
let
me
just
I
don't
know
if
you
saw
this
document,
let
me
link
it
is
the
actual
log
form
I
I
would
agree
if
you
say
that
the
summary
is
is
not
phrased
neutrally.
That
is
a
fair
point
to
make
I
I
would
not
agree
with
any
statement
implying
that
this
is
all
basically
happening
in
in
a
vacuum.
L
G
So
I
I
do
think
that,
like
again,
I
would
agree
with
steve
that
this
needs
some
sharpening
and
and
sourcing
and
so,
for
example,
liz's
comment
is
actually
is
absolutely
correct
that
there
should
be
a
link.
I
I
know
by
happenstance,
because
frederick
from
kubernetes
stick,
instrumentation
and
also
a
prometheus
team
mentioned
that
that's
why
he
stopped
using
the
go
library
because
he
had
too
many
too
many
memory
leaks.
But
I
don't
know
if
he
ever
filed
an
issue
or
not.
G
G
I
agree,
I
agree
so
I
I
know
this
has
some
backing
in
reality,
but
I
have
never
taken
a
look
myself,
but
I'm
just
trying
to
get
back
on
track.
So
for
the
intents
and
purposes
here
would,
should
we
just
put
an
action
item
for
bartek
to
to
actually
point
to
a
specific
thing,
because
then
you
can
just
take
it
off
and
we
can
also
remove
it
from
this
from
this
overall
list
in
assuming
that
the
rest
of
the
issues
or
concerns
or
whatever
are
resolved.
N
C
C
Other
thing
that
might
be
helpful
ritchie
is,
I
don't
know
if
there
are
and
going
back
to
peter's
original
question
like
what
are
we
doing
here?
Is
this
a
pass
fail?
I
think
maybe
an
open
question
is
what
is
the
goal
of
the
due
diligence
documents,
so
my
understanding
is,
there
are
certain
criteria
that
the
cncf
toc
has
dictated
or
specified.
Maybe
addicted
is
the
wrong
word
that
is
in
bold.
There
are
different
section
headers
in
this
doc
and
the
goal
is
to
respond
to
them.
C
G
Yes,
the
the
the
issue
which
I
was
trying
to
solve,
and
I
thought
we
had
agreement
last
time
that
that
we
are
we're
trying.
This
approach
is
to
just
detach
a
bulk
of
concerns
out
of
the
out
of
the
normal
document,
because,
as
happened
just
now,
we
are
basically
going
in
circles
on
a
lot
of
discussions
which
are
super
interesting
on
the
technical
level
and
in
particular,
as
new
voices
come
in
and
voices.
I
personally
value
that
that
just
makes
it
more
interesting,
but
that
doesn't
solve
that.
B
My
approach
yeah
they're,
proposing
production
stability,
because
the
project
is
that
big,
it
wasn't
before
another
one
to
have
more
production
users
than
just
three
because,
like
three
would
be
like
specific
to,
like
maybe
a
very
small
subset
of
the
project,
but
if
you're
concerned
about
certain
areas,
plus
they
have
specific
interviews
and
like
more
of
those
protect
that
project
like
if,
if
go,
is
one
of
the
concerns
here
with
the
standards.
A
lot
of
the
cncf
rules
are
for
projects
that
are
obviously
smaller
in
scope.
B
Historically,
that
would
be
a
fair
proposal
that
production
uses
for
all
of
the
major
components
would
be
a
recommendation
which
they
can
put
into
interviews.
I
think
that
might
be
helpful
here.
I
didn't
get
your
point.
Sorry,
hello.
So
one
of
the
criteria
for
incubation
is
that
three
production
users
like
reproduction
uses
for
a
project.
That
is
that
big
might
just
like
be
java.
B
H
If
I,
if
I
mention
anything
about
telemetry,
it's
scoped
to
the
open,
telemetry
and
that's
kind
of
the
problem
with
the
scope
and
it's
just
hard
to
work
with-
and
I
mean
this
is
only
showing
this
this-
this
kind
of
problem
and
again
some
recommendation
is,
is
what
we
discussed
is
that
maybe
we
should
put
incubation
kind
of
label
on
on
tracing
part,
but
I
I
heard
there
is
like
yeah.
You
are
not
agreeing
with
that
approach.
All
maybe
you
should
put
a
separate
kind
of
stages.
H
C
Projects
like
we
didn't
do
that
for
openmetrics.
That's
not
the
case
for
prometheus,
like
there
are
client
libraries
and
open
metrics
right
now
that
are
not
stable.
We
didn't
decouple
the
project
and
say
openmetrics
is
not
ready
for
incubation,
so
I
guess
I'm
having
a
hard
time
following
that
argument
like
the
project's
going
to
continue
to
evolve
and
will
continue
to
become
like
more
stable
in
different
areas
and
for
larger
projects
like
a
kubernetes
or
an
open
telemetry.
C
E
H
H
Yes,
but
it's
still
not
incubated
kind
of
high
bar
of
of
kind
of
an
incubation
again
means
like
a
step
towards
graduation,
and
I
talked
about
about
that
with
chris.
We
talked
like
both
with
richie
and
and
kind
of
ami
as
well,
and
you
know
there
was
this
strong
statement
that
we
are
not
here
talking
about
only
incubation
and,
let's
swipe
all
of
other
problems
for
graduation
to
later
stage.
No,
it
should
be
like
a
certain
pause,
certain
break
that
we
stop
and
think
hey.
H
Is
this
going
to
good
direction,
and
I'm
super
surprised
that
you
are
saying
there
are
so
many
successful
users,
because
I
don't
know
any,
and
maybe
we
are
in
the
bubbles,
but
I
just
want
to
point
out
that,
from
my
perspective,
from
our
perspective,
people
who
I
talked
to
this
is
not
that
clear.
That
is
going
in
the
best
direction,
and
I
think
that
this.
A
Right,
like
I
would
easily
say
at
least
half
of
our
deals
now
are
people
who
are
interested
in
using
open
telemetry
to
comparison
shop,
vendors
to
compare
against
jager
great
like,
and
it's
really
exciting
right
like
so.
I
think
there's
this
weird
kind
of
disconnect
where
we
just
have
communities
are
not
talking
to
each
other.
H
I
would
be
curious
like
what
makes
those
people
that
you
refer
very
happy
about
this
path
and
what
makes
you
know
people
I
heard
not
not
very
happy
and
okay.
I
just
want
to
one
make
one
more
point:
maybe
it's
unrelevant
so,
but
I
want
to
kind
of
leverage
that
okay,
I
agree
that
this
production,
stability
of
open,
telemetry
tracing
part
on
go
is
can
be
kind
of
controversial.
H
But
what
I
mean
behind
that
is
that
you
know
we
had
open
tracing
client
already
for,
like
I
don't
know
four
years
or
three
and
we
suddenly
moved
to
something
worse,
and
this
is
like
kind
of
showing
the
direction
right
that
it's
not
going
in
direction.
That's
my
point
here.
It's
kind
of
this
background
and
complex
also
that
matters.
O
And
I
also
think
that,
because,
like
one
of
the
things
that
incubation
means
that
you
have
users
in
production
running
this,
if
we
go
incubation
without
having
like
the
locks
part
or
anything
that
around
that
part
or
on
like
the
metrics
like
stealing
beta,
I'm
kind
of
saying
that,
like
this,
would
not
meet
the
bar
for
incubation,
the
locks
part
only
and
like
which,
which
part
of
the
project
need
to
miss
the
birth
to
to
be
incubation.
That's
that's
more
like
the
question.
I
think.
M
So
that
has
been
addressed.
Actually
that
was
addressed
by
liz
last
week
right,
it
is
very
common
for
products
to
have
things
are
experimental
right
like
how
else
do
you
build
components
such
a
new
project
that
isn't
ready?
Yet
right,
like
you,
don't
just
deploy
your
production
magically,
but
actually
just
because,
since
we
have
amy
here
as
a
resource
amy
is
there
anything
you
want
to
attend
to
help
us
make
sure
we
understand
the
scope
of
this
review.
K
G
And
also
just
to
synchronize,
because
I
basically
gave
up
on
being
able
to
pass
this
video
already
three
minutes
past
officially,
we'll
probably
run
over
as
per
usual
to
the
full
hour.
But
afterwards
I
have
a
hard
cut
just
to
onboard
the
people
who
who
haven't
been
here
before
the
initial
suggestion
for
to
do
a
partial
due
diligence
of
open,
telemetry
tracing
was
coming
from
steve,
I
think
in
october,
but
then
that
was
taken
back
so
just
for
completeness
for
the
matrix
of
overview
of
different
adoptions.
G
G
This
is
just
a
summary
of
what
we
walked
through
the
last
two
or
three
meetings
which
we
had
in
total
and
from
end
of
last
year,
just
to
to
get
everyone
on
board
steve.
Should
I
take
this
as
a
request
to
to
basically
not
make
that
statement
from
bardic
part
of
the
document,
but
basically
have
those
discussions
in
the
detailed
bits
and
pieces
of
the
of
the
due
diligence
document
is
this?
Is
this
correct?
This
interpretation.
C
So
I
think,
there's
two
options
unless
others
have
other
suggestions,
I
think
one
is
direct
feedback
in
each
of
the
sections,
because
I
believe
that's
what
we're
supposed
to
be
doing
here
is
addressing
the
individual
sections.
The
second
option
is
what
bartok
did
previously,
which
is
create
a
separate
google
doc
and
attach
that
to
this
as
well
like
with
a
link
at
the
top
of
the
dock
that
says
additional
information
over
here.
If
it
can't
be
folded
into
each
of
the
sections,
what
do
people
think.
G
I
think
both
is
fine,
as
long
as
bartek
is
okay,
with
the
with
the
form
of
representation
of
descent.
Of
course,
it
also
shouldn't
be
just
hidden.
I
think
that's
also
unfair,
but
I
I
I'm
fine
with
either
I
I
deliberately
don't
have
an
opinion.
I
deliberately
would
like
open
telemetry
as
the
applicating
project
to
to
say
how
they
prefer
it,
but
we
can
also
try
and
do
a
call
of
consensus
while
in
this
call-
or
I
don't
mind
so
steve
as
you
submitted,
I
take
you
as
the
person
who
leads
this.
C
Course
I
mean,
I
think
personally
in
my
mind,
what
is
better
is
if
it's
possible
to
add
direct
feedback
to
how
the
bolded
things
for
due
diligence
are
not
being
met.
That
would
be
ideal
in
my
mind,
if
that's
not
possible
or
there's
an
overarching,
a
bit
of
summary
or
feedback,
or
what
have
you
having
a
separate
dock
that
we
can
then
reference
to,
I
think,
is
also
acceptable.
So
that
would
be
my
recommendation.
G
Okay,
I'm
totally
fine
trying
to
do
this
in
this
case,
I
would
reject
politics
or
no.
I
would
not
reject
it.
So
people
can
comment
on
it
and
ask
for
a
clarification,
have
an
argument
about
the
underlying
things.
So
we
so
we
get
some
substance
to
it,
because
the
underlying
concerns
won't
magically
go
away.
H
G
C
G
C
G
So
maybe,
let's
walk
through
the
actual
concerns
get
baltic
to
to
to
put
meat
to
wear
or
non-meat
reproduc
reproduction.
So
we
can.
We
can.
We
can
have
this
on
firmer
legs
next
time.
Do
I
understand
correctly
that
we
should
not
consider
go
as
part
of
the
of
the
complete
thing
and
we
should
only
be
looking
at
net
and
java
within
the
context
of
open
implementations.
C
N
G
Yep,
okay,
okay,
then,
in
this
case
I
I
think
it's
fair
to
just
like
we
still
should
get
or
or
bartik-
and
I
can
take
this-
we
can
ask
frederick
to
to
to
file
an
issue
here.
He
has
some
something
going
on
with
controv,
so
maybe
he
can
help
quite
nicely
yeah
and
then,
for
the
intents
and
purposes
of
this
goal
will
not
be
considered.
I
think
that's
a
fair
statement
to
to
make
for
this.
I
don't
see
any
steve.
C
G
N
G
G
N
So
yeah,
I
just
the
comment
here-
is
there's
only
one
data
model
that
we
use
for
each
signal
type
in
the
collector.
There
is
nothing
inside
the
collector
that
is
vendor
specific
right.
You
have
exporters
which
are
clearly
done
through
a
separate
api
that
are
in
separate
repos
that
can
come
in
to
export
data
to
an
endpoint,
but
those
exporters
adapt
from
the
core
open
telemetry
data
model
to
whatever
data
model.
The
exporter
author
wanted
to
use.
H
I
meant
here
right,
it's
like
I
I
I
know
how
how
collector
works
nowadays
right
and
that
there's
inside
collector
there's
like
a
single
api
that
all
receivers
and
exporters
have
to
implement
right.
But
the
problem
is,
I
want
to
use
a
certain
vendor
which
is,
for
example,
big,
like
data
hub
splunk,
or
something
like
that,
and
you
know
a
user
now
has
to
use
some
kind
of
vendor
vendor-specific
api,
because
those
probably
not
yet
support
the
otp.
That
core
provides
right-
or
maybe
I
don't
know
like.
H
N
N
N
It's
a
fair
question:
no,
the
distributions
is
a
fair
question.
I
I
suspect
that
we're
going
to
need
distributions
long
term
just
because
vendors
will
want
their
own
fork,
even
if
it's
just
a
snapshot
like,
even
if
there
are
zero
changes
to
it,
just
so
that
they
can
make
a
quick
change
and
meet
their
customers
slas
for
support
for
reference.
N
Like
I
I
know
we
don't
know
each
other
super
well,
I
was
at
google
until
january
now,
I'm
at
splunk
google,
the
plan
there
is
not
to
have
their
own
distribution
they're
using
the
pure
oss
one,
no
special
distribution.
That's
really
good,
and
I
was
part
of
that.
Splunk
has
their
own
because
we're
pulling
in
some
older
stuff
until
open
telemetry
replaces
it.
Eventually,
ours
will
be
pure,
open,
telemetry,
we'll
probably
still
have
it
just
because
we've
customers
with
like
very
expensive
slas.
C
To
have
vendor
support
here
to
do
this,
so
otlp
is
supported
end
to
end
through
all
the
client
libraries
support
it
sending
directly
to
the
collector
today
and
open
source
standards
like
jager,
zipkin
and
hopefully,
eventually
entirely
prometheus
will
be
supported
as
well.
That's
the
goal
so
like
you,
don't
need
a
vendor
receiver
in
the
collector.
The
primary
reason
for
vendor
things
is
for
exporters
for
a
back-end
that
hasn't
adopted
to
otlp.
Yet
there
are
lots
of
vendors
that
have
been
around
for
a
decade.
They
can't
move
that
fast.
P
C
P
A
design
principle
of
open
telemetry
is
extensibility
and
having
vendor-specific
exporters
is
completely
viable,
as
well
as
having
distributions,
because
from
an
aws
standpoint,
we
want
to
provide
performance
and
security
guarantee
to
our
customers,
and
we
can
only
provide
that,
while
pointing
to
a
specific
set
of
bits
that
we
tested
and
just
to
point
out.
Kubernetes
has
distributions,
and
you
know
cncf
has
been
happy
with
that
for
a
while.
Now.