►
From YouTube: 2023-03-30 meeting
Description
Instrumentation: Messaging
C
Oh
yeah
always
yeah.
C
B
C
B
B
C
They
are
looking
for
maintainers
I.
Think
now
spot
this
step
in
as
maintainers.
C
B
B
C
Oh
yeah,
this
build
tools,
repo.
D
C
See
that's
yeah
I
think
people
are
looking
at
their
their
DC
or
something
I'll
stuck
with
Armin,
and
he
he
was
yeah
updating
me
on
or
us
in
that
I
think
they
are
looking
for
more
people
to
maintain
the
or
step
step
up
as
maintainers
for
the
build
tools,
repo.
C
It
will
require
I
guess
some
some
effort
there.
D
Okay,
I
think
we
can
get
started
or
one
thing
Amir
reached
out
to
me
yesterday
and
he
hasn't
shown
up
for
a
time
and
he
said
that
his
company
aspective
was
acquired
by
another
company.
I,
think
smart
bear
it's
called
and
he
said
yeah.
Basically,
he
they
choose
not
to
kind
of
change.
Robot
to
Smart
bear
so
he's
kind
of
funds
a
bit
of
a
sabbatical
now
and
he
will
look
for
something
new,
then
and
I
told
him.
Yeah
he's
still
invited
to
join
our
group
whenever
he
wants
so
yeah.
D
Let's
see,
he
definitely
says
that
he
he's
looking
for
some
work
in
the
basically
where
he
can
continue
working
in
the
hotel
space
and
also
in
the
long
run,
continue
contributing
to
this
group.
But
yeah.
Let's
see,
let's
see
foreign.
D
D
C
I
heard
I
heard
something
about
the
links,
I
think
the
disgusting,
the
maintainers
materials
back
meeting,
not
sure,
but
as
I
heard
from
army
that
apparently
the
goal
folks
are
not
so
much
against
it
anymore.
Some
I
think
they
maybe
will
put
some
some
some
prototype
or
some
proposal,
so
maybe
the
original
original
option
of
allowing
adding
after
creation,
maybe
that
that
will
will
be.
D
D
Some
discussion
been
on
this
one
that
the
Duane
took
over
and
or
deductible
some
discussion
on
this
one
I
think
I
didn't
get
to
change
the
spec
meeting,
but
on
Tuesday,
but
I
think
this
was
brought
up
during
the
spec
meeting
and
for
for
this
one
with
Miller
I'm,
not
sure
if
you
want
to
kick
us
off
on
this
today,
the
metric
stuff,
yep,
awesome
and
also
here
your
personal
discussion
on
the
on
the
issue.
D
B
Yeah
so
like
the
con,
like
the
concern
there
was
that
backhands
might
be
broken
because
of
the
invalid
context
on
links.
This
is
something
they
don't
expect,
but
there
is
a
similar
problem
of
context
where,
for
example,
AWS
Samsung,
ID
and
some
cases,
and
essentially
the
consensus,
was
that
it's
okay
to
put
invalid
context
into
anything.
B
But
since
some
back-ends
could
be
broken,
asked
us
to
find
the
reasonable
way
to
turn
it
off.
So
it
can
be
a
Sprint
processor.
It
can
be
a
hook
in
the
SDK
or
something,
but
we
need
to
make
sure
it's.
It
can
be
turned
off
before
we
can
hit
it
in
this
back
and
I'm
going
to
look
into
this
and
just
come
up
with
some
proposal.
C
C
I
was
going
to
ask
what
would
exactly
be
a
consider
invalid,
Spain
context
that
would
be
added.
D
B
Yeah,
so
when
we
extract
context
it
gives
a
default
thing
which
is
in
valid
context.
Well,
it
depends
I
think
it
depends
on
the
language,
but
okay
in
Java
it's
indistinguishable.
If
there
was
no
context
there,
there
was
an
invalid
context
and
I
think
it's
a
question
of
propagator
implementation.
So
if
AWS
implements
a
propagator
that
returns
a
trace,
ID
and
Nostrand
ID,
then
it
will
be
in
the
context.
E
There's
one
exception
that
we
didn't
talk
much
about
in
that
regard,
which
was
the
one
Anthony
Mirabella
from
Amazon
mentioned,
which
was
that
Spanish
is
actually
all
zeros,
but
Trace
ID
is
actually
a
valid
one,
which
is
kind
of
a
corner
case,
and
he
said
that
it
could
still
be
useful,
which
is
weird
to
me,
but
I
guess
that
could
be
useful
for
some
people.
B
D
For
pushing
for
pushing
this
and
yeah
that
those
are
basically
the
issues
that
are
currently
assigned
to
folks
and
that
are
in
progress
more
or
less
the
others,
one
other
ones
are
still
waiting,
as
you
are.
Turning
back
to
dejao
I
wondered
whether
this
one,
the
better
group
but
of
this
one
I,
could
assign
to
you.
D
D
Might
be
great
also
for
this
one
that,
for
example,
we
get
some
recipe
or
how
this
span
structure
that
we
currently
come
up
with
for
messaging,
like
in
in
the
old
tab,
how
that
would
integrate
with
the
card
events,
because
I'm
loading,
a
bobspan
structure
too
so
I
think
it's
great
to
see
how
that
fits
together.
D
Sure
we
can,
let's,
we
can
go
ahead
with
that.
Only
only
for
the
time
planning
today,
I
would
like
to
reserve
then
the
last
30
minutes
for
Ludmila
to
kick
us
off
his
metrics.
So
we
have
your
50
minutes
left
to
go
over
issues.
Let's
start
with
your
yours.
Doing
I
would,
if
time
is
left.
I
would
also
love
to
talk
about
the
consumer
d.
But
let's
start
with
the
cube
versus
topic.
A
So
his
basic
feedback
there
was
he's
just
basically
please
use
keyword,
topic
and
I
I.
Think
it's
a
valid
point.
You
know
it's.
It's
they're,
widely
used
and
and
well
understood,
I
think
he
doesn't
attend
the
meeting.
I
guess
he's
not
speaking
for
himself
here,
but
he
would
prefer
these
terms.
I
I
personally,
don't
have
a
problem
with
terms
q
and
topic.
I
find
they're,
they're,
well
defined
or
well
understood,
but
can
I
get
a?
Does
anyone
have
I
guess
there
were
objections
to
that?
A
A
Yeah,
so
if
the
description
I
provided
like
I,
provided
a
proposal
of
what
I
would
just
like
the
explanation
like
so
so,
Pub
sub
is
the
equivalent
of
topic,
so
whether
we
use
Pub
sub
or
topic,
but
the
the
definition
would
be
that
it's
you
know
published
using
a
publish,
subscribe
pattern
which
results
in
many
consumers
of
the
messages.
If
there
are
no
consumer
consumers
that
may
be
of
interest
to
observers,
perhaps
The
Source
could
be
shut
down
or
perhaps
there's
a
problem
with
consuming
applications.
They
should
be
investigated.
A
So
that's
that
messaging
pattern
and
then
P2P
highlights
the
fact
that
if
it
goes
to
multiple
consumers
that
that
may
be
of
concern
to
observers
because
it
could
represent
duplicate
message
delivery.
A
So
so
that's
the
value
now
so
I
guess
there's
two
things
to
discuss
like
is
this:
do
we
agree
that
this
could
be
useful
and
I
think
it
should
be
I,
think
it'd
be
optional,
right,
I,
don't
think
we
should
dictate
it
be
included,
because
if
a
particular
messaging
system
kind
of
doesn't
fall
into
either
of
these
descriptions,
I
think
it's
best
left.
You
know
either
just
Define
a
new
type
of
pattern.
A
That
is
the
contains
useful
information
or
just
don't
specify
it,
but
these
are
two
common
patterns
that,
like
I,
think
JMS
is
widely
used.
There's
a
lot
of
JMS
like
messaging
providers,
where
these
conditions
hold
and
so
I
think
it's
useful
to
including
the
trace
and
then
so,
if
we,
so,
the
first
point,
I
guess
discussed
is
if
there's
any
objection
to
including
this.
B
My
Beyond
this
is
that
even
if
it's
true
in
general,
the
topic
and
queue
like
how
do
you
define
too
many
subscribers
right?
So
two
subscribers.
Oh
sorry,
two
consumers,
consumers
that
how
do
you
distinguish
them?
So
you
need
to
say:
okay,
if
this
are
two
consumers
from
the
different
Services.
Otherwise,
maybe
it's
a
retrace
or
concurrency
right,
so
two
may
be
finer.
50
is
probably
not
fine.
So
it's
it's
a
difficult
analysis
that
leads
to
the
conclusion
that
it's
too
many-
and
this
is
too
low.
B
Backends
today-
don't
have
as
far
as
I
know
such
and
knowledge
is
done
and
it's
we.
We
cannot
Define.
The
algorithm.
Also
q1
topic
are
overloaded
terms.
So,
for
example,
I
sent
to
Q
as
a
producer
producer
doesn't
even
care
where
it
sends
to.
B
But
then
there
is
another
component
that
finds
out
it's
somewhere
else
and
they
have
multiple
tons
of
consumers
in
Azure
we
have
different
messaging
services
using
each
other,
so
I
can
send
to
service
bus,
and
then
it
will
pan
out
to
event
the
grid
deal
with
it,
if
I'm
great,
we'll
send
it
to
anywhere.
B
So
I
think
this
is
a
useful
thing,
but
we
don't
have
a
clear
understanding
how
we
want
to
express
it
and
how
it's
going
to
be
used
and
it
provides
value.
But
it's
a
questionable
like
the
cost
I
can
benefit
can
be
we
don't
know
so.
B
My
proposal
is
unless
we
have
an
algorithm
that
we
know
that
can
be
reliable
and
can
clearly
Express
what
we
do
and
also
we
wouldn't
introduce
it,
and
also,
if
we
do
this,
we
don't
use
value
things
like
here
on
topic,
we
would
say:
Okay
consumer
consume,
it's
a
it's,
a
topic
consumer,
it's
only
a
consumer
concept
and
also
it's
the
behavior.
It's
not
the
Cure
topic,
it's
broadcaster,
unicast,
or
something
like
this
that
clearly
expresses
what
it
means
not
trying
to
stitch
it
to
existing
Concepts.
That's
my
point.
A
Right,
okay,
I
mean
so
I
think
we've
got
into
both
subjects
there
like
in
terms
of
you,
you
address
both.
A
What
term
do
we
use
to
label
it
and
and
that's
a
whole
subject
matter
to
discuss
and
then
the
other
is
is
the
other
and
you
did
touch
on
the
other
as
well
like
you're
concerned
about
whether
two
is
too
many
or
whether
it's
50
or
whatever,
in
a
point-to-point
messaging
scenario,
unicast
Q,
whatever
term
we
use
and
I
mean
I,
like
a
vast
majority
of
messages
that
are
sent
point
to
point,
have
exactly
one
consumer
and
I
think.
A
A
A
A
It
doesn't
happen
very
often
that
that
duplicates
are
processed.
It
can
lead
to
problems
and,
and
customers
are
always
asking
us
for
ways
to
identify
duplicate
messages,
and
you
know
often
to
do
a
good
job
of
this.
It
requires
application
layer,
Intervention
which
they're
hesitant
to
do
it's
worked
for
them.
If.
B
B
A
Things
there's
nothing
in
the
message
to
say
it's
a
queue
so
that
that
is
exactly
the
sort
of
information
I'm
trying
to
include
that
you
could
use
to
augment
searches
and
weather
back
ends,
do
or
don't
are
have
the
capability
to
kind
of.
Do
that
thing
automatically
or
not,
I,
don't
know
it's
particularly
relevant
like
if
it
doesn't.
A
When
publishing
a
topic,
you
know,
we've
had
problems
with
our
with
customers,
who
you
know:
they've
got
systems
that
have
been
up
and
running
for
years
and
years
with
a
decoupled
producer,
consumer.
A
You
know
event
platform
and
the
producers
kind
of
our
publishing
information
that
nobody
cares
about
anymore
and
it's
just
bogging
down
their
system
and
so
being
able
to
identify
that
these
things
aren't
going
somewhere
is
potentially
interesting,
and
so,
if
there's,
you
know
a
way
to
include
that
information
that
perhaps
it
can
be
correlated
that
you
have
appreciative
information,
that's
not
going
anywhere,
I!
Think
it's
a
good
thing.
B
A
B
Look
so
wait.
My
point
is
that
in
general
case,
the
the
tracing
systems
don't
know
in
general
cases
they
look
at
the
Telemetry.
They
cannot
perform
reliable
analysis
unless
we
Define
how
right
the
main
point
I'm
trying
to
tell
is
that
it
may
be
useful,
but
given
them
certainty,
given
that
the
potential
benefit,
do
you
think
it's
the
essential,
absolutely
much
to
grow
in
B1?
Can
it
be
done
after
we
discuss
what
we
are
trying
to
do
with
just
the
very
basic
things?
B
A
Well,
I
think
it's
a
pretty
simple
concept:
it's
a
well-established
concept.
I
think
it's
useful
to
include
in
the
trace.
I,
don't
know.
If
anything
here
is
essential
right,
we
could
probably
cut
a
whole
lot
of
things
out.
I,
don't
know
I,
guess
I,
don't
I
I,
don't
know
where
the
source
of
the
hesitation
to
include
the
information
is.
B
The
source
is
that
this
is
additional
attribute,
it's
maybe
duplicated
in
future.
We
might
regret
that
we
edit
it
because
it
will
prevent
us
from
doing
something.
It
can
introduce
confusion
and
unless
we
know
how
something
is
used,
we
should
not
do
things
any
things
honestly,
and
here
we
can
continue
offline,
but
really,
if
you're
pushing
for
it.
If
you
think
it's
useful,
can
you
please
think
about
the
backhands,
the
the
tracing
back
ends
and
think
about
the
algorithm?
B
They
can
do
for
the
analysis
and
if
you
put
please
put
it
in
the
issue,
it
will
really
help
our
discussion
because
so
far
it
seems
it's.
A
very
education.
State
can
detect.
A
That
might
be
doing
queries
to
look
for
things
and
just
maybe
trying
to
analyze
a
problem
and
just
have
information
to
understand
what
was
happening
by
looking
at
a
trace
like
I
think
you
know
we
have
to.
We
want
to
be
provide
information
that
can
help
users.
B
A
I
don't
know,
what's
I,
don't
know
what
is
like
I
I'm
struggling
to
find
out
what
part
is
abstract
like
I
I've
tried
to
describe
it
as
concisely
as
I
can
and
if
there's
yeah
I
don't
know
how
to
describe
it
any
better
than
I
have
and
I
don't
understand
what
part
is
not
being
understood.
That's.
B
B
Systems
are
I,
probably
already
know
where
the
it's
secure
topic,
so
I
know
that
one
side
is
instrumented
another
one,
maybe
not
I,
know
how
it's
sent
out,
how
it's
routed
so
people
route
messages
to
for
reliability,
purposes,
to
multiple
destinations,
all
the
time
right,
so
I
I
know
most
of
it
already.
So
if
I
just
take
tracing
I,
don't
include
this
information
pure
topic.
If
I
see
okay,
this
message
came
from
point
from
service:
a
to
service
B.
B
So
what
you're
saying
that,
if
we
put
this
information
on
the
producer
and
consumer,
which
is
not
always
possible,
then
you
can
do
analysis
like
okay,
if
service
a
give
me
all
the
consumers
that
receive
this
message,
Services
listing
services
yeah.
If
there
is
more
than
one,
then
there
is
a
problem
right.
B
It's
the
the
only
beat.
That's
missing
is
the
topic
for
Q
and
the
producer
to
automate
this
analysis.
How
useful
is
it?
Oh,
it's
useful,
but
comparing
to
the
essential
things
we
describe
now,
I
would
say
it's
very
different.
It's
low,
especially
if,
as
a
user
I
know,
that's
a
topic
and
I
know
that's
a
Q
and
by
looking
at
the
service
map,
I
can
just
immediately
tell
something
everyone
just
visually.
A
Well,
the
part
that
I
think,
where
we
kind
of
have
a
difference
in
perspective,
is
that
I
don't
think
it
is
well
understood
or
well
known
that
someone's
going
to
look
at
it
and
they're
going
to
know
it's
being
sent
to
a
topic
or
know
what's
being
sent
to
it
to
you.
I
think
these
are
things
that
you
know
that
they're
going
to
want
to
ask
the
trace
like
they're,
going
to
want
to
find
out
if
it
was
sent
to
a
topic
or
a
cue.
That's
that's
the
that's.
A
Why
I
think
it's
useful
thing
here,
I,
don't
think
it's
well
known
and
I
I!
Believe
information
belongs
in
the
trace
and,
frankly,
like
there
are
use
cases
that
we've
envisioned
where
we
would
like
to
be
able
to
build
sort
of
maps
of
how
information
flows
based
on
analyzing
Trace
data
like
and
without
this
information.
A
B
A
B
A
B
A
I
mean
I
mean
I
I
can't
answer
that
I,
don't
think
we
anyone
can
right.
B
Well,
the
time
can
like
over
time
we
can
receive
feedback
from
people
who
would
say:
okay,
we
want
to
do
this
for
packets,
we'll
start
providing
analysis
and
automations
on
top
of
messaging
data
that
we
should
produce
first
and
then
they
can
come
back
and
say:
okay,
we
want
this
data,
this
specific
data
that
will
help
us
in
this
specific
way,
and
then
we
can
include
it
once.
We
know
how
it's
useful.
A
Anyway,
I
I
I
think
it's
hard
to
characterize
the
number
of
cases
like
I.
Don't
you
know
the
basically
I
think
it
could
be
useful
in
the
vast
majority
of
use
cases
I'm
familiar
with.
It
sounds
like
to
me
that
you're
in
the
majority
of
use
cases
you're
familiar
with
it,
might
not
be
useful.
So
there's
a
you
know,
we're
familiar
with
different
messaging
use
cases.
It
sounds
like
and
it's
hard
to
say
which
one
is
dominant
and
so.
B
So,
let's,
if
we're
not
sure
if
there
is
no
consensus,
let's
not
do
it,
because
otherwise
we're
just
putting
stuff
in
without
clearly
without
having
consensus
that
works
the
majority
of
of
our
all
common
pleases.
So
why
would
we
put
it?
Why
is
it
so
important
that
we
discuss
it
rather
than
how
we
should
add
links
and
like
how
we
do
all
the
other
stuff?
That
is
more
useful.
A
D
So
if,
if
so
sorry
I,
my
internet
connection
was
breaking
off
for
some
reason
so
but
yeah
I'm
back
now,
I
missed
the
last
I
think
three
minutes
of
the
discussion.
But
what
I?
What
I
wanted
to
say
is?
Could
you
please
comment
on
the
pr
and
add
your
concerns
there,
and
then
we
can
then
continue
continue
discussing
there,
because
the
last
30
minutes
today
surf
that
we
get
going
on
the
metrics.
D
And
maybe
then,
when
you
have
like
the
conference
written
down,
let's
continue
discussing
there
because
I
I
mean
I
personally
think
that
this
is
not
critically
for
V1,
but
they
also
get
to
ends
point
because
he
already
spent
some
people
some
time
into
that
that
we
would
want
to
reach
a
conclusion
here
and
I.
D
Think
it's
important
for
his
scenarios,
which,
if
I
understand
if
I
remember
correctly,
include
scenarios
where
a
destination
can
have
the
same
name
but
could
be
either
Pub
sub
or
point
to
point
so
where
it
actually
contributes
to
the
identity
of
the.
A
Destination
I
find
it's
a
minor
point,
I
think
it's
more
important
that,
given
the
name,
you
don't
know
what
it
is
and
that
you'd
want
to
be
able
to
just
know
by
looking
at
the
trace.
What
messaging
pattern
is
being
used
with
this
message?
That's
that's
just.
C
To
be
clear,
one
thing
that
I
also
thought
about,
and
and
for
example
like,
let
me
just
said
that,
for
example,
if
I
look
at
the
trace,
I
will
know
I
think
that's
probably
very
true
for
a
lot
of
cases,
but,
for
example,
if
if
it's
not
like
the
developer
or
someone
that
is
involved
with
with
the
architecture,
let's
say,
for
example,
SRE
or
something
that
is
not
really
connected
to
to
the
things.
But
it's
responsible
for
looking
at
things.
C
They
might
not
know.
For
example,
that
is
a
keyword
topic.
So
then
they
will
not
have.
This
I
was
thinking
if
this
is
even
relevant,
but
that's
something
that
came
to
mind
and
I
will
try
to
see
here
at
Dana
Trace
if
they
use
this
for
something
or
if
they
have
any
heuristics
or
something
if
I
can
find
out.
So
I
already
sent
a
message
to
one
of
the
one
of
the
persons
here
that
deals
with
with
messaging
instrumentation,
so
I'll
see
if
I.
D
Would
be
great
next
steps
thanks
for
all,
so
please
look
Miller
comment
on
this
issue
with,
with
with
the
order
with
your
Viewpoint
and
draw
yeah,
it
would
be
great
to
see
whether
a
diner
trace
this
destination
kind
is
actually
used
because
I
know
more
back-ended
Microsoft,
it's
not
used,
but
let's
see
what
actually
use
cases
are
there
and
then,
with
that
additional
information.
D
Let's
continue
discussion
offline
on
this
PR
and
if
we
don't
get
to
some
agreement,
let's
bring
it
up
next
week
again,
but
yes,
thanks
Dwayne
for
for
leading
this
and
thanks
everybody
for
the
discussion
and
Danielle
I'd
like
to
I
mean
it's
only
22
minutes
now
like
we're
going
to
go
to
book
Miller
to
kick
us
off
with
the
metrics.
B
B
Okay,
so
I
have
a
couple
of
things.
Let
me
first
talk
for
a
moment.
I'm
sure
talk
for
a
moment
about
what
we've
done
in
Azure
decades
and
then
how
we
should
change
it
I'm,
sorry,
okay,
so
we
played
with
metrics
and
Azure
sdks
and
the
we
instrumented
something
that's
probably
out
of
scope
of
this
conventions
that
we
can
introduce
today.
Can
you
see
my
screen
by
the
way?
B
Yeah
perfect?
Okay,
so
what
we've
done
is
the
following
things.
So
the
transport
thing
so
instrument
duration,
for
example,
on
on
transport
level
and
different
sorts
of
Errors.
We
were
not
sure
how
much
we
want
about
the
number
of
specific
MPP,
specific
things
that
we
want
to
expose
as
metrics,
so
we
started
with
curves
and
closed
connections.
B
So,
on
the
producer
side,
we
only
instrumented
message
found
because
this
this
guy,
it's
the
transport
level
duration.
We
can
understand
how
long
the
communication
the
service
takes.
We
can
do
all
the
analysis
based
on
this.
We
can
count
number
of
sent
messages,
send
batches
from
the
duration
from
the
histogram
and
essentially,
we
can
also
introduce
the
The
Logical,
like
just
send,
with
all
the
price
and
everything
here,
but
well
that's
questionable
what
value
it
provides.
D
A
B
That's
being
yeah
we'll
get
there
in
a
second
okay,
I
have
a
proposal
for
a
general
metrics
I
just
want
to
start
and
explain
reasons,
and
we
practice
what
we
preach.
We
don't
introduce
things
unless
we
clearly
know
how
they
will
be
useful
Okay.
So,
on
the
consumer
side,
we
instrument
to
three
things:
the
transport
level.
B
It's
a
push
thing
right,
so
we
don't
have
a
transfer
level
duration,
much
messaging
related.
We
like
the
so
the
messages
they
come
to
the
the
consumer.
We
call
it,
they
call
prefetch,
so
they
are
sitting
in
the
consumer,
but
they
are
not
delivered
to
user
application.
Yet
so
we
know
that
it
happened.
We
want
to
know
that
some
messages
are
there.
It's
not
well
expressed
with
traces.
B
So
we
think
that
essentially,
this
is
a
super
important
thing
to
measure
with
metrics,
so
we
record
the
last
sequence
number
or
offset
and
key
right
the
what
it's
called
in
Costco,
mostly
and
some
mqp
specific
stuff-
and
there
are
things
that
are.
We
found
super
helpful.
You
know
just
consumer
lack
which
I
will
show.
If
you
have
time,
I'll
show
you
a
demo,
it
shows
how
much
time
the
message
spends
in
between
it
was
and
cute
till
the
moment
it's
delivered.
B
B
So
maybe
there
is
a
something
created
in
advance,
so,
for
example,
we
have
compare
the
different
rates
here.
I
have
my
message
that
was
number
of
it's
the
its
watches.
D
B
Like
this,
is
the
number
of
batches
I
send
or
send
message
no
send
message.
Sorry,
this
is
a
number
of
messages
they
sent.
This
is
the
her
menu
was
received.
Do
you
see
that
the
rates
are
different,
so
they're,
probably
something
wrong
and
checkpointing,
so
the
checkpointing?
By
just
by
looking
at
it,
you
can
say
that
I'm
checkpointing
a
batch
because
the
the
rate
of
checkpointing
is
much
lower
than
receiving.
B
So
this
is
the
consumer
look,
so
you
see
because
the
rates
are
different.
The
time
this
is
in
seconds.
The
time
grows
the
so.
The
last
mess
like
messages
spent
243
seconds
in
this
on
the
broker
before
they
were
actually
processed
and
support.
B
Where
I
can
do
multiple
other
things.
I
didn't
have
any
errors
anywhere,
but
I
can
derive
a
lot
of
things.
I
can
derive
batch
size,
switches
average.
It's
not,
but
it
says
in
terms
of
messages,
count
of
messages
and
some
other
things.
I
can
also
compare
the
prefetch
with
checkpointing.
So
like
the
message
when
it
arrives
on
the
on
the
consumer
till
the
time
it
is
actually
settled.
B
B
Probably
very
little
so
I
I
saw
what
we
can
do
from
the
attributes
we
Define
so
far,
and
Concepts
I
actually
would
propose
to
stick
with
things
that
we
can
do
with
the
tracing
semantic
conventions
and
add
other
stuff
up
after
we
stabilize
the
first
thing,
and
we
can
still
see
it,
it
could
be
useful.
So
essentially,
we
want
instrument
transport
level
because
it's
not
in
scope
of
our
semantic
conventions.
B
We
can
instrument
duration
right,
the
duration
will
give
us.
So
this
is
the
message
count.
The
duration
will
give
us
batch
count,
so
some
systems
will
could
which
don't
support
batch
on
Sam
can
remove
this
one,
and
then
we
can
also
instrument
the
batch
size
in
terms
of
the
histograms.
We
can
have
a
histogram
from
number
of
bytes
and
number
of
messages.
C
B
Well,
it
can
be
a
counter,
but
the
counter
will
give
us
an
average
only
right
and
if
we
want
a
distribution
like
some,
some
batches
are
very
small.
Some
are
very
big
and
what
is
that
P95
size
of
the
batch.
E
B
C
Yeah,
okay,
combine
them,
yeah
I
didn't
get
the
so
the
same
duration
is
is
just
until
you
receive
a
response
from
the
produce
from
the
broker
that
you
invest
was
sent
right.
That's
that's
the
saturation.
B
Yes,
but
since
it's
a
histogram
I,
don't
know
how
you
folks
are
familiaros
the
metrics,
so
so,
for
example,
if
I
open
it,
so
they
have
yeah.
So
when
we
report
duration,
when
we
report
the
histogram
in
up
until
three
metrics,
they
are
actually
three
different
metrics.
So
if
we
were
talking
about
it's
too
ugly
yeah,
this
one
is
still
ugly.
So,
but
essentially
there
are
there
is.
There
are
buckets
that
describe
histograms
and
the
razor
account
that
describes
the
counter.
The
number
of
these
things.
C
B
And
some
yes,
so
by
some
sum
and
count,
we
can
figure
out
average
very
easily,
but
we
can
also
do
all
the
distribution
with
the
buckets
so
and
then
well.
Of
course,
it
depends
on
your
back
end,
but
in
Prometheus
we
can
derive
a
bunch
of
things.
So
these
are.
This
are
taking
count
and
rate
of
these
things
from
the
duration.
B
We
can
do
all
the
interesting
analysis
so,
for
example,
the
batch
size,
it's
the
ratio
between
two
different
metrics,
so
we
can
be
very
frugal
and
still
expose
a
lot
of
information
through
a
very
few
Matrix
and
I'm,
not
even
fully
convinced
that
we
need
all
of
them
like,
for
example,
batch
size,
the
number
of
messages
in
batch.
We
can
remove
it
later.
It's
just
the
first
proposal.
C
So
the
the
message
count
if,
if
I
work
with
patches,
then
what
is
it
you
want
to
have
the
you
want
to
see
just
the
histogram
for
a
batches
I
didn't
get.
So
if
it's
a
one
single
message
producer,
then
counting
is
just
a
normal
counter
right.
So.
B
So
if
okay,
so
maybe
I,
will
separate
this
diagram
into
two
different
scenarios.
B
B
C
In
HTTP
they
don't
also
have
request,
count
metric
right.
They
only
have
the
response
time
or
something
like
that,
and
then
there
is
also
there's
I.
Think
there's
an
issue
open
actually
to
add
this,
or
somebody
asked
for
a
request
count,
but
then
I
think
the
as
far
as
I
remember.
It
was
about
this
that
you
can
just
derive
from
the
histogram
yeah.
D
D
C
Yeah
yeah.
B
Yes,
but
if
I'm
instrumenting,
an
Arabic
mq
that
never
sends
more
than
one
message,
should
I
send
two
metrics
at
the
same
time.
So
perhaps
those
two
are
generic
and
this
one
is
recommended
for
messaging
systems
that
support
ascending
in
batches.
C
D
Yeah
I
mean
I
I,
just
think
about
somebody.
For
example,
you
are
coming
up
with
a
I,
don't
know
a
predefined
dashboard
based
on
on
those
metrics
that
we
come
up
here
and
I
think
you
have
to
make.
D
There
I
think
it's
it's
it's
great
to
have
consistent
semantics
for
metrics
across
scenarios,
so
that
I
say:
okay,
I
have
this
message
come
and
that's
the
same
semantics
for
all
scenarios,
regardless
of
of
of
whether
it's
a
better
or
not
I
mean
I,
get
the
I
get
the
other
point,
and
you
say:
okay,
it's
more
economically,
that
we
kind
of
can
do
with
fewer
metrics.
C
You
can
also
also
have
them
duplicated
budget
just
have
a
underscore
batch
in
the
end,
for
example,
to
differentiate
it.
That's
also
something
that
can
happen
if,
if
we
really
want
to
have
a
different,
having
attributes,
probably
is
not
a
good
idea
like
a
flag
at
a
good
badge,
true
or
false,
it
is
probably
also
not
very
good.
I.
Think.
B
C
D
But
what
I
like
about
your
approach
here?
Look
middle
I
mean
it
I
think
we
didn't
get
far
yet
the
consumer
side,
but
I.
Just
like
the
Symmetry
that
we
see
here,
you
see
here,
we
see
the
send
message
count.
We
have
a
received
message
account
on
the
other
side,
with
the
centeration
we
have
to
receive
consumed
duration
on
the
other
side
and
yeah.
Also
the
batch
size
I
think
there
was
an
initial
symmetry
there
too.
B
Awesome
yeah
and
all
of
those
things
like
the
the
general
purpose
stuff.
It
can
be
derived
from
the
attributes
we
defined,
so
we
can
I
can
go
ahead
and
create
a
yaml
file
and
a
simple
generate,
simple
markdown.
To
outline
it.
We
can
discuss
the
details.
I
think
there
are
a
couple
of
questions
there,
like
the
naming.
I
brought
up.
Another
question
is
the
how
to
express
failures
because,
like
we
want
to
put
also
fillers
so
sorry
as
a
dimension
on
the
send
duration
and
how
we
do
it.
D
B
So
these
guys
are
seem
to
be
software
sent
message
found,
or
obviously
it's
only
successes.
But
it's
interesting
to
know
that
the
defendancy,
like
the
correlation
between
duration
and
the
batch
size
or
not
duration,
much
less
the
duration
and
Status
rate,
and
also
the
the
payload
size
and
bytes.
It
should
also
have
an
error,
because
if
it's
too
big
I
want
to
know
that
I
I,
never
I
tried
to
send
something,
that's
bigger
than
a
certain
thing
and
it
never
successes
but
for
the
same
duration
yeah,
we
can
totally
put.
C
But
that
yeah,
but
that
you
can
kind
of
correlate,
for
example
like
if
you
plot
the
two
metrics
together,
like
you,
plot
the
the
message
bytes
into
any
plot,
for
example
the
request
something
because
then
you'll
have
some
sort
of
status
on
the
request.
I
guess
and
then
you
can
see
if
you
have
a
lot
of
failures
and
you
see
because
the
the
request,
the
the
matching
size
is
also
increased.
So
it
really
pretty
much
know
that
there
was.
That
was
the
reason.
B
You've,
probably
right,
the
question
is:
how
difficult
is
it
and
I
think
this?
This
is
also
a
question
of
prototyping
and
playing
with
it.
I
don't
feel
strongly
about
it.
D
Yeah
I
think
it's
definitely
a
question
of
prototyping,
because
I
just
think
here
you
can
compare
across
different
metrics.
But
then,
in
the
end,
when,
when
we
have
I
think
count
always
refers
to
a
single
message.
The
message
count,
but
the
other
thing,
the
duration
and
I'm
not
sure
the
payload
not
sure
about
that.
But
the
duration
for
sure
might
refer
like
to
the
duration
of
sending
a
batch.
D
So
there's
only
then
so
limited
that
it's
limited.
How
much
you
can
put
those
metrics
yeah.
B
And
regarding
so,
we
ended
up
introducing
some
attributes,
for
example,
the
delivery
state
that
is
MTP
specific
where
and
people
data
scored.
Unfortunately,
there
are
there
two
different
things,
but
essentially
for
some
things.
There
is
no
messaging
system
specific
status
code
like
HTTP
status
quo,
for
example,
and
here
we
don't
have
an
attribute
on
metrics
that
can
the
general
purpose
one
like
status
codes.
So
we
reused
tell
status
quad
from
some
other
places
and
it's
basically
a
failure
or
success.
We
will
have
to
discuss
how
we
approach
it
for
messaging.
D
C
I
guess
we
can
come
up
with
a
general
thing
and
just
use
it
I
think
that
should
not
be
problematic,
because
all
of
them
must
have
something
to
indicate
that
that
the
thing
didn't
work
right.
They
might
differ
how
they're
called
what
the
value
that
they
return.
But
I
guess
if
we
have,
for
example,
I
don't
know
like
you
said,
Hotel
status
quo,
for
example,
then
each
message
assistant
can
create
their
own
mapping
and
map
to
their
particular
response
and
then
do
what
hotel
has
to
make
to
make
to
populate
this
Dimension
I
guess.
B
C
Sounds
yeah,
yeah,
I
know,
I
think
we
might
might
I
think
it
might
be
more
interesting
to
have
different
ones
for
batch
and
non-batch,
but
yeah.
D
That
was
that
was
great
to
get
us
started
here.
So
I
would
like
to
resolve
a
time
box
for
pushing
to
metric
stuff
during
the
next.
The
next
things
that
we
have,
because
I
think
that's
the
largest
gap
that
we
still
have.
So
maybe
we
can
get
up
like
at
least
a
draft
PR
at
some
point
and
then
also
discussed
it
on
the
draft
PR.
That
would
be
awesome.