►
From YouTube: 2022-12-15 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
B
E
A
Ari,
you
are
from
the
op
amp.
Yes,.
A
Awesome
so
I
think
we
wanted
to
I
put
the
topic
that
topic
first,
so
that
we
can
discuss
and
you
all.
D
A
So
yeah
for
everyone
there
was,
we
were
discussing
on
Slack
this
op
amp,
Java,
repo
and
I.
Do
want
to
give
folks
here.
Do
you
mind
giving
folks
just
a
brief?
Like
not
everybody
here
knows
what
op
amp
is
about.
F
Okay,
so
basically,
we
open
Java
protocol,
basically
a
network
protocol
for
a
Remote
Management
of
collection
agents.
So
this
repo
is
mainly
for
Java
version
of
that
there
is
already
a
go
repo
for
similar
purpose
and
so
opam
Java
support
I
mean
the
intention
of
Oppam
Java
was
to
provide
both
client
libraries
as
well
as
server
libraries
for
the
for
the
entire
op-amp
protocol
communication.
F
So
open
protocol
basically
has
client
part
as
well
as
server
part
client
part
is
where
agent
communicates
with
the
op-amp
server
and
server
part
is
where
the
server
processes
that
message
and
responds.
So
there
is
a
lot
of
business
logic
apart
apart
from
just
the
transfer,
so
yeah,
so
Palm
Java
repo
was
to
provide
the
Java
artifact
for
the
same.
So
as
of
now,
we
have
just
started.
We
are
using
opam
in
our
company
and
we
wanted
to
use
the
Java
library
for
the
same.
F
There
is
no
development
as
such
as
of
now
so
we
have
just
initiated
that.
A
Cool
and
so
at
a
high
level,
op
amp
is
my
understanding,
is
op-amp
is
all
about
remote
configuration.
Yes,.
F
Yes
about
the
remote
configuration
of
the
agents
and
the
status
reporting
of
the
agents,
for
example,
when
and
agent
can
send
its
own
Telemetry,
like
CPU
RAM
usage
and,
if
downgrade
upgrade
of
agent
specific
packages
and
connection
management,
credential
management.
So
this
all
comes
under
opam
protocol
and.
D
B
Right,
so
my
understanding
is
that
op
amp
is
also
meant
to
be
able
to
configure
sdks
eventually.
So
it's
a
generic
protocol
to
be
able
to
configure
things.
The
Collector
is
one
of
the
primary
use
cases,
but
I
know
that
configuring
sdks
has
been
you
know,
included
in
those
conversations.
F
Yes,
so
correct,
we
are
the
I
mean
consumers
of
only
the
management
specific
portion
of
that
I
mean
this
configuration
management
of
agent
I'm,
not
sure
what
is
the
use
case
of
Hotel
SDK?
What
was
being
discussed
in
that
channel.
A
Interesting
yeah
I
could
see
it
being
very
useful
for
so
some
a
reasonable
portion
of
java,
oven,
Telemetry
Java
users
are
using
the
open,
Telemetry
Java
agent,
which
runs
in
process
inside
of
the
jvm,
and
a
reasonable
number
are
not
using
the
collector,
like
they're,
pointing
the
Java
agent
directly
at
the
back
end
ingestion
endpoint.
A
F
A
So
we
brought
up
in
slack
the
idea
of
moving
this
inside,
of
the
open
Telemetry
one
of
the
existing.
Basically
one
of
the
existing
open,
Telemetry
Java
repos
for
a
few
purposes.
A
A
few
benefits
that
would
bring
one
is
common,
tooling,
pipeline,
Bill,
CI
and
release
pipeline
for
all
of
our
Java
artifacts.
A
It
first
was
raised
because
the
op-amp
Java
folks
want
to
publish
to
Maven
Central
and
currently
the
Java
Hotel
Java
maintainers
are
the
only
ones
with
keys
to
publish
to
move
in
central,
but
I
think
another
benefit
is
getting
more
Java
expertise,
kind
of
the
consolidation
of
all
our
Java
open,
Telemetry
Java
projects
into
sort
of
these
common
Java
repositories
gives
that
consistent,
tooling,
but
also
more
review
from
more
people.
A
A
And
so
this
first
gets
assigned
to
the
reviewers
for
that
component
owner
and
once
that
is
done,
then
the
maintainers,
the
Java
maintainers,
will
merge.
It
sometimes
also,
but
we
also
do
review
it
also
sort
of
not
as
much
for
Content
as
much
as
just
sort
of
consistency
with
the
other
artifacts
and
code
in
the
Repository.
A
So
yeah
so
just
wanted
to
open
up
this
discussion
to
everybody
both
from
the
op
amp
side
vivavari.
If
you
have
any
concerns
about
moving
it
into
one
of
the
existing
Java
repos
and
also
from
the
Java
maintainers
approvers.
F
Okay,
so
trust
from
my
side.
The
ic2
benefits,
one
is
what
you
mentioned
is
already
built
in
CI
CD
and
release
pipelines.
So
we
will
not
have
any
work
on
that
and
the
we
will
have
get
the
support
of
all
the
existing
tools,
which
are
already
there
in
that
triple
and
another
one
is
that
we
will
get
better
reviews.
As
apart
from
review
on
the
opam
side,
we
will
also
get
Java
specific
reviews.
F
So,
but
one
concern
is
that:
will
it
slow
down
our
approvals
for
opam
Java
development?
F
So
that
is
one
concern?
I
have
and
another
is
I,
don't
know
what
is
the
what
what
kind
of
libraries
or
packages
are
inside
open,
telemeter,
Java
contract
reporters
does
opam
Java
also
comes
under
that
category
or
because
opam
Java
has
lot
of
business
logic
to
be
built
on
client
implementation,
server
implementation.
It
can
be
definitely
a
separate
repo,
so
I'm
not
sure
whether
moving
it
into
I'm,
not
sure
the
other
packages
which
are
inside
contrabo.
What
kind
of
use
cases
they
have
foreign.
B
Repository
is
kind
of
a
grab
bag
of
of
different
use
cases.
You
know
there
are
some
SDK
extension
components,
so
things
like
custom,
Samplers
processors,
exporters,
various
things
that
you
extend
the
SDK
with
and
then
there's
some
things
that
kind
of
resemble
instrumentation.
So
there's
this
thing
called
the
jmx
metric
collector
and
you
know
it
connects
to
remote
Java
processes
and
collects
jmx,
metrics
and
Maps
them
into
open
Telemetry
and
then
there's
propagators
and
you
know
some
resource
providers.
Those
are
kind
of
involved
with
the
SDK
again.
B
So
there's
nothing.
That
looks
exactly
like
this.
This
op-amp
client
and
server
that
you're
that
you've
been
working
on,
but
I,
don't
think
I.
Don't
think
that
contrib
has
you
know
any
sort
of
description
of
the
types
of
things
that
live
in
it.
That
would
exclude
that,
like
I,
think
think,
I
I
don't
see
any
reason
why
it
couldn't
live
there
based
on
the
types
of
projects
that
already
live
in
control.
F
D
Brings
brings
me
to
what
my
major
concern
with
having
it
be.
A
separate
repo
is
so
in.
Go.
We
there's
no
like
publishing
to
a
central
repository
like
go.
You
just
pulled
out
a
repo
and
you
build
stuff
right.
Yes,
but
in
the
Java
world
we
published
New,
Haven
Central
and
if
one
wanted
wants
to
publish
under
the
io
open
Telemetry
coordinate
space
coordinates.
D
That's
something
that's
currently
in
control
of
the
Java
maintainers
and
we
have
a
very
kind
of
strict
and
lengthy
process
to
become
a
maintainer
and
I
think
this
helps
protect
our
supply
chain
and
when
I
heard
some
people,
we've
never
met,
never
attended.
One
of
our
meetings
once
to
come
in
and
be
able
to
publish
two
Iowa
open
Telemetry.
My
first
concern
was
hold
on.
This
means
we're
giving
the
keys
to
our
publishing
Kingdom
to
people
that
we
don't
know
that
we
haven't
interacted
with
and
we
haven't
vetted
any
of
the
code.
D
F
Yeah
because
I
think
the
criteria
of
moving
it
into
the
quantity
report
should
not
be
that
we
do
not
want
to
get
a
credentials
or
we
do
not
want
to
access
the
Iota
dot
open,
telemetric
group.
We
can
create
a
separate
of
our
own
and
that's
what
I
think.
D
D
Yeah
I
guess
you
could
do
a
hyphen,
that's
true,
but
I,
don't
actually
know
the
details
of
how
Maven
Central
protects
that
stuff.
F
F
So
yeah
I
was
more
inclined,
or
even
we
I
had
an
opinion
of
keeping
it
as
a
separate
triple
because
two
things
one
is
opam.
Gold
is
a
separate
triple
and
there
is
a
lot
of
business
logic
apart
from
just
protobuf
classes,
which
will
come
into
upam,
Java,
so
yeah
that
that
is
where
we
are
opinionated.
As
of
now
the
repo
is
blank,
but
we
expect
lot
of
logic
to
be
here.
F
And
we
can
I
mean
we
can
always
discuss
on
what
access
group
or
I
I
o-
dot
open
Telemetry.
If
you
don't
want
to
publish
there,
we
can
find
out
something
else
which
will
not
impact
other
Maven
Central
repose.
D
Well,
I
think
that
also
the
other,
the
other
question
I
have
is
why
why
aren't
you
becoming
a
part
of
the
General
open,
Telemetry
Java
community,
like
we
don't
want
I
mean
if
this
is.
This
is
really
an
open
Telemetry
project
and
it's
implemented
in
Java
like
I,
feel,
like
you
all,
should
be
part
of
this
community,
because
we
are,
we
have
a
lot
of
expertise.
D
A
Yeah
that
that's
certainly
my
preference
is
to
I
think
it's
a
wonderful
open,
Telemetry
Java
community
that
exists
here
and
I.
Think
you
can
see
by
the
number
of
folks
on
this
on
our
weekly
call
here,
and
we
are
very
you
know
so.
I
I
would
love
to
bring
more
people
into
that
fold.
F
Okay,
so
so
that
the
concern
of
whether
it
will
slow
down
our
development
I
think
it
will
not
right
I
mean
we
will
always
have
op
amp
reviewers,
they
will
review
and
we
will
not
be
blocked
on
the
approvals
and
reviews.
I
assume.
A
Yeah
yeah
so
I
mean
we
would,
you
know,
provide
some
additional
review,
but
the
Java
we
do
have
a
pretty
good
number
of
Java,
maintainers
and
so
I
would
expect
that
we
could
keep
that
going.
If
it
becomes
an
issue,
then
certainly
you
know
poke
us
on
slack.
A
F
B
Class,
let's
say
just
like
hypothetically:
if
we're
not,
if
this
becomes
an
issue,
can
we
use
the
component
owner's
file
to
Grant
the
ability
to
like
selectively
Grant
the
ability
to
merge
to
certain
components.
A
One
of
us
still
needs
to
do
the
merge.
Okay,
but
I
am
I.
Don't
personally
object
to
doing
like
a
very
skim
review
if
needed
and
just
approve
and
merge
just
for
you
know
really
high
level
quality.
E
A
It's
nicer
if
one
of
us
has
time
to
do
a
little
bit
more
detailed
review,
but
if
not
I
agree
with
velocity
in
this
case.
In
the
contrib
case
and
relying
on
the
component
owner
reviews.
A
Sure
is.
B
D
D
A
Yeah
and
as
Jack
mentioned
really,
we
viewed
this
repo
as
anything
that's
open,
telemetry
that
the
open,
Telemetry
Community
is
building
that
that
they're
building
with
Java
so.
B
Yeah,
so
the
three
repositories
are
open:
Telemetry,
Java,
open
Telemetry,
Java,
instrumentation
and
open
Telemetry,
Java,
contrib
and
so
open
Telemetry
Java
has
pretty
strict.
You
know,
requirements
for
what
goes
in
there,
where
it's,
the
API
and
SDK
components
that
are
explicitly
defined
in
the
specification-
and
you
know
there's
there's
documentation
in
here
about.
What's
in
and
what's
out
of
this
specific
repository,
the
instrumentation
repository
is
pretty
similar.
B
Again,
it
has
pretty
strict
requirements
about
what
goes
in,
and
it's
largely
related
to
instrumentation
and
contrib
is
where
things
that
don't
emit
the
the
criteria
of
the
core
repository
or
the
instrumentation
repository
live.
F
D
Ute
I,
don't
think,
there's
a
I,
don't
think,
there's
a
reason
against
that.
The
proto-revo
could
definitely
live
in
contrib
I
mean
its
whole
point
is
that
in
the
core
repos
we
don't
use
the
the
artifacts,
but
some
people
do
want
to
get
the
Proto
the
protobus
or
otlp
independently.
So
I
could
definitely
see
moving
moving
Proto
Java
Proto
into
contrib.
D
B
B
D
We
I
mean
we.
We
have
a
little
bit
of
a
weird
issue
with
the
Proto
repo
that
we
don't
really
have
any
of
I
mean
we
have
people
who
are
assigned
as
maintainers,
but
also
there's
like
no
code
right.
It's
literally
just
a
build
process
and
Publishing
process.
So
maybe
that's
not
a
big
deal.
Somebody
has
to
I
think
do
we
have
an
automated
publishing
automated
right
now
or
do
we
have
to
go
click
the
button
manually
to
make
it
happen
on
release?
Will.
A
G
A
Then
you
know,
if
you
find
that
there's
reasons
in
the
future
that
it's
not
really
working
in
the
contrib
repo.
You
know
we
could
always
split
it
out
later.
I
think,
okay,.
F
A
Cool,
so
if
you,
if
you
send
a
PR,
go
ahead
and
send
a
PR
anytime,
and
we
can
help,
we
can
help
massage
it
sort
of
into
the
contrib
format
and
feel
free
reach
out
to
me
on
just
ping
me
on
slack.
Okay,
if
you
want
any
help
with
that
process,.
D
A
Cool
yeah
I'm
happy
to
help
kind
of
work
through
it's
a
good
point.
It
would
I
think
initially
it's
okay
to
have
the
sub
module
we
have
like
John
mentioned.
We
did
have
the
sub
module
originally
in
the
the
SDK
repo
there's.
Some
some
modules
are
a
bit
of
a
pain.
It's
nice
to
get
rid
of
them.
If
we
can
but
I,
don't
think
that
would
block
the
initial
move.
H
F
So,
in
summary,
I
mean
we
can
say
that
we
will
be
moving
this
to
contribute
and
in
future,
if
there
is
a
requirement
that
this
is
not
fitting,
we
can
definitely
come
out
of
control.
F
I
Is
it
is
it
for
like
the
collect,
or
only
or
do
you
think
that
vendors
also
were
like
native,
is
supporting
otrp
like
without
the
collector
should
or
will
implement
this.
F
So
we
have
otlp
collectors
as
well,
which
follow
which
are
built
using
the
otlp
protocols.
So
opamp
is
basically
to
manage
those
collectors
which
are
built
using
otlp
protocols.
I
I
I
get
it.
What
I'm
asking
is
what,
if
I,
not
using
the
collector
but
I'm
using
a
vendor
who
has
like
out
of
the
box
support
without
the.
I
They
are,
let's
say:
I
am
I'm
a
data,
Tok
user
and,
let's
say
data
Togo
Implement
data
like
otrp
like
they
can
accept
data,
video
DLP
format.
Should
they
or
will
they
Implement
or
Camp
too.
F
So
I
mean
it
depends
so
now
we
current
I,
don't
exactly
have
the
answer
for
that,
but
as
far
as
I
understand
now
also
we
do
have
some
OT
agents
which
follow
OT
protocol,
but
they
are
not
managing
themselves
using
opamp.
They
have
their
inbuilt
logic.
So
it
is
not
mandatory
that
they
have
to
use
opam
to
support
remote
configurations
and
manage
themselves
and
upgrade
downgrade.
But
it's
a
recommended
way.
A
So
I
think
Jonathan
from
your
perspective,
you're
thinking
like
micrometer
with.
I
A
So
it
could
I
think
it's
just
a
very
general.
My
idea
in
a
jack
maybe
hopefully
knows
more-
is
that
it's
just
a
very
general
remote
configuration
protocol
that
anybody
in
theory
could
use
for
configuring.
A
Sdks
figure
configuring
views
in
micrometer
configuring
anything
in
your
app
from
a
central
service.
Oh.
I
I
see
So,
eventually
the
open,
Telemetry
SDK.
You
use
this
as
well.
B
Thanks,
theoretically,
a
handful
of
things
have
to
get
done
before
then,
but
yeah
generally
speaking,
op
amp,
just
it
transmits
an
array
of
bytes
down
representing
the
configuration,
and
so
you
know
those
bytes
can
represent
a
collector's
configuration
and
sdks
configuration
or
something
else.
That's
not
related
to
open
Telemetry
at
all.
I
Cut
it
can
I
have
like
just
one
quick
created
question:
do
you
want
to
move
this
out
from
open
Telemetry
in
that
case,
because
if
this
is
kind
of
like
a
configuration
protocol
that
this
could
be
useful
for
basically
every
use
case
that
you
want
to
configure
something
not
just
like
a
hotel.
B
That's
a
conversation,
that's
above
my
pay
grade.
So
so
the
op-amp
specification
is
is
is
part
of
open
Telemetry
and
a
lot
of
folks
have,
you
know,
have
put
a
part
of
the
open.
B
Telemetry
Community
have
put
a
bunch
of
work
into
that,
and
so
the
the
specification
has
a
series
of
documents
that
describe
what
the
clients
and
servers
do
and
there's
protocol
buffer
definitions
describing
the
interactions
as
well
and
one
of
the
main
use
cases
I,
think
that
were
two
of
the
main
use
cases
that
were
thought
of
when
designing
the
spec
were
configuring,
The,
Collector
and
configuring
the
sdks.
B
Now
the
authors
of
this
were
you
know
they
made
it
generic
enough
where
it
wasn't
tied
to
anything
open
Telemetry,
so
you
can
expand
it,
but
I
think
it
was
built
with
those
with
a
couple
of
open,
Telemetry
use
cases
in
mind.
I
do
tend
to
agree
with
you,
though,
that
you
know
it's.
B
Yeah
so,
like
you
know,
if
you,
if
you
kind
of
project
out
into
the
future,
maybe
you
configure
your
your
agent
or
your
collector
with
just
a
URL,
a
remote
URL,
to
connect
to
and
there's
some
negotiation
that
happens
between
the
client
and
the
server
and
ultimately,
the
the
server
identifies
who
the
client
is
sends
down
the
appropriate
configuration,
and
you
know
they
can
change
that
at
runtime.
Even
perhaps
so.
Okay,
thanks.
I
A
I
A
I
I
would
recommend
joining
the
op
amp
fig
meeting
and
raising
it
there
or
raising
it
in
the
op.
J
D
Contrask,
as
our
governance
committee
member
here,
why
why
is
this
a
part
of
open
Telemetry
and
not
something?
That's
being
you
know,
part
of
the
cncf
in
general.
A
I
yeah,
I
I,
don't
know
what
discussions
have
gone
on.
I
would
equate
it
to
like
when
Jonathan
will
remember
the
context.
The
open,
Telemetry,
Java
context,
propagation
discussion,
where
we
were
at
one
point
thinking
of
moving
context,
propagation
outside
of
open
telemetry.
A
A
A
This
is
probably
a
lot
easier,
but
if
somebody
does
have
a
particular
interest
in
it
being
larger
than
open
Telemetry,
you
know
for
sure
ping.
There
is
a
slack
Channel.
There's
a
Sig
meeting.
There's
the
repo
there
may
be
context
there.
B
It's
really
a
question
of
the
scope
of
the
open
Telemetry
project.
What
falls
under
the
umbrella
versus
what
is
you
know,
I,
guess,
independent
enough
to
Warrant
being
under
a
different
umbrella
and
I
think
you
know,
each
situation
is
kind
of
unique
I.
Think
I
can
see
arguments
both
ways
for
those
yeah
I
was
just
asking
because
this.
I
Could
be
like
a
really
used
in
in
other,
like
theater
style
like
in
Frameworks,
this
can
go
to
Springfield
and
you
can
like
you
can
think
of
it
proper
piece
or
you
can
use
it
for
feature
flagging
as
well,
I,
guess
and
so
on
so
I
see
a
lot
of
like
use
cases
outside
of
open
telemetry.
I
So,
for
if
you
want
to
like
modify
that
runtime,
then
yes,
but
like
it's
not
just
spring
like
it,
can
be
like
every
other
Frameworks
like
work
with
my
turnout
and
so
on.
You
would
have
I'm
not
just
seeing
the
childhood
but
like
everywhere,
and
you
could
have
like
a
specification
for
such
a
configuration
management
and
configuration
like
modification
I,
don't
know
where
it
system
that
would
be
pretty
nice.
A
I
think
that
the
and
we've
established
that
there's
certainly
interest
among
this
group
in
that
module
yeah.
A
I
saw
Jack,
you
already
commented
on
this
and
yes,
Jason
agreed.
Thank
you
just
that
was
I
just
wanted
to
draw
attention
to
it.
Oh
but
Robert's
here,
yes,
hey
Robert,.
K
Yeah
I'm
here
yeah
I,
can
certainly
break
it
up
into
multiple
PR's.
B
Cool
yeah,
I
think
I.
Think
some
of
the
stuff
is
probably
pretty
easy
and
straightforward
to
merge
because
it's
simpler.
But
then
you
know
some
of
the
stuff,
like
the
memory
and
garbage
collector
stuff.
I
think
will
want
to
review
a
bit
more
closely
and
just
try
to
evaluate
just
how
those
JFR
behaves
when
different
garbage
collectors
are
configured
and
that
just
is
going
to
take
a
bit
more
time.
So
I
don't
want
to
hold
up
the
the
easy
stuff
for
the
more
complicated
stuff.
K
Yeah
makes
sense,
there
is
definitely
a
bunch
of
weird
stuff
going
on
with
the
garbage
collection
and
awesome
memory
related
events,
but
yeah
I
can
break
it
up.
K
I
did
have
a
an
agenda
item
here,
but
it
seems
like
Jack,
already
answered
my
question,
but
yeah
I've
been
working
on
the
JFR
streaming
Anders
and
the
Java
contrib
repo
and
I
was
just
wondering
about
how
to
make
it
actually
usable
because,
as
I
understand
it,
the
contrib
project
is
kind
of
like
a
little
bit
experimental
and
nobody's
really
using
the
JFR
streaming
work
as
a
Viet.
B
Yeah
I
think
it's
just
been
lacking.
Somebody
that
wants
to
push
it
over
the
Finish,
Line
I.
Think
it's
pretty
close
and
the
work
that
you've
done
in
the
in
this
PR
is
is
great.
It
helps
align
it
with
all
the
changes
we've
been
making
to
the
jvm,
runtime
semantic
conventions
and
then
I,
just
like
I
noted
a
couple
of
things
here
that
I
think
are
kind
of
small
hygiene,
things
that
are
need
to
be
done.
B
They're,
they're
all
really
really
digestible
things,
so
I
don't
see
a
lot
in
the
way
of
of
publishing
this,
at
least
as
like
an
alpha
release.
So
right
now
it's
not
published
at
all,
so
it's
impossible
to
use
it.
But
oh
yeah.
A
B
Missed
that
yeah,
it's
missing
the
Java
publish
conventions.
A
I
just
triggered
a
release
this
morning,
so
it's
too
late
for
this
month,
but
yeah,
even
if
and
just
to
kind
of
clarify
in
General
on
the
contrib
repo,
the
contribute
repo
doesn't
mean
experimental.
It's
a
great
place
for
experimental
stuff
to
live,
but
it
can
also
stuff
can
evolve
out
of
experimental
and
be
published
as
stable
artifacts
from
here
and
build
a
community
of
users
here,
there's
nothing
limiting
about
the
contrib
repo
in
that
aspect,
okay,
I.
K
See
yeah,
there
is
still
a
little
bit
of
work
that
has
to
be
done
even
once.
The
changes
in
that
massive
pull
requests
are
emerged,
there's
still
a
few
things,
but
they
actually
require
support
from
JFR
itself,
so
I'm
thinking
I'll
probably
have
to
make
some
changes.
K
Then
come
back
to
the
JFR
streaming
work
in
the
country,
repo
and
then
beef
up
the
the
existing
handlers,
because
there
are
some
attributes
that
are
I,
guess
incomplete,
with
respect
to
all
of
the
set
of
attributes
that
jmx
might
emit
for
a
specific
metric,
and
that's
just
because
there
are
JFR
events
that
are
missing
some
information
that
jmx
you
can
access
through.
B
Fantastic,
if
that,
if
JFR
could
be
adjusted
to
include
all
that
all
that
metadata,
you
know
if,
if
it
seems
impractical
for
some
reason,
like
one
thing
that
we
could
do
and
I
know,
we've
discussed
this
Robert.
But
you
know
the
the
jvm
runtime
semantic
conventions
are
pretty
strict.
They
say
that
all
the
attributes
must
be
present.
B
You
know
if
it's
for
some
reason,
impractical
to
add
those.
We
could
relax
those
requirements
and
say
they
should
be
added
if
they're
available,
you
know
recognizing
that
limitations
in
JFR
prevent
them
from
being
available.
In
some
cases.
K
Okay,
cool
and
it's
not
so
much
that
all
the
attribute
keys
are
not
may
not
be
available.
It's
just
some
of
the
values
for
this,
for
example,
like
a
set
of
values
per
key
may
not
be
available,
or
at
least
easily
accessed
through
JFR
event
data.
K
B
G
A
Yeah
yeah
I
would
love
to
see
any
future
updates
demos,
anything
I,
I,
think
people
are
who
have
several
folks
on
this
call
who
are
interested
in
general
in
how
we
can
better
integrate
JFR
into
open
Telemetry
and
the
open
Telemetry
the
Java
agent.
Also,
and
have
you
Robert?
Are
you
participating
in
the
open,
Telemetry
profiling
group.
A
A
Yeah
there's
a
Sig
group
that
is
kind
of
discussing
bringing
open
profiling
as
a
new
signal,
in
addition
to
traces,
metrics
and
logs,
okay
and
so
yeah.
You
may
be
interested
in
it's
not
on
the
community.
J
A
A
There's
a
slack
Channel
for
it
and
it's
fairly
active.
Actually,
if
you
go
to
the
slack
Channel,
they
post
good,
updates
there
on
kind
of
what
they're
talking
about
and
doing,
but
certainly
they're
discussing
how
JFR
could
I
mean
they're,
taking
a
language
agnostic,
trying
to
develop
something
language
agnostic,
but
at
the
same
time,
looking
at
established
things
like
JFR
and
how
JFR
data
could
be
mapped
into
this
more
General
profiling
protocol
wire
protocol.
K
A
C
Yep,
so
a
couple
of
weeks
ago,
I
preached
a
PR,
that's
the
implements
kind
of
like
a
logging
bridge
that
allowed
the
Java
agent
to
log
into
the
applications
logging
system,
and
there
is
enough
Twitter
demo
he's
he
actually
quit
this
meeting
so
like
well,
he's
lost
too
bad
for
him.
So
I
prepared
a
very
simple
application
that
does
pretty
much
nothing
I
mean
it
just
created.
I
I
hope
that
you're
seeing
it
by
the
way,
can
you
see
yeah
the
screen?
C
Okay,
cool
I
prepared
a
very
simple
application
that
gets
a
logger
locks,
something
and
gets
not
much
limited
Tracer
and
create
a
spell
and
I've
I
have
dedicated
like
logger
configuration
tool,
open,
Telemetry
and
everything
else
is
just
debug,
so
the
demo
is
very
simple:
I
just
run
this
application
with
our
Java
agent.
I
use
the
login
exporter
to
make
it
very
simple,
and
this
is
a
new
property
that
I
introduced.
This
is
this
Auto
Java
agent
logging
and
there's
like
a
logging
implementation
name.
C
It
has
three
values
at
the
moment.
It's
there's
none,
which
means,
of
course,
no
logging
at
all,
there's
a
simple
which
is
the
default:
Implement
logging
implementation
and
using
this
vessel
of
J,
it's
left
for
very
simple
implementation.
That
is
like
currently
being
used
in
the
agent,
and
this
is
the
new
option
which
basically
says
use
the
applications
slf4j.
C
If
you
detect
that
and
try
to
send
over
logs,
that
agent
produces
to
the
application
and
the
demo
is
very
simple
and
that
that's
it
as
you
can
see,
the
the
agent
log
is
actually
like
forwarded
to
the
applications
as
well
for
J.
It
is
printed
out
in
exactly
this
same
pattern
as
the
application,
all
the
application
logs,
and
you
can
also
like
configure
loggers
logger
levels
in
the
application
kind
of
thing.
So,
if
you
want
to
skip
Open
to
the
material
together,
just
turn
it
off.
C
If
you
want
to
enable
debug
or
info,
but
only
for
a
particular
logo,
you
can
also
do
that.
So
there's
actually
results
like
five
issues
that
we
have
in
in
our
backlog,
because
there
are
a
lot
of
users
that
complained
about
javage
and
just
like
printing
out
some
trash
into
sddr
and
just
breaking
the
unlocking
patterns
so
yeah.
This
should
be
an
improvement
that
will
allow
people
to
like
integrate
the
agent
more
into
their
logging
systems.
C
This
is
like
still
not
done.
I've
purposely
chosen
a
very
simple
application
and
just
initializes
the
logger
just
like
that,
using
the
Blogger
Factory
and
just
to
look
at
the
just
a
configuration
file.
It
unfortunately
doesn't
work
for
Springwood
right
now.
C
I
tried
for
Springwood,
because
spring
would
initializes
the
logger
configuration
a
bit
later
after
sla4j
is
loaded,
so
the
agent
actually
like
waits
for
the
excellent
project
Factory
class
to
below
that,
and
once
it
it
is
loaded
it
just
uses
it,
and
spring
rules
had
has
a
little
bit
of
delay
between
these
little
events.
C
So
the
next
step
and
the
next
PR
will
be
just
a
fix
for
that,
so
that
it
will
go
extremely
good
because
it
definitely
should
work
with
spindle
I
mean
it's
probably
the
most
popular
framework
for
writing,
a
single
jar
application
and
the
other
like
KV
this.
It
will
work,
probably
very
good
or
excellent,
with
like
with
singular
applications
or
simple
applications
that
do
not
have
a
very
complex
class
loader
structure,
but
I.
C
G
I
have
a
question
here
so
yeah
that
probably
assumes
that
the
application
uses
a
single
logging
system.
What,
if
there
are
multiple
will
it
use
the
first
one,
the
last
one,
all
of
them
any
of
them?
What's
what's
the
expectation.
C
So
we're
just
using
as
with
detecting
a
solar4j,
so
if
you're
using
like,
for
example,
I,
don't
know
both
log4j
and
sl4j
and
log
back
and
you're,
using
them
separately,
meaning
that
you
don't
use
like
look
for
drivers
for
the
API,
then
yeah.
The
agent
will
obviously
only
see
the
sl4j
and
and
the
same.
If
you
have
like
two
slap
project
configurations.
For
example,
you
have
two
class
loaders
which
both
load
sl14j
separately.
It
will
just
use
the
first
one
it
sees
so
it's
it's
fairly
simple
in
with
regards
to
that.
A
So
that's
why
I
we
wouldn't
recommend
it
for
app
servers
yeah,
because
it
would
just
pick
up
one
of
the
apps,
the
war
files,
for
example,
and
log
to
that
one.
C
Yeah-
and
this
is
also
the
reason
why
I've
chosen
this
left
4J
and
not
any
of
the
like
actual
logging
implementations,
because
if
you
have
more
than
one
of
them
on
the
class
path
like
which
one
do
you
choose,
a
solution
is
kind
of
like
simple,
because
it's
it's
an
API
and
you
usually,
you
use
the
API
and
developing
sort
of
like
logging
information.
Logging
backend
is
whatever.
C
C
B
Hey
traskin
mates
how
how
visceral
of
a
reaction
do
you
have
to
this
statement?
Can
we
use
the
open,
Telemetry
log
API
in
the
agent.
B
C
B
C
Well,
it
usually
goes
the
other
way
like
we
usually
capturing
whatever
the
application
produces
and
putting
it
into
open
symmetry
log,
API
and
SDK
right.
So
you
would
be
kind
of
like
maybe
skipping
a
step
and
just
you
know,
skipping
the
whole
application
part.
Then
just
logging
directly
to
the
Box.
What
is
the
thing.
C
And
I
mean
you
could
also
send
those
logs
like
overall
TLP,
but
there's
probably
lots
of
users
that
are
not
using
the
auto
logging
and.
G
I
B
Log
exporter
that
just
like
uses
I,
think
I
just
use
a
system
out
because.
A
Jack,
are
you
thinking
about
it
from
the
perspective
of
like
self-diagnostic,
self-diagnostics
kind
of
like
the
exporters
sent
their
drop
like
some
metrics
about
themselves,
and
so
the
agent
could
report
over
otlp
sort
of
like
warnings
and
things
more
like
self-diagnostics,
or
were
you
thinking
from
getting
it
just
getting
it
back
into
the
application
logs.
B
Getting
it
back
into
the
application
logs
and
then
whatever
you're
doing
with
those
application
logs,
whether
it's
just
printing
to
a
console
or
sending
them
to
a
network
location
just
seeing
if
or
sending
them
over,
otlp
yeah
exactly
seeing
if
there
was
any
opportunity
to
make
it
potentially
easier
with
that.
B
But
it
sounds
like.
Maybe
not
because
there's
there's
just
been
this
there's
been
there's
there's
this
environment
variable
that's
in
the
spec,
which
is
the
which
we
don't
respect
and
it's
kind
of.
B
Right
so
there's
the
the
spec
and
flies
that
you
know
there
should
be
a
really
easy
configuration
handle
to
decide
the
the
log
level
for
your
for
open
Telemetry
for
your
SDK
and
maybe
as
an
extension
of
that
for
any
any
logs
from
instrumentation.
B
C
C
Because,
even
if
you,
even
if
you
respected
that,
even
if
we
kind
of
like
use
it
use
the
tutorial,
the
Java
agent,
what
to
lock
the
mother
of
where
to
look
the
the
stuff,
it
would
be
still
undecided.
Whether
you're,
using
like
stdr
like
right
now
or
whether
you
like
kind
of
try
to
push
it
to
the
applications.
Logging
system
or
whatever
else.
H
I
have
one
question
about
sending
the
logs
to
the
application.
Currently
we
we
have
some
default
configuration
for
the
logger,
for
example,
I
think
we
disabled
muscle
failures.
C
Yeah,
we
will
probably
have
to
change
that
I
mean
we
will
have
to
make
them
debug
level,
lock
statements
in
case
you're,
not
running
debug
and
in
the
debug
mode,
because
you're
right
this
will
cause
Panic
people
see
them.
I
I
do
have
a
question
but
I
like
talking
so,
if
I'm
not
using
the
Java
agent
right
now,
the
such
as
Theta
thing
to
do
is
basically
using
a
set
of
4G
with
like
an
open
Telemetry,
a.
B
B
Is
that
a
question
or
a
statement?
It's
a
question
it
yeah!
So
if
you
don't
use
the
agent
you
have
to
configure
either
your
your
log
back
or
your
log4j
configuration
to
specify
this
open
these
one
of
these
open,
Telemetry
appenders
that
we've
written
yeah
cool.
A
Thank
you,
were
you
Jonathan?
Were
you
asking
application
logs
how
to
send
those
over
capture
those
or
the
the
sdks
diagnostic
logs
themselves.
A
Yeah,
it
was
a
big
day
when
we,
finally,
when
we
got
lag,
lagging
appenders
and
Auto
log
capture
in
yeah.
That
was
a
big
missing
piece
for
a
long
time
and
Jack
I
think
we're
it's
sounding
like
the
lag
API
will
might
be
stable
soon,
I.
B
Hope
so
yeah!
Actually,
while
we're
on
that
subject,
so
we
back
when
metrics
went
stable,
we
we
flipped
an
environment
variables
default.
We
switched
the
default
exporter
for
metrics
from
being
none
to
being
otlp,
and
so
you
know,
if
you
play
that
out
for
logs,
you
might
assume
that
we
do
a
similar
thing.
Hey
switch
the
default
exporter
from
none
to
otlp
for
logs
as
well.
B
What
do
you
all
think
about
that?
Is
that?
Would
that
be
surprising
to
users?
Is
it
just
something
we
need
to
document
in
the
changelog
and
make
them
aware
of.
D
So
I
here's
my
one
comment
and
it's
actually
based
on
an
experience
this
week,
I've
been
having
having
the
exporters
DePaul
to
otlp
is
a
real
pain
in
the
butt
because
we
don't
use
otlp
and
I
wanted
to
start
using
metrics
and
hook
them
up
to
Prometheus,
like
not
in
using
the
using
the
Prometheus
Prometheus.
Whatever.
D
The
thing
is
that
I
stole
from
the
test
code
right
and
in
order
to
do
that,
I
have
to
like
explicitly
set
a
nun
like
if
I
want
to
use
if
I
want
to
use,
Auto
configure
I
have
to
specifically
set
a
none
and
then
go
and
manually
do
a
bunch
of
work
to
configure
the
metrics
SDK
itself.
D
I
want
to
use
this
custom
thing,
and
so
I
have
to
like
set
this
variable
to
none,
rather
than
just
being
able
to
configure
what
I
want
like
use,
Auto
configure
for
tracing
and
then
metrics
do
what
I
want
to
do,
which
isn't
any
of
the
built-in
stuff
anyway,
I
wish
it
was
all
none.
Actually,
it
was
the
default
side
to.
D
C
You
know
so
from
a
like
a
vendor
perspective.
Yeah
I'll
be
turning
that
off
by
default
anyway,
because
I
don't
support
that
yet.