►
From YouTube: Opentelemetry with MicroProfile - JakartaOne 2022
Description
Microprofile OpenTracing will be dropped in favor of Microprofile Telemetry Tracing, based on OpenTelemetry. The talk will present the background story for this change, the advantages of getting into the OpenTelemetry bandwagon and the collaboration with a wider open source observability community. Migration paths will be addressed and live coding with examples.
-
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://jakarta.ee/
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
So
about
Eclipse
micro
profile,
so
this
is
the
the
old
version
five
and
when
about
two
two
years
ago,
back
in
time,
I
was
in
a
different
company
and
we
were
developing
a
large
monitoring
system
with
microfile
open
tracing
to
monitor
jobs.
That
would
send
messages
and
try
to
understand
where
the
the
jobs
would
fail
and
and
why,
in
an
efficient
way
and
by
then
we
had
a
lot
of
infrastructure
in
place.
A
But
everything
was
based
on
top
of
open
tracing
and
open
tracing
is
dead
now
and
was
already
there
two
years
ago.
So
I
got
a
bit
concerned
because
we
were
stuck
with
that
technology
and
two
years
after
here
we
are
with
a
new
specification.
So
a
lot
of
people
contributed
to
it
and
it
it's
great,
and
so,
but
the
decision
to
for
the
new
specification
had
some
constraints.
So
we
wanted
to
minimize
the
compatibility
difference
or
best.
We
wanted
to
maximize
the
compatibility
with
the
the
Legacy
open
tracing.
A
A
A
Currently,
it
supports
four
different
signals
and
we
call
signals
to
these
observability
pillars
like
traces,
metrics,
logs
baggage,
and
there
are
discussions
for
a
lot
more
signals
like
profiling
and
some
some
others
are
being
discussed
for
the
future
in
terms
of
contributions.
There
are
very
big
organizations
behind
it,
including
revat,
and
the
adoption
is
quite
large
already.
This
is
the
second
most
active
cnci
project,
just
behind
kubernetes
and
in
terms
of
observability
projects.
It's
a
second
only
behind
the
Prometheus
and
it's
supported
in
many
many
languages.
A
This
is
not
just
a
Java
project.
It's
supported
on
cplusplus.net,
Rust,
Ruby
python,
many
many
different
projects,
which
is
very
important
for
large
microservice
organizations.
Some
of
these
organizations
can
have
up
to
hundreds
of
microservice
developed
in
many
different
languages,
and
it
has
a
lot
of
value
to
actually
be
able
to
to
have
the
same
semantics.
The
same
proper
calls
on
all
the
microservice
with
all
these
different
languages.
A
So
we
started
well
adopting
this
new
specification
so
about
open
Telemetry
in
more
details.
It's
a
software,
a
set
of
software
and
tools,
Define
the
specifications
protocols
formats,
apis
libraries,
it's
client-side
only
it
does
not
specify
how
the
data
should
be
ingested
or
it's.
It's
not
an
observability
backend
Like
Jaeger
and
it
doesn't
care
about
how
the
the
storage
is
performed.
A
There
are
a
few
main
projects,
so
the
main
project
is
not
undoubtedly
the
the
open
Telemetry
specification
where
the
apis
for
the
different
signals
are
defined,
how
to
build
an
SDK
all
the
semantic
conventions
and
the
otlp
open
Telemetry
protocol
to
send
data
Across,
The
Wire,
and
with
this
you
can
create
implementations
of
open
Telemetry
in
different
programming
languages.
So
the
Java
implementation
projects.
A
A
This
we
are
going
to
talk
later
about
it
because
it
provides
a
compatibility
layer
for
the
Legacy
open
tracing
code,
also
the
open,
Telemetry
job
instrumentation,
which
in
Java
this
is
a
particular
case
because
it
was
created,
an
instrumentation
API
that
is
used
both
by
the
the
agent
that
you
can
instrument
your
services.
When
you
start
the
service
with
the
Java
manager,
you
can
use
this
agent
to
instrument
it,
but
you
can
also
use
this
API
to
manually
instrument
libraries
and
get
the
data
out
of
it.
A
Without
the
need
of
the
agent,
there
are
other
projects
like
country
for
more
experimental
code
and
also
documentation.
Then
there
is
the
open,
Telemetry
collector,
which
is
a
reference
implementation
and
it's
actually
implemented
in
go
so
how
all
these
relates.
So
the
Java
application
libraries
we
collect
the
data
using
the
Java
instrumentation
API.
A
About
different
signals
and
its
maturity,
as
of
September
tracing
was
stable,
as
as
baggage
was
stable
as
well
metrics.
The
API
was
stabled.
The
SDK
had
mixed,
especially
on
the
semantic
conventions,
because
you
need
to
define
a
lot
of
conventions
to
do
metrics,
there's
a
lot
of
different
types
of
information
that
you
want
to
collect,
and
that
takes
a
a
long
time
to
to
settle.
A
A
So
the
the
main
classes
on
tracing
opportunity
tracing
are
the
Tracer
provider
to
access
the
traces,
the
Tracer
that
creates
spans
and
spans
themselves,
and
also
the
systematic
conventions
that
are
specific
for
tracing
span.
On
a
span
like
on
open,
telemetry,
sorry,
open
tracing,
you
have
the
name
and
apparent,
so
you
can
correlate
different
spans
inside
the
center
face
and
you
have
a
context
you
can.
A
You
have
the
start
and
then
time
stamps
and
you
have
attributes
not
tags,
but
now
they
are
called
attributes
and
they
are
key
key
value
pairs
and
also
the
links
and
the
events
also
status.
But
links
and
events
are
not
widely
supported,
yet
that
they
are
fairly
new
features
and
they
are
not
yet
implemented
in
most
places.
A
So
microfile
Telemetry
Tracy
is
based
on
top
of
open
telemetry
and
it
wants
to
be
fully
compliant
with
open
television.
Traces
will
not
reinvent
the
its
API.
There
is
no
there's
no
feature
that
was
added
on
top
of
open
Telemetry
tracing
and
it
aims
to
provide
the
migration
path
out
of
microfile
open
tracing,
so
it
will
be
off
by
default
and
must
be
enabled
using
this
property.
A
A
A
So
for
the
migration
part,
I
can
tell
you
about
two
two
parts,
the
simple
one:
if
you
don't
use
any
manual
instrumentation
and
you
just
use
the
standard
out
of
the
box
instrumentation
that
comes
with
the
quarkus
previously,
with
a
smaller
open
tracing,
you
just
need
to
change
the
the
extension
you
remove.
The
the
old
one
and
you
are,
the
new
Quark
is
open
telemetry.
A
A
A
So
you
have
to
do
a
hard
migration,
so
you
can
do
these
manual
instrumentation
in
migration
in
three
steps,
so
replace
the
dependencies.
Remove
this
the
micro
profile
of
interesting
specific
features
and
replace
existing
and
then
you
can
replace
the
existing
Manual
of
interesting
instrumentation
and
then
remove
the
shield.
A
And
in
here,
I
I
can
show
you
a
very
simple
application.
This
has
a
resource
endpoint
and
it
stores
on
a
postgres
database,
an
entity
well
a
lot
of
legumes
here
and
that's
pretty
much
it.
This
resource
does
crud
but
I'm
going
to
focus
only
on
the
list,
which
is
the
simplest
method
in
here,
because
I
want
to
highlight
how
the
this
instrumentation
really
works
and
how
can
it
be
migrated
so,
on
the
side,
I
have
here
another
compose
running
with
a
postgres
database
and
a
Jaeger
with
an
open,
Telemetry
collector.
A
A
So
while
we
do
this,
I
have
an
endpoint
that
I
can
call
okay,
it
started
and
it's
it
just
loads
legumes
there's
nothing
on
database,
but
we
don't
care
what
it
returns
really
mainly
interested
in
the
choices.
So
so,
let's
double
check
that
then.
The
look
of
that
here
is
7
P.M
17
minutes.
So
this
Trace
is
okay.
A
A
And
this
thingy
now
uses
the
open,
telem2
Library,
okay
as
expected.
So
what
was
wrong
here
and
I
realized
it
now
is.
If
I
go
back,
see
this
huge
address,
sometimes
the
the
timestamp
stops
in
the
past.
So
unless
you
remember
to
actually
reload
the
whole
thing,
you
will
not
see
the
the
latest
ones
and
sometimes
well.
You
have
to
remember
that
okay,
so
let's
put
things
as
that,
they
were
before.
A
A
Use
the
I'm
using
the
old
Trace
annotation
from
my
profile
or
open
tracing
and
I,
get
the
Tracer
I
get
the
active
span
which
at
this
point
will
be
this
one
and
I'm
setting
an
additional
tag
on
it,
which
is
the
legume
resource.
The
the
name
of
the
class
also
I
create
yet
another
span
with
this.
Stressor
I
build
it
and
it
will
have
this
name.
A
A
A
The
second
one
comes
from
the
trace
annotation
and
it
has
the
elevation
like
in
resource
and
the
last
one
is
the
manual
instrumentation.
Has
the
manual
span
cool
so
now?
What
we
need
to
do
is
to
actually
change
this
for
the
new,
open,
Telemetry
and
the
shame.
So
we
need
to
start
by
changing
the
the
dependencies
here
on
the
palm,
but
I'm
going
to
show
you
something.
That's
will
cause
this
to
to
give
you
an
error.
A
So
if
I
do
this,
the
code
will
try
to
live
reload,
but
it
will
give
us
an
error
because
I'm
using
open
Telemetry
and
the
Legacy
small
variable
dressing,
so
quercus
complex
and
says
that
open
Telemetry
extension
Trace
cannot
be
used
in
conjunction
with
either
the
small
Royal,
contrasting
or
the
Jaeger
extension.
So
this
cannot
be
done.
That's
why
we
need
the
the
shim
to
provide
a
transition
layer.
A
And
wait
for
intelligent
reloads.
We
will
see
that
we
have
an
arrow
here
on
the
trace
because
it
because
it
doesn't
come
from
the
open
tracing
original
API.
It's
something
that
we
added
on
micro
profiles.
So
it
does
is
not
it's
not
part
of
the
ship,
but
everything
else.
The
open
tracing
API
is
part
of
the
ship,
so
it
doesn't
give
you
an
error.
A
A
A
A
A
Stack,
but
this
is
the
hybrid
because
it
will
be
an
open,
Telemetry
Span
in
there,
but
it
will
have
an
attribute
with
these
values
and
it
will
have
an
actual
open
tracing
open
Telemetry
span,
an
additional
one
but
created
with
by
the
shin
using
the
Legacy
API.
So
let's
see
how
it
goes
and
if
it
doesn't
fail
this
time.
A
A
A
A
A
A
So
symmetric
attributes
so
out
of
the
box,
you
have
this
huge
list
of
attributes
that
you
can
Define
on
spans
and
also
metrics,
and
this
is
very
important.
You
should
use
these
attributes
whenever
possible
because
they
are
standard
and
if
you
are
using,
let's
say
a
service
that
uses
Java
necessary
that
uses
Ruby
or
Python
and
so
on.
If
everyone
uses
same
attributes,
you
can
actually
generate
metrics
and
have
quality
indicators.
A
A
A
A
A
Okay
carcass
has
started
and
just
refresh
this
thingy
and
let's
see
if
we
get
another
three,
so
let
me
check
the
time.
37
sounds
good,
so
we
have
now
this
automatic,
instrumentation,
yeah
I
know
we
have
a
bucket
that
we
need
to
correct
because
we
need
more
information
about
which
route
on
the
HTTP
endpoint.
We
took
still
have
the
target
here,
but,
as
you
can
see,
there
are
many
more
things
that
we
are
setting
now
and
the
instrumentation
from
the
wheat
span.
A
So
this
is
pretty
much
how
you
in
multiple
steps
you
can
migrate
from
open
tracing
to
open
Telemetry,
and
sometimes
you,
if
you
are
just
using
the
annotations,
probably
you
can
do
it
on
a
big
bang,
but
if
you
have
lots
of
lots
of
code
with
this
manual
instrumentation,
it
kind
of
makes
sense
to
to
probably
use
the
shim
and
make
it
in
a
phased
way
Okay.
So,
let's
go
hit
the
presentation
again.
A
So
I
want
to
thank
especially
to
Emily
Young
from
without
her.
This
specification
wouldn't
ever
get
out.
So
I
want
to
also
thank
Yasmine
ome
Rudy
and
Roberto
Cortez
Felix
Wong,
Andrew,
Rose,
Dimitri,
alexandrov
and
Jan
westerkamp.
All
of
them
contributed
to
all
the
discussions,
the
code
from
the
specification
and
thank
you
for
to
them
and
to
everyone
that
contributed.