►
From YouTube: 2022-02-17 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
That
is
true:
yes,
yeah
the
instrumentation
I've
been
super
busy
with
other
stuff,
so
yeah,
the
instrumentation
repo
has
been
dormant
other
than
lor
laurie
is
still
fixing
all
of
our
sporadic
build
failure,
problems.
B
Yeah,
so
this
is
myself
and
some
colleagues
were
talking
about
some
edge
cases
of
views
and
what
the
behavior
should
be,
and
I
know
this
group,
and
maybe
john
in
particular,
will
help
prototype
views,
and
so
I
was
wondering
if
you
had
an
opinion
on
what
you
would
expect
to
happen
in
one
particular
scenario.
B
B
What
should
happen
when
you
know
you
create
two
counters
and
have
those
two
views
applied.
So
the
the
view
only.
B
So
that's
scenario:
one
there's:
I
have
a.
C
Second
scenario:
in
my
head:
25,
more
scenarios,
I'm
sure,
which
add
additional
complexity
as
you
go
all
right
this
I
thought
this
has
been
debated
in
the
metric
sig
so
a
while
ago.
I
want
to
say
like
in
august
or
something
okay
remind
me
description.
I
don't
think
is
part
of
the
identity
of
a
met
of
a
metric.
Is
it.
B
It's
being
it's
being
cleared
up
right
now
in
a
pr,
that's
not
merged
yet,
and
if
that
pr
were
to
merge,
it
would
be
part
of
the
identity.
So
I
think.
C
A
C
B
That's
what
I
would
expect
too,
and
so
the
the
second
scenario
I
think
makes
you
know
what
an
sdk
should
do
actually
a
bit
fuzzy
so
scenario,
two
same
selection
criteria,
you're
selecting
all
counters,
but
the
first
view
changes
the
description
and
the
second
view
applies
an
attribute
processor,
that
you
know
limits
you
to
attributes,
foo
and
bar,
and
so
those
views
are
compatible
with
another.
Should
we
merge
them
or.
C
C
C
That's
what
that's!
What
I
would
say
is
the
I
haven't
thought
through
all
the
corner
cases,
but
that's
kind
of
it
feels
like
that's
the
most
logical
if
you
change
the
identity
that
creates
a
new
stream.
If
you
don't
change
the
identity,
then
anything
that
has
identical
identity
should
be
able
in
general,
I
think,
to
be
merged.
B
B
That's
that
that's
that's
like
a
reasonable.
That's
a
reasonable
point
of
view.
I
think,
and
so
I
I
have
an
issue
open
to
get
this
clarified
at
the
spec
level,
because
it
impacts
the
behavior
that
we
do.
C
If
you
want,
if
you
don't
want
a
separate
stream,
don't
change
the
identity
and
then
I
think,
if
you
use
those
two
rules,
I
think
everything
should
compose.
I
mean
again,
you
might
end
up
with
one
of
the
streams
with
no
attributes.
If
you
the
way
you
define
things,
but
if
you
wanted
two
streams
each
for
each
of
those
attributes,
then
you
also
should
probably
add
something
to
change
the
identity,
change
the
description
slightly
or
change,
or
something
or
change
the
name
slightly
or
something
like
that.
Does
that
make
sense.
B
Yeah
yeah,
no,
it
does
so
part
of
the
context
of
how
this
question
arose
was.
I
have
a
pr
out
which
allows
you
to
load
it's
experimental,
but
it
allows
you
to
load,
file-based
view
configuration
and
so
joseth
commented
on
it
and
he
proposed
that
he
likes
this
idea,
because
you
know
it
would
give
library,
authors,
potentially
the
ability
to
specify
default
views
for
the
metrics
that
are
instrumented
by
their
library,
but
the
implication
of
of
this.
B
What
we're
talking
about
with
views
is
that
each
view
you
register
that
mutates
identity
results
in
a
new
metric
stream
being
exported.
So
it's
like
one
metric
in
is
many
out
potentially
many
out,
and
so
the
so
you
know
it's
not
a
good
use
case
for
what
josh
was
describing,
because
as
soon
as
a
library
registers,
its
own
views,
that's
going
to
interact
in
a
strange
way
with
any
views
that
the
user
registers.
C
C
B
But
doesn't
that
stop?
Let's
say
the
user
wants
to
all
of
a
sudden
turn
off
those
the
metrics
coming
from
that
library.
B
So
you
know
they
register
a
view
that
says,
switch
the
aggregation
for
these
instruments
to
be
the
drop
aggregation,
but
the
the
library
has
already
registered
its
default
views.
That
say,
you
know,
split
the
stream
into
stream,
one
and
stream.
Two
now
the
user's
you
know
request
to
drop.
Those
metrics
is
essentially
ignored.
C
Because
the
user
isn't
is
trying
to
drop
metrics
based
on
something
that,
like
a
misunderstanding
like
how
are
they
deciding?
How
are
they
deciding
to
drop
those
metrics
like
what?
Because,
if
I
would
see
they
would,
they
would
see
some
metrics
being
generated
in
their
back
end
or
logs
or
whatever
they're
like?
Oh,
I
want
to
get
rid
of
these
metric
streams.
They
would
have
the
name
they
would
have
the
identity
available
to
them.
At
that
point,
they
could
then
select
those
for
dropping,
maybe.
B
Yeah
yeah,
no
I'm
yeah.
I
get
that,
but
in
the
sdk
let's
say
they're
trying
to
configure
the
view,
which
is
to
say,
like
you
know
this,
this
metrics
too
expensive.
For
me,
it's
not
useful.
I
want
to
drop
this,
so
it's
not
possible
for
them
to
do
that.
If
the
library
has
already
configured
other
views
for
that
data,
because
those.
D
B
Yeah
exactly
there's
like
there,
there
might
be
like
an
implied
priority
and
that's
like
a
different
thing
than
what
we
talked
about.
First,
when
we
talked
about
first
we're
like
you
know,
if
two
views
select
the
same
instrument
and
change
the
identity,
you
get
two
streams,
but
arguably
a
different
behavior
would
be
that
views
have
a
priority
in
the
first
one
registered
that
selects
an
instrument
that
you're
talking
about.
That's
the
that's
the
stream
that
results.
C
B
I
think
so
too,
and
so
you're
kind
of
in
a
one
or
the
other
either
the
library
can
kind
of
register
its
default
views
and
kind
of
inform
the
user.
How
it
thinks
that
these
metrics
should
be
used
or
you've
retained
the
ability
for
a
user
to
take
like
a
single
stream
and
split
it.
C
C
Because
I
think
that
the
the
whole
automatic
like,
if
the
library
could
somehow
stick
it
into
the
class
path
and
have
it
automatically
be
picked
up
and
then
somehow
we
have
to
figure
out
how
to
merge
yeah
in
libraries
and
the
user's
configuration
into
one
final
configuration,
I
think,
we're
gonna,
it's
gonna
be
messy.
It's
gonna
take
some
time
to
figure
out
how
that
should
be
done.
B
Yeah
but
maybe
it's
possible,
so
you
know
they
publish
like
you
said
an
example
of
how
you
might
use
the
metrics
that
they
ins
that
they
provide.
But
you
know
it's
up
to
you
on
whether
you
want
to
use
that
configuration
and
decide
how
to
merge
that
with
the
views
that
you
want
to
apply
as
a
user
yeah.
C
A
Yeah,
I
think
how
we
were
hoping
to
use
this
from
the
instrumentation
side
is,
in
particular
the
cardinality
issue,
which
has
come
up
a
lot
where
we
would
like
to
capture.
A
C
So
in
the
agent
world
you
could
each
of
the
modules
that's
that's
emitting
metrics
could
have
a
yaml
fragment
embedded
with
it,
and
then
the
agent
could
be
responsible
for
taking
those
enamel,
fragments,
squashing
them
together
and
then
taking
the
user's
gamble
and
overlaying
it
on
that
right.
That's
one
possibility.
A
C
I
think
that
might
be
wiser
just
because
the
way
the
the
agent
is
having
to
take
so
many
disparate
sources
of
instrumentation
and
the
precedence
rules
for
those
even
within
the
agent
are
not
going
to
be
necessarily
simple
right,
like
you
might
have
some,
you
might
have
several
instrumentation
and
then
you
might
have
jetty
instrumentation.
Then
you
might
have
spark
java,
instrumentation
and
all
three
of
those
are
kind
of
working
together
and
you'll
need
to
have
a
coordinated
set
of
metrics
potentially
emitted
from
that
stuff.
B
Yeah,
I
think
that
makes
sense,
and
you
know
maybe
we'll
run
into
problems,
trying
to
figure
out
a
way
to
merge
those
those
yaml
blurbs
with
the
with
what
the
user
wants.
But
I
don't
know
it
seems
off
the
top
of
my
head.
It
seems
possible.
C
Yeah-
and
I
think
it
would
be
really
great,
especially
in
kind
of
a
controlled-
I
say
controlled
environment
like
the
agent.
I
mean
not
you're,
not
exposing
any
public
apis
at
that
point
yet
right,
so
we
could
maybe
sort
it
out
and
get
it
working
in
the
agent
world
where
things
are
probably
as
complicated
as
they
could
possibly
be,
and
then
take
the
learnings
from
that
and
build
an
auto
configure
module.
That
would
do
something
similar
made.
A
A
plus
one,
the
getting
lots
of
prototyping
feedback
experimenting
with
them.
Config
merging
in
my
experience
is
just
the
worst.
C
A
A
C
Yeah-
and
I
think
it
even
will
get
a
little
bit
more
hairy
if
I
want
to
like
the
there's
a
default
view
from
the
library,
but
I'm
like.
I
don't
want
that
many
buckets
in
my
histogram.
I
don't
want
13
buckets.
I
only
want
six
buckets
or
something
like
that
then
figuring
out
how
precedence
works.
They're
extra,
interesting.
B
Yeah
yeah,
I
think,
there's
a
lot
more
discussions
that
need
to
be
happen
at
at
the
spec
level,
but
you
know
I.
I
hope
that
they're
not
conversations
that
need
to
impede
stabilization
of
the
sdk
like
problems
we
can
solve
later.
I
just
want
to
make
sure
that
everyone
has
the
same
understanding
of
of
how
an
sdk
should
work
in
the
presence
of
multiple
views
that
select
the
same
instruments,
because
I
think
that's
an
important
thing
to
at
least
be
consistent
with.
A
I
see
so
views
are
part
of
this,
the
officially
part
of
the
sdk,
just
not
configuring
the
configurable,
the
non-code
config.
I
don't
know
the
config
file
yep
I
see
so
it
is.
It
is
something
that
has
to
be.
I
was
missing
that
piece
that
it
it
does
need
to
be
sorted
out
for
sdk
stabilization,
at
least
at
the
programmatic
layer
level.
B
And
you
know
what
we
do
in
the
presence
of
you
know.
Multiple
sources
of
views
arguably
influences
how
it
should
be
sorted
out
at
the
programmatic
level,
but
that's
that's
kind
of
what
we're
talking
about
here.
A
All
right
anybody
have
something
they
want
to
bring
up
chat
about.
E
Yeah,
I
have
a
probably
I'm
related
to
the
issue
hi.
This
is
this
is
emily,
so
I
kind
of
like
the
past.
We
talked
about
micro
profiles
consuming
open
television
metrics
today,
so
I
took
a
look
at
like
the
api
gi.
It
seems
it
has
chasing
and
also
matrix,
not
no
matrix,
open,
telemetry
choosing.
Sorry,
maybe
I
got
I
got
her,
so
the
api
has
all
the
tracing
and
metrics
apis.
E
So
isn't
there
any
gis?
Just
I
have
the
tracing
api.
Oh,
oh,
is
it
possible,
if
not
it's
possible
to
produce
the
jr
is
just
have
the
treating
only
so.
The
problem
is,
if
we
you
buy
a
consumer
one
and
but
we
don't
support
metrics
or
don't
support
logging.
So
that's
so
very
consuming
people
can
see
the
api,
but
that's
nothing.
E
A
E
C
E
A
E
Yes,
we
only
use
like,
for
example,
basically
use
a
choice,
creator
trees,
but
not
integrate
pulling
in
the
magics
aspect,
so
I
know
the
intention
to
gather
all
of
them.
However,
we
are
not
in
the
position
to
consume
all
of
them,
so
my
question
is:
is
possible.
D
E
To
create,
for
example,
the
the
this
basically
the
the
separate
api
idr,
for
example,
the
open
teleme
open,
telemetry
api
dash
chasing
open
telemetry.
Here,
that's
you
know
matrix.
So
it's
a
to
cater
for
the
requirements
that
only
use
like
the
portion
in
not
all
of
them.
C
E
Yeah,
so
my
question
is,
for
example:
is
it
are
they
interconnected,
so.
C
They
are,
although
that
could
be,
that
could
be
just
in
the
open
filter
api
that
ties
them
all
together
right,
although
right
now
that
thing
is
like
that
is
stable.
We
can't
go
and
undo
that
at
this
point
without
going
to
version
two,
so
the
opentology
api
jar
is
what
it
is,
and
it's
not
going
to
shrink
the
question
I
think
would
be:
could
we
produce
separate
artifacts
that
had
only
the
pieces
and
probably
no
global.
E
B
E
The
issue
is,
this
is
complicated.
The
issue
is
in
micro
profile.
We
have
our
own
matrix,
so
it's
a
this
is
very
I
mean
we
have
a
macro
profile
matrix
and
so
now
is,
though
we
go
to
auto
box.
We
go
to
like
pulling
in
adding
in
more
magics
from
the
open
telemetry
treating
so
I
think
yeah.
This
is
really
it
will
be
confusing.
E
So
I
think
the
cleaner
way
to
do
is
the
canon
gesture,
just
the
continuous
tracing
portion.
So
it's
a
but
at
least
the
tracing
portion
is
not
depending
on
the
matrix
apis
right.
C
B
A
Are
there,
but
these
would
have
completely
separate
packages
right?
Do.
C
C
E
Yeah,
so
that's
kind
of
that's
really
when
we
talk
about
metrics
is
that
the
team
is
kind
of
having
a
difficult
time
to
judge
like
at
the
moment
that
they
are
investigating
the
micrometers.
E
A
Yeah,
I
think
in
the
java
world
we're
in
a
tough
spot
in
because
in
the
in
other
languages,
in
open
telemetry,
as
john
was
mentioning
it's
a
very
explicit
effort
to
basically
provide
a
full.
A
You
know
tracing
metrics
and
logs
solution,
and
I
think
in
other
language,
but
in
java,
because
micrometer
is
such
a
strong,
pre-existing
metrics
solution,
we're
yeah
it's
a
little
bit
different,
so
I
think
we're
kind
of
torn
into
those
two
from
an
open,
telemetry
perspective.
I
think
we're
sort
of
the
guideline
the
it's
good
to
keep
to
kind
of
have
everything
tied
together
but
yeah.
I
can
see
this
being
difficult.
E
Yeah,
so
basically
it's
like
previously,
we
do
chasing
open,
treating
magic,
the
job
wizard.
Now
it's
like
we
want
to
move
like
open,
chasing
at
least
to
open,
telemetry,
treating
first
and
then
well.
The
micro
biometrics
can
catch
up
or
make
make
up
for
their
mind.
A
And
so
from
a
bridging
perspective,
so
we
have
today
the
a
bridge
from
micrometer
to
open
telemetry.
A
A
Okay,
I
see,
and
so
is
that,
are
you
deciding
on
microprofile
metrics,
whether
to
go
to
micrometer
off
of
drop
wizard.
E
A
A
And
so
one
nice
thing
about
going
to
open,
telemetry
metrics
is
that
users
can
still
use
this.
They
can
still
use
micrometer
api,
but
everything
goes
to
open
telemetry,
metrics.
E
Right,
I
see,
but
that's
from
different
entry.
So
that's
the
entry
is
directly
from
matrix.
Now
is
the
opposite.
Entry
now
is
a
kind
of
entry
is
from
twisting
right.
So
it's
basically
we
want
to
do
the
open,
telemetry
tracing
and
then
now
is
the
you
got
the
matrix
aspect
and
more
like
the
bridge
will
bridge
into
the
opposite
direction.
E
So
it's
a
four
micrometer
the
bridge
to
the
open
telemetry
matrix
for
this
potential
bridge
is
a
kind
of
bridge
opposite
direction,
from
open,
telemetry,
matrix
back
to
the
microprofile
job,
with
the
style
matrix
or
in
the
future.
There
will
be
a
microprofile
canon,
micrometers,
diabetes.
A
Yeah,
so
if
you
do
use
so
say
you
go
with
micrometer
metrics
and
can
then
it
comes
back
to
building
a
bridge
from
open,
telemetry
api.
So
if
the
open
telemetry
api
metrics
is
exposed
to
the
user
right
and
they
accidentally
or
they
see
it
and
they
want
to
use
it.
A
A
E
If
we
could
kind
of
hide
the
apis,
so
maybe
the
way
explore
whether
it's
possible
to
hide
the
apis.
So
it's
the
how
much
how
much
metrics
api
is
used
when
increased
tracing
api.
A
Right
so,
as
john
was
saying,
the
the
tracing
api
doesn't
use
the
metrics
api,
but
the
tracing
sdk
does
use
the
metrics
api.
E
It
could
work
if
the
if,
if
you
could,
if
that
open
telemetry
could
have
the
open,
telemetry
api
trees.
So
we
consume
this
one,
but
the
sdk
will
transitively
depend
on
the
whole
open,
telemetry
api.
So
that
might
be
a
solution.
E
E
So
basically,
it's
kind
of
the
exposed
open,
telemetry
api
trees,
so
the
other
one
is
the
inner
implementation
details,
not
a
user
facing.
B
Well,
I
think
we
have
to
go
and
evaluate
how
you
know
how
practically
possible
this
is,
and
then,
if
it
is
possible
whether
like
what
the
maintenance
burden
is,
I
don't
that's
not
immediately
obvious
to
me
so.
A
Yeah
we
can
follow
up,
discuss
with
honorag,
and
it
may
also
be
worth
looking
at
other
languages
if
they
have
bundled
everything
into
a
single
artifact
or
a
separate
artifacts.
A
E
A
D
D
So
that
would
mean
that
if
the
open,
telemetry
sdk
is
not
involved,
the
math
is
done
by
micrometer.
It
is
the
format
that
is
used.
D
So
if
you
have
a
backend
which
only
supports
otp
micrometer
should
support
it
in
the
next
minor
version.
A
Yeah,
how
about
at
the
api
level-
because
I
think
the
the
concern
here
is
that
users
have
two
different
apis,
that
they
can
use
either
micrometer
api
or
open,
telemetry
metrics
api,
and
we
have
a
bridge
from
micrometer
api
into
open,
telemetry
and-
and
you
also
have
this
coming
basically
bridge
from
micrometer
to
otlp.
A
D
So
when
you
are
using
open,
telemetry
is
an
api,
and
so
don't
you
have
a.
As
far
as
I
remember,
there
was
a
pr
for
this,
as
well
of
which
is
like
a
micrometer
registry
which
is
available
through
the
through
the
open,
parametry
api.
A
D
A
D
Maybe
yes,
I
guess
this
is
the
one
yeah.
A
So
yeah
so
emily
this
might
be
worth
looking
at
as
an
option.
So
at
the
time
I
think
we
were
more
interested
in
the
bridging
to
users,
we're
from
an
open,
telemetry
perspective,
we're
expecting
more
users.
You
know,
there's
a
huge
user
base
already
for
a
micrometer
api,
so
we
want
to
make
it
easy
for
those
users
to
use
open
telemetry.
A
So
that's
why
our
the
bridge
that
we
have
currently
is
in
that
direction,
but
this
was
a
prototype
of
bridging
in
the
reverse,
otel2
micrometer.
A
Which
would
potentially
solve
your
users
like,
if
you
could
add
this
direction
of
the
bridge,
then,
if
your
users
use
open,
telemetry
metric
api
metrics,
then
it
would
still
go
into
micrometer.
It
would
still
flow
into
micrometer
into
that.
Micrometer
would
be
sort
of
this
system
of
record
still.
E
Yeah
so,
however,
it's
you
know
it's
a
in
a
micro
profile
like
only
all
different
aspects,
if,
like
we,
do
open,
telemetry,
treating
and
immediately
slow
cuts,
and
they
all
get
metrics
and
if
they
have,
they
have
not
enabled
that
you
know
metrics
and
they
have
nowhere
to
go
so
because
the
fundamental
design
is
there
to
separate
now
is
a,
I
think,
is
in
order
to
do
all
this
bridging
and
to
merge
them
so
basically
the
kind
of
open
telemetry.
E
Basically,
we
have
to
say
because
at
the
moment
we
kind
of
say,
okay,
that
is
the
only
open,
telemetry
teaching.
If
we
immediately,
we
say:
oh,
oh,
okay,
even
though
you
said
that
you
want
to
chase
him.
Actually
you
also
got
magics.
So
you
see
what
I
mean
you
got
like
immediately.
I
didn't
see
my
I
need
the
matrix.
I
got
some
metrics.
E
Yes,
so
the
I
think
is
yeah,
it's
I
think.
Technically,
it
seems.
Okay
like
I
have
them
open
telemetry.
If
we
we
say:
okay,
we
want
matrix
as
well
as
the
tracing
and
this
bridge.
It
seems
okay
to
the
if
we
say
okay,
microprofile,
matrix
based
on
job
based
on
micrometer,
and
then
we
delegate
on
all
the
api
work.
E
So
you
you,
you
put
the
metrics
and
all
together.
If
we
say
okay
well,
I
only
want
a
teasing
and
then
no
matter
what
you
want
or
not.
You
got
matrix.
D
So
there
is
another
like
piece
of
information
I
can
give
for
this.
Like
oh
open,
telemetry,
micrometer
interoperability,
which
is
this
year,
we
are
planning
to
release
a
tracing
api
for
micrometer
and
that
tracing
api
is
basically
like
abstracts
of
ad
tracer
libraries.
D
So
if
you
are
using
that
api,
you
will
be
able
to
go
to
hotel
as
a
tracing
library
and
micrometer
is
a
metric
solution,
and
eventually
you
can
like
bridge
that
to
back
to
open
telemetry
or
you
can
just
use
the
otlp
registry.
E
D
So
I
believe
that
is
that
is
that
pr
that
you
can,
you
can
see,
or
you
are
saying
that
micrometer
implements
the
hotel
api.
E
D
D
So
we
would
like
to
keep
the
the
micrometer
api
and,
if
I
believe
what
you
are
saying
is
is
exactly
that
that
pr,
just
just
showed
a
minute
ago
that
that,
should
that
should
give
you
the
this
should
be
the
bridge
between,
like
you,
are
using
the
open,
telemetry
api
and
under
the
hood,
there
is
micrometer.
E
Right,
so
you
do
a
translation.
Basically
you
say:
okay,
if
I
use
this
magic,
the
gauge
that
translates
to
micrometer
api,
something
else,
and
then
you
get
a
data.
Is
that
what
you're
you're
trying
to
do.
D
I
I
don't
remember
if
it
is
like
a
translation
to
the
api
or
if
it
is
using
the
micrometer
registry,
under
the
hood
from
the
user
perspective
it
doesn't
it
doesn't
matter.
I
guess,
oh
okay,
because
then
you
just
see
that
they
are
using
the
open,
telemetry
api
and
the
data
ends
up
in
a
micrometer
registry.
E
A
Cool
yeah
so
go
ahead
and
open
the
issue.
So
we
have
it
tracked
and
we'll
discuss
in
this
evening's
meeting
with
onorag
and
john,
because
the
honorable,
john
and
jack
are
the
maintainers
of
the
the
api
and
sdk
repo.
So
they
they
have
to
accept
the
additional
maintenance,
work
and
maintenance
of
multiple
artifacts.
E
Okay,
yeah
I'm
yeah
right
here,
so
I
just
do
a
feature
request
right
because
it's
just
a
feature.
Yes,
yeah.
D
A
A
We
have
customers
who
are
wanting
already
to
implement
custom
metrics
using
the
open,
telemetry
apis,
and
I
mean
I
think
we
all
acknowledge
that
micrometer
is
going
to
be
around
for
a
long
time.
It's
not
going
anywhere,
but
we
do
have
customers
that
are
trying
to
use
the
apis
because
they,
I
I'm
guessing
that
they
feel
like
it's
more
vendor
neutral,
and
that
I
mean
for
whatever
reason.
A
D
B
B
More
vendor
neutral,
but
it
might
be
more,
it
is
more
language,
agnostic,
yeah,
good
point
too
yeah.
A
A
I
don't
think
they
have
a
preference,
okay
yeah,
because
they're
yeah,
because
they're
just
sending
to
splunk
exactly
yeah.
I
think
they
just
wanted
to
be
distracted.
E
Yeah,
I
think
that
that's
a
canoe
adjacent,
you
said
it's
a
print
amount.
What
I
have
heard
so
that's
why
I
asked
jonathan.
Do
you
plan
to
like
adopt
some
macrometer
api?
I
think
that
would
simplify
yeah
things
and
I
was
yeah.
Is
it
some
people
taught
me
and
they
really
want
to
use
the
standard
standard
apis.
D
I
believe
that
is
kind
of
the
same
situation
with
the
microprofile
matrix
x
back
as
well
right.
E
Yeah,
yes,
absolutely
so
when
you
run
into
the
single
thing,
so
isn't
it
now?
Is
it
kind
of
we
say?
Okay,
it
was
a
so
that's
why
in
the
open
telemetry
tracing,
we
are
not
going
to
reinvent
the
wheels.
So
we
wanted
directly
and
like
I
exposed
them,
the
open
telemetry
teaching,
but
when
the
team
discussed
macrometer
apis
immediately
a
lot
of
people
jumped
out
and
say
no,
no!
No!
So
don't
want
to
expose
that
because
not
not
standard.
So
so
that's.
E
Okay,
if
we
don't,
we
prefer
micro
profile
kind
of
apis,
because
it's
a
standard.
So
oh.
A
E
Metrics
api,
when
we
discuss
the
micrometer
adoption
and
that
a
lot
of
people
don't
want
to
like
expose
a
micrometer
api,
because
we
are
the
macro
profile
is
a
standard,
so
they
want
to
use
the
standard.
So.
A
D
It
is
not,
it
is
not
owned
by
such
a
such
an
organization,
but
like
the
vendor
neutrality
like
depends.
What
do
you
mean
by
that?
Because
micrometers
supports,
like
half
of
the
thirteen.