►
From YouTube: 2022-06-03 meeting
Description
Instrumentation: Messaging
B
B
C
A
A
All
right:
well,
I
guess
we
can
give
a
couple
more
minutes
for
people
to
filter
in
yeah
I
created
a
doc.
I
just
from
what
I
had
talked
to
morgan
about
before
of
like
what
potential
steps
are.
I
created
a
new
doc
more
specific
to
just.
I
guess
this
meeting
I'll
put
it
in
the
chat,
I
guess
to
move
to
eventually
with
a
potential
agenda
for
today
yeah.
C
C
All
right
ryan:
do
you
want
me
to
kick
this
off
and
just
talk
about
a
bit
of
the
background
about
adding
signals
to
hotel
and
then
we
can.
I
figured
we'd
use
your
dock
as
as
like
the
big
launching
pad
for
this
after
after
the
intro,
because
it's
honestly
exactly
what
we
need,
if
you
already
have
it.
A
C
Okay,
cool
well
welcome
everybody.
I
see
a
lot
of
faces.
I
recognize
and
some
that
I
don't
so
the
this
is
our
first
sort
of
sync
between
people
inside
of
open,
telemetry
or
just
generally
inside
of
the
cloud
computing
programming
industry
who
are
interested
in
adding
profiling
as
a
new
signal
type
to
open,
telemetry.
C
Telemetry
is
a
project
in
the
cloud
native
computing
foundation
that
was
started
in
2019,
that,
with
the
goal
of
being
able
to
better
capture,
signals,
types
of
machine
generated
or
custom
telemetry
from
applications
and
from
infrastructure,
opencellometry
started
with
the
goal
of
of
capturing
distributed,
traces
and
metrics,
and
then
a
few
years
about
a
year
into
the
project.
We
also
added
logging
as
a
different
type
of
signal
and
at
its
core
open
telemetry,
provides
a
few
things
at
the
base
level.
There's
a
specification.
This
specification
describes.
This
is
a
trace.
C
This
is
a
span.
This
is
a
metric
or
a
time
series.
This
is
a
point
here
are
the
attributes
they
have
here
are
the
properties
they
have.
Here
are
the
sort
of
things
you
can
do
with
them:
here's
sort
of
how
they're
used
and
how
they
can
be.
How
they're
meant
to
capture
data
that
spec,
then
within
the
project,
is
turned
into
a
few
things.
The
first
is
the
open
telemetry
protocol.
C
This
is
a
protocol
that
allows
you
to
transmit
some
of
these
signals
from
one
location
to
another,
but
probably
the
most
well
used
are
the
the
sdks.
So
we
have
a
set
of
apis
and
sdks
one
for
language
and
the
open
telemetry
collector,
which
is
a
agent
that
you
can
run
on
hosts,
typically
on
kubernetes
or
in
linux,
or
windows
vms
that
can
receive
data
from
the
host
itself
and
also
receive
data
from
the
sdks
and
and
the
sort
of
language,
specific
agents
that
complement
those.
C
I
mentioned
the
signals
that
open
telemetry
already
has
so
tracing
shipped
out
last
year
as
ga
and
it's
pretty
heavily
used
metrics
literally
just
we
had
a
first
wave
of
ga
release
candidates.
Two
weeks
ago
that
was
announced
at
kubecon.
The
actual
geo
releases
will
be
taking
place
the
next
few
weeks,
and
while
there
will
be
some
holdover
work
to
add
more
functionality
to
metrics
the
real
heavy
lifting
is
done,
and
so
logs
will
be
done.
C
Probably
later
this
year
early
next
year,
that's
already
in
flight,
a
lot
of
progress
is
being
made,
and
so
at
kubecon
we
came
together
as
a
community
and
discussed
well
we're
done
with
a
lot
of
the
projects
that
were
in
flight.
What
do
we
want
to
do
next
and
the
item
that
had
the
highest
amount
of
interest
after
blogging,
which
again
is
already
being
worked
on,
has
been
worked
on
for
two
years?
C
C
So
I
expected
to
be
fairly
open-ended,
so
I
think
myself
and
ryan
and
various
others
had
sort
of
been
discussing
this
in
various
forms
and
we
came
together
and
said:
hey,
let's
get
serious
about
this.
Let's
add
profiling
as
a
signal
type
to
open,
telemetry,
so
I'll
just
wrap
this
up
before
handing
it
over
to
ryan,
but
like
the
usual
process
by
usual,
it's
the
one
we
followed
for
logs
for
adding
a
signal
to
open
telemetry
is
first
finding
enough
people
who
are
interested
in
working
on
it.
C
C
This
is
like
sort
of
basic,
almost
pm
work
in
the
context
of
an
open
source
project
of
saying,
like
here's,
our
vision
for
profiling,
we
you
know,
for
example,
we
think
that
we
want
to
capture
regularly
capture
like
stack
traces
and
equivalent
data
from
people's
running
back
end
applications
and
turn
that
into
some
statistical
profiling
data
with
a
low
performance
impact.
So
people
can
judge
the
performance
of
their
systems,
something
like
that.
C
Right,
like
we
should
just
come
together
on
some
norms
and
sort
of
a
general
vision
of
you
know,
two
years
from
now,
one
year
from
now.
What
what?
What
is
our
actual
goal?
What
do
we
want
to
achieve,
and
then
we
can
turn
that
over
time
into
actual
open,
climatry
specification
work
that
describes
like
what
needs
to
be
done
in
the
open,
telemetry
collector.
C
What
the
signal
looks
like
and
and
how
the
apis
and
sdks
and
other
components
actually
need
to
extract
this
information
from
from
applications,
and
once
we
do
that,
then
we
can
work
with
the
existing
language
sigs
and
with
the
existing
collector
sig,
who
work
on
these
components
in
hotel
to
go
produce
these
things
and
by
work
with
them.
I
mean
like
a
provide
the
spec
and
b.
C
Of
course,
if
there's
people
here
who
are
interested
in
directly
contributing
code
to
those-
and
I
expect
there
are
probably
many
of
us
than
actually
joining
those
groups
and
and
implementing
the
profiling
functionality.
So
that's
the
typical
process.
We
can
also
share
some
of
the
docs
docs
that
we
used
a
few
years
ago
for
logs,
but
I'll
stop
now,
just
because
I
noticed
that
alexi
and
then
t
grind
had
raised
their
hands
and
zoom
so
alexi
do
you
want
to
go
first.
E
Okay,
I
guess
I'll
go
okay,
yeah,
so
yeah
thanks
morgan.
That
was
a
great
introduction.
Those
who
don't
know
me,
I'm
tigran,
I'm
a
tc
member
of
opencountry,
so
I
had
a
quick
remark.
The
way
that
you
presented
it.
I
think,
implied
that
this
is
going
to
be
a
signal
similar
like
what
we
call
signals
at
open
climate
like
logs
metrics
and
traces,
which
may
be
a
valid
way
to
approach
this.
E
But
this
is
not
the
only
way
to
support
yeah
adult
inflammatory,
so
I
think
it's
important
for
us
to
maybe
decide
on
what
is
it
that
we
actually
want
to
do.
There's
many
different
ways:
we
can
support
profiling
at
open
climatry,
as
it
can
be
as
simple
as
helper
methods
which
allow
to
represent
profiles
as
structured
logs
and
that's
all
you
need
to
do
right
and
then
the
rest
works
as
just
as
log
records.
E
The
rest
of
open
clementry
just
treats
the
the
profiles,
as
any
other
log
record,
would
be,
and
that's
a
much
much
smaller
volume
of
work
than
implementing
profiles
as
their
own
full-blown
signal,
which
has
vastly
different
implications
that
it's
a
new
api
new
specification.
New
sdk
new
implementations
in
all
of
the
languages
in
the
collector,
the
collector,
has
hardcoded
support
for
three
types
of
signals:
logs
traces
and
metrics
and
adding
the
fourth
signal
has.
It
has
a
very
different
implications
compared
to
what
you
would
do
in
the
simplest
form
right.
C
That's
a
really
good
point:
yeah
you're
right,
like
I
kind
of
assumed
it
would
be
a
dedicated
signal
type,
but
we
could
definitely
like.
We
should
look
at
considering
like
piggybacking
on
existing
ones
and
they
come
up
with
an
opinion.
I
think
alexi.
If
you've
got
your
microphone
fixed,
you
were
next.
We
still
can't
hear
you,
unfortunately,.
C
F
F
If
we
come
up
with
that
and
I'm
interested
in
participating
from
that
perspective,
ready
to
consult
on
various
subtle
and
and
not
so
subtle
aspects
of
profile,
proto
and
as
well
as
as
well
as
contribute
to
the
definition
of
of
the
format
that
we
end
up,
using
and
and
also
like.
As
part
of
that,
I
would
love
to
learn
more
about
open
telemetry
because,
as
I
said,
we
we
don't
use
open,
telemetry
much
ourselves,
but
I
think
it's.
G
Yeah,
I
just
wanted
to
to
ask
a
question
really
was
mentioned
multiple
times
that
we
would
have
to
like
that.
If
we
were
to
add
a
new
signal
type,
that
language,
specific
clients
would
have
to
be
changed,
and
I'm
a
little
bit
confused
about
that,
because
my
understanding
would
have
been
that
we
mainly
want
to
define
a
format
for
different
profilers
to
send
the
data
in,
like
I'm.
I'm
sure
what,
where
the
the
language
specific
sure
stuff.
C
So
yes,
I
suspect,
in
some
cases
that
we'll
follow
the
model
that
we've
used
for
other
hotel
signal
types
so
like,
for
example,
for
tracing
there
wasn't
a
very
large
cohort
of
really
robust
tracing
clients
out
there
before
open
telemetry
like
there
was
open
census
and
open
tracing
and
those
projects
merge
together
to
become
open,
telemetry,
and
so
the
language
sdk
is
that
open
telemetry
offers
right.
There's
like
one
api,
an
sdk
package
for
java,
one
for
python,
one
for
ruby
and
so
on.
C
H
The
other
thing
that
is
relevant
here
is
interoperability,
with
the
other
signals
and
correlation
of
the
tags
and
other
and
span
ids
and
so
forth,
and
there
it
may
be
that
profilers
can
just
leverage
the
existing
data,
that's
in
the
open,
telemetry
sdks,
but
in
the
event
that
the
sdks
need
to
interact
with
the
profiling
subsystems.
In
order
to
say
here
by
the
way,
here's
the
span
id
right.
That
would
be
a
change
that
would
need
to
be
made
to
the
to
the
existing
sdks.
C
That's
a
really
good
point:
that's
a
core
part
of
open
telemetry.
Is
that
signal
correlation
and
that's
one
of
the
reasons
so
much
is
we've
tried
to
provide
so
much
in
those
sdks
themselves,
so
you
can
just
pull
one
down
and
start
using
it
and
all
those
signals
get
correlated.
So
you
can
work,
do
cool
things
with
them
later,
also
to
clarify.
I've
talked
a
lot
about
the
sdks
we
also
for
for
non-compiled
machine
code
languages.
We
also
offer
as
a
complementor
as
an
alternative
to
the
sdks
language
agents.
C
So
for
java,
for
example,
there's
the
java
api
sdk
there's
also
a
java
agent
that
can
do
much
of
the
same
data
capture
work
as
the
sdk.
Some
people
I
mean.
Actually
I
think
more
people
at
this
point
probably
use
the
java
agent
because
it's
very
easy
to
get
started
with
there's
some
who
use
the
sdk
both
can
capture
spans
and
metrics
and
everything
else.
You
need
both
rely
on
the
same
underlying
instrumentation
to
capture
that
data,
but
the
agents
tend
to
be
a
little
quicker
to
get
started
with.
C
But
of
course
you
can't,
you
can't
use
them
as
a
developer
to
generate
custom
data.
To
do
that,
you
have
to
use
the
sdk.
You
can
also
use
both
together.
They
don't
stop
on
each
other
or
anything
like
michael
was
next
and
after
that,
ryan
had
his
hand
up,
and
we
can
basically
just
turn
it
over
to
you,
ryan.
After
michael.
I
All
right,
so
I'm
super
excited
and
happy
to
see
so
many
folks
showing
up.
That's,
that's
very
encouraging.
I'm
looking
after
adopt
inflammatory
and
aws
from
the
product
side,
and
I
think
it's
it's
a
great
idea.
The
one
thing
that
I
really
would
like
to
avoid
is
that
we
are
a
little
bit
in
our
bubble
and
if
I
look
through
the
google
docs
the
affiliations,
it
suggests
strongly
that
this
is
mostly
vendors,
which
doesn't
surprise
me
too
much.
I
H
A
A
Conforming
to
one
is
that
it
would
allow
for
that,
regardless
of
which
language
you're
in
as
opposed
to
right
now,
we're
like
if
you're
doing
it
in
like
go,
for
example,
it's
much
easier
to
do
something
like
that
than
it
is
in
some
other
languages,
but
yeah
I
mean.
I
definitely
think
the
the
document
that
I
started
with.
I
definitely
meant
it
as
just
a
starting
point
like
I
said
this
is
kind
of
from.
From
my
perspective,
I
know
there's
a
lot
of
other
perspectives
out
there.
A
Profiling
is
a
I
think,
alexa
mentioned
it
a
pretty
big
term
and
that
I
think
that
there
will
definitely
be
an
element
of
us
having
to
kind
of
really
define
what
it
is
that
we're
talking
about
come
up
with,
like
common.
You
know
vocabulary
of
of
you
know
what
means
what
as
we
as
we
work
on
this,
but
yeah
I
mean
I,
I
would
be
yeah.
I
think
it
would
be
interesting
to
hear
more
p.
So
you
know
I
spoke
about
what
what
my
interest
is
and
having
profiling.
A
As
a
support
event
type,
I
know
there's
a
lot
of
other
people
here
who
have
other
perspectives
on
that.
I
do
think
that
it
would
be
great
to
hear
from
more
people
on
on
sort
of
what
you
think,
because
at
the
end
of
the
day,
we're
gonna
need
to
come
find
some
common
denominator
here
of
you
know
what
it
is
and
what
benefits
everybody
collectively,
and
I
guess
that's.
A
The
ultimate
goal
here-
is
to
find
something,
as
michael
said,
not
just
to
like
pat
ourselves,
on
the
back
of
like
coming
up
with
something,
but
rather
coming
up
with
something:
that's
actually
productive
for
the
community
and
and
yeah.
It
moves
things
forward
in
a
in
a
meaningful
way.
So
yeah,
I
don't
know
if
anybody
else
wants
to,
I
guess-
share
their
perspectives.
A
I
think
this
would
be
a
good
time
to
do
that,
because
I
think
sort
of
after
after
that,
the
sort
of
next
steps
is
then
trying
to
sort
of
yeah
condense.
All
of
that
filter
it
down
and
then
find
that
sort
of,
like
common
thread
between
what
actions
we
could
take.
That
would
you
know,
serve
the
various
purposes
that
people
hopefully
mentioned
today,
thomas,
you
have
your
hand
up.
G
Number
one
is
liz
mentioned
the
the
utility
and
importance
of
doing
correlation
between
profiling
events
and
trace
ids,
and
that
is
something
where
standardization
with
otel
is
just
the
superpower.
Everybody
needs,
meaning.
We
need
a
unified
way
for
profiling,
different
profiling
implementations
to
get
a
span
id
when
an
event
occurs,
because
that
unbox
a
huge
amount
of
really
awesome
stuff.
G
The
second
reason
I'm
really
keen
to
be
involved
in
the
discussion
is
the
functionality
of
the
profiler
later
on
in
terms
of
filtering
and
ability
to
drill
down
onto
individual
bits
and
scalability
is
very
much
dictated
by
the
decisions
you
make
when
collecting
and
sending
the
data
out,
and
I'm
like
I've,
never
been
involved
in
any
hotel
meeting
before.
I
think
my
my
worst
nightmare
is
that
we
make
poor
decisions
in
the
format
and
then
severely
hamper
the
utility
of
profiling
through
those
decisions.
And
that's
why
I
I
would
like
to
be
involved.
H
Talk
about
the
idea
that
we
don't
need
to
reinvent
the
wheel
right
like
we
have
gopro
format
which
supports
tagging.
We
have
jfr
right
like
there
is
not
necessarily
a
reason
that
we
have
to
invent
our
own
formats
here
if
there's
something
that
we
can
extend
and
standardize,
and
some
of
these
things
already
do
have
have
thought
through
some
of
these
trade-offs.
Right
like
I,
don't
think
that
we're
necessarily
going
to
be
reinventing.
A
Yeah,
I
definitely
agree
I
mean
I
think
that
yeah
like
I,
I
think
one
of
the
next
steps
that
we
can
definitely
take
here
is
I
linked
or
I
can
when
I
stop
talking
here,
like
a
link,
I
think
it's
mark
hansen
has
like
a
pretty
comprehensive,
like
list
of
many
of
the
profilers
that
are
out
there.
What
formats
they're
in
you
know
how
they
support
things,
what
things
they
support
with
things.
They
don't
and
I
mean
really
it
does
seem
like
you
know
it
will
be
some.
A
You
know,
combination
of
those
options
and
there's
not
really
a
if
we
go
that
direction.
I
guess
then,
there's
not
yeah
that
we
don't
need
to
reinvent
the
wheel.
We
can
probably
take
bitses
and
pieces
from
the
profilers
or
the
profile
types
that
exist
out
there
and
find
some
some
common
ground
there.
So
yeah,
that's
that's
a
great
point.
C
C
The
downside
compared
to
other
types
of
profilers,
like
the
ones
you
might
use
while
developing,
is
that
you
can't
look
at
the
sort
of
chains
or
traces
of
function,
calls
for
like
a
particular
interaction
right,
so
it's
different
than
distributed
tracing
in
that
sense,
where
distributed
tracing,
will
show
you
across
services
like
what
happened
when
a
person
clicked
buy,
and
it
gives
you
this
graph
of
like
this
is
the
exact
chain
of
steps
that
happened.
That
type
of
profiling
can't
do
that.
C
C
That
is
very,
very
useful
in
some
circumstances,
but
typically
has
a
much
higher
performance
impact
for
capturing
it,
which
is,
I
think,
why
it's
fallen
a
bit
out
of
favor
the
last
few
years
because,
like
anecdotally,
I
know,
like
firms
have
said
like
yeah.
We
were
using
this,
but
it
consumed
like
20
percent
of
our
aggregate
cpu,
which
was
unacceptable
yeah
there's
the
highest
approaches.
C
H
H
We
think
that
open
telemetry
can
help
in
that.
If
you
have
a
specific
span
id
and
you're
tagging
your
statistical
profiles,
then
you
can
correlate
that
back
together
with
for
this
very
time-consuming
call,
you
may
not
get
the
non-time-consuming
calls,
but
for
the
very
time-consuming
calls
you
can
statistically
get
where
we
spend
our
time.
C
I
think
it's
worth
considering
both
to
be
clear.
I'm
just
like
describing
those
are
the
two
sort
of
when
people
talk
about
profiling
in
production
applications.
Those
are
the
two
that
typically
come
to
mind.
Obviously,
there's
also
like
profiling
during
development,
which
actually
is
kind
of
similar
to
the
second
method.
I
described
probably
something
we're
slightly
less
interested
in,
though
in
open,
telemetry
development
time
scenarios.
C
F
F
Well,
nothing
is
orthogonal
but
fairly
orthogonal
attributes
that
we
want
from
the
from
the
formats
and
thing
I'm
thinking
about
is
like,
as
you
said
like,
does
it
need
to
support
timestamp
data
or
is
it
in
support?
Is
it
form?
Is
it
a
format
for
aggregated
profiling,
data
or
also
profiling?
Data,
I
think,
is,
I
think,
fairly
more
massive
compared
to
monitoring
data
and
logging
data
like
if
you
take.
If
you
take
a
signal,
a
single
profile
because
it
has
stacks,
it
may
have
multiple
metrics
in
it.
F
Things
like
that,
like
how
compact
we
want
the
format
to
be,
because
if
you
talk
about
representation
of
profile
of
a
profile
of
a
profile
profiling
data
on
the
wire
versus
in
memory
versus
a
trust,
sometimes
stays
may
end
up
actually
being
a
different
like
different
formats
in
a
particular
product,
and
I'm
sure,
like
there
are
multiple
people
from
multiple
products
here.
I'm
I'm
sure
I
would
not
be
surprised
if
some
of
them
use
a
different
format
for
like
a
trust
representation
for
profiling
data
than
on
the
agent
side.
F
Also,
what
do
we
want
to
optimize?
We
do
want
to
optimize
for
the
format
to
be
easily
producible,
because
agents
are
usually
many.
Each
language
has
an
agent
and
having
the
implementation
of
an
agent
as
lightweight
as
possible
is
usually
a
good
thing,
because
you
need
to
implement
that
multiple
times
or
do
we
want
to
optimize
for
the
consumption
of
the
profile.
A
G
If
you
are
reckless
with
sending
out
stack
traces,
I
guess
the
other
thing
that's
interesting
is
we
like
when
it
comes
to
the
existing
forms?
We
mostly
referenced
file
formats
like
ppro
for
jfr,
and
I'm
not
a
hundred
percent
certain,
whether
what
works
well
for
a
file
format
will
necessarily
be
the
right
format
in
which
to
send
out
individual
events,
because
we're
really
thinking
about
an
event
stream
from
machines.
H
Definitely
strongly
agree
with
that,
in
that
you
know,
we've
seen
in
our
experiments
at
least
a
lot
of
inefficiencies
with
scraping
the
prof
endpoint
every
single
minute.
Right
like
it's
like
okay,
you
know.
Yes,
I
understand
that
was
originally
designed
for
local
dev.
It's
convenient.
It
exists
on
every
ghost
server,
but
maybe
that's
not
how
we
want
to
do
things
in
the
future.
In
particular,
we've
thought
about
things
like
how
do
you
attach
the
prop
output
to
just
as
a
span
attribute
and
turns
out?
That's
huge.
You
can't
do
that.
C
Any
other
comments
on
what,
when
people
think
of
profiling,
is
there
anyone
here
who
thinks
of
something
that
hasn't
been
discussed
yet
right?
So
we
talked
about
like
statistical
profiling.
We
talked
about
instrumented
profiling.
I
don't
really
know
what
it's
called,
but
we'll
call
that
for
now
are
there
any
other
types
of
like
did.
Is
anyone
here
who's
like
oh?
I
came
here
to
talk
about
something
else.
If
so,
can
you
please
speak?
J
Hi
thanks
so
so
yeah,
so
just
a
brief
introduction.
I'm
a
researcher
at
the
university
of
massachusetts,
amherst
I've
been
working
on
performance,
profiler
stuff
for
quite
some
time
or
performance
related
things
and
yeah.
So
the
the
most
prominent
thing
right
now
is
probably
our
scalene
profiler,
which
is
for
python
and
then
there's
a
previous
project.
That's
still
active
called
cause,
which
is
a
cause
so-called
causal
profiler.
J
The
the
thing
is
that
these
yeah,
so
my
concern
has
been
I'm
echoing
some
other
concerns
about
sort
of
the
setting
our
sites
a
little
too
narrowly
on
what
it
means
to
profile
things.
So
one
of
the
things
that
scalene
does,
for
example,
is
it
does
statistical
profiling
of
memory
consumption
and
it's
not.
You
know
it's
not
something
that
you
can
trigger
just
every
so
many
seconds
it
has
to
be
triggered
by
some
sort
of
allocation
signals.
J
It
captures
gpu
utilization,
which
is
not
something
that
people
have
mentioned
right
and
it
captures
gpu
memory.
Consumption
cause
is
a
profiler
that
produces
graphs
that
say
for
this
line
or
chunk
of
code.
If
I
were
to
optimize
it
by
this
much
from
0
to
100,
how
much
would
it
increase
throughput
or
reduce
latency?
J
So
this
is
a
totally
different
kind
of
profiling
information.
So
my
concern
is
that
that
what
we
do,
what
up
whatever
you
all
do,
I
should
say
I
hope,
to
help
in
the
open.
Telemetry
will
still
enable
innovation
in
the
profiling
space
and
allow
for
signals
that
maybe
people
haven't
anticipated
extra
payloads
that
could
be
passed
around
and
consumed
downstream
by
things
that
were
designed
to
handle
those
things,
as
opposed
to
sort
of
pushing
everything
through
a
very
narrow
pipe,
which
would
drop
a
lot
of
potentially
really
useful
information.
B
J
Oh
in
terms
of
performance
overhead,
so
cause
has
nearly
no
overhead.
It's
it's.
You
can
dial
it
up
or
down,
but
it's
it
can
be
made
vanishingly
small.
It's
a
sampling
based
profiler
scaling
for
cpu
and
gpu
has
essentially
no
overhead
for
memory
consumption.
It's
also
dialable.
It
depends
on
the
granularity
of
your
memory,
traces,
so
you'll
get
higher
overhead.
J
J
This
is
the
context
of
python,
of
course,
and
your
mileage
may
vary
if
it's
consuming.
You
know
if
it's
a
lot
of
python
code
versus
a
lot
of
native
code,
then
things
behave
differently.
If
there's
no
memory,
consumption
or
the
memory
consumption
is
stable,
the
way
the
sampling
works.
It
actually
has
almost
no
overhead
in
that
case.
So
it's
really
when
you're
allocating
and
freeing
tons
of
memory
that
you
get
you
get
the
overhead.
A
All
right
cool,
I
mean
anybody
else
have
yeah.
No,
I
think
that's
a
a
great
perspective.
I
definitely
think
you
can
say
we
as
we're
all
here
together
on
this
call,
but
yeah
I
mean
I
think
those
are
the
types
of
input
that
we'd
love
to
have
to
make
sure
that
yeah,
that
you
know
it's
a
a
good,
robust
solution
that
works.
You
know
I
for
as
many
people
as
possible
in
as
many
use
cases
as
possible.
H
H
K
Yeah
omit
from
pixi
here,
pete's
also
on
the
call
from
pixie
yeah.
We
should
definitely
consult
those,
I
think,
from
a
format
perspective
as
we
get
into
the
details,
we'll
be
interested
to
see
that
and-
and
I
think
there'll
be
a
lot
of
commonality
but
yeah.
We
should
definitely
consider
those
things.
I
view
ebpf
as
a
different
source,
but
from
the
format
perspective,
I
think
we
can
find
something
unified.
K
L
L
I
was
inspired
by
the
discussion
around
some
of
the
concerns
about
data
volume,
and
I
just
wanted
to
mention.
I
and
my
headspace
is
surely
within
the
statistical
stack
trace
profiling
realm,
but
they're,
and
I
think
this
would
come
up.
There's
some
capability
to
aggregate
the
data
before
you
send
it,
and
if
you
aggregate
your
data
before
you
send,
you
should
be
reducing
the
data
volume
you
send,
but
you
do
lose.
You
know
that
granularity
and
that
could
be
a
knob.
L
You
know
some
kind
of
knob
that
you
think
about
and
another
one
that's
on
my
mind.
Quite
a
bit
is
symbolization
and
I
do
wonder
if
there's
a
way
to
be
smart
about
this,
where,
if
you're
not
getting
the
symbols
kind
of
on
the
go,
somehow
know
what
the
get
get
a
resolution
through
the
through
the
mappings
and
the
virtual
address
space
to
a
degree
that
you
could
post
hoc
symbolize.
L
Actually,
I'm
just
throwing
this
out,
I
don't
know
if
this
is
feasible,
but
if
this
was
something
you
know
in
the
context
of
otel,
it
might
be
more
interesting
that,
even
if
your
data
is
partial,
when
you,
when
you
get
it
on
to
the
wire
it
might
you
could
be
the
case,
you
could
reconstruct
something
useful
later
on,
and
I,
and
so
those
kinds
of
fields
are
coming
to
my
mind
as
ideas.
You
could
consider.
I
M
Okay,
cool
yeah,
so
I
that
the
like
debug
infos,
basically
is
definitely
one
of
the
things
why
we're
in
this
call,
because-
and
I'm
sure
thomas
would
have
said
something
different
sorry,
something
similar
as
the
like
profiler
evps,
based
profiler.
I'm
sure
it
does
something
very
similar.
I
don't
know
for
sure,
but
I
think
it
does,
and
so
another
aspect
of
why
I
think,
like
keeping
evpf
in
mind
with
all
of
this,
is
something
we
slightly
touched
on
earlier,
which
is
the
correlation
bits
right?
M
A
Nice
yeah
thanks
for
the
input
there
yeah.
I
don't
know
if
there's
anything
I
guess
like
actionable
like,
I
guess
yeah.
If
you
have
any
thoughts
on
something
actionable,
we
could
do
there
to.
I
guess
kind
of
I
don't
know.
If
there's
some
like
research,
we
could
do
there
or
something
I
guess
yeah.
You
know
it's.
You
know
something
to
consider
broadly,
but
is
there
anything?
A
Maybe
I
not
to
put
you
on
the
spot
now,
but
I
guess
yeah,
if
you
think
of
something
that
we
could
do
to
kind
of
you
know
sort
of
like
inch
forward
there.
That
would
be
great
at
the
end
of
this
call,
we'll
probably
try
to
come
up
with
some
sort
of
like
you
know,
action
items
of
what
we
can
start
working
on
either
between
this
meeting
and
the
next
one
or
just
moving
forward
and
so
yeah.
A
That's
a
big
topic
would
definitely
be
interested
to
to
try
to
think
about
what
we
could
do
there
mike.
Would
you
still
have
something
you
wanted
to
add
there
nope
good,
okay
yeah,
I
guess
yeah.
Anybody
else
have
any
other
thoughts
on
there.
The
on
the
agenda
added
a
couple
other
just
general
points
of
being
able
of
talking
kind
of.
A
I
would
be
interested
to
hear
if
anybody
was
involved
in
the
tracing
process,
like
I
guess,
I'm
sure
similar
like
concerns
and
stuff,
were
brought
up,
how
those
were
resolved
and
and
moved
forward.
I
would
be
yeah.
Is
anybody
here
that
could
potentially
speak
to
that,
just
as
like
a
point
of
reference,
how
we
might
be
able
to
like
sort
of
move
forward
on
some
of
the
points
that
people
have
mentioned
today.
A
C
C
C
But
it's
it's
really.
I
think
the
next
step
is
like
we've
talked
about
what
profiling
means
to
us.
The
next
step
is
basically
providing
a
document
with
requirements.
Think
of
almost
most
people
here
work
at
companies
that
build
things.
Think
of
like
your
sort
of
pm
product
requirements
like
like
what
what
we
need
for
for
profiling
right.
So
that's
a
description
of
like
here's,
our
vision
for
profiling.
C
Here's
sort
of
the
usefulness
of
the
data
that
part
doesn't
have
to
be
particularly
large,
but
but
useful
to
have
some
some
anecdotes
there,
but
the
the
core
part
should
be
like
here's.
What
profiling
is
right,
like,
for
example,
and
again,
might
be
at
the
risk
of
bias
in
the
group.
It's
us
capturing
this
profile
data
format
to
do
to
capture
like
statistical
profiles
from
various
language.
Runtimes.
C
A
draft
just
doesn't
have
to
be
perfect,
and
then
we
all
sort
of
stare
at
this
and
and
hone
it
and
once
we're
all
happy,
we
nod
our
heads
and
then
we
both
talk
to
the
open,
telemetry
technical
committee
and
also
so
to
formally
add
it
to
the
project
and
then
also
create
typically
one
or
two
languages:
a
prototype
of
this
functionality.
So
not
final
code.
C
Nothing,
that's
going
to
be
shipping
out,
but
just
prototypes
of
like
here's,
an
example
of
this
working
in
java
and
here's
the
data
coming
out
and
here's
some
basic
analytics.
We
can
do
in
some
back
end,
doesn't
matter
which
one
to
analyze,
this
information
and
look.
It
works,
and
then
we
formally
define
the
spec
at
that
point
and
get
it
sort
of
set
in
stone
and
locked
and
then
go
and
develop
it
either
in
the
language
parts
or
in
the
collector
or
or
via
ebpf,
and
also
in
the
earlier
parts.
C
E
E
One
thing
I
would
advise
on
how
to
be
successful
with
this
is:
please
go
and
read:
open,
telemetry
specification
familiarize
yourself
with
inflammatory
you
you
want
to
create
something
that
is
part
of
inflammatory
and
you
want
it
to
be
consistent
with
what
exists
right,
because
there
is
so
many
new
people.
I
see
a
risk
of
this
being
developed
in
isolation
from
the
rest
of
open
telemetry,
which
would
then
make
it
very
difficult
to
actually
you
get
it
accepted
to
be
part
of
open
plan
energy.
E
E
It
there's
been
a
lot
of
discussion
about
the
formats
that
should
be
one
of
the
starting
points
for
you,
because
you're
you're
likely
going
to
make
a
proposal
that
is
going
to
become
part
of
otlp,
and
that
needs
to
be
consistent
with
what
exists
there
right
and
please
be
in
sync,
with
the
rest
of
open
climate
defaults
that
people
who
work
on
tracing
in
particular,
because
you
want
to
do
correlation
and
context
correlation,
and
so
so
that's
my
advice.
Don't
don't
don't
work
in
in
vacuum
right
in
isolation?
E
Please
work
also
with
the
logging
seek.
So
that's
that's
one
of
the
possible
directions
that
profiling
can
go
to
become
a
structured
format
of
events
of
g
that
generally
are
possible
already
today,
as
local
log
records
right,
we
we
have
a
way
to
represent
structured
data
and
profiling.
I
mean
you
could
say
that
any
information
can
be
represented
as
sort
of
a
structured
data.
So
that's
one
of
the
possibilities
or
or
maybe
not
right.
E
So
when
you
make
proposals
about
formats
right
or
for
profiling,
data
you're
going
to
hear
questions
about
why
this
and
not
why
the
alternate,
which
is,
for
example,
to
to
propose
semantic
conventions
to
represent
profiles
as
log
records
right.
So
when,
when
you
do
your
research
now,
you
will
be
able
to
have
good
answers
to
these
questions.
E
F
F
E
The
the
so
what
I
was
hearing
is
that
you
guys
are
really
interested
in
finding
the
right
format
for
profiles,
and
I
do
agree
it's
extremely
important
and
and
on
the
wire,
this
format
is
going
to
be
part
of
otlp.
So
that
would
be
my
first
stop.
Read
the
otlp
section
of
the
specification
and
read:
there
is
a
separate
repository
which
outlines
the
protobuf
definitions
for
the
for
otlp,
make
sure
you
you
know
those
two
and
then,
if
there
is
a
feeling
that
this
can
be,
the
profiles
can
be
log
records.
E
Then
absolutely
read
also
the
specification
for
logs
at
open
telemetry,
which
is
in
flux,
so
be
aware
that
it's
also
it's
another
experimental
signal.
At
the
moment.
It's
not
stable
yet,
and
also
please
do
read
the
the
general
guidelines
on
the
specification.
We
have
the
notion
of
api
packages,
sdk
packages
and
the
specification
that
defines
how
these
two
are
interrelated,
how
they
are
supposed
to
work,
anything
that
is
profiling.
That
is
a
new
signal
to
to
open
telemetry
needs
to
also
fit
the
same
base
same
same
same
approach
right
with
the
api
sdk.
H
A
A
We
can
start
sharing
this
with
the
other
sigs
as
well
and
just
kind
kind
of
get
their
input
both
on
the
process
and
on
potential
routes
forward,
so
that
so
yeah,
so
that
we're
not
doing
it
in
a
vacuum
and
making
sure
that
we
are
being
as
consistent
as
we
can
with
the
other.
The
ways
that
it's
been
been
done
before
yeah
any
other.
E
For
you,
folks,
if
you
have
any
questions
about
how
to
navigate
the
open
telemetry
process
right
or
about
open
telemetry
or
wait
where
to
find
the
links
to
the
things
that
I
was
talking
about,
please
feel
free
to
ping
me
I'm
on
slack
on
cncf
slack
and
and
then
and
you're
likely
going
to
have
your
your
github
repository
created
all
that
stuff.
So
that
is
done
by
pc
members.
You
can
ping
me
on
github
as
well
just
mention
my
handle
and
I'm
happy
to
help
you.
Oh.
N
H
N
A
E
A
D
A
For
adding
that
yeah,
so,
let's
see
is
there
anything
else?
Yeah
we've
got
a
couple
minutes
left
here,
I
think
yeah
I
mean
we
talked
about
most
of
the
stuff
that
was
listed.
I
don't
know
if
anybody
else
has
any
other.
You
know
thoughts
or
ideas.
You
want
to
add
before
we
get
off
here,
but
if
not
then
then
yeah.