►
From YouTube: 2022-06-23 meeting
Description
Instrumentation: Messaging
B
B
C
D
B
D
C
C
C
B
Should
we
implement
the
messaging
specification,
because
one
of
the
things
that
we
are
wondering
is
it
makes
a
lot
of
sense
for
for,
for
example,
a
client
sdk
like
rabbitmq
to
implement
the
messaging
specification,
but
because
we
are
a
layer
on
top
of
that
we
were
asking
ourselves.
Does
it
make
sense
for
us
to
adhere
to
that
same
specification
or
could
that
become
more
confusing
to
the
users.
B
C
This
is
a
question
we
didn't
really
yet
discuss
in
the
group
there
there
are.
There
are
people
were
thinking
about
that
in
in
other
contexts,
not
in
messaging
and
I'm
afraid,
open
telemetry
does
not
have
kind
of
really
stable
solution
for
that.
Yet
I
think
the
the
safest
solution
probably
would
be
that
that
you
provide
consistent
instrumentation
from
your
site
and.
C
And
maybe
then
in
the
in
the
end,
like
suppress,
lower
level
instrumentation
that
might
be
there
or
might
not
be
there.
I
think
in
that
I
think
in
the
end,
it's
it's
it's
probably
it's
it's
your
car.
Where
to
go.
I
mean
the
two
possibilities
are
that
you
don't
provide
instrumentation
and
rely
on
other
libraries
providing
instrumentations
and
then
you
might
end
up
with
probably
different
user
experiences,
and
maybe
some
libraries
don't
have
instrumentation
at
all.
C
B
That
we
considered
is
that,
in
tim,
correct
me,
if
I
say
anything,
but
to
basically
try
to
create
a
solution
in
which
we
add
instrumentation,
where
it
makes
sense
to
create
visibility
into
what
we
are
doing
inside
the
framework
and
then
still
being
able
to
connect
that,
with
whatever
a
downstream
component
may
be
emitting
as
well.
So
let's
say
that
a
user
is
using.
We
have
the
messaging
middleware
on
top
of
that
and
we're
adding
instrumentation
that
creates
visibility
into
what
we
are
doing
in
the
framework.
C
A
Yeah,
no,
it's
more
basically
on
the
client
side,
providing
apis
and
abstractions
on
top
of
transports,
for
example
like
rabbitmq
what
we
call
transports
or
brokers.
Ultimately,
so
it's
more
the
the
client
to
client
side
where,
as
you
already
said,
it's
the
difficulty
there
we're
not
really
sure
we
can't
really
know
what
kind
of
underlying
open
telemetry
support.
There
is
on
ultimately
client
sdk
levels
and
on
the
broker
side,
and
so
on.
A
Then
we
integrated
spots
to
provide
additional
information
and
there's
always
kind
of
this
or
one
of
the
difficulty
we're
experiencing
at
the
moment,
is
what,
as
layla
described,
that
we
don't
really
know
like
what
is
there?
What
is
not
there?
How
far
does
does
our
implementations
go
ultimately
on
the
transports
which
are
supported?
Where
do
the
client
sdks
go,
and
it
looks
like
at
the
moment
the
at
least
in
the
messaging
space
and
dotnet
space?
There
aren't
many
client
sdks
that
are
doing
anything
or
a
lot
in
regards
to
open
telemetry.
A
That's
the
thing
we
kind
of
want
to
avoid,
and
we
saw
from
like
community
contributions
that
typically
or
that
people
look
at
the
messaging
spec
the
way
they
described
and
try
to
follow
these
messagings
back
with
you
know
the
tags
and,
and
these
type
of
things
where
we
then
seem
to
that
seems
to
be
a
high
chance
of
getting
into
conflicts
in
that
regard.
So
I
think
one
of
the
discussions
we're
having
is
whether
we
should
then
maybe
really
try
to
stick
basically
to
our
own
namespaces,
for
example.
C
E
A
C
I
think
we
have
time
today.
I
think
I
think,
for
in
terms
of
the
trend,
I
think
we
will
skip
the
discussion
about
the
the
messaging
attributes,
because
many
of
the
participants
are
not
here
and
then
we
can
split
the
time
in
half
between
the
two
topics
we
have
like
we
until
8
30.
We
can
stay
on
this
topic
and
then
at
8
30.
We
can
switch
to
the
x-ray
okay.
A
Okay,
should
I
start
layla
and
kind
of
just
you
fill
out
where
I
miss
some
details.
I
guess
so
one
of
the
things
I
got.
The
main
reason
we're
doing
this
at
the
moment
is
because
most
of
the
client
sdks
are
not
really
doing
open,
telemetry
stuff.
Yet
so
one
of
the
benefits
we
see
is
that
by
for
our
clients
that,
regardless
of
the
transport
they
are
using,
they
already
get
a
very
high
level
sort
of
of
tracing
capabilities
where
they
can
see
tracing
on
at
least
how
we
say
more.
A
Some
stuff
is
not
connected.
There
are
some
there's
some
trickiness
in
how
exactly
we
do
the
dispatching
of
messages,
because
we
have
like
this,
some
sort
of
the
I
think
it's
described
in
the
specs.
Also,
as
batching
like,
we
call
it
batch
dispatch
where
we
group
up
a
bunch
of
scents
and
then
only
hand
them
over
to
the
transport
layer.
A
So
there's
a
lot
of
things
where
we
need
to
make
sure
that
the
spans
are
correctly
connected
in
a
way
to
make
sense
for
the
user
and
to
make
sure
that
not
some
bands
are
just
kind
of
showing
popping
up
somewhere
without
any
connections
and
don't
make
sense
or
even
in
the
worst
case.
If
we
use
the
wrong
parents,
then
kind
of
split
the
part
spans,
because
at
some
point
the
the
the
connection
is
not
made
well
enough
or
it's
just
like
yeah.
A
Ultimately,
every
transport
in
the
end
supports
some
sort
of
message:
headers,
some
do
it
natively
for
some,
we
kind
of
wrap
it
in
additional
to
provide
the
message,
headers
concept,
but
we
use
the
headers
there
and
that's,
for
example,
that
meant
also
with
if
we,
for
example,
use
a
transparent
header
or
something
like
that,
we
immediately
get
into
potential
conflicts.
If
what
somebody,
if
somebody
else
wants
to
use
exactly
that
same
header.
So
currently,
the
idea
is
to
use
that,
but
maybe
with
different,
like
our
own
custom,
headers
yeah.
E
A
E
E
A
A
E
A
E
B
B
B
E
Yeah
yeah
exactly
this
was
like
what
was
my
question
about
basically
so
relationships
yeah
between
traces
and
spence.
Like
say,
if
I
don't
know,
if
you
support
this
topology,
it's
like
fan
out.
You
know
already
recently,
as
since
recent
times
has
streams,
for
example,
yeah
so
like
different
usage,
different
exchanges,
different
combinations
of
cues,
and
for
me,
then
it
will
be
interesting.
E
E
E
E
C
C
I
put
a
link
to
an
open,
telemetry
issue
in
this
like
channel.
I
will
wait
a
bit
quickly
share
my
screen,
so
I
can
walk
you
over
that.
It's
this
one
of
the
things
that
actually
corresponds
to
your
situation.
It
was
brought
up
by
ludmilla
factory
works
on
azure
sdks,
including,
like
the
azure
event,
hubs
and
service
bus
sdks,
and
she
brought
this
basically
proposal
up
here
about
like
having
instrumentation
layers
and
having
rules
how
to
interact.
I
think
that
is
basically
a
problem
that
you
are
facing.
You
have
the
different
instrumentation
layers.
C
But
I
think
it
applies
to
your
use
case
as
well,
and
she
gives
a
proposal
here
of
how
to
basically
make
sure
that
only
one
of
those
layers,
kind
of
kind
of
one
of
those
layers
more
or
less
adds
information
and
then
the
other
layers.
Basically,
the
lower
left,
the
lower
layer,
kind
of
knows
okay.
This
is
already
taken
care
of,
so
I
just
do.
I
don't
I
just
do
nothing
because
there's
already,
I
don't
know
a
messaging
expand
or
an
http
spend
there.
C
I
think
what
what
you
some
concrete
steps
that
you
could
do
for
your
to
move
forward
with
your
problem.
Now,
maybe
you
could
just
add
a
comment
on
this
old
tab
and
say:
okay,
that's
of
interest
for
us.
We
need
that.
Another
thing
I
think
that
you
could
definitely
do.
Is
that
usually-
and
I
just
noticed
from
from
azure
sdks
from
this
from
the
instrumentation
open
the
dimensions
to
make
instrumentation
there?
C
I
think
in
that
way
you
are
100
under
control
and
you
can
provide
like
a
consistent
experience
to
to
users
because
also,
as
you
said
before,
tim
is
that
you're
not
even
know
if
your
customers
are
interested
in
digging
down
into
the
rapid
mqa
details
vendor
actually
using
your
api.
It
might
actually
be
more
confusing
to
them
to
see
that
and
actually
for
your
users.
It
should
be
kind
of
a
consistent
experience.
C
C
But
that's
just
from
my
point
of
view,
like
the
kind
of
guidance
I
would
give
now
to
say:
okay,
take
the
responsibility
on
yourself
and,
and
probably
I
think
for
now
it's
just
good
enough,
not
enabling
any
instrumentation
on
the
lower
level
library
you
are
you're
using
because
they,
I
think
at
least
for
azure
sdk.
It's
not
enabled
by
default
for
others.
C
E
A
E
E
B
C
Yes,
the
I
think
the
challenging
here
is
that
this
functionality
is
not
that
that
is
described
in
this
old
tap.
Here
is
not
really
there
yet,
so
that
suppression
would
be
then
something
that
would
needed
to
provide
from
open,
delametry
site
that,
and
that's
why
I
said
I
think,
from
what
you
can
I
think
currently
do
is
that
you
just
don't
enable
open
the
lam
instrumentation
for
this
instrument
for
this
lower
level.
C
C
I
know
that
it's
there
and
I
guess
it's
there
for
most
other
libraries,
do
you
have
to
explicitly
kind
of
activate
this
instrumentation
and
then
they
basically
create
spans,
and
I
think
the
short-term
solution
for
you
would
probably
just
be
to
just
kind
of
not
turning
it
on
or
turning
it
off.
Whatever
is
the
default
and
just
kind
of
making
sure
in
that
way,
making
sure
that
you
were
the
only
layer
adding
this
messaging
instrumentation.
A
A
problem
so,
in
that
regards,
when
you
know
saying
okay,
we
should
be
basically
making
sure
that
that
we're
not
having
anything
underlying
to
avoid
conflicts.
Would
you
say
it
is
still
like?
In
that
case,
we
should
still
basically
follow
the
recommendations
that
are
currently
defined
in
the
in
the
messaging
specific
specs,
like
the
specific
tag
names,
for
example.
C
So
this
is
this
is
not
very
kind
of
mature
yet,
but
I
think
the
vision
is
that
that,
for
example,
I
mean
http
is
a
very
good
example,
because
there
is
already
their
http,
the
spans
have
certain
attributes,
so
http
url
http
status,
and
when
the
backend
basically
sees
this
attributes,
they
know.
Okay,
that's
an
http
span
and
that's
what
those
attributes
mean-
and
I
don't
know
if
the
status
is
five
zero,
something
then
okay.
This
is
an
error
and
maybe
make
this
band
red,
and
this
is
kind
of
fun.
C
This
gives
backhands
kind
of
fun
means
to
kind
of
interpret
spans
and
provide
kind
of
tailored
experiences.
On
top
of
that,
and
in
that
regard,
if
you
want
to
benefit
from
these
capabilities
that
might
be
there
in
the
future,
then
it
might
make
sense
for
you
to
follow
the
open,
telemetry
recommended
attributes,
because
it's
just
kind
of
the
idea
or
division
that
the
backhands
at
some
point
kind
of
use.
This
semantic
information
kind
of
to
interpret
the
span
information
they
get
and
then
provide
a
tailored
experience.
On
top
of
that.
A
Okay,
yeah,
I
think
that's
a
good
point
for
us.
I
mean.
Maybe
it's
a
little
bit
too
much
detail
there,
but,
for
example,
on
the
ends
of
space
level,
we
typically
use
a
different
type
of
message
id
than
what
the
rabbit
mq
then
would
probably
produce
on
the
wire,
especially
than
if
we
take
into
account
recoverability.
C
A
I
think
the
the
standard
cases
is
that
they're
using
our
library,
both
on
the
on
the
producer
and
the
consumer
side
since
there's
a
transport
there's
always
the
possibilities,
are
some
some
customers
that
do
use
like
what
we
call
external
integration,
which
means
that
they
send
from
a
different
like
directly
from
using
the
rabbit
client,
sdk
or
potentially
also
consume.
I'd
argue,
the
consume
site
is
probably
less
likely.
It's
typically.
What
we
see
is
more
of
that
they
send
messages
directly
and
use
our
library
more
like
on
the
consumer
side.
A
C
That
makes
sense
because,
because
I
was
just
asking
because
of
the
message
id
because
otherwise
you
would,
on
the
producer
side,
have
your
specific
message
id
and
on
the
consumer
side,
you
would
see
the
rabbitmq
message
id
and
if
you
see
then
that
in
a
trace
kind
of
that
might
be
might
be
confusing.
But
then,
basically
you
say:
okay,
it's
anyway
standard
that
you
just
put
your
layer
on
top
of
it
across
the
producer
consumer
kind
of
a
consumer
side.
And
then
you
have
the
consistent
yeah
experience
there.
D
You
could
add
a
pr
to
add
your
library,
specific
attributes
there,
and
then
users,
using
your
library
or
your
your
engineers,
make
an
instrumentation
just
follow
those
and
and
then
again
back
ends
will
know,
because
this
is
a
popular
library,
for
example.
Is
it
in
service
spots
right?
That
is
your?
Is
your
library
yeah
yeah?
So
so
this
is
a
highly
popular
library,
so
pressure
backends
will
benefit
from
having
your
specific
thing
there
and
and
highlighting,
like
johannes
said,
like
the
ins
and
service
bus
logo
and
things
like
that,
and
so
on.
D
C
C
I
think
it's
to
require
those
are
more
that's
conditionally
required
and
if
you
want
to
be
compliant
with
opencenometry,
basically
those
required
ones
you
have
to
put
on
and
message
id,
for
example,
is
not
the
required
attribute.
So
if
you,
if
you
think
that's
confusing
in
your
case,
you
can
skip
that
basically
required.
C
Is
that
you,
you
have
a
messaging
system
and
a
destination,
and
what
trial
was
referring
to
is
that
here
we
have
this
general
attributes
in
the
spec
and
there's
then
also
messaging
system,
specific
attributes
like
for
rapid
and
q
for
kafka,
and
I
think,
there's
rocket
rocket
mq
at
some
point
rocketing.
You
here,
yes
and
what
you.
C
That
there
could
be
an
additional
section,
basically
for
your
library,
with
specific
attributes,
that
kind
of
that
your
library
adds
in
addition,
and
then
this
information
basically
can
also
be
used
in
this
in
this
form
by
backhands
to
kind
of
provide
the
daily
experience.
Also
of
of
this
instrumentation
that
you
provide
it's
just
once
once
your
attributes
are
here
that
you're
using
there's
pretty
strong
backwards
compatibility
guarantees
that
are
imposed
by
the
the
convention.
C
C
D
D
But
if
you
know
the
day,
then
you
can
look
at
the
faces
in
the
in
the
time
some
day
of
the
video,
then
it's
not
ideal,
but
that's
how
I
do
it
anyway,
when
I
have
to
look
it
up
and
in
in
slack
I
don't
know
if
you
saw,
but
there
is
a
channel
just
for
messaging
I'll
put
you
as
well,
so
you
can
direct
the
questions
directly.
There.
C
F
F
Yes,
okay,
so
just
to
give
a
quick
overview
of
what
we
discussed
just
like
last
time,
so
we
I'm
like
neras
from
aws
excellent
team
and
we
have
alex
also
from
aws
x-ray
team.
So
last
time
we
were
discussing
about
like
how
sqs
to
lambda
works
internally
and
how
we
are
planning
to
generate
the
links.
The
questions
was
majorly
around
where
to
generate
the
links.
F
So
this
was
the
architecture
where
we
have
a
sql
service
and
we
have
internal
service
sql
spoiler,
which
receives
the
message
from
sqs
and
then
invokes
the
lambda
on
customers.
Behalf
and
lambda
is
split
into
the
two
parts:
lambda
front-end
service
and
lambda
worker
service.
So
we
had
two
options
to
generate
the
links.
One
was
at
the
sql
spoiler
when
it
receives
the
message
and
then
like,
then
they
invokes
the
lambda.
At
that
time
we
can
generate
the
links.
Another
one
was
from
into
the
customers
code.
F
If,
because
lambda
has
like
constraints
on
the
resources,
just
in
case
they
fails,
the
links
will
also
not
be
generated,
but
in
sps
polar
services
like
many
services,
can
handle
those
scenarios
in
a
better
way.
So
that's
that
are
those
are
the
benefits
and
like
easy
to
find
the
siblings
into
the
sps
polar
way,
but
into
the
lambda
worker
way.
One
one
big
benefit
is
that
if
customers
are
processing
the
messages
one
by
one
in
that
case
like
they
can
directly
link
to
a
message
like
processing
spam
directly
to
the
message
panel.
F
So,
in
that
case,
if
like
they
want
to
find
the
end-to-end
latency
of
a
particular
message,
it's
very
easy
to
follow
the
path.
So
in
that
case
that
it's
being
highlighted,
sqs
message,
one
sql
message
was
put
into
the
s3.
Another
message
was
put
into
the
dyno
db
and
but
they
were
processed
by
the
same
invocation,
same
lambda
function
invocation.
So
if
we
go
with
this
sps,
polar
approach,
we
don't
know
like
because
links
are
at
the
left
front
hand
side.
F
We
don't
know
which
links
to
follow
like
which
path
to
follow,
to
find
out
how
much
what
first
message
took,
because
first
message
is
going
into
the
s3,
so
we
need
to
go
and
traverse
the
s3
pass.
So
we
actually
lost
that
information.
But
if
we
have
a
links
at
the
lambda
worker
site
like
at
the
processors
pen
directly,
then
we
already
know
that
sqs.
That
squeeze
message
is
linking
to
a
particular
process
message
once
pen
and
that's
the
path
we
need
to
follow.
F
F
So
that's
where
we
left
and
and
the
kind
of,
if
I
can
quickly
go
on
the
agreement.
So
this
is
done
before
you
also
after
that
we
just
dived
if
there
was
no
kind
of
concrete
this
decision
on
that
one.
But
when
you
were
there
correct
me
if
I'm
wrong
please
so
the
the
idea
was
that,
like
from
the
by
default,
generate
the
links
from
the
sqs
folder,
so
that
by
default,
customers
get
that
experience
without
customers,
making
any
changes,
and
that's
actually
kind
of
aligns
with
the
hotel.
F
Stacks
kind
of
guidance
also
like
give
some
default
custom
experience
to
the
customers
but
allow
the
customization
the
customer
wants.
So
that's.
Why
I
think
recommendation
was
to
still
generate
the
links
from
the
sql
spoiler
side
and
allow,
if
you
are
allowing
customers
to
generate
the
links
at
the
lambda
worker,
then
this
is
the
something
in
kind
of
requirement
and
for
the
hotel
specs
like
how
to
distinguish
between
those
two
links
which
are
actually
kind
of
doing
the
same
stuff.
F
C
I
mean
some
remarks
to
that
is:
first,
it's
it's
not
really
like,
but
just
to
get
this
out
of
the
way
you
said
that
maybe
can
you
go
two
slides
back,
comparing
like
the
two
first
approaches
that
you
said:
okay
yeah
when
you
basically
in
the
first
case
the
information
about
which
message
is
basically
put
into
a
s3
and
ddb
kind
of
this
is
lost.
That
is
true.
C
C
Basically
with
this,
with
with
the
combination,
you
have
all
the
information
there
and
I
think
the
challenge
is
then
just
is
just
to
know,
okay,
which
link
which
link
to
follow
to
kind
of
get
what
information-
and
I
there
is,
I
think,
currently
there
are
two
answers
to
this-
and
one
one
possibility
to
do.
That
is
looking
at
the
looking
at
the
span
kind
of
spans
that
are
linked
together
because
in
in
our
maybe
you
can
go
to
the
to
the
to
the
github
document
of
this.
C
I
think
I
saw
you
had
it
open
before
with
the
this
one.
Yes,
because
here
when
we
look
at
yes
in
this
case,
we
see
that
there's
a
published
span
and
a
receive
span,
and
here
the
published
span
will
always
be
of
type
producer
and
the
receive
span
will
always
be
of
type
consumer,
so
kind
of
these
band
types.
C
But,
for
example,
if
you,
if,
if
your
lambda
functions,
if
the
span
type
of
the
spans,
there
is
not
consumer
but
something
different,
that
that
could
already
give
you
a
hint
of
what
the
link
means.
So
when
the
link
goes
from
producer
to
consumer,
it
basically
is
this
kind
of
link
to
the
that
shows
you
the
badge
and
if
the
producer
link
goes
to
some
kind,
something
that's
not
consumer,
then.
Basically
that
can
help
you
to
give
the
end-to-end
latency.
C
F
C
I
I
think
when
you,
I
think,
if
you
make
if
this
attributes
are,
then
I
think
that
here
is
that
adaw's
x-ray
then
uses
these
attributes
kind
of
to
do
something
specific,
for
example,
calculate
this
end-to-end
end-to-end
duration,
and
I
think,
as
long
as
the
attribute
name
makes
it
clear
that
this
attribute
is
specific
to
aws,
then
I
think
it
that
should
not
be
a
problem.
I
think
we
we
actually
have
that
there
is
already
a
set
of
semantic
conventions
specific
to
aws.
D
Well,
I
I
just
wanted
to,
but
I
I
I
don't
want
to
take
the
time,
but
because
I
missed
last
the
the
last
week's
meeting,
but
the
problem
that
I
I
could
understand
is
that
you,
you
want
to
to
add
a
link
into
this
folder
and
then
there
could
also
be
a
possibility
to
add
another
link,
and
you
don't
want
to
have
both
of
them
right.
It's.
That
is
the
problem
right.
C
Yeah,
I
think
I
think
they
want
to
have
both
links,
but
then
the
question
is
here
which
link
kind
of
right.
If
you
I
mean
the
the
questions,
then
from
the
basically
producer
side,
you
see
it
in
two
links
and
you
then
have
to
know
okay,
which
links
actually
goes
to
the
processing
message.
This
is
the
relevant
one
for.
D
For
example,
it
could
be
the
attribute
like
johannes
said,
but
I
think
if
you
know
which
which
of
these
two
links
like,
if
you
can
answer
which-
which
one
of
these
two
links
you
can
use
to
calculate
the
latency,
then
I
think
you
should
be
good
to
go
without
any
any
hotel
thing.
But
the
problem
happens.
If,
if
you
say
no,
no,
I
cannot.
I
don't
know
which
one
to
calculate,
because
sometimes
I
want
to
calculate
from
the
limit
and
then
and
then
it's
a
bigger
problem.
D
I
think,
but
I
I
still
feel
that,
even
though,
if
you
have
two
of
them,
you
might
know
in
your
logic
like
if
I
have
two
of
them,
I
want
to
calculate
the
one
from
the
label,
because
it's
the
more
accurate
one.
Then
I
take
that
one.
Otherwise,
if
I
don't
have
the
one,
then
I
take
the
other
one.
You
could
use
some
sort
of
this
logic.
That's
what
I
would
imagine,
for
example,
back
then
doing
something
like
this.
C
C
C
F
D
Single
message
not
a
batch,
then
the
link
will
work
right.
Then
you
can
do
pretty
much
what
you
want,
but
the
problem
is
it's
the
middle
case.
Then
this
one
that
I
I
didn't
get
it.
Okay,
the
one
that
goes
from
sqs
to
this
lambda
front
end
and
then
goes
to
the
lambda
function.
Then
the
lambda
function
sends
to
some
processing.
D
Okay,
then
you
don't
know,
then
you
don't
know
anymore,
which
which
but
isn't
the
processing
still
also
getting
the
message.
And
then
the
message
has
the
context.
So
you
know
which
which
link
it
is
like
in
the
end,
you're
processing,
a
message
right.
It
goes
through
this
hops,
lambda
front,
end
and
so
on.
But
in
the
end
the
mat,
the
processing
circle
there
is
processing
one
message
right.
F
Yeah,
so
it's
like
we
are
assuming
this
lambda
function
actually
is
processing
the
messages,
but
it's
processing
in
a
in
a
one
by
one.
So
each
message:
that's
process
we
like
is
creating
a
new
spam,
so
processing
message.
One
and
processing
measures
too
like
we
can
just
it
already
knows,
which
message
is
processing,
so
it
can
add
instead
of
the
link
attributes.
Maybe
it
can
add
some
other
attribution
to
the
span
directly
that
we
can
also
utilize
to
say
that
okay,
this
is
yeah.
That's
like
another
way
to
look
into
like.