►
From YouTube: 2022-06-21 CNCF TAG Observability Meeting
Description
* Nominations (TL, co-chair)
* New Sandbox Projects - discussion of "welcome packet" for CNCF Projects
* Update on OpenTelemetry Profiling efforts
A
B
B
I've
been
largely
off
grid.
To
be
honest,
so
I
have
a
couple
of
like
administrative
things
to
just
announce
sort
of
for
the
record
on
the
video
I
know.
Ryan
was
gonna,
give
again
for
posterity,
even
hey
man,
an
update
on
what's
going
on
profiling,
and
we
have
the
time
to
use.
However,
we
want,
but
oh
and
alolita
is
literally
on
a
plane
actually
rather
on
a
plane
at
the
moment,
so
won't
be
here
today
either.
B
B
B
Good
there
now
I've
just
said
something
just
popped
up:
things
are
good.
I've
been
busy,
my
family's
back
to
being
healthy,
like
no
one's
sick,
so
that's
cool
and
sometimes
and
mental
space
is
free
enough
to
catch
up
on
some
profiling
stuff,
I'm
about
a
week
behind
the
conversation
on
the
hotel,
profiling,
stuff.
So
I'd
love
to
hear
an
update,
but.
A
B
B
B
So
one
of
the
things
that
we
should
probably
throw
on
the
agenda,
for
you
know
we'll
formally
talk
about
next
week
after
a
brief
comment
period
is
not
only
for
a
pack,
but
you
know
we
might
want
to
move
to
it
every
other
week,
every
like
every
month,
32
meetings,
one
of
those
meetings
should
probably
be
at
this
time,
but
another
should
be
at
a
time,
that's
better
for
other
time
zones
and
or
schedules.
So
we
could,
just
you
know,
be
interlocked
exactly
at
the
wrong
time
for
many
people.
B
B
If
you
have
any
one
that
you
would
like
to
nominate,
please
reach
out
to
myself
or
alita
and
or
in
the
channel
I'll,
be
sending
out
an
email
with
later
on
tonight
with
specific
steps
to
the
list,
we've
not
done
nominations
before,
so
it
will
probably
just
be
a
google
doc
or
something,
but
yeah
do
reach
out
for
any
questions.
So
that's
one
thing.
B
Second,
the
toc
just
a
week
ago
met
for
their
regularly
cadenced
sandbox
inclusion
meeting
and
I've
put
in
the
meeting
notes
the
most
recent
set
of
votes
and
decisions
about
sandbox.
I
think
that
I
had
talked
with
some
other
other
members
a
few
weeks
ago,
newcomers
to
the
sandbox
as
well
as
just
some
people
in
the
community,
and
I
think
that
it
would
make
sense
if
we
as
a
workflow
and
as
a
tag
just
whenever
the
new
members
are
added
to
the
sandbox.
B
If
we
had
sort
of
a
welcoming
kit
a
from
the
tag
but
b,
you
know
with
stuff
specific
to
the
observability
and
analytics
side,
perhaps
something
like
a
survey
where
they
could.
You
know
in
a
consistent
way
we
could
just
collect
some
information
on
you
know.
Do
you
have
open
telemetry
integration
already?
Do
you
have
logs?
Do
you
have
specific
concerns
or
challenges?
B
A
B
B
B
A
yearly
update
or
review
you
know
that
they
give
to
the
toc.
You
know
we're
we're
not
we're
not
in
that
workflow
as
like
an
approver
or
anything
like
that,
but
I
think
it
would
behoove
us
and
then
maybe
it
would.
It
would
give
it
would
make
space
for
new
contributors
to
to
kind
of
come,
come
forward
and
contribute
and
actually
help
out
here
and
get
more
involved
with.
B
You
know
just
reaching
out
to
projects
that
are
in
our
scope
again
and
just
helping
to
facilitate
you
know
either
quantifying
where
they're
at
or
what
the
roadmap
is
or
identifying
places
where
the
community
might
be
able
to
reach
out
and
help
that
project.
So
I
kind
of
see
this
as
one
of
the
roles
of
the
tag
to
help
facilitate
and
to
facilitate
and
enable
that,
where
possible,
surely
do
you
keep
a
running
list
of
like
where
you
need
help
with
things?
B
Yeah,
I'm
I'm
pulling
up
a
link.
Right
now
seems
like
a
good
thing
to
put
in
the
welcome
kit.
I
mean.
Maybe
you
don't
want
to
scare
people,
but
no,
no
exactly
here.
I'll
put
it
in
the
chat
in
the
notes.
So
there's
a
few
different
projects
that
we
have
the
third
one,
the
the
kanban
kind
of
has
what's
going
on,
but
the
issues
have
a
help,
one
and
tag
so,
for
example,
here
there's
the
query.
B
This
is
like
a
list
of
all
the
projects
we
have
to
find.
Now
that
are
like
you
know,
shovel
ready
and
in
most
cases
someone
can
just
pick
it
pick
it
up
and
work
on
it
and
then
there's
also
a
few
that
are
marked
as
good
first
issue
versus
hope
wanted.
But
I
haven't
really.
We
haven't
really
been
using
that,
but
the
good
first
issue
is
like
I
have
no
contacts
on
what
observability
is,
but
I
want
to
do
something
to
help
anyway.
B
Do
the
links
in
the
chat
get
recorded
into
the
call
they
technically
do
in
terms
of
they?
Well
so
there's
two
things
there's
when
I
upload
them
the
videos
from
youtube.
I
do
get
a
well,
it's
not
chat,
but
it's
it's.
The
closed.
Captioned
closed
captioning.
The
actual
chat
is
like
a
text
file
and
up
until
recently,
we
didn't
have
a
great
place
to
put
them
other
than
github.
I
could
put
them
there,
but
we
also
just
got
a
google
drive
folder.
B
So
if
yeah
I
could
start,
we
can
start
persisting
the
notes
and
we
can
get
them
for
previous
meetings
too,
like
when
you
log
into
zoom
as
tag
observability,
you
have
access
to
all
of
the
previous
recordings
and
everything
so
if
you
think
do
that,
is
that
what
you're
implying
or
oh?
No,
I
was
just-
I
just
wasn't
sure,
that's
all
oh
yeah
I
mean
I
usually
try
to
make
a
habit
of
duplicating
everything
into
the
actual
notes.
B
I
think
another
workflow
that
I've
seen
work
in
places
like
the
cross
plan
project
and
some
of
their
meetings
is
moving
to
hackmd
or
something
like
that.
You
know
so.
We're
just
starting
with
markdown
and
then
committing
the
notes
from
the
meeting,
as
well
as
any
links
and
stuff
like
that
from
the
chat
to
github.
I
think
a
bureau
of
k-8s
that
working
group
with
ken
finnegan
and
others
started
to
do
that
to
try
to
try
it
out.
B
Anyway,
other
than
maybe
yammering
on
about
the
landscape
graph
project,
which
I've
been
tinkering
with
on
the
side-
and
I
think,
has
some
implications
for
observability
and
and
for
the
tag
which
I
can
talk
about
at
the
end,
if
we
need
full
time,
but
I
had
planned
a
more
comprehensive
overview
for
our
next
meeting
ryan,
if
you're
ready
to
give
the
hotel
profiling
update.
That's
really
the
last
thing
on
the
agenda
unless
there's
other
stuff
that
either
of
you
would
like
to
discuss.
A
A
A
What
you
know
is
is
in
the
realm
of
like
what
I'll
tell
hotel
is
meant
to
do
and
and
that
kind
of
stuff,
and
so
so
yeah
so
anyway,
so
for
the
last
so
for
the
first,
we've
had
two
meetings
so
far.
The
first
meeting
was
just
a
overview
of
just
a
lot
of
different
people
from
a
lot
of
different
profiling
related
either
companies
or
functions,
open
source
performance
or
apm
solutions.
Some
of
the
cloud
providers
what's
up
can.
B
A
B
B
A
A
I've
got
their
charter
here
too
for
experience
so
meeting
notes.
I'll
put
it
up
or
let's
see,
where's
the
part
that
I'm
talking
about.
Okay
yeah.
Here
we
go
so
that's
the
technical
committee,
so
yeah
a
bunch
of
people
from
various,
I
guess:
yeah,
there's
typically
yeah,
mostly
sort
of
apm
providers
and
like
the
cloud
you
know:
microsoft,
google,
splunk,
facebook,
lightstep
and
dynatrace,
and
so
yeah,
so
we're
working
on
trying
to
get
a
is
official
sort
of
sponsor.
A
I
just
came
from
the
meeting
right
before
this,
where
we
were
talking
about
what
that
actually
looks
like
and
they're
trying
to
also
sort
of
fix
that
process
there
and
they're
thinking
about
using
the
profiling
group
as
a
good
sort
of
like
you
know,
test
of
updating
their
docs
so
that
because
yeah
like
there
was
no
information
on
that
for
us
so
anyways
but
yeah.
What
I
was
saying
was
that
the
first
meeting
was
just
a
lot
of
people
meeting
talking
about
what
they
would
want
out
of
a
standardized
profiling
format.
A
A
You
know
agreed
upon
standardized
format
that
would
hopefully
address
all
of
those
issues,
as
opposed
to
everybody
branching
off
into
their
own
custom
formats,
which
is
kind
of
the
goal
here,
is
to
to
kind
of
get
one
format
that
everybody
can
or
most
people
can
agree
on.
That
will
support
most
of
the
use
cases
and
in
that
way,
when
people
build
on
it
going
forward,
they
build
collectively
versus
building
off
in
their
own
little
silos.
A
So
yeah
that's
kind
of
the
update,
there's
yeah
there's
so
far.
I
can
speak
on
behalf
of
pyroscope
that
we
we
use
a
custom
format
for
profiling
and
we
submitted,
or
we
created
a
video
and
a
doc
that
sort
of
explains
what
we
would
like
what
we
would
like
to
see
out
of
a
custom
format.
Obviously
we
don't
speak
for
everybody,
but
we
kind
of
got
the
ball
rolling
there
so
we'll
at
least
be
talking
about
it
and
then
pixie.
They
also
use
a
custom
format.
A
A
They
were
going
to
talk
about
sort
of
more
in
general,
they
their
thoughts
on
the
suitability
of
just
p
prof
in
its
current
form,
and
you
know
what
improvements
it
might
need
and
then
and
then
we're
still
looking
for
someone
to
contribute
to
the
jfr
part
of
that
conversation,
sort
of
evaluating
jfr
on
a
couple
of
different.
You
know
points
on
the
goals
that
I
mentioned
and
and
yeah
that's
kind
of
what
the
what
the
plan
is
for
thursday.
B
Yes,
I
just
realized
that
I've
not
been
on
mute,
so
if
you
all
have
been
hearing
the
clickity
clack
of
a
mechanical
keyboard,
my
apologies
as
you're
talking,
as
I
said,
I'm
about
a
week
behind
on
on
some
of
this
stuff.
So
in
the
most
recent
meeting
I
have
a
question.
I
remember
you
and
I
at
one
point
or
maybe
in
a
previous
tag
meeting.
I
can't
remember
where
we
had
talked
about
the
notion
of
you
know,
rather
than
trying
to
enforce.
B
You
know
in
terms
of
finding
consensus
for
a
profiling
format
by
having
sort
of
like
a
consensus
format,
but
then,
as
part
of
the
the
format
of
the
protocol,
spec
being
able
to
define
or
at
least
reference,
and
it
can
in
a
consistent
way,
conversion
lambdas
or
conversion
function.
That's
that
would
that
would
move
either
to
or
from
a
very
particular
vendor
specific
format
that
might
have
additional
metadata
or
be
augmented
with
additional
stuff.
B
You
know,
as
part
of
that,
so
so
being
able
to
engage
with
this
without
having
to
change
one's
own,
existing
tooling
or
be
constrained
by
it.
Has
that
sort
of
idea
come
up,
or
is
it
still
more
at
the
at
the
first
order?
You
know
assessment
of.
Can
we
just
all
agree
on
a
format
you
know
which
I
think
is
less,
but
personally
I
I
think
is
less
likely
just
in
terms
of
yes.
A
Yeah,
I'm
just
adding
the
video
recording
and
the
meeting
notes
as
well
to
the
these
meeting
notes
yeah
that
definitely
made
it
in.
So
we
haven't
gotten
down
to
like
what
that
actually
looks
like,
but
we
did
include
that
as
one
of
the
four
main
goals
that
we
have
established
so
far
and
I'll
read
those
off
now
that
those
goals
are.
A
It
is
just
like
the
idea
of
like
continuous
profiling
being
the
primary
goal
of
this
format,
like
it
being
able
to
at
least
support
that,
but
at
most
hopefully
also
supporting
more
of
a
like
ad
hoc
sort
of
instrumented
profiling
type
of
use
case,
but
that
the
the
vast
majority
was
focused
on
like
continuous
profiling
and
the
idea
of
being
able
to
send
yeah
send
a
lot
of
profiling
data.
So
that
was
one
goal.
A
The
other
goal
was
it
being
able
to
connect
profiles
to
other
hotel
signals,
so
logs
metrics
traces,
this
new
format,
being
something
that
is
somewhat
custom-built
for
that
use
case
as
that's
obviously
one
of
the
main
goals
of
otel
or
maybe
not.
Obviously.
But
yes,
it's
one
of
the
main
goals
of
otel
and
something
that
people
have
seem
to
be
most
excited
about
and
most
interested
in,
and
I'm
sort
of
unifying
all
of
their
various
signals
in
one
in
one.
A
You
know
in
one
place
and
using
otel
as
the
means
to
do
that.
The
third
one
was
representing
transmitting
profiles
across
native
code,
slash
runtimes,
that's
something
that
I
think
was
sort
of
coming
out
of
the
ebpf
contingent
there
of
wanting
to
be
able
to
represent.
You
know
this
code
and
I
guess
it's
not
necessarily
ebpf,
but
at
least
those
are
the
ones
who
brought
it
up
being
able
to
say
this
is
python
code.
A
This
is
library,
code,
kernel
code,
I
guess
being
able
to
differentiate
somehow
and
allowing
space
in
the
format
to
be
able
to
differentiate.
Different
parts
of
the
code
was
important
to
people
and
then
the
fourth
one
and
last
one
that
we
came
up
with
so
far
again
we
may
come
up
with
more
as
time
goes
on,
is
the
one
that
you
mentioned
being
able
to
the
way
we
phrased.
A
What
can
we
build
on
top
of
this
to
make
it
so
that
you
know,
for
example,
if
we
were
to
use
something
close
to
p,
prof
or
close
to
jfr
or
whatever
format
we
ultimately
choose,
you
know:
how
can
we
build
something
that
can
sort
of
flip-flop
between
them
or
or
some
type
of
tool
that
can
go
between
them
so
that
people
people's
existing?
You
know
the
go
runtime
already
uses
p-prop,
for
example,
java
uses
jfr
already.
You
know
a
lot
of
cloud
providers.
A
Google
or
google
created
pprof,
so
they're,
obviously
using
it
datadog.
So
there's
like
a
lot
who
are
using
certain
formats
already,
and
so
what
we
don't
want
to
do
with
this
new
format
is
make
it
so
that
everything
is
obsolete
and
it's
a
huge
pain
to
change
it,
but
rather
make
it
something
that
will
enhance
and
hopefully
like
improve
upon
those
one
of
those
or
all
of
those
existing
formats
and
kind
of
take
the
best
of
each
of
them
and
then
sort
of
unify
it.
B
B
Perhaps
you
can
provide
you
know
summarize,
but
all
of
this
that
we've
been
talking
about
is
kind
of
about
about
the
specific
structure
of
the
format
of
you
know
a
profile
report
when
it
comes
when
it
comes
to
continuous
profiling
or
continuous
tracing,
but
I'll
leave
the
tracing
bit
alone,
not
distributed
tracing
but
old
school
older
execution
tracing.
You
know
that
could
be
viewed
as
like
a
series
of
micro
batch
reports.
B
Like
you
know,
you
can
have
a
profiling
report
covering
a
particular
time
span
and
and
on
the
wire
you
know
it's
it's
little
little
nuggets
of
discrete
reports
covering
some
period
of
time
or
it
could
be
viewed
as
more
of
a
streaming.
You
know
unbounded
versus
a
bounded,
but
you
know
rather
instead
of
a
series
of
bounded
chunks
of
data.
You
know
in
series:
perhaps
you
know
actually
treating
it
as
the
unbounded
data
source.
B
B
For
example,
if
you
look
at
avro
right
where
it's
it's
really
optimized
for
change,
detection
and
capture
relational
databases-
so
you
know
you
can
almost
think
of
every
row
of
a
table
has
an
extremely
compact
rough
schema
or
reference
to
a
schema.
You
know
the
analogy
being
for
symbolic
information
version,
or
some
other
kind
of
you
know
schema
information
that
describes
the
rest
of
the
data.
A
B
A
Up
with
keep
in
mind,
you
know
as
we
move
forward,
which
is
part
of
what
we're
going
to
talk
about
on
thursday
as
well.
Actually
it's
just
like
the
current
existing
formats,
for
example
like
jfr
profiles,
can
be
like
massive
just
because
of
you
know
just
java
stuff,
but
but
yeah,
and
so
it's
like
you
know,
can
we
use
that?
Like
that's,
you
know
how
feasible
is
that
that
you
know
so
that's
kind
of
the
discussion
that
that
this
thursday
will
be
focused
on
is
sort
of
you
know
evaluating.
A
What
is
the
current
spectrum
that
this
sort
of,
like
you
know
that
these
profiles
exist
on
on
the
wire
currently
for
whether
it's
pprof
or
these
custom
formats
or
jfr
or
whatever?
And
then
you
know
from
that
spectrum,
we
kind
of
have
a
you
know.
Okay,
this
is
the
maximum.
We
can't
do
that.
This
is
the
minimum.
We
could
do
that,
but
we're
not
going
to
be
able
to
do
as
much
as
we
want
with
that.
A
B
So
so,
from
reviewing
the
notes
and
from
listening
to
talk,
it
sounds
like
if,
if,
if
you're,
echoing
sort
of
the
sentiment
of
the
of
the
community
or
the
discussion
thus
far,
it
sounds
like
this
is
really
profiling.
Continuous
profiling
data
and
metadata,
I
suppose,
is-
is
being
thought
of
as
a
series
of
discrete
reports
of
formats
that
cover
potentially
overlapping
time
ranges,
but
it's
not
being
considered
as
sort
of
a
stream
so
yeah
as
of
right.
A
Now
I
would
say
that
is
where
the
conversation
is
leaning.
I
mean
obviously
yeah
we
haven't
like
you
know,
and
there
have
certainly
been
people
who
have
voiced.
You
know
the
opposite
of
that,
but
I
would
say:
yeah
the
stronger
consensus
seems
to
be
that
direction
and
but
they
aren't
necessarily
mutually
exclusive.
B
And
has
there
been
any
thank
you
and
has
there
been
any
sort
of
specific
look
at
in
terms
of
implementation
in
the
hotel
collector
either?
You
know
you
know
what
existing
pieces
might
pick
up
which
which
portions
of
this
already
you
know,
since
whether
there
are
advantages
as
opposed
to
treating
you
know,
treating
the
the
continuous
profiling
stream
as
a
you
know,
set
of
packetized
discrete
chunks,
because
you
know
some
of
them.
B
A
I
mean
some
people
do
have
been
talking
as
well
about
a
concept
of
like
if
we
were
able
to
find
a
way
to
make
profiles
slightly
stateful
or
make
something
stateful
in
a
way
where
you
could
do
like
symbols,
basically
making
it
easier
to
like
deal
with
symbols
and
that
kind
of
stuff.
So
there
is
a
a
you
know.
There's
definitely
talk
about
that
as
well,
but
that
complicates
things
a
lot.
B
A
B
B
You
know,
then
every
report
comes
from
a
particular
binary
and
that
particular
binary
really
links
to
a
particular
point
in
time
in
the
histories
of
all
the
constituent
parts
of
it
in
terms
of
symbolic
information
right,
so
it
almost
motivates
a
discussion,
and
I
I
don't
think
this
has
come
up
yet
or
I've
not
seen
it,
but
you
know
you
can
almost
have
you
always
now
have
the
need
for
a
symbolic
database
that
kind
of
not
only
tracks,
you
know
a
particular
binary
or,
like
you
know,
lookups.
You
know
like
for
this
binary.
B
A
giant
relational
store
or
other
other
sort
of
like
key
value
store.
You
know
that
just
gives
you
symbolic
info
for
a
particular
binary
right
and
leave
it
at
that,
but
that
puts
a
lot
of
onus
on
any
kind
of
tooling
to
make
sense
of
it
versus
like
building
something
a
little
more
nuanced,
like
a
graph
back-end
graph
database,
there's
more
time,
traveling
in
nature,
right
and
and
and
not
only
tracks
like
the
raw
like
symbol,
server
and
other
symbolic
information
data
database.
B
Databases
typically
are
just
that
key
value
kind
of
thing,
but
you
know
perhaps
a
data
store
that
understands
the
lineage
of
things.
You
know
all
the
way
to
source
with
with
some
indexing
there
as
well.
You
know
so
when
you're
looking
at
continuous
profiling
for
binaries
that
change
over
time,
but
only
in
iterations,
you
know
you
can
you
can
almost
envision
one?
Could
one
can
imagine
a
revision,
a
symbolic
store
back
end
and
or
source
server
back
end
that
could
pair
with
any
tooling
that's
using
these
profile.
B
A
Yet
appropriately
yeah,
everybody's
kind
of
like
everybody's,
like
yeah,
would
be
great,
and
then
it's
like
when
it
comes
down
to
like
okay,
but
like
how
do
you
actually
do
that?
There's
a
lot
there
yeah
it's
like!
That's
that's
a
whole.
I
think
I
mean
yeah.
It
seems
to
me
that
that
could
be
a
whole
step,
because
I
mean
I
and
I
don't
think
that's
a
problem.
A
That's
like
necessarily
unique
to
profiling,
like
it
would
be
nice
to
be
able
to
make
use
of
something
like
that
for
other
signals
as
well,
and
so
it's
like
you
know
it
does
to
me.
You
know
personally
feel
like
a
separate
like
it
could
be
its
own,
separate
sort
of
like
working
group
thing
to
then
like
take
all
of
these.
You
know
hotel
signals
and
find
a
way
to
make
them.
You
know
yeah
make
that
all
work,
but
for
now
we
that
is
not
necessarily
or
yeah.
B
You
know
something
something
like
this
right.
Where
you
have
a
temporal
index
and
these
time
domains,
don't
necessarily
have
to
be.
You
know,
wall
clock.
They
can
also.
Are
you
sure,
on
your
screen
or
where
did
you
show
this?
Oh,
I
I'm
not
sure
my
screen,
but
it's
in
the
document
in
the
meeting
notes.
Oh
I'm,
looking
at
I'm
looking,
I
put
a
link
to
so
in
this
case.
You
know
this.
B
This
graphic
there
it
is.
This
comes
from.
It
was
a
neo4j
library
for
indexing
time.
You
know
when
you're,
when
you
want
to
when
you
want
to
interest,
but
anyway
the
temporal
domain
you
know
like
are
the
indexing
of
this.
This
kind
of
tree
around
you
know,
wall,
clock
time.
You
know
kubernetes
revision
or
binary
revision
and
illness
in
a
lineage
of
you
know.
This
could
be.
B
B
A
I
would
just
would
just
say
for
this
meeting
yeah
like
anyone
who
has
you
know,
thoughts
on
this,
and
I
do
you
know
hope,
like
long
term
that
this
will,
you
know.
Hopefully
this
group
will
be
able
to
you
know,
help
contribute
in
some
way,
like
maybe
you
know,
as
as
things
mature
talking
with
people
who
would
be
implementing
this
or
companies
who
would
be
integrating
this
into
their
systems
or
something
like
that.
A
A
B
B
B
B
Nice,
I
just
confirmed
that
it
works
swimmingly,
cool,
okay,
okay!
Well,
unless
there's
anything
from
anybody
else,
I
think
that
might
be
a
wrap
actually
starting.
So
technically,
these
our
tag
meetings
are
supposed
to
be
50
minutes
long,
not
an
hour
to
my
knowledge
in
two
years.
I
don't
think
we've
ever
quit
early,
but
but
once
44
minutes
past
we
can
be
six.