►
From YouTube: 2022-07-19 CNCF TAG Observability Meeting
Description
* Profiling in OTEL update - join #otel-profiling on CNCF Slack
* https://github.com/cncf/tag-observability/issues/89
* Annual Review for O11y sandbox projects
* See https://landscape.cncf.io/images/landscape.pdf for project status
* Open Source Stories - Topics that Henrik would like to cover -
A
B
B
No
a
little
earlier
this
year,
there's
four
kids
in
the
house,
and
so
we
got
them
all
like
like
tiny
little
boards.
You
know
with
a
ryzen
3000,
like
you,
know,
kind
of
cheap
and
I
think
it'll
be
like
a
four
node
house
cluster
like
when
they're
not
around,
but
that's
just
a
dream,
really
they're
playing
games.
B
C
B
A
B
A
Quite
too
too
too
young
they
were.
I
did
some
build
some
raspberry
pi
with
a
lot
of
electronic
components.
Hey
we're
gonna,
do
a
lead,
we're
gonna,
do
a
display
with
a
here
is
let's
work
together
and
then
after
two
minutes
I
was
going
to
prepare
the
this
is
the
circuit
when
you
put
all
the
various
electronic
components-
and
I
just
looked
at
my
kids
and
they
were
looking
at
me
and
saying:
okay,
maybe
maybe
you
need
more
more
more
school.
B
D
C
D
C
B
B
B
So
with
that,
I
I
did
seed
the
agenda
with
a
couple
of
just
newsworthy
notes,
if
nothing
else
that
I
could
plow
through
probably
extremely
quickly-
and
we
have
most
of
the
the
agenda
and
the
time
open.
So
maybe
we
could
kind
of
as
alita
mentioned,
but
oh
I
forgot
to
put
in
the
docs
if
somebody
already
has
them,
otherwise
I
will
put
them
in,
but
you
know
there
has
been
some
movement
around
the
hotel,
profiling
effort
to
add
a
new
signal.
B
Ryan
is
actually
getting
on
a
plane
right
now,
or
else
here
as
well
and
for
the
meeting
coming
up
this
thursday.
The
topic
that
was
raised
by
folks
that
they
wanted
to
chat
about
this
week
was
you
know
who
actually
benefits
from
a
consistent,
consolidated
profiling,
open
telemetry
format
so
and
in
previous
weeks,
we've
gone
through
the
various
profiling
formats,
as
well
as
some
discussion
around
what
it
might
look
like
or
what
it
could
look
like.
There's
some
substantive
discussions
in
hotel
profiles.
B
You
know
anyway,
so
I'll
just
highlight
there
there's
active
discussions
and
it's
pretty
pretty
amazing
from
the
toc
and
the
cncf
side
tag
contributor
strategy
has
just
put
out
an
email
template
that
could
be
used
by
you
know
once
projects
do
their
annual
sandbox
review.
You
know
that
that
a
template,
the
toc
or
tag
could
use
to
reach
out
to
that
project
and
say:
hey
you've
just
had
your
review.
There
was
some
feedback
here
are
some
next
steps.
B
B
Yeah,
so
the
issue
I
was
talking
about
was
issue
number
80,
which
is
just
something
for
us
to
form.
An
annual
sandbox
review
like
the
durability.
Analytics
section
has
been
growing
rapidly
and
you
know
minimally.
This
would
be
like
a
timeline
with
when
they
join
the
sandbox
and
when
their
annual
annual
reviews.
B
D
B
B
This
is
like
the
wrapper
issue
to
actually
make
a
graphql
endpoint,
so
without
delving
too
deep
in
long
and
short
of
it
is
graphql
is
a
nice
typed
interface
definition,
language
that
supports
inheritance,
and
you
know,
interfaces
and
unions
and
and
all
kinds
of
other
custom
types
and
the
integration
between
neo4j
graph
database
and
graphql
is
great.
Since
we've
started
this
project
apollo,
which
is
in
roughly
90
of
of
all
graphql
server
implementations
that
are
kind
of
out
there
in
force
at
least
that's
another
number.
B
I
read
they've
released
what
they
call
federation
2.0.
So
it's
a
and
they've
released
a
bunch
more
of
this
as
open
source
versus
an
enterprise
offering
in
addition,
they've
released
a
router.
So
we
have
our
first
contributor
that
popped
up
and
started
asking
all
kinds
of
questions
you
know
about.
How
are
we
gonna?
You
know
the
different
ways
we
could
do:
schemas
and
whatnot
and
some
of
the
issues.
I've
responded
here
and
I'll
be
following
up
in
the
next
week
or
so
with
some
more
serious
stocks.
B
B
C
B
Yeah,
so
it
turns
out
that
I
had
done
this
way
back
in
april
this
notion
of
subgraph
modules
and
without
reading
all
this
you
can
kind
of
see
like
if
we
had
these
sorts
of
modules
that
were
independent,
independently,
testable
independently
soluble.
If
you
will
you
end
up
with
something
that
kind
of
looks
like
this,
sgm
is
subgraph
module
right,
so
we
want
to
not
have
a
monolithic
schema.
B
B
What
apollo
federation
does
is
specifically
provide
a
really
well-formed
way
to
do
exactly
this.
So,
for
example,
you
know
something
in
one
part
of
the
graph
can
use
a
type
defined
in
another
or
can
even
extend
the
type
and
there's
some
rules
around
how
these
are
composed,
together
into
a
unified
schema,
made
up
of
all
of
these
subparts.
So,
rather
than
going
on
and
making
something
bespoke
in
the
last
month,
you
know
I've
kind
of
taken
on
taking
a
left
turn
and
said.
B
Well,
you
know,
there's
a
industry
standard
way
that
is
being
well
received.
That
is
very
well
thought
out.
So
let's
do
that
instead,
so
that,
in
a
nutshell,
is
where
we
are
with
this
graph
project.
So
in
the
next
week,
or
so,
I'm
working
on
docs
and
getting
an
mvp
of
this
working,
we
already
have,
I
should
say
an
mvp
of
this
compositional
model
working.
So
that's
that.
C
I
think
matt
I
wanted
to
again.
You
know,
first
of
all
enable
everybody
to
you
know
kind
of
output
items
that
they
wanted
to
discuss,
but
also
wanted
to
look
at
and
revisit
our
observability
projects
under
cncf
to
see
if
we
can
shortlist
some
of
the
projects
we
can
reach
out
to,
for
you
know,
reviews
and
I
did
share
a
link
for
the
landscape
graph
again.
There's
a
card
form
also
that
we
could
look
at
but
would
like
to
kind
of
go
through
at
least
the
list.
C
A
For
me
I
was
just
I'm
trying
to.
I
started
this
open
source
news
initiative.
Yeah
I've
been
been
a
bit
bit
been
a
bit
busy
with
the
content
all
the
stuff,
so
I
didn't
have
a
I.
I
still
have
the
storyboard
open,
but
I
didn't
have
the
right
bandwidth
to
to
record
and
produce
everything,
but
it's
still
still
in
my
I
didn't.
C
C
A
Do
I
I
because
I
we
work
closely
with
michael
on
this
one,
so
I
usually
go
start
with
what
he
has
identifying
his
open
source
news
and
from
there
I
look
at
it.
I
try
to
usually
he
he
selects
blogs
and
stuff.
So
I
try
to.
I
have
a
section
where
I
put
the
blogs
in
the
books
at
the
end,
so
I
select
few
a
few
links
there,
but
then
I
try
to
identify
project
that
that
are
interesting
or
updates
on
projects
that
are
interesting.
C
Mean
I
think,
one
of
the
other
areas
hendrick
that
I
was
thinking
that
might
be
very
useful
and
maybe
kevin
can
also
provide
us.
Some
input
here
and
I'll
reach
out
to
other
folks
in
the
kubernetes
community
is
actually
to
highlight
on
some
of
the
integrations
that
the
kubernetes
project
is
building
out
of
the
box
for
observability,
and
you
know
again
kind
of
focus
in
on
more
how
to's
in
that
area.
D
A
Yeah,
because
the
open
source
news
is
is,
is
the
main
objective
is
to
share
updates.
So
people
is
aware
and
spreading
the
news
for
everyone.
The
is
it
observable
is
more
on
the
tutorial
side.
So,
for
example,
now
I
just
recorded
and
I'm
starting
the
post
production.
I
do
a
deep
dive
on
the
collector
and
and
I'm
I'm
using
an
example
saying:
hey:
can
we
fully
observe
kubernetes
using
only
the
collector?
A
So
then
that's
this
excuse
to
to
present
few
receivers
that
has
been
built
by
the
community
for
kubernetes,
so
communities
cluster
companies
cubelets.
There
is
a
couple
of
them
like
this,
so
I
think
that
that
was
an
excuse
for
me
to
explain
how
you
build
a
pipeline
and
also
introduce
few
interesting
receivers
processor
whatever
to
our
audience
and
provide
tutorials
to
that.
So
again,
the
news
is
more
to
share
updates
and
projects
and
whatever
it
is,
and
is
it
observable-
is
more
on
the
tutorial.
C
Cool
yeah
and-
and
I
think
that
you
know
again
as
a
general
topic-
I
think
it
would
be
useful
to
just
you
know
kind
of
look
at
it
even
from
a
documentation
point
of
view
because,
as
you
know,
even
on
the
hotel
side,
there's
a
significant
project
that
has
been
ongoing
in
recent
weeks
on
improving
the
documentation
and
integrating
it
under
open
o.
So
again,
you
know:
that's
something.
Just
continuing
to
improve
the
documentation
on
major
projects
is
a
I'd
love
to
see
more
contributions
to
it,
especially
on
the
kubernetes
side.
D
C
D
C
C
And
then
you
know,
especially
the
area
where
for
configuration
like
are
you
using
side,
cars
versus
you
know,
operators
and
stateful
sets
and
and
really
you
know,
having
configurations
and
pros
and
cons
of
each
right,
because
they
are
again
scalability
considerations
that
you
would
have
otherwise
so
again
kevin.
If
there
are
topics
that
you
know
your
team
could
cover,
that
would
be
pretty
awesome
and
then
perhaps
we
can
get
other
contributors
who
are
also
working
on
a
hotel
like
david
ashford
and
others
to
you
know
maybe
dive
into
some
of
the
other
areas.
C
B
B
C
D
No
yeah,
I
haven't
been
in
the
instrumentation
for
a
while
I'm
looking
forward
to
this
week,
so
I
I'm
not
familiar
on
all
the
topics
they're
working
on.
I
only
know
that,
like
my
team
is
also
catching
up
on
metric
server
and
seeing
what
is
contributing
there
and
the
scalability
issues
we
have
with
it.
But
aside
from
that.
D
Like
the
metric
server
is
one
of
these
examples,
like
the
same
as
running
one
collector
per
cluster.
If
you
run
one
like
it's
a
it's
a
singleton
component,
it
can't
scale
other
than
vertically
and
the
more
nodes
you
add
and
the
more
pods
and
resources
you
add
at
some
point
it
like
use,
60
gigabytes
of
memory
and
that's
not
fun.
If
you
know
it's
only
50
gigabytes
of
memory.
D
C
That
integration
has
been
ongoing
for
a
while
and
and
of
course
metrics
is
you
know,
by
default,
supported
by
the
prometheus
agent
today,
but
would
love
to
see
you
know
more
integration
with
hotel
as
the
metrics,
you
know,
implementation
stabilizes
on
hotel
and
then,
of
course,
logs
has
a
different.
You
know
integration
today,
so.
D
The
tracing
question
in
kunis-
I
find
that
I
I
first
I
heard
about
it
were
like
looked
at.
It
was
a
few
years
ago
and
when
the
whole
thing
adding
tracing
to
kubernetes
started-
and
I
find
interesting
difference
because
right
now,
tracing
is
very
focused
on
requests
and
events
and
like
tracing
them
in
a
distributed
system
and
kubernetes
is
like
one
challenge
I
observed
was
tracing.
D
So,
like
an
operator,
I've
worked
on
a
project
before
we,
I
think,
tried
to
add
tracing
to
an
operator
or
maybe
did,
and
it's
like
it's
a
loop.
There
is
no
request,
so
you
need
to
export
trace
for
every
loop
and
every
run
of
the
loop,
and
that
can
give
you
interesting
data.
But
it's
counterintuitive
to
what
tracing
is
known
for
right
now.
C
Agreed
so
I
mean
there,
there
are
exactly
those
nuances
that
I
think
are
well
worth.
You
know
kind
of
looking
at
on
a
regular
basis,
because
it's
an
environment,
production
environment.
You
know
that
everybody
is
using
and
then
again
as
a
baseline
would
be
good
to
track
on
the
on
the
tag
group
to
kind.
D
B
Yeah,
so
I
think,
if
I'm
not
mistaken,
you're
referring
to
the
kubernetes
api
server
having
been
instrumented
for
yeah
yeah
yeah,
I
I
concur,
and
I
just
had
two
great
things
to
talk
about.
You
mentioned
that
we'd
reach
out
to
stick
instrumentation
last
summer.
I
believe
when
a
new
tech
lead
was
voted
in.
Yes,
I
reached
out,
you
know
with
my
tag
you
had
on
and
kind
of,
like
formally
said,
hey
sig
interpretation,
we're
taking
observability
we'd
love
to
talk
with
you
and
blah
blah.
B
B
C
B
And
then
the
second
thing,
absolutely
the
second
thing
kevin
what
you're
saying
around
operators
in
particular
being
hard
to
understand
by
looking
at
the
signals
we
have
today.
I
actually
couldn't
agree
more
and
I've
done
some
thinking
around
this
and
just
in
short,
like
you
know,
you
know
the
the
logs
approach
that
we
all
kind
of
grew
up
with,
and
many
of
us
did
where
everything
is
fine.
B
B
Into
a
graph
database
that
keeps
prior
versions
of
them
in
a
linked
list,
so
you
can
think
of
every
kubernetes
resource
has
a
linked
list.
The
head
of
that
linked
list
is
the
current
state
and,
as
you
traverse
this
list,
you
have
prior
states
back
in
time.
If
you
do
that
plus
link
everything
together,
you
know
objects
that
refer
to
other
objects
like
deployments
and
replica
sets
or
or
crds
or
whatever.
B
It
kind
of
works.
It's
actually
possible
to
go
the
other
way
too.
So
in
theory,
we
could
take
the
open
api
spec
from
kubernetes
right
for
from
all
these,
for
all
the
the
kubernetes
types,
but
more
interestingly,
for
all
of
the
crds
too.
You
know
that
all
these
operators
are
using
across
the
landscape
and
you
know
you
could
greatly
accelerate
creating
a
graphql
model.
B
You
know
to
to
define
the
schema
for
that
graph
database
and
and
because
the
open
api
surface
knows
the
connections
between
things
and
their
types
and
everything
you
know
you
have
a
really
quick
way
to
build
a
model
that
could
consume
this
data
and
then
provide
it
back
with
some
insights.
So
I'd
love
to
chat
more,
maybe
in
a
different
meeting,
yeah
that
I
have
here,
but
I
think
there's
legs
here
in
that
overall
approach.
D
D
I
think
these
days,
because
it
kind
of
gives
you
a
graph
if
you
know
what
you're
searching
for
but
yeah
and-
and
I
I
I
think
it
was
like
four
years
ago,
I
I
played
with
a
d
graph
for
a
while
and
and
tried
that
too
and
yeah.
That
would
be
interesting
and
if
you
could
enrich
it,
then
with
like,
if
operators
do
tracy
or
whatever
yeah.
B
Yeah
exactly
the
other
interesting
thing
about
that
data
model.
Is
that
the
intersections
be?
You
know
the
vertices
in
that
connected
graph?
That
is
the
state
of
kubernetes.
That's
a
nice
place
to
aggregate
metrics
very
efficiently
right.
You
can.
You
can
do
graphics
in
neo4j.
In
particular,
you
have
the
ability
to
very
quickly
filter
by
node
types
or
node
labels
so
like,
if
you
want
to
know
the
current
state
of
something
boom
and
then
I
think
it's
in
previous
notes,
I'm
just
scrolling
down
for
a
picture
yeah.
B
The
other
thing
that
you
need
to
make
a
useful
tool
is
to
very
quickly
be
able
to
get
time
spans
without
having
to
traverse
all
of
these
linked
lists
linearly,
and
so,
if
you
build
a
structure
kind
of
like
this
into
the
graph,
actually
two
of
them
is
what
I
hypothesize
would
be
nice
one
based
on
wall,
clock
time
like
this.
That
goes
down
to
seconds
and
microseconds,
but
you
could
think
of
kubernetes
resource
number,
which
is
monotonically
increasing
as
another
time
domain.
C
B
C
C
C
D
D
D
C
Yes,
I
totally
agree,
and
I
think
that
that's
really
an
area
where
it
really
benefits-
you
know
everyone
in
the
in
the
larger
ecosystem,
who's
using
kubernetes
in
any
shape
or
form
to
continue
to
increase
and
and
integrate
observability
out
of
the
walls
with
with
the
apis
that
that
are
developing
right.
So
totally,
I
I
think
we
have
ran
here,
ryan,
just
joined
in
so
hi
ryan.
Did
you
want
to
give
a
quick
update
on
profiling
and
just
you
know,
kind
of
some
of
the
areas
that
you're
blocked
on.
E
Yeah
sure,
sorry,
if
there's
noise
in
the
background,
I'm
at
an
airport
right
now,
but
but
yeah,
basically
the
yeah
we've
we've
gotten
a
good
some
good
momentum.
Going,
I
mean,
I
would
say
we
probably
have
an
average
of,
like
you
know,
15
to
20
people
who
show
up
at
at
the
meetings.
We
moved
the
meetings
to
bi-weekly,
I
mean
by
monthly
sorry
so
every
other
week,
but
but
yeah
we've
heard
from
let's
see
from
pixi
pyroscope,
basically
elastic
datadog,
basically
a
bunch
of
different.
E
You
know
profiling
companies
who
are
doing
some
sort
of
custom
format
and
sort
of
what
is
custom
about
their
format.
Why
it's
custom
and
then
also
from
the
google
prof
folks,
and
then
some
some
people
from
datadog
talked
about
jfr,
and
so
basically,
we've
heard
about
a
bunch
of
different
kinds
of
formats
and
so
now
we're
starting
to
sort
of
transition
into
okay.
Now
that
we
know
sort
of
a
taxonomy
of
all
the
different
formats
that
are
out
there,
what
is
you
know?
E
How
can
we
better,
you
know,
benchmark
these
things,
so
we
have
a
lot
of
like
qualitative
data
about
which
you
know
formats
are,
you
know
out
there
and
the
pros
and
cons
of
them,
but
we
don't
have
a
lot
of
quantitative
data
as
to
you
know,
yeah
like
how
they
compare
both.
You
know
on
the
wire
and
just
the
you
know
the
format
itself
and
then
so
that's
on
one
side.
E
E
Everybody
is
convinced
that
a
standardized
format
is
actually
net
beneficial,
for
you
know,
vendors
and
users,
and
you
know
hotel
in
general,
so
on
and
so
forth,
and
so
I
think
that's
another
area
where
this
group
might
be
useful
in
you
know,
sort
of
helping
convey
where
those
benefits
are
and
and
why
it
should
be.
You
know
a
an
effort
that
that
continues
to
move
forward.
So
those
are
the
biggest
things
and
then
I
guess
another
small
thing
is
just
that
we
need.
E
C
Okay,
ryan,
that's
that's
a
good!
Thank
you
again
for
a
very
comprehensive
summary.
I
think
that
again
the
cncf
tag.
Definitely
can
this
group
can
definitely
help
in
having
more
of
the
cross
project
conversations
you
know,
as
is
to
the
value
of
having
an
uniform
product
call
for
profiling,
but
also
perhaps
looking
in
more
in
depth
about
semantic
conventions
that
are
common
to
be
able
to
be
used.
C
E
I
winners
the
biggest
headwind
there
is
the
like.
I
think
the
vendors
have
been
generally
supportive
of
the
idea,
but
you
know
there's
always
going
to
be
like
well.
We
do
it
this
way.
What's
the
benefit
for
us
to
switch
to
this
other
standardized
format,
when
we've
already,
you
know,
invested
resources
and
so
on
in
you
know,
format
x,
why
should
we
switch
to
format
y?
E
And
you
know-
obviously
it's
you
know
happened
with
logs
and
metrics
and
traces
so
far,
so
you
know
so
there's
some
precedent
there
that
I
think
we
can
also
rely
on,
but
but
I
think
it's
just
a
matter
of
sort
of
you
know
conveying
that
it.
You
know,
I
mean
personally,
I
think
just
the
general
sort
of
promotion
of
profiling
at
itself,
as
just
you
know,
as
a
signal
type,
would
be
beneficial
for
everyone
and
if
it
takes
a
standardized
format
to
do
that,
I
think
it
would
probably
be.
E
You
know
again
like
net
positive
in
that
sense,
but
I
think
there's
also
benefits
as
well
as
being
able
to
you
know,
support
multiple
languages
more
easier
and
that
kind
of
stuff,
but
I
think
it's
just
a
matter
of
getting
those
kinds
of
messages
from
you
know
more
places,
so
companies
who
are
thinking
about
profiling,
who
are
willing
to
say
like
yeah.
It
would
be
much
nicer
to
adopt
this
if
all
of
our
stuff
was
going
to
be
in
the
same
format
or
you
know
like
stuff
along
those
lines.
If
that
makes
sense,.
C
A
great
agreement
totally
and
and
again
to
that
point
I
think,
there's
more
work
to
be
done
there
and
do
you
think
it
would
be
useful
to
kind
of
pull
in
the
you
know,
different
projects
who
have
done
their
own
implementations
like
pixie,
has
presented.
You
know
at
the
tag
before,
but
some
of
the
other
projects,
but
like
periscope
and
others
to
also
kind
of
do
a
deep
dive,
and
I
mean
I'm.
E
Yeah
yeah,
I
mean,
I
think,
yeah
having
a
larger
audience
would
definitely
help
in
that
sense.
Yeah,
that's
definitely
something
we
could
do
moving
forward.
Yeah
I
mean,
I
think
I
think
the
bigger
side
is
yeah
like
the
use.
I
think
the
the
sides
that
we
haven't
heard
from
as
much
are
the
users
who
would
be
actually
you
know,
implementing
profiling
in
their
project
and
you
know
adding
profiling
to
their.
You
know
to
their
company's
stack
and
then
you
know
also
a
little
bit
of
the
the
languages
themselves.
E
I
think
that
might
also
be
kind
of
a
tricky
one.
So
people
from
the
java
community
or
the
like,
you
know,
golang,
which
already
does
you
know
kind
of
supports,
p
prof
natively.
You
know
if
goling
had
to
switch
to
some
other
format.
I
imagine
the
language
maintainers
themselves
would
probably
have
you
know
some
thoughts
there,
and
so
it's
a
matter
of
kind
of
you
know
hopefully
finding
some
way
to
get
connected
with
people
from
those
communities
who
would
be
able
to
speak
to.
E
You
know
how
much
of
an
appetite
they
have
for
you
know
changing
the
way
that
they've
been
doing
things
as
well.
So
I
think
those
are
the
two
biggest
groups
that
we
haven't
heard
from
that
it
would
be
nice
to
have
input
from,
and
hopefully
people
from
this
group
could
you
know,
potentially
connect
us
with
people
from
those
you
know
the
right.
C
C
No
ryan,
I
mean
that's
a
great
point,
because
I
see
a
lot
of
similarities
with
you
know
the
discussions
and
the
work
that
has
been
ongoing
and
the
logging
sig
and
the
logging
you
know
implementation
per
language
right
because
again,
some
languages,
you
know,
come
with
logging
out
of
the
box
like
java
or
python,
and
then
there
are
others.
You
know
who
kind
of
built
a
layer
for
observability
on
top
right.
D
E
D
No,
I
said
I'm
also
interested
in
the
collecting
collecting
lots
of
profiles
both
in
the
language
and
getting
it
out
of
the
application.
Also
again
mainly
because
I
nice
question
I
last
week,
did
that
with
a
component
and
was
fascinating
or
like
looking
into
what
makes
it
so
much
more
again
memory
expenses
to
collect
profiles.
And
if
we
can
do
something
about
it
or.
E
A
E
And
I
think
that's
that's
one
of
the
biggest
things
too
is
that
you
know
one
thing
that
we've
seen
as
we've
talked
to
some
people
is
that
you
know
profiling
can
really
tie
a
lot
of
the
other
signals
together.
You
know,
for
example,
with
profiling.
You
know
how
expensive
it
is
to
add
tracing
and
logging
and
metrics.
You
know
you
have
like
a
collective
sort
of
overview
of
each
one
of
those
like
instrumenting
it
themselves.
I
think
you
had
mentioned
that
earlier,
that
you
were
kind
of
you
know
like
each
one.
E
Instrumenting
itself
has
its
own
overhead
and
so
you're
able
to
kind
of
understand
that
with
profiling,
and
we
also
want
to
kind
of
move
forward.
This
idea
of
like
linking
everything
together,
sort
of
natively
and
with
hotel.
You
know
it's
a
lot
easier
to
already.
You
know,
like
the
the
sort
of
foundation.
Is
there
to
be
able
to
link
it
together,
and
so
it's
just
a
matter
of
kind
of
tying
everything
together,
sort
of
like
conveying
the
story
in
a
cohesive
way
and
and
sort
of
getting
some
some
momentum
behind
it.
E
E
C
Yeah-
and
I
mean
I
totally
agree
with
that
statement,
because
I
I
do
think
that
you
know
again,
there's
a
lot
more
implementations
and
usage
and
metrics
and
logging,
which
have
kind
of
you
know
their
ad
hoc
standards
if
you
will
and
and
hence
you
know
that
influences
when
you're
trying
to
make
a
new
standard,
consistent
right.
So
in
profiling,
I
think
we
are.
The
field
is
still
greenfield,
so
definitely
much
higher
chance
of
of
being
consistent
at
the
protocol
level.
So
good
good
points
to
raise.
D
There's
also
an
interesting
point
of
like
teaching
people
when
to
do
profiling
or
like
yeah
like
when,
if
you
want
to
do
it
all
the
time
which
is
expensive,
I
added
I
never
profiling
in
the
hotel
collector
and
to
find
out
why
exploring
some
metrics
is
so
expensive
and
all
of
a
sudden
exporting
profiles
was
more
expensive
than
exploring
metrics,
which
was
kind
of
funny,
so
also
not
like
traces
and
metrics
and
profiling
and
logging
like.
How
do
you
balance
it?
C
B
One
thing
that
I've
noticed
is
that
the
meetings
have
been
really
good
and
that
you
know
so
far.
It's
been
a
series
of
show-and-tells
of
various
profilers
and
their
formats,
some
of
them.
For
example,
you
know
the
pixie
folks.
The
p-proc
folks
went
into
significant
substantive
detail
about
some
of
their
choices.
But
while
we've
approached
the
subject
in
slack,
I
think
in
terms
of
like
what
is
that
question
like?
What's
the
utility
of
having
a
standard?
B
It's
a
bit
the
discussion's
a
little
muddy
or
conflated
at
present
right
between
the
data
format
and
the
wire
protocol,
and
and
if
you
look
at
scenarios
as
it
relates
to
the
wire
protocol,
there's
a
couple
really
important
things
that
I
don't
think
it's
useful
to
like
hammer
out
consensus
on.
You
know
that
that
that
being
pushed
versus
pull
another
one
is
stateful
versus
stateless
right.
B
So,
like
is
every
request
of
the
transport
gonna
like
have
duplicate
data
right,
so
that
it's
a
stateless
request
or
a
stateless
packet
that
stands
alone,
but
then
you've
got
duplicative
overhead
right.
There
there's
different
times
where
you
might
want
to
do
different
things
or
similarly,
if
we
think
about
when
profiles
come
in,
there's
probably
like
a
parsing
step
right
to
go
from
whatever
format
to
whatever
kind
of
superset
data
model.
B
We
have
right,
but
then
there's
subsequent
you
know
compression
deduplication,
there's
these
different
transforms
that
can
be
applied
right
and
and
for
some
of
those
you
might
want
to
do
the
compute
expensive
part
of
that
processing.
At
the
point
of
collection
like
if
you
you
know,
some
people
might
want
to
do
that,
because
then
you
don't
have
to
shovel
the
data,
or
maybe
it
stays
there
in
sort
of
an
effective
ring
buffer
that
with
timing
out
data
after
a
month
or
so
or
a
couple
weeks
or
even
a
day.
B
You
know
deferring
all
post-processing
to
the
back
end
or
somewhere
in
between,
and
one
of
my
concerns
is
that
we
have
this
really
good
group
of
people
coming
together
in
you
know,
with
good
intent
and
truly
a
model
for
open
source
collaboration.
But
I
think
if
that
group
tries
to
force
like
one
size,
fits
all,
we
risk
fragmentation
and
then
making
things
worse,
not
not
better.
So
so
I
I'm
eager
to
to
get
to
those
more
focused
discussions.
B
C
D
C
E
B
E
The
ability
for
tags
is
something
that
or
labels
is
something
that
has
been
sort
of
like
emerged
as
something
that
is
commonly
you
know.
Every
custom
format
had
some
way
of
labeling
data,
whether
that
was
data
for
like
symbolization
type
of
stuff,
or
you
know
like
traditional
labels
like
you
have
with,
like
you
know,
traces.
You
know,
pod
name,
name
space.
You
know
that
kind
of
stuff,
and
so
yeah
I
mean
we've
definitely
had
a
lot
of
those
conversations.
E
You
know
sort
of
the
existing
formats
in
a
way
that
will
support.
You
know
all
the
different
people's
use
case,
and
so
that's
kind
of
where
the
conversation
is
now
but
yeah
I
mean,
I
think,
that's
kind
of
where
the
conversation
is
now
and
I
think
that
there's
generally
a
consensus
there,
which
is
why
we're
sort
of
moving
to
the
benchmarking
stage
to
at
least
benchmark
sort
of
yeah.
E
You
know
some
of
the
you
know,
sort
of
yeah
like
quantitative
metrics
that
will
come
with
you
know
if
you,
if
you
do
add
room,
for
example,
to
encode
labels
or
something
like
that
like.
How
do
you
do
it
in
a
way?
That's
you
know
efficient
and
low
overhead
and
that
kind
of
stuff-
and
so
I
think,
that's
sort
of
you
know,
regardless
of
which
direction
we
go,
that's
something
that
we'll
need
and
then
figuring
out
the
you
know,
wire
format
and
that
kind
of
stuff
will
sort
of
come
after
that.
C
I
totally
agree,
and-
and
again
I
think
we
have
some
action
items
over
here
and
then
some
good
topics
so
matt.
Maybe
we
can
kind
of
follow
up
on
some
of
these.
I
have
two
action
items
I'll
definitely
reach
out
to
the
sig
instrumentation
group
from
kubernetes
and
get
some
of
the
folks
also
to
join
in
and
then
on
the
profiling
side,
ryan
I'll,
follow
up
with
the
tc
to
see.
If
you
know,
there's
another
dc
member
who
can
join
him.
E
E
B
If
we
do
have
that
kind
of
coupling
decoupling,
rather,
you
could
almost
think
of
as
a
as
a
thought
experiment.
You
know,
because
so
many
profiles,
you
know,
they're
looked
at
after
the
fact
you
know
you
don't
really
need
real-time
profiles,
you
can
almost
think
of
like
what
would
it
look
like
if
there
was
a
global
data
model
for
all
profiles
on
earth?
B
You
know,
you
know
then,
and
you
assume,
that
it's
okay,
if
things
are
eventually
consistent,
then
suddenly,
like
the
specifics
of
a
wire
protocol,
are
less
important
than
the
description
of
the
data
that
that
protocol
would
move
because,
for
example,
there's
all
kinds
of
ways
to
move
data,
and
you
know
you
could
use
a
distributed.
Key
value
store
like
tikv.
B
It's
obviously
not
optimized
but
like
there
are
ways
where
you
could
like
not
have
to
make
hotel,
define
an
actual
down
to
the
bit
protocol
and
still
move
data
where
it
needs
to
be,
or
maybe
the
data
resides
there,
but
it
needs
to
be
sharded
out.
You
know,
because
you
don't
want
to
move
all
this
data,
you
want
to
leave
it
there,
but
have
it
in
a
different
database
or
a
different
way
to
a
different
back
end
right.
B
So
I
I'm
not
sure
if
that's
a
crazy
idea
or
not,
but
but
that's
what's
been
in
my
in
my
brain,
coming
out
of
the
last
profiling
meeting,
it's
like
what
would
that
global
data
model
look
like,
because
if
we
could
agree
there,
it's
easier
to
agree
to
that.
You
know
across
all
these
concerns
and
then
it
and
then
it
kind
of
it
forces
a
discussion
of
it
forces
treating
the
transport
layer
as
just
that
just
a
way
to
shovel
bits
and
there's
different
scenarios
that
are
needed
there
right.