►
From YouTube: 2022-07-28 meeting
Description
OpenTelemetry Prometheus WG
B
C
Oh
right
looks
like
we
have
a
good
number
here,
so
I
think
we
can
go
ahead
and
get
started.
Welcome
back
everybody
hope
you
are
enjoying
the
extra
week
off
in
between
for
anyone
who
this
may
be
the
first
time
here.
This
is
the
sixth
meeting.
So
far
of
this
group
we've
been
meeting
every
you
know
couple
weeks
to
determine
you
know
what
it
might
look
like
to
have:
a
standardized
hotel,
profiling
event
and
yeah
we've.
C
We've
talked
a
bunch
so
far
about
kind
of
the
goals
and
and
then
sort
of
what
various
formats
look
like:
we've
heard
from
pixi
elastic
pyroscope
about
custom
formats
and
then
from
datadog
about
jfr
from
the
prof
team
at
google,
and
so
we've
got
kind
of
like
a
good
overview
of
a
lot
of
different
kinds
of
formats.
Sorry,
if
I've
maybe
missed
one
but
yeah
and
and
so
now
we're
starting
to
think
about
you
know.
Basically,
in
the
last
meeting
we
I
think
it
was
felix
kind
of
brought
up.
C
You
know
sort
of
just
revisiting
again
just
what
the
overall
benefits
and
disadvantages
are
of
a
new
standardized
profiling
format,
and
so
I
was
thinking
we
could
talk
about
that
some
today
and
then
we've
also
been
sort
of
in
parallel
discussing
what
you
know
getting
the
ball
rolling
on.
Benchmarking
might
look
like,
as
we
currently
have
a
lot
of
kind
of
qualitative
information
about
what
you
know.
C
What
various
formats
look
like,
and
you
know
at
some
point
if
we're
going
to
move
forward,
we
need,
to
you
know,
get
some
quantitative
information,
first
of
all,
comparing
various
formats
to
using
the
sort
of
standard
hotel
events
themselves
and
and
yeah
and
in
determining,
if
you
know,
if,
if
and
how
it
makes
sense
and
and
how
much
of
an
improvement,
it
is
being
able
to
measure
all
that
kind
of
stuff
I'll
paste
the
agenda
in
the
chat,
if
there's
anything
else
that
people
want
to
add
or
want
to
discuss,
feel
free,
yeah
feel
free
to
add
it
on
there.
C
Also
an
attendees
list
feel
free
to
add
yourself
I'll
pause
there.
If
anybody
has
anything,
they
want
to
say
or
add.
C
Going
going
gone
okay,
so,
let's
see
I
will
so
yeah
up
in
the
in
the
first
link
of
the
agenda.
There's
sort
of
you
know
there's
a
doc
there,
thanks
for,
I
believe
it's
pronounced
francesco
for
recommending
the
doc
yeah,
and
so
a
lot
of
people
have
been
contributing
to
it
over
the
past
couple
weeks
about
sort
of
what
some
of
the
advantages
and
disadvantages
are.
Let
me
see
if
I
can
share
my
screen
here.
C
C
Here's
kind
of
just
like
a
or
let
me
accept
some
of
these-
an
outline
of
some
of
the
different
groups
that
will
you
know,
sort
of
that
are
sort
of
stakeholders
in
this.
So
on
one
hand
we
have
developers
instrumenting
profiling
in
their
applications,
and
I
think
that
could
kind
of
be
broken
down
into
those
already
using
hotel,
those
who
might
not
be
using
hotel
developers
building
profiling
solutions.
So
that's
you
know.
C
Vendors
and
felix
had
a
comment
there,
but
yeah
I'll,
just
kind
of
go
over
this
overview,
and
then
we
can
kind
of
dig
in
it's
like
vendors,
open
source,
profilers
language,
maintainers,
all
developers
dealing
with
various
kinds
of
issues
around
profiling
hotel
as
an
organization.
C
Obviously,
otel
has
its
own
mission
of
sort
of
standardizing
and
making
things
sort
of
agnostic
in
a
way
and
and
then
I
believe,
matt
added
sort
of
a
somewhat
of
a-
I
guess
less
represented
group
in
in
this
group,
but
someone
who
might
others
that
might
be
interested
in
this
as
well.
Let's
see
so
felix
said.
C
D
C
Makes
sense
and-
and
I
guess
yeah
you
had
mentioned
that
you
you
felt
like
it
was
important
to-
I
guess
like
dig
a
little
deeper
on
these
sort
of
advantages
and
disadvantages
point.
Do
you
want
to
we
kind
of
ran
out
of
time
to
discuss
more
about
sort
of
the
reasoning
for
that?
But
I
don't
know:
is
there
anything
you
want
to
kind
of
add
as
to
maybe
what
we've,
what
we've
missed
or
areas
where
we
haven't
gone
sort
of
deep
enough
into
in
you
know,
on
that
side,.
D
No,
I
think
if
we
just
go
over
the
the
bullets
and
headlines
that
you've
grouped
down
there
and
discuss
them
as
a
group,
I
think
that
will
bring
a
lot
of
light
to
the
question
of
what
the
benefits
are
to
to
this
effort,
and
I
think
it
will
also
help
guide.
Then
the
technical
discussions
on
how
it
should
be
implemented,
because
certain
benefits
we
might
assume
will
also
translate
into
requirements.
D
C
Makes
sense?
Okay,
so
I
guess
let's
we
can
just
keep
on
going
down
the
list
then
so
yeah
I
mean
I
guess
one
of
the
biggest
ones
was
you
know
for
those
already
using
hotel.
You
know
whether
that's
you
know
tracing
logs
metrics.
C
The
advantages
is
that
we
could
you
know
that
profiles,
you
know,
can
kind
of
complement
those
other
signals
you
know
provide
extra
in.
You
know
information
depending
on
how
we,
you
know,
build
this
format
potential
to
kind
of
link
the
you
know
link
to
different
types
of
of
signals.
C
C
Sounds
like
no
yeah,
I
mean
I
I
I
mean
honestly.
I
think
that's
pretty
straightforward
that
you
know
there's
there's
obviously
a
benefit
to
if
you're,
using
profiling
to
it
being
somewhat.
You
know
designed
in
a
way
where
it
can
interact.
Well
with
these
other,
you
know
signals
and
obviously,
just
generally
become
easier
to
use
yeah.
I
I
it
looks
like
nobody
thought
of
any.
I
guess
disadvantages
there,
so
we
could
go
ahead
and
move
on.
Looks
like
ludovic.
C
Ludovic
has
a
comment
on
the
advantages
here.
You
know
for
those
not
using
otel,
you
know
potentially
helping
give
users
confidence
that
the
format
is
stable.
I
mean,
I
know,
there's
a
lot
of
like
companies
that
will
you
know,
sort
of
or
developers
that
will
sort
of
wait
until
you
know
it's.
You
know
a
signal
has
kind
of
been
approved
in
a
formal
way
as
we're
trying
to
do
before
they
really
kind
of
introduce
it
into
their
system,
and
so
that's
a
potential
advantage
for
those
not
using
otel.
C
Yet
I
don't
know
if
ludovic
is
weird.
I
don't
know
if
I'm
pronouncing
your
name
right
as
well
right,
oh.
E
C
E
I
think
that
joins
fedex
point
right
above
I
don't
know
if
we
talked
about
explaining
on
so
the
profiling
data
is
transient
as
it's
being
generated
since
the
backend
is
being
announced,
but
unless
you
can
transfer
this
data
between
vendors,
like
back-end
vendors
in
a
way
what's
the
like,
is
there
any
use
case
of
the
the
breaking
changes
and
like
this
kind
of
stuff.
C
E
No
like
are
we
expecting
users
to
store
data
on
their
own
things,
which
would
be
helpful,
which
would
be
greatly
helped
by
arizona's
format,
but
if
we
don't
expect
users
to
store
data
anywhere
and
just
from
the
library
send
it
to
the
collector
which
send
it
to
the
backend
directly,
is
there
any?
Is
there
going
to
be
any
useful
disadvantage
in
a
way
interesting.
A
It's
about
the
ability
to
switch
vendors
when
you
want
to
that's
what
the
standardization
brings
right,
because
the
data
sources
emit
the
data
in
a
standardized
format
and
the
vendors
all
vendors
or
many
vendors
accept
that
updating
the
standardized
format
you
can
switch
your
vendor
and
from
them
from
the
moment
you
switch.
Your
new
data
goes
to
different
vendors,
but
this
doesn't
solve
the
portability
of
existing
data
right
exactly,
but
that's
that
hasn't
been
a
goal
for
open
telemetry.
A
Supposedly,
yes,
because
that's
what
inflammatory
does
right,
we
have
client
libraries,
we
have
collectors
which
you
can
use
to
generate
telemetry
loads,
metrics
or
traces.
I
think
profiling
should
be
the
same
from
this
perspective
yeah.
I.
F
Implementation
that
would
even
be
the
specification
of
what
a
profiler
should
do
and
then,
of
course,
the
implementations
will
be
across
every
single
language
that
open
telemetry
supports.
We
might
pick
to
your
point
a
little
bit.
We
might
pick
one
or
two
of
those
languages
to
be
like
the
first
sort
of
prototype
implementations,
but
fundamentally,
by
the
end
of
the
project,
we
will
have
implementations
in
like
java.net,
node.js,
c,
plus,
plus
ruby
and
so
on.
C
Yeah
it
looked
like
matt,
you
had
your
hand
up.
First.
B
Targeting
back
to
the
you
know,
the
purpose
here
is
to
be
able
to
switch
vendors.
I
do
I
do
concur,
but
I
think
it's
also
the
case
that
you
know
one
might
want
to
use
either.
Multiple
vendors
or
multiple
tools
in
concert
right
in
tandem
or
in
a
tertiary
or
config,
and
an
open
format
facilitates
that
as
well.
C
D
Yeah
one
point
I
was
trying
to
make
is
also
under
switching
vendors.
The
one
thing
that
is
not
really
clear
to
me
right
now
is:
if
profiling
really
has
the
the
problem
that
tracing
has
when
it
came
to
comes
to
switching
vendors,
which
is
very
deep
integration
of
the
instrumentation
in
like
the
customer's
application.
D
That
doesn't
seem
to
be
the
case
for
profiling,
where
you
either
deploy
a
standalone
agent.
That's
collecting
the
profiling
data,
or
in
case
of
like
datadock,
and
I
think,
google
cloud
you,
you
integrate
a
little
library,
but
it's
like
10
lines
of
code
that
go
in
the
beginning
of
the
main
function,
and
if
you
want
to
use
a
different
company,
you
rip
those
10
lines
of
code
out
and
switch
them
out,
and
that
is
where
I
really
want
to
drill
into
and
kind
of
understand
like
what
is
the
challenge
in
switching
under
today.
C
Yeah,
that's
that's
a
good
point.
I
mean
I,
I
guess
yeah,
I'm
curious
what
others
think
about
that
as
well.
I
know
yeah
so
far.
A
lot
of
the
conversation
has
been
kind
of
about
the
I
guess,
like
format
itself
being
standardized
and
you
know
put
the
potential
for
you
know
whatever
agent
someone
may
already
be
using
sort
of
like
supporting
this
like
hotel
format,
yeah
yeah,
I'm
curious
what
others
think
about
you
know,
yeah
the.
B
Sort
of
more
on
the
device
or
the
edge
device-
or
there
are
a
broad
category
of
devices
for
which
there
may
not
be
the
presumption
of
a
sas
vendor
or
a
vendor
at
all,
necessarily
with
or
the
assumption
of
data
actually
leaving
the
device.
They
consider
like
a
ring
buffer
that
you
know
has
a
week
worth
of
data
or
a
day
worth
of
data
or
some
amount
of
data,
and
it's
only.
B
Right
or
you
might
have.
You
know,
devices
that
want
to
store
absolutely
no
data
right
and
do
no
processing
right.
So
I
think
I
think
the
interoperability
again,
I
don't
think
we
should
presume,
is
necessarily
a
vendor
with
that
type
of
integration,
exclusively
they're
standalone
tools
and
things
like
that
as
well.
C
Yep
good
point:
florian.
G
Hi
thanks,
I
think,
coming
back
to
felix's
point
is:
most
of
us
are
working
on
solutions
that
does
not
need
instrumentation
of
existing
code,
and
so
switching
vendors
should
not
be
a
problem
so
so
to
speak.
You
can
use
an
agent
from
company
a
and
the
back
end
of
company
b
and
vice
versa,
and
I
think
the
main
difference
for
the
end
customer
will
be
how
much
resources
will
agent
a
versus
hmd
introduce
and
not
not.
G
How
do
I
need
to
instrument
my
code,
so
I
think
the
advantages
we
have
nowadays
in
the
worst
case
you
can
use
perth
of
linux,
translate
all
curve
profiles
into
profiling,
hotel
profiling.
Now
that's
possible.
G
I
I
guess
no
one
in
this
room
will
do
this,
but
in
in
the
worst
case,
it's
possible,
and
so
I
think
the
real
advantage
is
really
that
we
agree
on
a
standard
on
a
standard
that
is
only
really
about
the
transforming
data
and
format
of
the
data
and
not
how
something
is
implemented
on
an
agent
or
backend
smart.
I
think
the
agent
back
inside
is
really
usually
around
companies
best
practices
or
whatever
companies
choose
to
do,
and
for
also
for
the
marketing
purposes.
C
Yeah
yeah,
I
mean,
I
think
that
that's
a
great
point
and
honestly
I
mean
maybe
like
I
mean
either
way
I
mean,
maybe
eventually
it
could
kind
of,
I
guess
kind
of
converge
into
you
know.
Out
of
the
various
agents
you
know
sort
of,
like
you
know,
picking
the
the
best
of
each
of
them
into
one
but
yeah.
It
does
seem
like
the
I
I
mean
yeah.
It
seems
like
so
far.
C
E
E
And
also
I
wanted
to
ask
the
question
of
how
common
do
we
expect
the
case
of
a
customer
is
using.
So
a
developer
is
using,
let's
say,
data
as
a
front-end
or
as
a
library
but
protractor
as
a
back-end?
Is
it
something
or
authority?
Sorry,
is
it
a
case
that
we
expect
often,
or
do
we
expect
much
more
often
to
be
like
data
as
a
library,
data,
back-end
or
hotel,
as
a
library
and
data
occurs,
back-end.
F
I
would,
I
would
fundamentally
expect
the
final
one
in
all
the
examples
you
had
right
like
where
people
are
using
open,
telemetry
to
capture
their
data,
whether
it's
library,
agent
or
whatever,
and
then
they're,
sending
that
to
a
back
end
right.
That's
the
model
for
everything
else
in
open,
telemetry,
open
telemetry,
doesn't
do
back
ends
it's
just
about
collecting
data
in
a
format
that
works
and
then
sending
that
data
to
one
or
many
backends
in
formats
that
they
can
accept.
F
C
Cool
any
other
comments
on
that,
and
if
not,
we
can,
let's
see
I'm
trying
to.
H
Sorry
ryan,
can
you
guys
hear
me
yep?
So
I
I
think
it
was
pretty
interesting
to
hear
this
is
pete
from
pixie.
H
On
the
one
hand,
it's
obviously
going
to
cost
be
more
efficient
for
the
workload
if
it
doesn't
have
to
be
doing
the
symbols,
but
if
you
want
that
on
the
back
end,
you're
going
to
have
a
setup
penalty,
your
that
setup
is
more
complicated
and
if
you
want
to
have
an
hotel
data
collector-
and
you
also
want
symbols
on
the
back
end,
it
seems
like
you're
in
a
bad
corner,
because
there
is
no
back
end,
and
I
think
this
is
all
just
an
interesting
trade-off
space.
H
And
I
I
don't
suspect
that
99
would
use
the
same
agent,
although
I
could
be
wrong,
I
mean,
but
I
I
guess
I
just
wanted
to
say
it
would
the
upside
of
this
from
just
wrapping
it
up.
It
would
be
so
neat
to
have
sort
of
a
best
of
breed
pick
off
all
of
them
under
like
kind
of
one
under
that
banner.
I
think
that
would
be
neat
by
the
way.
C
Interesting
so
you're
saying
that
you
think
the
sort
of
the
symbols
piece
makes
it
harder
for
you
know,
sort
of,
I
guess
yeah
sort
of
like
two
dif,
almost
two
different
use
cases,
and
so,
if
we
have
you
know
one
agent,
it
may
not
be
able
to
support
both
of
those
use
cases.
H
I
I
think
the
what
I
heard
was
that,
and
this
matches
my
understanding,
the
hotel
doesn't
really
provide
the
back
end,
and
so,
if
you
want
the
full
package
without
providing
a
back
end,
you
want
the
symbols
to
be
traveling
in
band
with
the
profiles
as
it
were.
If
that
makes
sense,
that's.
A
H
H
A
That
is
not
that
is
that
has
a
precedent
in
open
climatry.
We
have
something
called
schema
files
which
are
produced
by
open
telemetry
and
which
are
supposed
to
be
consumed
out
of
band
by
the
back
ends
to
interpret
the
telemetry
data,
but
we
don't
provide
the
actual
implementations
of
how
you
consume
this
thing.
We
defined
the
format.
We
have
a
specification
for
the
format,
but
it's
up
to
the
backend
to
do
the
processing.
G
B
Thank
you.
If
this
is
a
newbie
question,
then
I'll
I'll
rtf,
but
does
does
tiger
interest
the
same
set
of
standards
that
you're
you're.
Making
reference
to
here
also
include
any
aspects
of
you
know
out
of
band,
as
it
relates
like
parallelism,
right
or
or
having
aspects
of
the
protocol.
B
You
know
be
conducive
to
splitting
apart
and
multiplexing
or
going
over
multiple
transports,
or
you
know
just
to
facilitate
shuffling
data
quickly.
If
there
are
fat
pipes
that
can
that
can
consume
it
at
that
line
rate
right
or
or
is
it
sort
of
presumed
that
it's
a
stream,
a
serialized
stream?
You
know
almost
like
that.
You
know
where
there
isn't
an
overarching
indexing
or
some
way
to
chunk
things
up
in
a
rational
way,
as
you
would,
if
you
were
gonna,
do
a
muxty,
mux
pattern,
or
rather
a
dmx
mux
pattern.
A
Yeah,
I'm
I'm
not
sure
how
exactly
it
would
work,
but,
for
example,
one
way
you
could
do
this
is
you
produce
the
symbols,
the
profiling
symbols
or
the
symbols
that
are
necessary
to
be
referenced
from
profiling
samples
at
build
time
right
at
build
time.
You
produce
these
symbols,
you
provide
tooling.
A
The
open
telemetry
would
provide
tooling
to
produce
the
symbols
as
well
or
it
would
provide
provide
tooling
to
let's
say
if
your
compiler
produces
symbols.
Open
telemetry
would
profile
tooling
to
to
use
these
symbols
and
convert
them
to
a
format
that
open
telemetry
defines
this
would
be
produced
at
build
time
and,
and
then
the
agent
would
and
the
agent
and
the
the
protocol.
A
The
wire
protocol
would
have
the
means
to
reference
those
symbol,
files
right
and
then
it
would
be
up
to
the
user
to
decide
how
to
decide
how
they,
how
they
transfer
these
symbols
that
are
produced
at
build
time
to
the
back
end
and
whether
the
symbols
are
identified
by
the
by
the
by
the
by
the
application
name
by
some
sort
of
url.
A
How
you
do
that
probably
needs
to
be
part
of
the
specification,
but
essentially
what
happens
is
that
on
the
wire
when
you,
when
you
send
a
sample
the
sample
references,
the
single
file
somehow
right
and
that
symbol
file,
has
a
unique
identifier
which
which
makes
it
clear
which
which
of
those
symbol
files
and
which
part
which
symbol
inside
the
symbol
file
is
referenced
and
then
the
back
end
when
it
receives
the
just
just
the
sample
it
can,
then
it
even
either
already
has
this
single
file
stored
somewhere
that
it
can
then
open
and
and
use
the
reference
in
the
central
to
to
correlate
this
to
things
or
somehow,
maybe
it's
a
url
that
is
fetchable
on
demand
right,
maybe
even
right.
A
That's
that's
what
we
do
with
the
schemas.
We
reference
them
by
urls
and
the
back-ends
can
fetch
them
as
they
observe
as
they
receive
telemetry.
They
see.
We
we
tell
them.
This
data
point
has
a
schema
with
this
particular
url.
If
the
back-end
has
never
seen
that
schema
url
previously,
it
can
dynamically
fetch
the
the
schema
using
that
url
and
then
then
be
able
to
interpret
the
data
point
after
that.
So
something
like
that
probably
could
work
with
the
profiling
symbols,
but
I'm
totally
speculating
here
right.
So
just
out
of
the
top
of
my
head.
C
Cool
yeah,
that's
yeah
helpful
to
kind
of
picture
what
it
could
look
like
jason.
You
got
your
hand
up
yeah.
I
I
just
wanted
to
address
matt's
question.
I
I
I
I
thought
you
you
were
asking
more
specifically
about
like
existing,
like
telemetry
spec
in
opencl
yeah,
exactly.
B
I
mean
I
mean
that's
it
thank
you
for
for
the
response
and
it's
also
informative
and-
and
I
concur
in
in
in
many
ways
I
had
a
follow-up
minor
question
that
I
don't
want
to
realize
with,
but
just
to
put
it
out
there
you
know
I'll
go,
look
myself,
but
is
batching
built
into
that
sort
of
schema.
So
you
know
you
can
say
I
need
these
thousand
symbols
go
but
but
yeah.
My
original
question
was
more.
I
Yeah,
I
think
my
short
answer
to
that
is,
I
think
the
existing
spec
does
not
really
address
parallelism
and
transport
to
bri
in
really
any
detail
and
there's
kind
of
not
really
any
mux
demucks
that
I'm
aware
of
so
like
when
I
think
about.
B
B
I
I
mean
my
my
read
on
it
is
that
I
think
we
would
be.
I
think
we
should
be
open
to
it.
We
should
consider
those
options
as
we
make
design
decisions,
but
I
think
we
also
need
to
just
be
careful
about
adding
levels
of
complexity
early
on
and
maybe
maybe
do
the
simple
thing
and
lead
lead
toward
a
more
complicated,
more
mature
solution
down
the
road.
C
Yeah,
I
would,
I
would
agree
with
that
yeah
something
we
can.
Definitely
you
know
pay
attention
to,
but
yeah,
I
think,
there's
a
lot
of.
I
guess,
lower
hanging
fruits
to
to
solve
or
move
towards
before
yeah.
Before
addressing
that
someone
else
had
their
hand
up.
Is
everybody
good
sounds
like
it?
Okay?
Yes,
let's
we
can
quickly
kind
of
go
through
the
rest
of
these
and
potentially
move
on
to
maybe
discussing
benchmarking
stuff.
C
You
know
another
advantage,
alexa
mentioned
related
or
yeah,
basically,
people.
I
think
one
of
the
biggest
things
that
helps
you
know
I
would
say
most
people,
both
users
and
you
know,
vendors
and
open
source-
is
just
that.
You
know
it.
You
know
people
being
able
to
see
profiling
as
a
more
mature
symbol
is
obviously
you
know
good
and
we'll
have
you
know
yeah
a
lot
more
tools
we'll
be
able
to
build
on
top
of
it.
C
I
don't
know
what
a
cambrian
explosion
is,
but
I
guess
using
context
clues.
I
assume
that
means
you
know
more
tools
being
able
to
be
built
around
it
as
as
it's
you
know,
kind
of
built
on
a
standardized
format.
C
All
right,
you
get
a
little
biology
lessons
or
whatever,
but
yeah
the
the
idea.
Is
there
yeah?
I
mean
pretty
straightforward
there
and,
let's
see
yeah
I
mean
and,
and
the
rest
of
this
is
we've
kind
of
talked
about
most
of
the
rest
of
this
already
you
know
for
hotel,
you
know
it.
C
It
definitely
fits
in
with
the
you
know,
with
the
general
idea
of
the
other
sort
of
sort
of
the
general
mission
of
otel
and
and
yeah
I
mean,
I
think
that
there
is
a
lot
and
yeah
and
I
think,
having
things
be
standardized,
you
know
I
I
know
a
lot
of
like
you
know.
Vendors
will
have
support
for
maybe
like
one
language
or
one
profile
type,
and
I
think
this
will
allow
as
well.
C
For
you
know
whether
it's
ruby
or
python,
you
know
you
can
kind
of
build
one
thing
on
the
back
end.
We
didn't
talk
about
much
of
the
disadvantages.
C
I
guess
you
know
one
disadvantage
there
is
that
you
know
some
you
know
may
need
to
kind
of
rework
things
to
work
with
a
new
format,
but
I
hopefully
that's
you
know
we
can.
If
we
can
sort
of
prove
that
it's
better
in
in
some
way
than
you
know,
whatever
format
is
already
being
used,
then
you
know
I
guess
that
could
also
be
seen.
As
you
know,
a
short-term
disadvantage
for
a
long-term
advantage.
So
let's
see
yeah
and
then
again.
D
C
D
Also,
the
other
point
about
the
standardized
format
could
limit.
You
know
innovation
and
create
performance
bottlenecks,
which
I
added.
C
D
D
About
this,
this
one,
the
the
worry
there
is
that
one
of
the
hardest
parts
of
connecting
tracing
signals
and
profiling
signals
is
actually
making
that
connection
and
creating
the
api
and
figuring
out
how
the
profiler
gets
access
to
the
span
ids
or
how
the
span
ids
end
up
in
the
profiles
and
and
doing
this
wrong
may
actually
really
cause
overhead
and
problems
that
are
going
to
be
difficult
to
fix
down
the
road,
which
is
why
I
think
this
should
be
maybe
something
this
group
also
spends
more
time.
D
Thinking
about,
because
it's
fine
to
say
like
we
want
to
make
this
correlation
happening,
but
that
doesn't
fall
out
of
a
format.
A
format
does
not
create
that
correlation.
We
will
need
apis
inside
of
the
runtimes
and
inside
of
tracing
libraries
to
make
this
happen,
and
we
might
yeah
this
might
be
where
we
hit
the
wall.
We
found
a
data
dock
where
we've
done
this
correlation
already.
We
found
this
to
be
one
of
the
hardest
problems
here.
I
So
yeah
so
felix,
I
think,
really
really
good
point.
I
mean
you're
touching
on
us
being
more
concerned
with
wire
format
initially,
rather
than
kind
of
specking
behavioral
aspects
of
a
profiler.
I
think
that
we
will
definitely.
E
I
To
give
like
a
lot
of
consideration
to
behavioral
patterns
and
and
how
those
fit
into
the
spec,
because
yeah
the
wire
format,
the
transport
alone
is
not
going
to
be
enough
for
us,
and
I
think
that
that's
a
really
good
point
in
response
to
what's
on
screen,
though
on
disadvantages,
I
hope
that
having
a
standardized
format
doesn't
limit
innovation,
because
a
format
can
still
undergo
revisions
right
like
we
can
still
enhance
it.
I
B
B
You
know,
then
ostensibly
some
layer
of
the
collector
a
transform
filter
in
mine
in
my
nomenclature
might
be
where
correlations
of
various
types
are
made,
because
it
can
be
uniquely
findable
and
it
could
do
it
in
line
or
any
number
of
ways,
but
so
so
sort
of
like
what
do
folks
think
about
again.
What's
our
concern
here
in
as
part
of
this
initial
effort
versus
what
could
be
done
elsewhere
right,
the
funnest
part
of
architecture,
I
think,
is
what
don't
you
do
on
purpose?
C
Yeah,
I'm
not
sure
I
guess
how
I
mean
yeah,
I
don't
know
if
anybody
necessarily
has
the
answer
to
that
yeah,
I
guess
that's
kind
of
the
goal
is
to
figure
out
how
do
we
add
support
for
certain
things
in
a
way
that
you
know
you
know
yeah,
there's
obviously
going
to
be
trade-offs,
and
you
know
you
know,
advantages
and
disadvantages
of
whichever
route
we
choose
and
so
yeah.
C
I
don't
know
if
anybody
has
an
answer
to
that,
but
I
do
think
that
you
know
I
guess
you
know
in
in
the
I
guess
effort
to
move
things
forward
in
some
direction.
C
You
know
I
suppose
like
if
we
are
going
to
evaluate
you
know
whether
it
is
you
know
the
wire
format
or
behaviors
or
whatever
it
is.
You
know
I'm
wondering
like
what
can
we
do
that
you
know
sort
of
which
you
know
if
we
assume
that
we
will,
you
know,
find
something
you
know
standardized
that
we
can
agree
on.
You
know
some
common
denominator
where
we
can
say
you
know
this
is
you
know
a
is
better
than
b
on
some
metric.
C
I
think
that
that
would
be
a
good
start,
and
you
know
if
we
do
end
up.
You
know,
as
we
start
to
measure
things
and
as
we
start
to
you,
know
kind
of
like
build
some.
You
know
a
piece
together,
some
whether
it's
a
format
or
whatever
it
is.
If
we
have
some
methodology
for
kind
of
you
know
evaluating
that
and
moving
forward.
I
think
that
is
my
vote
would
be
to
to
try
and
move
in
that
direction,
as
opposed
to
you
know
talking
about
theoretical.
C
You
know,
oh
this,
you
know
this
could
not
work
or
this
could
you
know?
Actually
you
know
limit
performance
here
or
whatever
it
is
so
yeah.
I
would.
I
would
like
to
you
know
we
have
you
know
some
time
left.
We
have
the
benchmarking
doc.
We
don't
necessarily
have
to
like
dive
into
it,
but
I
would
like
to
try-
and
you
know,
yeah
like
discuss
together-
how
we
could
potentially
move
forward
on.
You
know
at
least
yeah
making
some
progress
towards.
C
You
know
proposing
a
format
that
may
or
may
not
be
better,
but
but
at
least
proposing
some
new
format.
Ludovic,
you
have
your
hand
up.
Yes,.
E
On
the
experience
we
have
a
datadog.
The
format
has
some
impact
like
jfr
being
event-based
like
tank-based,
people
are
being
prograded
like
forces
us
into
some
some
things
or
not,
but
looking
at
jfr,
for
example,
that
I
work
on
that's
where
the
most
experienced
the
format
itself
is
extremely
dynamic.
We
can
do
whatever
we
want
with
it.
It
is
literally
just
binary
encoding
of
some
higher
level.
Data.
Prof
is
very
similar
in
that.
E
In
many
ways.
Most
of
the
limitations
were
on
the
implementation
itself,
like
okay,
what
run
times
what
what
each
runtime
support
allocation
like
summer
and
time
super
allocation,
some
others
don't
cpu
like
it's
machine
wide.
You
do
it
in
a
in
an
agent
or
do
you
do
it
like
ebpf
at
the
os
level?
E
So
most
of
the
details,
most
of
the
difficulty
was
not
in
the
format
but
was
in
the
implementation
itself
and
sure
the
format
is
important
because
it
allows
interp
interoperability
and
all
old-school
stuff.
But
I
think
there
is
way
more
value
in
defining
what
we
expect
of
the
hotel
reference
implementation
to
do,
as
in
from
the
user
perspective
like
there's
a
two-point
cpu.
E
Maybe
how
is
should
point
cpu
or
what
are
the
different
constraints
that
it
has
to
support
to
fit
to
be
a
no-till
cpu
profiler,
for
example,
and
then
the
format
is
going
to
come
from
that,
but
I
would
love
to
see
more
discussions
on
what
we
expect
the
referendum
reference
implementation
to
do
why
we
expect
you
to
do
that
than
on
the
way
we
encode
the
data
interesting.
C
E
That's
super
important
as
well,
and
that
requires
a
lot
of
work
on
the
tracing
side,
because
how
do
you
capture
what
is
executing
at
any
given
time?
How
do
you
communicate
that
with
the
profiler
and
everything
that
has
nothing
to
do
with
the
format,
but
that
is
extremely
important,
because
we
want
it
to
be
highly
performant
right,
because,
potentially
you
are
going
to
have
tens
of
thousands
of
span
at
any
given
time
millions
of
activations
per
seconds,
and
so
that's
going
to
be
the
hard
part
of
okay.
How
do
we?
E
J
I
have
a
couple
of
comments
and
one
question
with
regards
to
what
you
just
said:
luluvik
yeah.
Maybe
it
might
be
a
good
idea
to
start
on
the
other
way
around
because
yeah
the
format
in
the
end,
we
can
manipulate
as
much
as
we
want,
but
one
of
the
primary
goal
of
the
format
should
be
efficiency,
as
we
already
said
previously.
J
So
at
certain
point,
some
decision
about
things
that
we
are
discussing
the
previous
meeting
will
have
to
be
taken
and
the
backend,
the
reference
implementation
of
the
agents
will
need
to
adapt
to
the
performance
decision
of
the
format
and
not
the
other
way
around.
This
happened
in
our
case,
and
we
know
it's
important
to
give
in
the
hands
of
users
something
that
works
really
well,
it's
not
a
bloated
overhead
of
network
transfer,
so
we
can
probably
do
it
in
parallel
and
maybe
try
a
small
reference
implementation,
a
small
format
and
try
to
evolve.
J
Alternatively,
but
with
regards
to
the
advantages
and
disadvantages
before
moving
on
the
benchmark
stuff,
I
wanted
to
ask
everybody
if
you
think
this
document
should
be
published
in
the
hotel
repository.
I
don't
know
if
there's
an
auto
repository,
which
we
use
to
gather
feedback
from
the
broader
community.
It
seems
that
we
have
quite
interesting
content
that
we
might
want
to
get
feedback
from
other
groups
than
the
one
that
we
have
here.
So
what
do
you
think.
C
Yeah,
I
maybe
tigran
can
answer
or
morgan
can
answer
that
with
what
you
said
about.
You
know
yeah
like
what
the
main
focus
should
be.
I
guess
before
we
answer
that.
Second
part
of
your
question,
I'm
curious,
like
I
guess
what
do
you
think
should
be
the
sort
of
path
to
making
a
decision
there
on
you
know
if
it's
you
know,
if
we,
you
know,
focus
on
the
format
sec.
If
you
yeah-
and
you
know,
I
think
what
you
said
makes
sense.
C
You
know
if
the
format
sort
of
derives
from,
I
guess
the
way
of
collecting
the
data.
You
know,
I
guess
yeah.
What
do
you
think
should
you
know
we
should
start
with
in
order
to
evaluate
like
how
do
we
you
know
move
forward
in
in
that
sense
as
well?
C
Is
it
just
sort
of
like
defining
you
know
what
overhead
should
be
and
then
you
know
choosing
a
one
that
exists
out
there
and
sort
of
like
branching
off
of
that
I
guess
kind
of
yeah
like
how
do
you
envision
sort
of
making
progress
there?
Maybe
not
you
specifically,
but
you
know
this
group
I'd
be
interested
to
get
you
guys,
thoughts.
F
I
mean
there's
many
different
ways
we
can
go.
What
we
do
is
vlogging
was
pretty
close
to
what
you
just
described,
where
we
aligned
on
a
prototype
format,
and
then
we
looked
at
implementations
that
were
out
there
and
and
decided
to
work
like
sort
of
mirror
or
use
one
of
those
and
logging.
You
know
we
had
the
benefit
of
one
of
those
implementations
being
willing
to
be
literally
just
donated
into
open
telemetry
to
make
it
part
of
open
telemetry.
So
it's
a
little
special
like
that.
F
For
this,
I
think
it
probably
makes
sense
to
start
around
a
format
and
just
basic
requirements,
which
I
think
is
what
you're
doing
about
like.
We
want
to
capture
profi
like
just
as
as
an
example.
We
want
to
capture
profiles
statistically
from
applications
by
in
doing
so.
It
means
that
we
will
generally
sample
them
sort
of.
At
this
rate,
we
will
capture
this
metadata
that
will
allow
people
to
do
these
things
once
this
data
is
analyzed,
and
then
we
can
have
some
prototypes
that
do
that.
B
F
Benefit
of
profiling,
as
people
have
mentioned
earlier
on
this
call
unlike
tracing
or
metrics,
is
we
don't
need?
A
bazillion
integrations
right,
like
generally
integrations,
are
per
language,
not
per
library,
within
a
language,
so
that
makes
it
a
lot
easier
for
us
to
go
into
a
sort
of
a
prototyping
phase,
because
we
don't
have
to
commit
to
a
whole
bunch
of
integrations
when
we're
when
we're
toying
around
with
it
see-
and
I
don't
know
if
you
had
had
separate.
A
Yeah
yeah,
so
I
guess
this
is
this
is
going
to
be
an
iterative
process
right
so
that
work
group
comes
up
with
some
ideas.
You
probably
go
and
do
some
experimental
implementations
then
the
I
guess
use
the
learnings
from
that
to
to
iterate
on
it
right
but
related
to
this.
I
think
this
is
important,
as
I
was
speaking
with
with
the
other
tc
members
about
profiling
and
sponsorship.
A
I
saw
that
it's
not
obvious
to
to
to
everyone
why
profiling
must
be
part
of
open
climatry
and
how
it
fits
in
the
overall
picture
of
telemetry
collection
and
what's
the
end
goal.
So
one
thing
I
would
I
would
there
is
this
potential
possibility
that
this
work
group
will
will
work
for
moms,
but
that
work
primarily
will
happen,
disconnected
from
the
rest
of
open,
clemency
and,
and
then
the
worker
will
bring
the
results
to
to
the
community
and
and
a
lot
of
people
will
start
then
asking
the
question
why
this
is
even
needed?
A
What's
the
goal,
etc,
that
can
be
very
frustrating
right
and
we
want
to.
We
want
to
avoid
that.
So
I
would
advise
to
do
maybe
two
things.
One
is
so
it's
been
a
few
weeks
now
that
this
work
group
has
been
working.
I
think
there
is
some
vision,
crystallizing
here
right
of
what
needs
to
happen,
what
the
end
goals
are.
A
So
what
I
would
would
advise
to
do
is
write
an
an
op,
an
open,
telemetry
proposal,
a
high
level
document
which,
with
a
vision
document,
which
explains
what
this
work
group
believes,
is
the
goal
of
the
profiling.
What
needs
to
happen
right?
A
Is
it
the
collection
portion,
the
the
the
format
of
the
of
the
profiles
right?
What
is
it
a
very
high
level,
two
pages
right,
maybe
let's
say
of
the
of
the
vision?
What's
the
end
goal,
where
do
we
want
to
be
in?
I
don't
know
six
months,
twelve
months,
what's
the
goal
right
and
and
present
it
to
to
the
to
the
to
the
community,
the
all
tips
are:
are
the
documents
which
are
are
usually
reviewed
very
thoroughly.
Lots
of
people
see
them.
A
I
think
it
would
be
very
useful
to
to
sort
of
touch
base
with
the
rest
of
the
community
to
make
sure
that
people
are
aware
of
what
is
happening
here
in
this
work
group,
so
that
there
is
no
surprises
when,
when
you
actually
make
the
specific
proposals
now
right,
this
is
the
format
of
profiling.
This
is
how
we
believe
the
the
api
is
going
to
look
like
all
the
behaviors
are
going
to
be
on
the
profiling
libraries
and
that
that
open
all
type
is
a
good
opportunity
to
to
begin
that.
A
That
communication
with
the
rest
of
the
community-
and
the
second
thing
that
I
would
advise,
is
that
periodically
touch
pays
with
the
specification
seek,
so
the
specification
seek
has
weekly
meetings.
I
don't
think
there
is
a
need
to
do
any
weekly
things
with
the
profiling,
but,
let's
say
monthly.
It
would
be
great
that
this
work
group
summarizes
what
what
has
been
done
or
agreed
for
that
past
month
and
comes
to
the
specification,
seek
and
shows.
Let's
say
it
tells
this
is
what
we
we
did.
A
What
do
you
guys
think,
and
I
think
it
will
be
a
great
opportunity
for
for
the
others
to
come
in
and
provide
the
feedback
that
you're
looking
for
there's
two
different
people
there
usually
coming
to
the
spec,
seek
also
in
from
from
different
language
sigs.
So
it
would
be
a
way
to
kind
of
cross-pollinate
the
ideas
as
well.
A
I
don't
know
if
I'm
answering
the
the
original
question,
but
I
thought
it's
kind
of
related.
I
had
this
in
my
mind,
so
I
wanted
to
to
kind
of
talk
about
this
as
well,
so
op
and
periodic
thinkings
I
would
be.
I
think
it
would
be
great
for
for
to
make
to
make
sure
that
this
this
work
group
is
successful.
C
Great
yeah,
I
appreciate
that
yeah,
obviously
we
don't
want
to,
you
know,
meet
a
bunch
and
then
you
know
have
it
be
for
nothing,
and
so
I
think
yeah,
the
the
most
we
can
do
to
sort
of
optimize
for
chances
of
success,
or
you
know
at
the
very
least
at
you
know,
early
on.
If
you
know
the
rest
of
the
community
isn't
interested
for
whatever
reason,
then
you
know
we
can
save
ourselves
some
time,
but
yeah
I
mean
I.
I
agree.
C
I
think
that
we
do
have
you
know
some
sort
of
vision,
crystallizing
and
it'll
probably
be
good
to
to
kind
of
document
that
in
a
coherent
you
know
consistent
way
and
and
go
from
there
alexa.
You
had
your
hand
up.
C
K
Yeah,
okay,
can
you
hear
me
one
thing
tigran.
I
wonder
if
you
have
in
mind
a
good
example
of
otep,
which
would
kind
of
like
serve
a
similar
purpose
in
the
past.
A
Yeah,
let's
let
me
see
if
I
can
find
the
notep
of
that
kind.
Reps
are
usually
quite
specific,
but
maybe
there
is
something
that
is
of
that
kind
that
I
have
in
my
mind
and
if
not
maybe
I
can
kind
of
provide
some
sort
of
maybe
guidance
around
what
I
would
like
to
see
an
authentic
of
that
kind.
So
let
me
have
a
look
how
positive
it's
like
afterwards.
A
That's
that's
an
issue.
That's
not
an
author.
Odd
app
is
a
document
that
gets
merged
that
gets
reviewed
and
then
gets
merged
to
the
op
repositories.
That's
an
issue
that
that
is
being
discussed.
All
types
are
they
have
a
slightly
different
format:
they
they
they
usually
are
being
reviewed.
They
they
go
over
the
rounds
over
the
reviews.
They
are
pull
requests,
not
issues.
B
Yeah
they're
in
the
model
of
the
kubernetes,
the
kubernetes
equivalent
as
well.
I
just
wanted
to
talk
on
to
what
what
you
were
saying
before
and
and
both
ryan
and
tigran.
You
know
it's
not
just
the.
The
point
is
well
made
around
preventing
sort
of
downstream
or
future
kerfuffles,
but
it's
also
the
case
that
we
have
an
opportunity
to
seed
a
formalized,
a
formal
proposal
with
at
least
something
like
a
consensus
opinion
or
or
like
the
output.
B
A
C
Yeah
alexa,
you
had
your
hand
up
is
that
still
from
before.
K
Yeah
I
had
another
question:
is
I
don't
know
like
if
it's
open,
telemetry
question
or
general?
K
A
Let
me
try
to
answer
that
previously,
I
guess
with
with
major
new
new
initiatives.
The
way,
the
way
that
we
would
start
is
to
define
principles
of
the
design
right,
what
what's
important
for
our
design?
What
what
matters
and
what
doesn't
matter
so
that
probably
could
be
the
framework
for
profiling
as
well.
We
believe
that
performance
is
important.
A
We
don't
believe
that
we
care
about
tech
and
storage
formats,
for
example,
right
some
sort
of
principles
which
then
you
can
point
to
and
tell
what
you're
suggesting
is
useful
because
of
that
or
not
useful
because
of
that
other
item
right,
so
that's
that's
one
way,
process
wise.
The
way
that
it
happens
is
usually
again.
If
it's
a
major
proposal,
it's
an
all-tap,
it
gets
discussed
and
there's
a
it's
actually
more
about.
How
do
you
get
it
accepted
not
about
how
do
you
get
it
rejected,
because
it's
usually
people
are
it
undergoes
scrutiny?
A
And
people
are
so.
You
need
to
have
a
strong
case
to
make
something
into
open
climatry.
Usually
there
is.
There
is
the
danger
of
not
being
able
to
make
into
open
flame
tree,
rather
than
the
danger
of
accepting
something
that
is
useless,
but
you're.
Right
and
again.
The
way
that
you
reject
things
is,
if
you
want
to
avoid
being
too
subjective
and
arbitrary,
is
by
having
principles
of
what
what
the
design
is
and
having
the
vision
of
what
you
want
to
achieve.
B
C
All
right:
well,
that's
probably
a
good
place
to
end
it.
We
yeah,
I
mean
it
sounds
like
we
have
a
good
kind
of
you
know,
sort
of
next
step
in
you
know
getting
that
that
first
otep
or
official
draft
of
it,
I
guess,
pay
attention
to
the
slack,
and
we
can
I,
I
think,
tigran
you've
posted
before
some.
I
don't
know
if,
like
the
logs
data
model,
if
that
was
like
counts,
yeah.
A
But
those
those
were
the
ones
that
I
posted,
they
were
more
specific
right.
They
were
concrete
proposals
to
do.
What
do
we
do
with
the
data
format?
What
is
the
data
model?
The
one
that
I
think
would
be
very
useful
at
this
stage
is
a
vision
document
which
explains
what
this
work
group
as
a
whole
wants
to
achieve
and
make
sure
that
the
rest
of
the
open,
telemetry
communities
on
board
is
aligned
with
that
right,
so
that
there's
no
surprises
down
the
road
that
people
come
and
say.
Oh
well,
why
are
you
doing
this?
C
Yeah
so
yeah,
so
basically
just
stay
tuned
to
the
slack,
we'll
and
yeah
we'll
talk
about
this.
You
know
a
little
bit
asynchronously
and
at
the
next
meeting
I
know
we're
over
time,
so
benchmarking
on
deck.