►
From YouTube: 2023-03-09 meeting
Description
OpenTelemetry Prometheus WG
A
A
B
And
let's
say:
go
ahead
and
get
started
all
right,
so
welcome.
Welcome
back
everybody
yeah
the
past
couple
weeks
we
have
been
talking
about
you
know
profiling
within
you
know,
obviously
adding
profiling
to
hotel
and
then
particularly
a
lot
of
the
conversations
more
recently
have
been
around
how
that
will
work
with
the
collector
and
I
guess
exactly
what
that
looks
like,
as
well
as
the
idea
of
whether
or
not
we
make
the
case
for
a
stateful
or
a
state
list
protocol.
B
There
has
been
yeah
a
lot
of
discussion
and
I
think
that
we
are
trying
to
yeah
I
guess
trying
to
to
come
to
a
decision
we're
sort
of
at
that
fork
and
road.
So
we're
trying
to
figure
out
I
guess
two
things
like
one:
what
criteria
we
want
to
make
the
decision
based
off
of
we've,
heard
some
feedback
from
some
of
the
collector
maintainers
from
some
of
the
TC,
and
so
we
are
just
trying
to
figure
out.
B
You
know
yeah
what
what
the
best
path
for
it
is,
and
so
one
of
the
things
that
we
had
started
working
on
I
guess,
let
me
move
it
back
up
to
maybe
first
instead,
I
guess
yeah.
So
as
part
of
that
I
think
we
probably
should
I
added
some
of
the
comments
from
the
slack
Channel
about
care.
How
do
we
do?
How
do
we
actually
characterize
stateful
and
stateless
protocols
And
discussing
what
kind
of
filtering
people
went
because
that
informs
I?
B
Guess
how
the
you
know
what
the
collector
will
or
will
not
be
able
to
do,
but
one
thing
that
we've
been
talking
a
lot
about
is
just
benchmarking
results
to
see.
You
know,
that's,
obviously
a
big
part
of
the
argument
for
or
against
a
stateful
versus
stateless
protocol,
and
so
my
understanding
is
that
Christos
from
elastic
has
slash.
Prod
filer
has
done
some
benchmarking
related
to
this
I.
Don't
know
if
you
want
to
start
with
what
you
found
so
far.
C
C
C
C
It's
just
that
I
think
as
it
is
right
now,
it's
useful
enough
for
us
to
have
some
numbers,
so
we
did
a
bunch
of
benchmarks
and
we
used
different
workloads,
and
so
we
found
out
that
the
the
biggest
difference
we
can
get
between
stateless
and
stateful
in
terms
of
network
traffic
is
2x
right.
So
stateless
is
2x
was
non-stateful
in
in
pretty
much
every
Benchmark.
C
So
you
know
some
people
mention
six
to
seven
X
improvements.
I
We're,
not
gonna,
say
that
right,
because
the
benefits
we've
been
using
are
also
worst
case
and
that
I
made
sure
that,
on
the
interpretive
workers
that
they
use
generate
enormous
numbers
of
unique
traces,
most
workloads
are
not
going
to
be
that
bad,
there's
going
to
be
a
lot
more
redundancy,
so
yeah
I,
don't
think
six
seven
X
is
consumable
in
any
way
yeah.
So
that's
that's!
Basically
it
from
from
The
Benchmark
perspective.
Of
course
there
are
other
dimensions.
C
B
Cool
thanks
for
doing
that,
I
guess:
yeah.
Anybody
have
any
any
thoughts
on
that.
I
mean
I,
guess
if,
as
we
were
talking
about
it
last
week,
we
were
saying
even
at
a
much
higher
Improvement
that
it
was
going
to
be
hard
to
make
a
case,
for
you
know,
stateful
over
stateless
due
to
the
increased
complexity,
I'm
curious
yeah.
If
anybody
has
any
you
know
with
more
information,
any
opinions
or
thoughts
as
to
you
know,
yeah
I,
don't
know!
If
that
changes
things
in
anyone's
mind.
D
I
realize
I
haven't
joined
in
a
while,
but
I
I
tend
to
agree
like
a
stateless
protocol
is
probably
preferable
in
terms
of
just
the
complexity
of
going
and
actually
building
and
implementing
everything.
Hotel
has
I
think
always
I,
don't
know
any
counter.
Examples
of
this
thing.
Hotel
currently
always
uses
stateless
protocols,
because
it's
just
a
lot
easier
to
write
receivers,
whether
it's
for
the
collector,
whether
it's
for
other
backends
that
want
to
receive
otlp
data
making.
D
This
stateful
would
be
a
big
change
to
that
model,
and
it
would
mean,
for
example,
that
the
it
might
be.
There
might
be
cases
where
you
stream
this
data
to
The
Collector,
because
it
would
obviously
implement
this,
but
not
to
other
destinations
if
it
wasn't
pre-processed
by
The
Collector.
B
Nice
Alexa.
E
Christos
you
mentioned
that
2x
was
with
5
10
second
buffer
window
size
right
and
20
30
40
percent
was
with
larger
buffer.
What's
what's
the
what's
the
what's
the
window
size
you
use
in
production
right
now,
just
curious
five
seconds.
Okay,
did
you
choose
five
seconds.
C
Some
of
the
design
considerations
that
came
into
that,
because
the
size
of
the
castles
on
the
host
also
processing
overhead,
because
we
do
civilization
of
cost,
for
example,
traces.
So
that
comes
with
you
know
more
CPU
use.
But
that's
for
that.
So
if
we
decrease
the
size
of
the
buffer
that
we're
using
recipe,
you
basically
and.
F
If
we
want
to
utilize
collector
for
more
in-depth,
like
parsing
and
filtering
and
manipulation,
so
the
profiling
data,
it's
definitely
we
should
go
with
the
stateless.
Given
those
benchmarks,
level
2X
and
as
I
mentioned
on
the
last
call.
We
there
is
a
project
on
error,
error,
support
based
on
glp
as
a
protocol,
so
that
that
one
also
will
introduce
ability
to
make
streaming
status
protocol
based
on
hlp,
which
is
stated
by
default
and
to
be
aligned
with
any
other
signals
that
we
have
for
the
telemetries.
F
C
Yeah,
you
can
say,
there's
a
new
protocol.
It's
basically
our
state
for
protocol
transformed
into
stateless
forms,
so
it
would
be
similar
to
what
would
come
with
and
name
it
auto
specific
protocol.
So
it's
a
new
protocol.
It
does
not
carry
any
all
JFR
or
people
of
data.
It's
its
own
thing
and
I
see
a
Google
is
specified.
F
Oh,
that's
great
yeah
that
that
would
be
ideal
approach,
aligned
with
all
other,
open,
Telemetry
signals
and,
like
I,
believe,
that's,
that's
the
right
right
approach.
Thank
you.
Christoph.
B
B
I
guess
like
on
the
elastic
side,
like
big
proponents
of
the
going
the
staple
route
I
guess
given
these
benchmarks,
do
you
feel
any
differently
about
that
I
mean
as
we're
trying
to
yeah
I,
guess
yeah?
It
did
we
because
it
seemed
like
earlier.
It
was
expected,
I,
don't
know
by
you
or
by
other
people
that
there
would
be
a
lot
higher
improvements
there
between
the
two
protocols,
I'm
curious,
like
now
having
seen
The
Benchmark
results.
Do
you
think
that
it's
makes
a
better
case
still
for
stateless?
B
Or
do
you
still
think
that
there's
you
know
a
case
that
you
would
make
for
stateful,
even
despite
the
benchmarks.
C
So
so
for
us,
there
are
other
dimensions
that
come
into
this:
a
complexity
agent,
you
know
Horseman
CPU
memory,
but
one
thing
I'll
say
is
that
you
know
personally
I'm
not
as
opposed
to
actually
have
the
elastic
four
station
operating
status.
You
see,
because
you
know
I
found
out
that
it's
actually,
you
know
not
that
complicated
to
have
it
operate
in
this
mode,
so
it
wouldn't
be
a
problem
for
us
to
actually
support
status
protocol
based
on
what
we
learned
through
this
exercise.
C
But
you
know
there
are
other
questions
we
Supply
regarding
the
big
one
is
whether
we
consider
symbols
being
part
of
stateless
methods.
Do
we
require
symbols
to
be
there?
If
we
don't,
if
we
make
them
optional,
then
you
know
there
are
other
questions
that
fall
out
from
that,
for
instance,
how
do
we
allow
people
to
do
Post
profiling,
symbolization
right,
like
they
need
a
way
too
much
symbols
with
the
data
that
came
in
a
status
message
and
yeah
I
mean
there
are
some
ideas
for
that.
C
Like
I
mentioned
one
possible
solution
in
the
document
that
shows
the
stateless
stateful
comparison,
we
could
use
fixed,
IDs
or
frames
I,
don't
know
how
we
do
it
right
now
at
elastic
with
the
statement
protocol,
but
it's
not
something
that
can
carry
over
in
a
status
but
we'll
just
have
to
clarify.
You
know
whether
we
want
that
or
not
because
I
think
tigrant
mentioned
the
ability
to
filter
on
simple
data.
A
B
B
I
also
see
some
questions
or
comments
in
the
chats
about
how
we
characterize
staple
and
stay,
listen,
I,
guess
yeah.
Maybe
now
would
be
a
good
time.
Just
I
guess
so
we're
using
the
same
terminology
here.
B
G
If
you
want
from
from
the
hotel
side
so
I
think
Morgan
hinted
at
this,
but
the
the
hotel
side-
it's
if,
if
I
get
a
packet
of
otlp
right,
an
exporter
should
be
able
to
just
look
at
that
packet
and
figure
out
how
to
translate
it
into
its
underlined
back
end
and
fire
that
data
down.
That's
that's
kind
of
the
definition
of
the
state
list
that
we
have
right
now,
so
every
packet
can
be
self-contained,
and
if
you
only
get
that
packet,
you
can
still
make
meaningful
use
of
the
data.
G
Now,
whether
or
not
you
can
make
meaningfully
the
use
of
a
profile
without
the
symbol
table
I.
That's
that's
actually.
My
the
question
that
I
think
we're
asking
right
is:
is
that
data
meaningful
without
a
symbol
table
it's
better
with
one
for
sure,
but
is
it
meaningful
without
and
I
think
you
could
argue
yes
or
no.
H
I
H
That's
absolutely
the
the
question
is:
is
it
Josh
I
think
Josh
was
mentioning
I
I
want
to
take
like
a
kind
of
pragmatic
Viewpoint,
where
there
will
be
cases
where
there
won't
be
symbols
and
those
cases
may
arise
for
various
reasons,
whether
the
debug
symbols
are
stripped
or
it's
an
interpreted
language
or
it's
legited
language.
H
There
may
be
symbolization
on
the
back
end.
There's
an
argument
to
be
made
that
if
you
don't
symbolize
in
line
with
collecting
the
profile
and
you
symbolize
it
later,
that's
better
for
perf
and
I,
see
Felix
coming
in
I
think
the
interpreted
jitted
case
absolutely
can
have
symbols
available
on
the
host
I.
Just
don't
think
it
will
have
that
in
every
single
case.
H
So
when
I
think
about
like
these
kind
of
Matrix
of
possibilities,
I
think
requiring
that
there
be
symbols
to
call
it.
Stateless
is
sort
of
a
misdirection.
Perhaps
but
I
I
get
I
do
take
the
point.
It
would
be
better
with
symbols
to
my
thinking
anyway.
I
just
look
at
P,
Prof
and
I.
Think
P
Prof
supports
symbolization
up
front.
It
supports
symbolization
on
the
back
end,
you
can
have
addresses
and
symbols
and
P
Prof,
so
yeah,
that's
kind
of
the
that's
just
my
thought.
Process
I
see.
I
For
interpreted
languages
like
Java,
PHP,
Python
and
so
on,
the
symbols
that
are
traded
there
on
the
host
and
we
can
transfer
them
in
the
properly
call
and
it
can
be
stateless
but
for
Native
languages
like
rust,
go
C,
plus,
plus
and
so
on.
I
People
usually
strip
their
their
executables,
and
in
our
case,
it's
usually
so
in
that
way
that
we
feed
in
the
symbols,
maybe
from
the
CI
once
into
the
back
end
and
so
visualize
everything.
So
there
is
a
different
power,
but
it
could
be
considered
in
not
full
stateless
because
there's
a
second
part
or
second
way
of
getting
these
symbols.
So
that's
why
the
question
at
least
for
myself
that
did
come
up.
I
Hey,
do
you
require
always
to
have
symbols,
and
if
we
have,
if
you
need
to
have
symbols
every
time
everywhere,
this
becomes
a
deployment
and
architecture
story.
B
F
B
Yeah
because
I
guess
yeah
I
mean,
and
we
we
you
know,
some
people
had
asked
in
the
slack
Channel
and
we
kind
of
mentioned
it
briefly
in
the
original,
like
Otep,
that
we
did
about
the
use
cases,
what
kind
of
filtering
users
won
and
don't
want
and
as
far
as
I
understand-
or
you
know,
for
the
most
part,
it's
the
type
of
filtering
will
be
more
I
guess
higher
up
in
the
sense
that
you,
you
don't
necessarily
have
to
deal
with
symbols
to
filter
the
kind
of
things
you'd
want
to
filter,
maybe
not
I
don't
know.
B
J
E
Yeah
to
me,
filtering
is
a
bit
abstract
and
I
would
also
love
to
hear
like
what
are
the
actual
use
cases.
I
know
we
discussed
it,
but
I,
don't
remember
what
the
use
cases
were
or
what
was
it
more
like
some
people
might
want
some
filtering
in
the
future,
but
then,
if
we
cannot
come
up
with
use
cases,
then
maybe
we
should
just
drop
this
as
a
requirement.
B
Fair
enough
yeah.
K
I
mean
I
think
so.
I
can
maybe
talk
about
it
just
a
little
bit.
What
we've
heard
from
some
customers
is
ability
to
drop
or
remove
potential
pii
stuff,
and
that
comes
up
in
labels
right.
If
you
tag
the
profiling
data,
it
may
potentially
come
up
in
some
scenarios
where
I
know
you
have
a
ruby
app
and
sometimes
it
generates
stack
traces
in
runtime
and
maybe
there's
you
know
some
customer
information
in
those
stack
traces
rare.
But
you
know
that
that's
what
those
people
kind
of
worry
about.
K
Yeah!
That's
what
we've
heard.
B
Yeah,
it
seems
to
me,
like
labels
is
probably
the
only
in
most
likely
it
would
be.
You
know
we
probably
shouldn't
be
adding
those
kind
of
the
is
labels,
but
yeah
I
mean,
and
it
might
be
a
corner
case
that
we
just
have
to
accept
that
you
know
that
we
aren't
going
to
allow
people
to
do
that
and
just
tell
people
not
to
put
that
kind
of
information
in
their
labels.
I
guess
yeah
Felix.
J
Well,
it
doesn't
seem
like
we
have
to
make
a
decision
like
it's
either
we
have
all
the
symbols
and
everything
or
we
have
nothing
right.
There
can
be
something
in
between
where
the
stack
traces
might
not
have
symbols
on
them,
but
maybe
they
have
labels
and
then
the
collector
could
still
do
some
filtering
on
those
if
it
wants
to
so
I
would
say
that
providing
textual
information
along
with
stack
traces
is
sort
of
the
best
effort
deal
and
if
available,
The
Collector
can
filter
on
it.
J
B
Fair
enough
Alexa
did
you
have
something
else
to
add.
E
Yeah
one
thing
I'm
curious
about
is:
if
it's
about
filtering
sensitive
information
like,
why
does
it
need
to
be
on
the
response
path?
Why
it's
not
a
part
of
configuration
for
the
collection
itself
like
why
this
information
is
collected
than
in
the
first
place?
Because
because,
when
we
said
filtering,
it
seems
like
we
meant
something
like
we
first
would
collect
everything
and
then
something
on
the
response
path
would
filter
this
out.
But
why
is
this
collected
in
the
first
place?
I
kind
of
like
I,
don't
understand
the
whole.
The
whole
flow
in.
D
K
The
security
team
wants
to
have
ability
to
whatever
developers
are
doing.
They
want
to
make
sure
that
certain
pieces
of
information
never
leave
they're
kind
of
their
data
center
whatever,
and
so
this
is
a
perfect
kind
of
use
case
for
a
collector
with
some
sort
of
filtering
ability.
K
E
K
Well,
potentially,
yes,
but
you
are,
but
it's
like,
but
I,
don't
know
my
understanding
with
the
collector
the
typical
kind
of
setup.
Is
you
keep
the
collector
within
your
you
know,
virtual
private
Network,
so
sensitive
data
never
lives
that.
But
then,
when
you
know
some
data
leaves
your
virtual
private
Network.
J
I
want
to
disagree
with
the
statement
that
you
need
to
distribute
sensitive
information
in
order
to
to
detect
it.
The
best
example
would
be
credit
card
information
which
hopefully
nobody's
trying
to
add
to
their
profiling
data,
but
if
they
did,
you
could
detect
that
without
shipping
credit
card
data,
but
yeah
otherwise,
I'm
plus
one
on
the
centralized
management
use
case,
because
we
live
in
these
crazy
macroeconomic
times,
where
the
people
who
developed
a
service
might
not
even
be
at
the
company
anymore.
J
At
the
time
they
decide,
they
need
to
filter
something
sensitive
I
wish
I
was
making
this
up
but
real
story.
So
it's
very
valuable
for
companies
to
have
centralized
control
over
what
data
flows
out
of
their
systems
and
be
able
to
configure
it
without
redeploying
the
services
that
might
be
collecting
that
data.
So
I
think
it's
a
really
good
use
case.
E
That's
that's
reasonable.
Do
you
think
in
this
case
it's
actually
filtering,
or
would
you
just
want
to
drop
the
whole
profile
if,
like
it
matches
like
if
anything
inside
of
the
profile
matches
I
would
do
want
to
actually
fix
up
the
profile
and
potentially
because
it's
still
the
profile
is
a
bit
of
a
black
box
to
the
system?
I
would
assume
so
it
would
if
it
would
just
filter
some
strings
out
or
well,
it
could
replace
them
with
I
guess
with
some
placeholders
or
something.
J
I
I
think
both
cases
I
think
maybe
the
more
common
one
would
be.
They
would
decide
to
send
less
data
to
save
costs
or
something
so
they
might
make
that
decision
on
tax
that
are
sort
of
like
on
the
envelope
of
a
profile
and
maybe
not
the
stack
traces,
but
they
could
also
be
working
on
a
security
incident
where
some
data
is
leaking
out
of
their
service
and
they
want
to
stop
that
as
fast
as
possible.
So
I
think
both
use
cases
I
had
in
mind.
Maybe.
E
Maybe
one
Maybe
One
requirement
here
is
that
in
the
in
like
in
whatever
format
we
choose,
it
should
be
possible
for
some
intermediary
to
easily
inspect
all
strings
within
the
profile
like.
Maybe
it
poses
a
requirement
like
there
should
be
an
explicit
string
table
and
all
strings
are
only
contained
in
a
string
table
so
that
it's
kind
of
like
it's
easier
to
implement
this
kind
of
filtering.
B
Yeah
dang
Josh,
just
left
I
was
gonna.
Ask
his
opinion.
Oh,
never
mind,
go
ahead.
Felix.
Do
you
have
something
else
you
want
to
do.
J
Yeah,
it's
just
something
very
quick,
I
I
agree
that
having
just
an
ability
to
filter
over
all
strings
is
generally
useful.
It
doesn't,
however,
need
to
be
necessarily
part
of
the
format.
I
think
it
could
be
helper
function
in
The
Collector
that
just
lets
you
iterate
over
all
the
strings
and
filter
them,
so
the
representation
I
think
is
secondary
for
that.
B
Yeah
so
I
guess
the
I
mean
the
the
the
big
question
here
is,
like
you
know
at
some
point,
we're
gonna
have
to
you
know,
start
making
progress
towards.
You
know,
building
something
at
least
some
sort
of
proof
of
concept.
Some
sort
of
you
know
here's
what
this
might
look
like
and
I'm
curious.
You
know
we've
kind
of
talked
a
lot
about
a
lot
of
different
paths.
We
can
go
down,
yeah
I
mean
and
it
seems
like
more
and
more
we're
generally
in
agreement.
B
Maybe
that's
a
you
know,
maybe
others
might
disagree
with
that
statement,
but
I
guess
I'm
curious.
What
you
all
think
is
the
The
Next
Step
I
mean
to
me
my
from
what
I've
heard
and
seen
and
and
all
that
kind
of
stuff
there's.
It
seems
like
the
collector
piece
and
what
that
actually
like
looks
like
on
the
collector
seems
pretty
important.
I
know.
Last
week,
Alexa
had
mentioned,
you
know
the
actual
format
of
the
or
like
protocol
itself,
but
yeah
I,
guess
I'm
curious.
B
You
know
as
a
group
if
we
can
come
up
with
some
next
steps
as
to
like
how
do
we?
Actually,
you
know
start
making
progress
towards
something
that
we
can
start
sharing
with
people,
something
that
we
can
start.
You
know
testing
out
seeing
what
it
actually
looks
like
in
a
real
world
environment
yeah,
any
Felix
or
Alexa
I.
Think
Alexis.
Him
was
just
still
up
so
Felix.
J
Yeah
I
think
one
discussion
that
we
should
finish
up
before
we
jump
into
too
many
details
is
whether
or
not
we
want
to
support
sending
gfrs
through
the
collector
I
see
a
lot
of
good
Arguments
for
why
that's
really
not
a
good
fit
for
the
collector
and
hotel
in
general.
J
It
would
be
a
shame
in
my
from
my
point
of
view,
and
it
would
certainly
mean
that,
for
example,
for
data
doc,
we
would
probably
never
consider
hotel
to
be
our
first
class
ingest
format.
We
we're
not
moving
away
from
JFR.
We
would
probably
support
otel
in
another
format,
especially
if
it's
simple
to
implement
on
intake,
but
we
would
not
be
emitting
hotel
natively
from
our
clients
and
I'm
kind
of
curious.
J
If
other
vendors
here
sort
of
see
a
big
benefit
from
emitting
an
Hotel
native
format
when
it's
really
not
very
more
capable
than
what
we
already
have
on
the
table
and
doesn't
really
provide
a
lot
of
benefits.
So
I
I
think
we'd
still
be
interested
in
supporting
hotel
in
general,
but
yeah.
If
JFR
is
not
supported,
then
it
would
sort
of
be
for
us,
a
secondary
channel
of
data
acquisition
and
less
interesting
for
becoming
our
primary
export
format,
which
would
be
okay,
I.
We
wouldn't
be
voting
against
it.
B
Can
you
I
guess
explain
why
you
say:
there's
an
argument
against
support
or
I
guess
what
you
would
say.
The
argument
against
supporting
JFR
is
just
because
it's
not
structured
enough
is
that
I
feel
like
you've
said
it
before,
but
I.
J
Mean
yeah
no
I
think
like
Dimitri
was
making
really
good
case.
J
The
other
meeting,
where
basically
don't
tell
collector,
expects
data
to
come
in
through
various
receivers,
and
then
it
gets
converted
into
P
data
and
P
data
is
the
canonical
format
that
hotel
data
is
represented
in,
and
that
makes
all
the
collector
magic
happening
where
you
can
transform,
filter
drop,
redirect
whatever
and
then
you've
got
the
exporters
which
can
now
export
into
otlp,
but
also
into
other
formats,
because
again
there's
a
shared
Central
format
that
makes
it
easy
to
import
from
many
different
formats
and
exports
into
many
different
formats
and
with
something
like
JFR.
J
You
would
not
get
that
benefit.
You'd,
basically
only
be
able
to
send
it
forward
to
successfully.
If
somebody
on
the
author
end
understands
JFR,
and
you
would
have
a
pretty
hard
time
implementing
it
in
The
Collector,
you
could
I,
guess
still
have
a
receiver,
but
that
that
takes
it
apart,
but
in
most
cases
you
probably
just
want
to
send
to
JFR
on
as
it
is
and
so
yeah
it
doesn't
seem
like
a
naturally
good
fit
for
a
hotel
but
yeah.
It's
it's
a
trade-off.
F
So
like
open,
Telemetry
vision
is
to
be
completely
blender
agnostic
and
to
not
be
attached
to
any
of
the
existing
implementations
right.
So
in
the
ideal
world
P
data
is
not
is
based
on
otlp,
with
otlps
like
a
native
open
Telemetry
protocol,
which
will
be
implemented
for
profiling
as
well
as
we're
discussed
in
here,
and
that
protocol
supposed
to
not
be
only
attached
to
the
collector.
That
will
be
the
first
phase,
but
in
the
next
phrases
we
will
get
support
for
profiling
for
all
the
instrumentation
libraries.
F
They
will
be
kind
of
an
agent
and
they
will
emit
open
to
language
or
glp
protocol
and
that's
like
an
end
goal.
Right,
emit
open,
Telemetry
protocol
right
away.
So
no
no
GFR,
no
P
proof,
and
there
isn't.
There
will
be
no
no
conversion,
but
if
some
back-ends
understand
only
GFR
for
now
later,
hopefully
they
will
support
open
telemetry.
F
They
will
need
to
send
through,
let's
say,
GFR
exporter
the
exporter
that
will
take
open,
Telemetry
and
convert
it
to
GFR
and
send
it
to
the
backend
same
thing.
Initially,
we
need
GFR
receiver
that
would
receive
GFR
format
and
translated
to
open,
Telemetry,
even
site
collector,
and
then
it
can
be
sent
in
anywhere
like
whatever
can
support.
F
If
we
embed
GFR
kind
of
an
open
television,
it's
not
going
to
be
aligned
with
open
Telemetry,
what
kind
of
vision
of
vendor
agronosis
and
yeah,
and
it
means
that,
if
open
television,
it
means
that
every
open,
Telemetry
compliant
backend
will
need
to
support
GFR
as
well.
So
it's
not
open
to
imagery
anymore.
That
does
that.
That's
the
idea.
J
Otel
tries
to
really
hard
to
be
vendor
agnostic
argument,
because,
if
there's
something
good
out
there,
wouldn't
the
hotel
be
open
to
adopting
it,
because
arguably
hotel
has
adopted
grpc
right
like
for
otlp
and
that's
kind
of
the
vendor
non-agnostic
Network
protocol
standard
in
so
I'm
wondering
if,
like
Hotel
like,
if
something
was
out
there,
that's
already
like
an
open
source
technology.
This
hotel
really
opposed
to
adopting
it
just
because
it
wasn't
invented
by
hotel
or
what
makes
something
like
vendor
agnostic
in
hotel's,
mind
like
what's
the
bar
for
that.
F
Yeah
grpc
is
just
like
a
layer
to
like
Network
protocol
right.
It's
how
you
encode
the
data.
You
can
encode
everything,
it's
not
it's,
not
that
we
rely
on
GRTC
and
only
we
we
can
send
to
glp
and
HTTP
like
in
Json
with
HTTP
or
like
with
everything.
So
just
like
another
transport
option
that
we
have,
but
we
don't
have.
We
don't
rely
on
anything
signal
specific,
so
we
used
to
have
open
sensors
that
that
was
used
for
metrics
and
we
went
away
from
that.
F
And
again,
JFR
is
not
controlled
by
open
Telemetry.
If
they
change
something,
we
need
to
catch
up
and
Etc.
So
that's
not
like
viable
solution,
launcher.
J
F
Yeah
I'm,
not
the
expert
in
profiling,
but
we
may
be
based
on
people
off
and
like
create
open,
Telemetry
protocol
that
closed
the
people,
because
we
think
that
is
the
best
format
right,
and
it
means
that
any
anything
that
MHP
Prof
will
be
much
easier
to
convert
to
otlp
so
received
property
0,
for
example,
The
Collector
will
be
minimal
overhead
to
convert
from
P
proof,
so
it
will
be
not
a
problem.
I
mean
it
will
be
kind
of
be
supported
in
a
still
supported
in
a
good
way.
B
Yeah
I'm
thinking
maybe
like
how
does
the
collector
are
there
other
instances
where
the
collector
has
to
like
deal
with
JFR
in
some
way
already
I
guess:
I'm,
not
a
JFR
expert,
but
doesn't
you
know
I
guess,
isn't
that
the
idea
of
JFR
that
it
also
has
other
types
of
information
in
it
too,
like
yeah
I,
don't
know?
Maybe
we
should
try
and
get
someone
from
I
I
assume
there's
some
like
Java
collector
group
or
something
along
those
lines
that
might
be
able
to
give
their
perspective
on
this
easier
than
we
would
I.
B
Don't
know,
I'm,
just
brainstorming
how
we
can
resolve
something
for
the
job
aside.
E
E
For
GFR
data
that
people
care
about
that
are
not
easily
representable
with
something
like
P
Pro
format,
because
GFR
is
so
so
like
customizable.
That,
as
far
as
I
understand
like
some
things
might
not
even
be
representable
would
be
probably
doing.
L
F
And
there
we
is
open.
Telemetry
group
see
some
good
parts
in
GFR
that
are
not
available
in
people
of
we.
We
can
come
up
with
superset
right.
We
can
take
good
parts
from
JFR
and
take
the
P
probe
the
base
and
immerse
them.
At
least
we
need
some
additional
field
for
correlation
with
tracing
right.
We
need
some
Spanish
Trace
ad,
at
least
so
those
things
needs
to
be
added.
We
cannot
just
take
people,
for
example,
and
we
can
take
good
parts
from
JFR
and
add
them
to
otlp
protocol.
J
And
I
think
that
the
correlation
is
very
important.
In
fact
to
me
it's
the
main
thing
why
we
should
be
doing
this
hotel
profiling
thing.
I
would
say
it
can
be
layered
on
top
of
both
P
Prof
and
JFR.
So
if
you
would
send
people
for
JFR
with
an
envelope
where
you
specify
hey,
look
this
label
right
here
is
the
trace
ID
the
span
ID
or
some
similar
metadata
for
JFR
that
could
be
layout
on
top
I.
Don't
think
it's
an
arguments
against
those
formats.
J
F
I'd
say
the
biggest
argument
against
envelope
and
is
that,
let's
say
back
end
says
that
it's
opportunity
compliant.
It
means
that
it
has
to
support
everything
that
can
be
enveloped.
Well,
you
just
not
like
vision
of
open
telemetry
and
we
will
stick
with
that
forever.
If
we
go
that
route,
I,
don't
think
we
will
be
able
to
duplicate
those
envelopes
and
remove
them
at
some
point
in
time.
C
Yeah,
so
so
I
guess
the
consensus
are
slowly
arising
is
that
you
know
we're
going
for
a
native
otlp
format,
and
then
we
can
have
converters
from
people
open
J5
to
that
format,
so
that
you
maintain
unified
vision
and
also
we
have
the
flexibility
to
mold
that
format
in
a
way
that
we
see
fit.
That
covers
our
cases
and
so
on
which
elastic
point
of
view
is
is
sounds
good
yeah.
C
We
wouldn't
have
difficult
distance
supporting
that
just
the
other
questions
of
the
rise,
especially
for
symbolization,
and
maybe
we
dedicate
a
future
changing
personalization
alone,
because
from
today's
meeting
it
seems
that
people
are
open
to
to
making
symbols
optional
in
a
stateless
message,
but
that's
mostly
going
to
apply
to
Native
traces
right,
CC,
plus,
plus
and
last
interpret
race
is
always
kind
of
symbols,
and
it's
not
really
possible
to
attack
symbols
after
the
fact.
C
So
then
you
know
we
need
to
answer
the
question:
do
we
specify
how
possible
profiling
civilization
is
going
to
be
done,
because
we
have
to
make
allowances
for
symbolization
data
to
be
able
to
be
correlated
with
profiling
data?
So
then
you
know
we
have
to
talk
about
that
or
so
we
leave
that
area
unspecified.
J
A
starting
point
I'm
curious.
What
if
anything,
is
lacking
in
P
Prof
for
the
Post
symbolization
use
case,
because
the
symbols
are
optional
and
P
Prof
already
in
fact,
P
Prof
historically
and
go
didn't,
have
symbols
in
it
and
you
always
needed
to
have
the
binary.
The
path
to
the
binary
is
included
in
the
piperoff
metadata
somewhere
and
I.
Believe
there's
also
something
like
a
build
ID
field,
or
at
least
you
could
put
it
there.
J
So
you
would
have
some
unique
identifier
for
the
binary
to
to
kind
of
correlate
it
with
symbols
that
you
get
from
somewhere
else.
So
I'm
not
saying
like
that's
the
argument
for
why
we
should
use
P,
Prof,
but
I
think
it's.
My
question
is
like:
if
we
take
inspiration
from
somewhere,
is
there
anything
in
P
Prof
missing
that
we
would
have
to
consider
here?
For
that
case,.
C
I
think
it
doesn't
have
a
support
for
high
resolution
Dynamics,
so
yeah
we
could
take
different
from
use
metadata
to
kind
of
track
it
into
what
we
want.
But
then
the
argument
is:
do
we
really
want
to
do
that?
Like
you
know,
because
then
it
starts
looking
like
a
monstrosity.
While
we
have
a
native
format
and
then
we
are
the
ones
who
can
you
know
dictate
exactly
what
goes
between.
You
can
pick
the
best
parts
of
paper
from
JFR
and
also
allow
it
for
future
extensions.
C
J
Yeah
I
guess
my
comment
was
mostly
about
like
for
the
simplestation
use
case.
Is
there
something
missing
from
P
Prof
the
general
case?
Is
there
something
missing
from
P
profs
that
we
as
a
group
one
for
hotel
profiling,
like
timestamps
I,
think
that
is
a
worthy
debate
as
well
and
I
agree?
The
timestamps
that
you
mentioned
is
a
very
good
thing.
That's
missing
from
P
Prof.
That
would
be
interesting
to
have.
E
For
for
the
question
of
like
what,
if
odlb
format
would
be
something
that
essentially
like
both
GFR
and
paperov,
can
be
converted
to
Felix
in
the
chat
you
mentioned,
that
you
do
allow
people
download
original
GFR,
does
it
mean
that
this
otlp
format
will
also
need
to
be
kind
of
like
convertible
back
to
GFR,
or
that
you
wouldn't
be
able
to
use
this
common
format
like
how
that
would
work?
Do
you
have
any
thoughts
on
that
yeah.
J
So
if
we
added
support
for
in
otlp
based
profiling
format
on
our
intake,
we
might
allow
people
to
download
that
file
that
comes
in
the
same
way
it
came
in
just
like
we
do
for
pre-profit
GFR,
it's
just
another
data
format
that
we
allow
people
to
download.
Once
we
get
it
out,
we
currently
don't
convert
between
them.
So
if
you
send
us
a
JFR,
you
cannot
download
it
as
a
p
Prof.
If
you
send
us
a
p
Prof,
you
cannot
download
it.
J
Shfr
I,
don't
know
if
we'll
ever
change
that,
but
yeah
I
don't
think
like
for
us
in
our
architecture.
It's
a
problem
to
add
another
opaque
format
that
comes
in.
We
take
what
we
need
out
of
it,
but
still
allow
people
to
download
it.
That
would
I
think
work
for.
J
J
Maybe
there
are
some
time
series
data
in
there
there's
all
kinds
of
there's
JMC,
which
is
like
a
pretty
powerful
fuel
for
JFR
data,
and
my
understanding
is
that
what
basically
people
do
is
download,
HFR
loaded
up
in
GMC,
Java
mission
control
and
then
look
for
interesting
things
that
they
can't
get
out
of
the
tooling
that
we
as
a
vendor
would
right
now
offer
in
our
UI
even
for
p.
J
Prof
I
can
give
you
a
simple
example,
which
is
to
look
at
the
disassembly
and
basically
look
at
individual
instructions
like
because
people
has
program
counters,
but
we
don't
expose
them
to
to
users
right
now.
So
if
they
want
to
do
that,
they
can
download
to
P
Prof
and
look
at
it
in
the
P
Prof
fuel,
which
is
still
useful,
I.
Think
in
some
cases.
E
E
Yeah
I
feel
like
this.
What
level
of
GFR
support
should
be
in
the
whole
profiling
thing?
I
think
that's
I,
think
that's
kind
of
like
the
biggest
question
for
me
right
now,
because,
like
on
one
hand,
we're
hearing
from
from
the
from
the
hotel
folks
that
just
supporting
some
external
format
is
not
what
odlb
usually
does
and
usually
targets,
and
at
the
same
time
it
seems
like
it's
an
important
ecosystem
for
at
least
some
customers.
J
J
There
is
a
decent
chance
that
it
will
meet
backlash
from
the
Java
community
and
they
will
not
deduct
profiling
solutions
that
don't
support
JFR,
which
means
they
might
go
with
vendors,
that
produce
profiling,
data
for
Java,
In-Shape
R
format
and
can
consume
it
on
their
intake
and
just
sidestep
hotel
for
the
intake
of
java
profiling,
information,
which
I
think
it
would
really
be
that
outcome
for
the
signal
correlation
use
case.
Because
then,
if
service
vendors
try
to
use
tracing
solutions,
they
wouldn't
be
able
to
correlate.
There
is,
of
course,
a
long-term
argument.
J
That's
saying,
like
over
time,
hotels
going
to
become
so
big
and
and
inevitable
that
the
JFR
is
natively
going
to
emit
data
in
this
format
and
whatever
changes
will
make
it
powerful
enough
to
contain
the
other
metadata.
But
that
could
take
a
very
long
time
like
that.
Could
that
could
take
five
plus
years
before
the
JFR
decides
it's
important
enough
to
to
bother
and
if
otel
decides
in
the
meantime
that
our
data
cannot
be
correlated
to
tracing
data
collected
through
otel?
J
F
But
if
you
look
from
the
different
perspective,
From
perspective
of
existing
Java,
open
Telemetry
users,
they
they
use
Java
instrumentation
for
tracing
and
metrics,
and
it's
already
there.
They
like,
install
one
by
one
library
and
they
get
everything
out
of
the
box
and
those
users
would
like
to
get
a
profiling
as
well
just
from
installing
the
same
library
and
getting
it
out
of
the
box
as
well.
So
it's
a
big
opportunity
on
that
front
as
well.
J
I'm
not
saying
they
wouldn't
appreciate
the
profiling
information
and
maybe
for
some
people,
it's
okay
to
to
basically
lose
everything
else
that
would
be
in
JFR
if
they
haven't
been
using
JFR
until
now,
and
they
would
gain
profiling
as
a
new
ability.
I
think
those
people
will
be
okay
and
be
happy
with
it.
I
think
who
you're
going
to
lose
is
the
more
advanced
group
who
are
taking
full
advantage
of
JFR
today
and
if
they
are
proposed
to
use
something
that
is
not
safe
or
they'll,
be
like
no.
J
Why
would
I
because
it
puts
them
in
an
awkward
place
like
right?
They
could
get
profiling
data
through
hotel,
but
then,
where
else
do
they
put
the
j4
stuff?
And
how
do
they
correlate
that,
like
you're,
basically
taking
what
used
to
be
one
stream
of
information
for
them
and
putting
it
in
two
different
directions?
And
now
they
have
to
figure
out
how
to
put
it
back
together
with
no
help
from
hotel,
so
it
seems
strictly
worse
than
what
they
had
before
hotel
to
some
degree.
J
But
I
I
could
be
wrong
on
this.
This
is
what
I
hear
from
talking
to
Java
users
and
Java
people
on
my
team,
but
yeah.
L
Yeah
I'm
aware
we're
almost
at
the
end
of
the
hour,
but
I
think
broadly
I
agree
with
what
Felix
is
saying
about
the
Java
Community
I
think
I'd
like
to
spend
some
time
in
the
next
meeting,
discussing
not
so
much
where
we
want
to
get
to
as
how
we
get
there
so
Logistics
stuff,
like
the
frequency
of
these
meetings,
but
also
as
we
transition
into
into
writing
code.
L
What's
the
kind
of
order
of
deliverables
sort
of
My
Mind
One
of
the
ways
we
can
easily
get
users
is
to
allow
them
to
Tunnel
their
existing
formats,
whatever
those
are,
so
that
would
get
us
to
some
value
very
quickly,
but
there's
a
perception
in
some
ways:
that's
that's
going
downhill.
You
know
we're
conceding
that
we're
we're
just
going
to
Tunnel
stuff
and
not
focus
on
our
own
protocol.
At
least
at
first
and
I
could
argue
yeah,
it's
a
local
Optimum
thing
you
have
to
get
worse
before
you
can
get
better.
L
You
know
you
have
to
go
down
the
hill
before
you
can
climb
the
next
big
hill
and
get
to
the
summit,
and
but
the
counter
argument
is
no.
Let's,
let's
take
a
bit
longer,
you
know
we'll
we'll
let
this
new
protocol
bake
for
as
long
as
we
need
to
and
getting
it
right
is
our
priority.
L
B
Yes,
I'm
very
much
in
favor
of
that
as
well.
I
mean
I,
think
yeah
I
I
mean
I.
Think
it's
easy
to.
You
know
yeah
to
to
get
stuck
in
the
loop
of
of
discussing
a
bunch
of
stuff
and
then
not
just
like
you
know
at
some
point.
We
have
to
try
something-
and
you
know
see
if
yeah.
L
I
think
if
we,
if
we
get
you
know
what
six
or
so
months
in,
if
we,
if
we
get
a
year
in
and
there's
still
no
code,
I'm
gonna
start
to
worry.
We
need
to
start
thinking
about
getting
something.
That's
you
know
minimum
viable.
You
can
actually
download
and
run
this.
B
Yeah
yeah,
okay,
well
yeah,
let's
plan
on
I
mean
yeah
I.
Think
if
you
know
between
now
and
next
week,
I
don't
know
if
there's
any
other
particular
deliverables
here
but
yeah.
If
everybody
could
take
some
time
and
think
about
you
know,
obviously
you
know
we
would
like
to
collectively
as
a
group
make
make
progress
and
you
know
be
able
to
to
share
the
progress
that
we've
made
and
so
yeah
I
mean
if
everybody
could
take
some
time
this
week.
You
know
ask
questions.
B
If
you
went
in
the
in
the
slack,
Channel
or
or
wherever
and
see
like
okay,
what
can
we
actually
do
to
start
yeah,
like
writing
code
for
this,
that
you
know
that
we
can
start
testing
whether
it
means
you
know.
Maybe
we
just
start
and
focus
on
non-java
stuff
and
just
see
like
what
that
looks
like
and
figure
out.
B
Java
later
you
know
whatever
it
might
be
something
so
that
we
can
start
getting
some
code
written
down
and
make
some
progress
there
and
I
will
that's
what
I
was
hoping
to
ask
Josh
before
he
left,
but
he
left
a
little
early
I'll
ask
in
the
slack
and
see
if
I
can
get.
You
know
tigran
and
Josh's
perspective
as
well
as
TC
people,
but
yeah
other
than
that
does
anybody
else
have
anything
else
they
want
to
add
before
we
leave
here
today.
F
I
just
want
to
add,
like
some
insights,
about
how
this
was
dealt
for
other,
like
other
signals.
So
first
thing
to
to
do
is
to
agree
in
the
protocol
itself
so
like
brought
above
definition
of
the
new
signal
that
we
are
reading.
I
I
think
we
should
do
some
kind
of
superset
of
GFR
and
P
Prof
to
make
like
happy
both
the
users
and
then
it's
like
I
believe
First.
It
goes
to
collector
and
The
Collector.
We
Implement
receivers
that
can
take
some
like
other
formats
and
convert
it
to
otlp.
F
Then
we'll
get
maybe
exporters
right
and
after
that,
all
the
instrumentation
libraries
work
is
going.
But
where
is
going
on
so
instrumentation
libraries
add
in
support
for
the
native
for
dlg
format
to
emit
them
out
of
the
box.
That's
like
how
it
happened
before
for
other
signals.
B
Okay,
so
just
make
sure
I
got
C
said
to
agree
on
the
protocol
itself,
then
step
after
that
is
Implement
receivers
in
the
collector
step
after
that
is
creating
exporters.
Yeah.
F
Actually,
they
might
be
important
because
back
and
still
don't
accept
the
glp,
so
yeah
exporters
should
be
there,
and
someone
asked
in
the
chat
whether
it's
envelope
or
I,
don't
think
it
should
be
envelope
because
otherwise
it's
not
a
glp
and
the
back
end
will
have
to
support
the
all
the
other
language,
all
the
other
protocol
formas,
as
I
said
before
yeah.
So
it
should
be
like
some
different
growth
based
as
we
discussed
it
now,.
J
Should
we
consider
the
enveloping
or
completely
roll
it
out,
because
it
I
think
there's
a
lot
of
benefits
to
considering
that,
even
if
it's
a
stepping
stone
to
what
you're
proposing
you're
just
proposing
like
hey,
let's
decide
to
not
do
that
and
Skip
straight
ahead
to
a
custom,
otlp
format
which
may
have
been
how
it
works,
has
worked
for
logs
and
and
tracing,
but
I'm,
not
sure
if
this
group
is
ready
to
to
make
that
jump.
I,
I'm
neutral
on
it,
but
I'm
just
saying
that
yeah
yeah.
F
B
Okay,
we
will
I
do
think
we
will
likely
try
just
because
that
seems
like
the
most
logical,
Next
Step,
but
we'll
yeah
we'll
discuss
offline
more
over
time,
so
yeah
we'll
discuss
in
slack
and
yeah,
get
at
least
Josh
and
Tegan's
perspective
on
that
and
go
from
there,
but
thanks
everyone
and
have
a
good
couple
weeks.