►
From YouTube: 2022-12-07 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
B
B
B
So
the
first
item
on
the
agenda
is
this
pull
request,
which
is
moving
all
the
DI
and
configurated
apis
into
a
new
package
and
also
updating
the
existing
extensions
hosting
and
SDK
package.
B
I
am
still
reviewing
it.
It's
but
I
think
this.
Should
this
looks
good
overall
to
me
and
I.
Think
Alan
has
also
been
reviewing
this
PR
and
once
this
gets
merged.
Hopefully,
in
the
coming
few
days
before
this
weekends,
we
can
have
an
RC
release
and
then
let
that
RC
release
stay
for
two
weeks,
so
I
think
yeah
I
mean
if
just
review
and
try
to
use
these
I
mean
review
these
this
PR
and
see.
If
anyone
has
any
questions
or
anything
stands
out.
B
B
Like
Ascent
like
previously,
we
were
having
two
different
metric,
two
different
extension
methods.
One
was
add,
open,
Telemetry,
metrics,
another
one
was
add,
open,
Telemetry
tracing,
so
I'm.
Just
trying
to
understand
like
how
different
things
are
now
like
previously,
a
user
could
have
had
could
have
configured
the
tracing
part
somewhere
in
the
file
and
then
used
add
open,
Telemetry
metrics
to
somewhere
else
altogether.
B
C
No,
you
can
call
it
as
many
times
as
you
want.
It'll
it'll
only
register
one
hosted
service,
and
if
you
look
at
the
XML
dot,
like
the
code
comments
on
all
of
those
extensions,
I
called
out
whether
or
not
it's
safe
to
be
called
multiple
times
whether
or
not
it's
safe
to
be
called
by
Library
authors.
It
was
kind
of
painful
to
do,
but
I
tried
to
document
all
of
that
with
the
codes.
B
Okay
yeah:
this
is
not
the
best
view,
of
course,
but
yeah
I.
D
B
I'm
still
going
through
the
pr
so
I,
just
I,
probably
haven't
seen
those
comments
yet,
but.
B
B
C
A
C
B
Okay,
so,
like
let's
say,
I
want
to
like
configure
tracing
so
I
will
just
have
this
part
right
and
then
later
on
somewhere
in
that
same
file,
I
could
I'll
have
to
do
add,
open,
Telemetry,
dot
with
metrics,
again
yep,
and
then
I
can
have
an
ad
open,
Telemetry
dot
start
with
host
yep.
Okay!
Okay,
if
you
want
all
right.
C
B
C
Anymore,
it
actually
ended
up
when
that
haulback
fires,
you're
gonna,
get
a
different
Builder.
It's
going
to
be
the
SDK
Builder.
The
first
one
is
going
to
be
one
of
the
base
classes.
It's
like
Tracer
provider,
Builder
base
or
meter
provider
Builder
base.
Those
are
also
in
SDK,
but
the
base
ones
do.
Is
they
just
dump
stuff
into
the
service
collection?
The
final
one
you
get
actually
is
configuring
the
state
that
we're
then
going
to
use
so
how
it
kind
of
evolved
and
ended
up?
Is
you
actually
do
get
a
different
Builder?
Now.
B
C
D
B
B
B
C
Go
so
you're
in
the
dependency
injection
package
there
go
to
SDK
right
there.
The
very
top
of
your
screen
is
kind
of
clipped
a
little
bit
that
one's
fine.
You
have
the
meter
provider
Builder
base.
If
you
look
at
the
Constructor.
B
C
So
what
the
base
Builder
does?
Is
it
registers
a
callback
so
that,
once
the
Builder
is
actually
starting
its
work?
It
clears
the
service
collection
so
that
if
anybody
tries
to
do
anything
else
on
that
Builder
they'll
get
exceptions.
So
this
line
right
here
is
trying
to
make
it
a
little
bit
safer
in
case
anyone
messes
up.
B
B
Okay,
yeah
I
mean
I'm
like
still
on
I'm
still
reviewing
it.
I
think
it
looks
good
to
me.
I
see,
Alan
has
also
joined,
and
we
were
just
discussing
before
you
joined
that,
like
once
this
PR
gets
merged.
We
can
have
an
RC
release,
hopefully
before
this
before
the
end
of
this
week,
and
then
let
that
RC
stand
forward
two
weeks
before
we
do
this
table.
E
B
Yeah
I
also
noticed
that
you
had
a
comment
about
removing
the
deciding
whether
we
need
to
remove
the
older
extensions
hosting
apis
before
the
stable
or
not.
E
Yeah
I
think
we've
discussed.
There
is
at
least
it's
my
opinion.
I
think
Mike.
This
is
I.
Think
you're
open
to
this
too,
which
is
a
number
of
methods
have
been
marked
Obsolete
and
we
would
ship
stable.
E
E
E
B
Yeah
I
think
we
can
also
ask
Martin
if,
if
like
I,
think
because
he
represents
that
user
base
to
us.
So
if
there
is
any
like
we
I
would
also
like
want
like
I
would
be
in
favor
of
removing
these
apis
before
this
table.
For
sure,
should
we
do
it
right
away
for
the
next
RC
I
I
think
we
can
but
like
yeah?
Yes,
because
that
will
make
people
use
force
them
to
use
the
new
ones
which
we
eventually
want
that
to
happen.
E
No
worries
we
were
just
talking
about
there
that
there's
been
a
number
of
methods
that
have
been
marked
obsolete
in
the
hosting
package
and
I
just
posed
the
question
that
when
we
do
the
next
release,
what
if
we
were
to
just
instead
of
obsoleting
the
methods
just
straight
up,
delete
them,
because
we
we
would
like
to
do
that
eventually.
Anyways.
F
E
F
So
how
much
of
a
refactor
would
it
be
for
people?
Is
it
pretty.
B
So
it
used
to
be
these
two
methods:
I
mean
them
obsolete
still
there,
but
this
is
the
new
API
that
is
being
proposed.
This
new
way
of
setup.
F
F
So
the
the
question
from
an
implementer's
perspective
would
be:
is
the
risk
in
doing
it?
How
does
it
change
my
my
stuff?
F
F
B
C
E
But
if
we're,
if
we're
only
talking
like
just
a
few
weeks,
then
I
kind
of
suspect
that
we
we'd
miss
a
lot
of
people.
People
would
end
up
just
you
know,
having
to
their
first
realization
that
the
API
is
totally
changed.
Is
you
know
adopting
the
major
release.
B
No,
we
we
would
be
doing
it
post
1.4
stable,
so
we
expect
1.4
stable
to
be
released
by
The
before
the
end
of
this
year,
so
hopefully
by
end
of
December.
So
we
plan
to
do
an
RC
version
release
this
week.
Once
this
PR
is
merged,
then
let
that
RC
be
out
there
for
like
two
weeks
and
then
do
a
stable
release.
And
after
that
we
work
on
stabilizing
the
extensions
hosting
package.
F
So
if
I've
gone
and
upgraded,
the
SDK
package
to
1.4
and
I've
still
got
the
old
hosting
package
which
it
hasn't
been
marked
as
obsolete,
because
I've
not
had
to
upgrade
it.
F
So
I'm
just
trying
to
work
you
through
in
my
head
what
I
do
as
a
running
the
upgrade,
because
I
would
do
T
net
ad
package
open
telemetry?
F
B
Our
next
another
RC
of
extension
hosting
for
sure
oh
yeah,.
E
And
that
that's
where
these
obsolete
methods
come
in
is
that
we're?
You
know
there
would
be
a
new
version
of
hosting
it
would
have
a
number
of
methods
that
were
previously
used,
marked
obsolete
in
hopes
that
that
would
allow
people
to
want
to
see
that
get
the
compiler
warnings
and
then
make
the
migration
prior
to
the
stable
release
of
Hosting.
C
F
Yeah
I
mean
if
we're:
if
we're
talking
about
stable
hosting
package,
I'd,
say
even
up
to
the
end
of
January
I,
don't
think
they
there's
a
interim
step
is
worth
it.
F
If
it
literally
just
enables
the
background
task
s.
E
F
That's
what
I
thought
we
were
doing,
you
know
it
was
meant
to
be
incredibly
tiny
and
we
are
part
of
the
move
into
SDK
was
around
making
that
really
tiny.
B
I
guess
we
could
do
that
I
think
we
just
thought
that
it'd
be
good
to
have
it
out
there
for
more
time
for
people
to
test
things
and
Report
issues.
But
if.
D
A
C
Just
throwing
out
here
that
there
are
some
other
methods
that
were
obsoleted
in
previous
pull
requests
there's.
So
today
we
have
configure
services
and
configure
Builder.
Previously
those
existed
as
different
things
in
hosting
there
was
just
configure
which
became
configure
services
I,
take
that
back,
configure
was
configured
Builder
and
then
configure.
Services
is
a
method
called
link
get
services,
so
the
two
old
ones
are
there
marked
as
Obsolete
and
they
shim
into
the
new
versions.
C
C
Pretty
sure
they
were
in
one
three:
yes,
so
how
it
used
to
work
is
we've
always
actually
had
support
for
all
of
this
dependency
injection
stuff.
It
just
lived
in
hosting,
and
you
needed
those
two
methods
to
do
it,
and
now
we
put
it
all
in
SDK
and
this
new
package
and
in
doing
that,
I
renamed
a
little
bit
of
it.
So
it's
a
little
more
consistent
and
clearer.
So
most
of
it
is
gone
from
hosting
I
just
left
those
two
methods
because
they
were
renamed
to
give
people
kind
of
a
migration.
C
So
if
you
upgrade
your
old
code
to
the
new
code,
it
will
still
compile
and
work
you'll
just
get
warnings
that
those
methods
are
now
Obsolete
and
it
tells
you
the
new
ones,
to
use
just
as
kind
of
a
friendly
migration.
We
remove
them
completely.
It'll,
just
get
a
compile,
break
and
they'll
have
to
go
figure
out
what
to
do.
F
Yeah
I
think
my
point
is:
if
we've
got
a
four
week,
you
know
four
or
five.
You
know
four
four
to
six
week:
Gap
I,
don't
think
it's
worth
it
I
think
you
will
miss
a
lot
of
people
and
the
main
people
who
would
be
worried
about
because
anybody
who's
adopting
quickly
will
come
to
the
repository
anyway
and
find
that
oh
we've
changed
stuff,
great
okay,
here's
the
new
way
of
doing
it.
F
Anybody
who's
outside
of
the
four
to
six
week
window.
They
wouldn't
what
am
I
trying
to
say
the
people
inside
the
four
to
six
week
window
that
would
see
the
obsolete.
Are
the
people
who'd
be
able
to
find
the
the
upgrade
path
really
easily
anyway,
the
people
outside
of
the
forza
six-week
window
that
were
saying
that
wouldn't
get
it
because
we'd
be
deleting
the
obsolete
methods.
C
The
one
thing,
the
one
thing
that
would
be
kind
of
nice.
If
we
do
release
an
interim
package
with
the
obsoletes.
Let's
say
we
release
one
for
stable
and
people
go
to
upgrade
and
their
builds
break.
They
don't
know
what
to
do
or
they're
complaining
like.
Let's
say
we
get
an
issue.
That's
I
want
to
use
up
down
counter
right
now.
I,
don't
want
to
update
my
starting
code
right
now,
like.
C
C
C
So
basically,
what
we're
looking
at
doing
is
if
we
merge
this
PR,
we
can
just
run.
You
know
all
the
CI
that
we
have
in
place.
That'll
put
out
the
RCs,
that's
kind
of
easy
to
do
and
then,
when
we
go
to
do
stable,
we
have
to
do
another
PR
anyway.
That
does
like
some
book
cleaning
and
you
know,
moves
things
to
the
ship
files.
At
that
point,
we
could
go
and
just
remove
these
methods.
It's
not
a
whole
lot
of
extra
effort
to
push
out,
but
the
interim
package
I,
don't
think
I.
A
B
No,
it's,
it
means
just
about
pushing
attack
and
then
extension
hosting
will
also
have
a
release.
F
F
If
we're
making
that
recommendation,
I
think
we
need
that
in
a
ticket
somewhere
as
a
when
we
go
stable,
you
can
use
this
old
RC
package
to
get
yourself
back
if
you
want
so
I
think
that
needs
to
exist
somewhere.
If,
if
that's
one
of
the
things
that
we're
talking
about,
we
need
somewhere
to
point
people
on
the
issues.
F
C
Do
you
think
it
would
be
in
so
if
we
do
a
PR
to
remove
these
methods,
there'll
be
a
change
log
note:
could
we
just
link
back
to
the
pr
and
then
have
something
on
the
description
saying
like
hey?
If
you
need
the
old
API
use
this
package,
or
do
you
think
it
should
be
like
a
blog
or
something
no.
F
No
I
mean
that
that
would
be
enough
for
literally
if
we
get
people
raising
tickets
saying
this
is
broken,
that
you
can
literally
put
in
hash
four
seven,
three,
five
or
whatever.
It
is
sorry,
three,
nine
two
one
three
and
have
the
link
and
then
the
top
of
that
PR
says:
if
you
need
these
old
apis,
whatever
it
is
for
the
the
obsolete
one.
F
If
you
need
these
old
apis,
you
can
use
the
old
RC,
but
we're
removing
them.
So
we
can
link
in
an
issue
to
the
pr
that
remove
them
completely.
F
F
D
Because
one
I
mean
I
agree
with,
like
basically
everything
Martin
said
I,
just
I
feel
like
if,
if
like,
when
people
do
have
to
do
that,
downgrade
or
whatever
they're
like
jumping
like
multiple
minor
versions
and
stuff,
it
might
raise
more
questions
in
the
sort
so
I
mean
in
my
mind
they
should
be
the
same
version,
because
why
wouldn't
they
be?
But
I
don't
know
if
that
raises
a
different
concern.
F
What
do
we
do
with
the
ex
calls
and
the
the
exporters
that
stable
at
the
moment.
E
E
You
know
RC
or
beta
of
of
Prometheus,
so
we
probably
should
have
done
something
similar
like
that
with
hosting
and
had
we,
we
would
of
course,
opt
for
keeping
it
on
lockstep
I.
Think
that
we,
just
you,
know,
bite
the
bullet
and
bring
the
hosting
package
into
alignment
just
like
we
did
with.
G
E
A
E
F
E
F
If
that
wasn't
maintained
by
yours,
I
think
is
what
I'm
trying
to
say
there
I
think
what
I'm
saying
is
everything
inside
the
open,
Telemetry
hyphen.net
repo
should
be
version
the
same
because
it's
maintained
the
same,
so
it
kind
of
has
the
same.
Reverence
of
a
everything
inside
of
that
is
fine,
is
ready
to
send
that
list,
or
is
that
in
contrary,
right,
yeah,
so
yeah?
If
it's
in
contrib,
then
there's
this
idea
that
contrib
is
not
quite
as
up
to
standard
as
the
rest
of
the
stuff.
E
Yeah
I
think
the
lines
are
kind
of
blurry
I,
don't
know.
I,
don't
have
strong
opinions
on
this,
but
I
think
the
lines
are
definitely
blurry.
Like
the
the
I
know,
the
runtime
instrumentation
that
we
have
in
the
contributory
bow
is
I
mean
heck.
It's
the
only
it's
the
only
instrumentation
that
is
actually
has
a
stable
version.
Today,
it's
like
the
most
legit
instrumentation.
We
have
in
some
sense.
F
A
It
for
the
RC
release,
yeah.
A
B
Cool
so
I
think
this
PR
looks
good,
we'll
get
it
much
today
itself
and
then
I
can
mark
the
extensions
hosting
package
code
and
start
working
on
the
RC
release.
B
Cool
I
think
you
can
move
to
the
next
topic.
Then,
if.
F
A
E
No,
we
haven't
I
didn't
know
if
you
wanted
to
continue
to
discuss
it
or
if
you
know
see
Joe
chimed
in
on
that
thread
and
basically
gave
some
assurances
that
this
has
happened
before
and
that
the
Azure
functions
team
will
eventually
do
the
thing
that
will
not
just
fix
us,
but
you
know,
fix
diagnostic
Source
version.
Seven
in
general
for
the
Azure
functions
in
process
model.
F
So
what
I
suppose?
What
is
Our
advice
to
users
as
of
right
now,
because,
as
we
release
this,
anybody
using
Azure
functions
or
more
specifically,
I,
have
a
client
outside
of
honeycomb
that
I
work
with
that
has
shared
libraries
that
work
across
Azure
functions
and
ASP
net
core
sites.
F
B
B
F
I
mean
they're
using
improv
functions
because
it's
harder
to
change
onto
out
of
proc
stuff
but
yeah.
That's
not
that's
a
non-trivial
change
to
move
on
to
our
proc.
F
Yeah
I
mean
it's
been
the
option
to
fix
diagnostic
source
for
the
last
12
months,
everybody
going
oh
just
moved
to
out
of
process
like
yeah.
It's
not
that
easy,
and
it's
not
as
fast.
B
F
Oh
yeah
I
mean
that.
Well,
we
need
a
link
to
that,
because
people
are
going
to
be
coming
to
us
and
saying
I
can't
use
1.4.
It's
failing
in
functions,
they're
not
going
to
go
to
functions
and
say
functions.
What
are
you
doing
wrong
they're
going
to
be
coming
towards
and
saying,
as
your
functions
doesn't
work
with
1.4.
B
E
E
Yeah,
this
is
the
repo
that
I
actually
ultimately
found
I
didn't
know
where
to
look
originally
for
where
you
know
where
the
appropriate
repository
is,
but
I
found
an
issue.
Four
Diagnostics
or
seven
in
this
Azure
functions
host
already
opened.
Somebody
else.
G
E
It
I.
B
E
F
E
E
E
F
F
E
F
F
So,
in
a
year's
time
it
won't
be
an
issue
anyway,
because
they're
not
going
to
be
fixing
all
this
crap,
but
we
need
a
story
and
we
need
something
solid
if
we're
saying
that
there
are
bugs
in
1.3
and
we're
excluding
an
entire
subset
of
users
for
a
year
to
say
sorry,
you
can't
have
any
of
the
bug
fixes
in
1.4
or
1.5
or
any
of
the
other
versions
that
we
had
next
year.
You
can't
have
any
of
those.
F
And
that
that's
my
worry,
you
know:
we've
used
the
the
new
apis
in
seven
we've
used,
we've
added
the
off-down
counter,
so
it's
not
an
easy
thing
to
fix.
F
Yeah
but
I'm
more
meaning
that
we've
got
other
bug
fixes.
What
I
was
saying
is
that,
because
we've
added
up
down
counter
into
1.4
or
the
ability
to
export
it
and
we've
used
the
new
faster
access
apis,
it
would
be
non-trivial
for
us
to
remove
those
and
depend
on
sex,
very
non-trivial.
F
E
E
Think
there's
other
things,
though,
that,
like
you
know,
I've
only
recently
started
playing
with
functions
and
and
open
Telemetry,
Azure
functions
and
I'm
I
mean
this
bug
aside,
like
I,
it's
kind
of
rough,
in
my
opinion,
like
I,
was
playing
with
with
in
process
versus
out
of
process
and
and
the
interesting
thing
about
in
process
which
sounds
like
it's
going
away
is
that
it
actually
invokes
our
asp.net
core
instrumentation.
E
So
so
folks
folks
get
things
out
of
the
box.
But
if
you
go
to
the
out
of
process
model,
it
does
not
invoke
our
ASP
Nightcore
instrumentation,
so
it
effectively
just
relies
on
folks
today,
at
least
to
to
instrument
things
on
their
own,
which
might.
A
E
Okay,
but
for
folks
making
that
migration,
you
know,
if
that's
a
thing
that
is
expected
to
happen
over
the
next
year,
it
might
be,
it
might
be
kind
of
surprising.
F
I
have
a
middleware
things
that
I'm
either
going
to
contribute
or
I'm
going
to
try
and
bring
into
call,
because
I
think
it
is
a
pretty
a
pretty
cool
thing,
but
yeah
I
have
a
middleware
package
that
would
do
exactly
that
because
they
needed
it
so
I
built
it.
E
Very
cool
yeah,
so
so
yeah.
The
functions
has
like
the
a
middleware
kind
of
like
architecture.
A
F
Pretty
much
exactly
the
same
as
ASB
Network,
but
they
SDK
team
are
also
building
diagnostic
Source
into
the
activity
saw
stuff
into
the
function
of
stuff
is
just
taking
ages.
F
So
I've
been
talking
to
somebody
on
the
SDK
team
about
exactly
that.
They're
working
through
the
sdks.
Apparently
they
thought
all
of
the
Azure
sdks
were
up
to
scratch
and
yeah
I've
been
pointing
them
in
the
direction
of
the
ones
that
really
aren't.
So
that
will
be
one
of
them.
F
But
yeah
that
whole
thing-
and
this
is
where
that
performance
stuff
that
I've
been
doing
is
coming
out
of
as
well
tracing,
adds
some
problems,
even
if
you
don't
listen
to
it
and
as
your
functions
is
supposed
to
be
fast
because
it
costs
if
it's
slow,
so
performance
is
a
concern
anyway,
out
of
proc
isn't
really
a
problem
because
we
can
make
it
work
well,
yeah,
we're,
probably
gonna,
have
to
play
some
kind
of
article
out
about
the
Azure
function,
stuff
to
say
sorry,
no,
it's
an
Azure
functions
issue.
E
F
I
mean
if
you
can't
find
that
I
know
enough
people
that
I
could
probably
find
out,
but
I
think
we
do
need
to
put
some
pressure
on,
because
it's
a
how
do
we
make
our
rocket
a
hard
place,
not
a
rock
and
a
hard
place?
Well,
if
Azure
functions
just
do
their
upgrade,
which
they
need
to
do
anyway
to
to
get
up
down
counters
outside
of
our
stuff,
then
yeah.
F
E
B
F
I
want
to
slow
ramp
down
I'm
supposed
to
not
be
working
at
all
throughout
the
entire
December,
so
I've
been
given
my
marching
orders
that
I
achieved
burnouts
and
needs
to
stop
working,
but
I
can
do
it.
I
can
open
the
discussion
inspired.
Oh.
F
B
Yeah
I
know
like
it
is
an
important
discussion,
I
think.
Even
we
have
seen
some
internal
complaints
about
hotel
1.4,
not
working
on
functions,
so
jump.
B
Okay,
I
guess
we
can
move.
We
have
four
more
minutes.
This
I
added
these
two
PRS
I
see
the
two
other
PRS
have
been
added.
This
one
is
by
our
first
time,
contributor,
I,
think
so.
I
guess
I
think
we
should
review
it
and
get
this
merged
soon.
Mostly,
it's
ready.
G
B
I
will
also
review
it,
but
just
asking
everyone
to
do
that
if
they
can,
and
this
one
has
been
out
there
for
some
time.
This
is
a
simple
bug
fix
where
console
console
activity.
Exporter
would
have
found
an
exception
if
there
were
no
tags
for
the
for
an
activity,
link
and
yeah.
B
Doesn't
I
mean
it's
console
exporter?
It
doesn't
matter
if
it
gets
in
the
next
RC
or
not.
We
can
wait
like
it's
all
sorts
of
very,
very,
very
particular
condition
where
it
will
fail.
So
it's
I
mean
yeah,
it's
not
needed
for
RC,
but
for
the
other
one
again,
that's
instrumentation
library,
right,
I
think
this
one
we
could
get
in
for
the
next
RC.
B
B
G
Yeah,
so
those
two
I
just
added
them
just
to
get
some
feedback
on
any
particular
way.
Folks
prefer
here
like
for
the
the
way
we
are
subscribing
to
diagnostic
Source
events
for
the
metrics,
so
I'm,
trying
to
add
the
the
second
metric
for
asp.net
core,
which
is
the
active
request,
one.
It's
an
updown
counter.
G
Currently,
the
the
pattern
that
we
have
is
like.
We,
we
just
create
a
a
new
subscriber
for
for
the
metric
and
for
traces
like
we
have
another
one.
So
there
are
two
ways
we
could
do.
This
is
like
create
one
subscriber
for
each
metric
that
we
have
and
just
handle
the
callbacks
separately.
The
other
part
is
just
like
merge
it
into
the
the
already
existing
metric,
which
is
the
HTTP
server
duration
and
just
like
record
the
details
in
the
same
place.
G
So
if,
if
we
have
any
particular
preference,
we'll
just
close
another
one
and
move
with
the
the
one
that
people
prefer
here,.
B
E
I
was
just
curious,
pretty
sure
what
your
preference
was.
What
are
the
benefits
of
one
over
the
other,
so.
G
Yeah
so
like
it's
more
more,
the
benefit
is
most
mostly
on
the
readability
part
of
the
code.
It's
just
easier
to
to
manage
if
we
have
working
with
different
subscribers
other
than
that,
it's
not
really
any
like
any
any
puff
or
anything
like
that.
There's
no
such
benefit
of
one
over
another
and
also
like.
G
Since
we
are
also
adding
more
options,
it
will
be
easier
to
manage
at
two
different
places
so
like
we
have
filter
and
enrich
yeah,
we'll
have
to
do
multiple
callbacks
in
the
single
place
for
each
of
the
metrics
that
we
are
doing
again.
It's
it's
not
really
like
any
puff
issue,
but
like
something
that
if
we
have
to
manage
it
will
be
here
to
do
it
at
separate
places.
B
G
No
I'm
creating
a
new
one:
oh
okay,
yeah,
because
maybe
I
should
be
able
to
use
reuse
the
actually,
no
because,
because
of
the
enriched
part
where
we
are
passing
the
tags
as
a
reference
so
like.
If.
B
E
Seems
like
that
sure,
when,
when
we
originally
put
in
the
metric
instrumentation,
you
know
and
we
ended
up
using
a
listener
and
they're
just
like
we
do
with
the
trace,
instrumentation
I,
remember,
I
vaguely,
remember,
see
Joe
raising
a
a
question
of
whether
the
more
antlers
we
introduce
it.
That
would
cause
something
like
negative
perf
I
think
he
was
it
was
based.
His
question
was
based
off
of
some
experience
that
he'd
had
where,
maybe
maybe
it
was
like
a
ridiculous
number
of
handlers
caused.
E
Degradation
and
perf,
but
I
think
I
did
some
like
so
long
ago.
I
think
I
did
some
some
perf
tests
between
the
two
and
just.
A
G
Yes,
that's
what
my
understanding
them
most
buff
comes
from
actually
creating
the
payload,
and
that
will
happen
irrespective
of
the
fact
that
if
we
have
one
or
two
writing
is
usually
faster
but
again,
I
have
not
done
any
benchmarking.
To
prove
that
I
can
probably
like
try
to
do
that
see
if
I
can
notice
some
and.
B
I
I
mean
I,
haven't
looked
at
the
code
but
I
when
I
preferred
this.
One
I
also
hope
that
there
would
be
some
things
which
could
be
extracted
out
like
some
common
logic
for
like
both
these
metrics,
so
that
yeah.
Yes,
we
work
to
do
but
I
yeah
I'll
have
to
look
at
this
again,
considering
how
enrich
and
filter
will
also
apply.
G
Yeah
sure
it's
it's
not
something
that
we
have
to
get
right
away.
We
can
do
it
for
the
next
release
as
well.
Yeah,
just
one
more
metric
for
customers
to
use
so.
A
B
All
right,
then,
they're
already
five
minutes
overdue.
B
Six
minutes
already
enough
so
yeah.
Thank
you.
Everyone
I'll
work
on
these
things
like
making
the
package
code
where
you
have
this
merged
soon
and
get
the
get
working
on
the
RC
version.
Release.