►
From YouTube: 2021-10-27 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).
C
E
F
E
H
Probably
helps
if
I
turn
up
my
speakers
all
right.
Let
me
pull
up
the
agenda.
Apologies
for
being
a
minute
or
two
late.
H
All
right
looks
like
we're
going
to
start
with
a
discussion
on
resource
attributes
and
then
discuss
the
broader
plan
forward
who's
on
point
for
the
resource
attributes,
discussion.
E
G
H
So
some
questions
should
we
should
we
create
one
right,
so
the
the
you
know
we
have
service
but
like.
I
think
it
would.
Probably
I
mean
john
you're,
probably
the
most
experienced
of
this
out
of
the
group,
but
it
would
probably
follow
that
we
need
some
kind
of
delineation
that
defines
the
type
of
source
that
we
have
or
use
one
of
the
existing
keys
for
this.
F
F
G
B
So
the
name
client
I
mean-
can
get
conflated
with
device
a
little
bit
here,
because
here
we're
actually
talking
about
an
instance
of
the
app
on
the
client
device
right.
We
won't
actually
have
device
attributes
in
it,
because
we
already
have
a
device
name
space.
G
Yeah,
this
is
kind
of
a
place
for
the
equivalent
of
service
name,
because
service
name
doesn't
make
any.
It
doesn't
really
make
sense.
When
you're
talking
about
a
mobile,
app.
E
E
There
are
api
clients
as
well,
which
are
not
necessarily
clients,
but
let's
say
one
backhand
talking
to
another
back
end.
I.
G
A
C
E
E
Now
the
rest
of
the
attributes
could
be,
let's
say,
the
brow.
The
device
dot
star
could
be
coming
from
the
mobile
devices.
The
browser
dot
star
could
be
coming
from
browser.
You
know,
instrumentation
libraries.
B
E
B
H
E
Yeah
yeah
and
the
motivation
is
really
that
on
the
back
end,
I'm
assuming
that
the
process
how
we
process
the
signals
coming
from
the
client
side
would
be
a
little
different
from
how
the
back
end
signals
would
be
processed,
at
least
for
the
traces,
and
I
could
be
wrong,
but
there
will
surely
be
some
differences.
We
need
to
identify
at
least
the
spans.
E
You
know
I
was
thinking
that
the
top
topmost
the
parent
span-
could
be
the
client
spend,
but
it
doesn't
have
to
be
right.
You
know
it's
possible
that
in
some
cases
you
know
your
your
you
know.
The
mobile
app
is
not
instrumented
with
your
sdk
and
you
know
the
server
starts
to
span.
So
the
parent
span,
in
that
case
is
is
starting
from
the
you
know.
The
back
end.
J
I
think
we
might
be
confusing
still
span,
attributes
and
resources.
I
think
the
best
way
to
think
of
resources
is
they're
like
an
envelope
around
a
batch
of
spans.
That's
sent
so
or
it
might
not
be
the
case
if
we
use
headers,
for
example,
for
this,
but
at
least
this
is
the
way
how
kind
of
the
apm
side
or
the
back
end
agents
model
this,
and
we
cannot
rely
on
attributes
present
in
spans
to
make
this
determination,
because
the
resources
are
kind
of
the
wrapper
around
spans.
E
So
let
me
restate
my
motivation
like
why
why
I'm
asking
for
this?
So
in
our
case
you
know
we
look
at
all
the
spans
coming
from
the
client
side
and
then
compute.
Let's
say
the
average
response.
Time
of
your
api
call
right
off
your
rest,
api
call
for
that.
We
don't
want
to
look
at
the
spans
coming
from
the
backend
sdks.
E
So
how
do
we
only
pick
the
spans
from
the
client
side?
You
know
we
could
look
at
the
instrumentation
library,
but
then
you
know
tomorrow
there
might
be
a
new
library
we
could
keep
when
we'll
have
to
keep
adding
to
that
list.
So
I
think
the
resource
is
exactly
the
right
place
for
this,
and
if
you
look.
E
Yeah
sure
place
is
fine,
but
what
would
be
that
convention
for
the
attribute
so.
G
I
think
kind
of,
as
I
said,
I
don't
think
we
really
have
boolean
resource
attributes
at
the
moment,
they're
all
valued
with
information
in
them,
and
my
guess
is.
If
we
try
to
try
to
propose
some
sort
of
boolean
resource
attribute,
it
would
not
get
approved.
G
Okay,
I
mean
I
could
be
wrong
but
like
given
the
way
that
things
are
structured
in
the
resource
conventions.
Right
now,
I
think
our
best
bet
is
going
to
be
produce
a
new
top
level
prefix
like
app
or
whatever
we
decide
that
prefix
should
be
and
use
that
as
the
place
to
hold
all
of
the
client
telemetry
specific
resource
attributes.
E
Okay,
the
the
one.
E
Comment
on
the
app
prefix
is:
let's
say
there
are
iot
devices
right.
You
know
in
those
cases
with
the
mobiles,
I
understand
it's,
it's
the
apps
on
the
mobile
that
send
the
telemetry,
but
on
in
the
case
of
iot,
like
devices
apps,
I
don't
know
if
they
are
common.
B
G
Yeah,
I
think
the
easy
way
to
to
get
lots
of
opinions
is
to
open
a
pull
request
and
with
a
proposal
and
you'll
get
lots
and
lots
of
opinions
very
quickly.
J
Okay,
but
at
the
minimum
it
seems
that
we
all
agree
that
we
need
this,
be
the
boolean
be
the
different
namespace.
We
need
some
kind
of
a
flag
or
or
anything
to
make
this
decision
that
we
agree
upon
at
least
what
to
name
it
or
is
it
a
boolean
or
or
a
flag
or
a
namespace?
We
just
need
to
figure
this
one
out
if
we
can
just
plot
that
one
down
it's
a
great
step
forward.
I
guess.
H
So,
john,
I'm
not
as
familiar
with
the
resource
part
of
our
spec,
as
perhaps
I
should
be
do
we
have
similar
conventions
like
this
today,
right
like,
for
example,
and
and
this
is
going
to
sound
dumb
if
it's
wrong,
but
like
do
we
have
do
we
have
a
resource
for
an
application
that
runs
on
a
back
end
versus
the
actual
resource
for
the
underlying
infrastructure.
Like
are
those
described
in
different
ways
today
in
the
resource
spec,
and
if
so,.
H
G
Yeah,
there's
in
fact
a
to
do
in
the
near
at
the
top
of
that
document.
That
says,
add
web
browser
so
there's
clearly
we
know
that
the
people
who
wrote
originally
original
authors
knew
that
there
was
stuff
missing
here.
So.
G
Okay,
I
mean,
I
think
there
will
be
things
that
automatically
that
already
fall
into
this
like
os,
I
think,
there's
a
whole
os.
I
don't
know
where
it
went,
but
there's
an
os
grouping
and
like
os
and
android
or
os
of
ios.
All
these
I
mean
these
are
valid
values
that
can
already
be
plugged
into
existing
pieces
of
the
resource.
Spec,
maybe
new
new
values
for
the
the
enumerations,
but
I
think
there's
there's
definitely
something
that
we
need.
G
E
I
I
was
thinking
about
device,
90
percent-
I
think
you're
right,
but
would
there
be
any
chance
of
the
like
the
onboard
devices
on
the
server?
Let's
say
the
cpu
temperature
would
cpu
be
considered
as
a
device
or
any.
E
B
H
Not
things
that
are
generating
open,
telemetry
telemetry
on
their
own.
H
Yeah
and
again
with
device
we
do,
as
someone
had
brought
up
on
this
call
a
few
minutes
ago,
we
do,
we
probably
do
want
to
delineate
or
have
some
special
treatment
of
iot
devices
versus
like
a
phone
right.
One
is
has
a
person
interacting
with
a
large
operating
system.
The
other
has
does
one
thing.
E
H
Yeah,
so
I'm
looking
at
I'll
actually
start
presenting
I'm
looking
at
the
semantic
inventions
right
now
for
devices,
and
I
wanted
to
ask
something:
just
pull
it
up.
H
So
this
is
this
is
here
for
scenarios
like
ours
for
for
client
devices
and
john
again,
you're,
probably
the
most
familiar.
If
I
set
up
anyone
on
the
call,
what
I
see
is
missing.
This
is
what
we
were
discussing
earlier,
but
but
what
I
see
is
missing
is
actually
just
saying
like
this.
This
entire
resource
is
of
the
type
like
client
device
right
like
this.
This
is
details
like
metadata
about
the
specific
device
that
something
is
captured
on.
H
I
could
imagine
that
that
even
for
backend
server
spans,
if
I'm
running
on
a
physical
machine,
that
you
might
put
the
details
of
the
physical
machine
that
is
running
on
here,
right
like
which
is
a
totally
different
scenario
than
rum.
That
is
a
standard,
open,
telemetry
scenario
today
but
like
if
I'm
running
on
some
super
micro
server
with
an
asus
motherboard
or
something
that
this
would
show
up
here,
and
that's
not
really.
What
we're
talking
about
today,
like
is,
is
there
anything
to
delineate
like
the
sort
of
type
of
resource?
Does
that
make
sense.
H
G
Is
definitely
specifically
intended
for
client
client
oriented
devices
you
can
see
all
the
examples
are
very
specific
to
the
mobile.
I
notice
that.
H
G
Yeah,
but
I
do
say
I
do
agree
that
there's
probably
that
description
in
here
probably
needs
a
little
bit
more
explanation
specifically
to
say
this
is
talking
about
like
a
a
user's
mobile
device,
although
if
we
want
to
expand
it
to
iot
devices,
then
it's
probably
also
good.
To
put
it
in
there
I
mean
maybe
there's
iot
stuff.
That
would
actually
be
useful.
G
G
K
G
H
Okay,
so
it
looks
like
for
resource,
then
we
may
already
have
the
basic
information
that
we
need
for
mobile
clients,
perhaps
not
for
web
clients,
and
I
think
the
the
one
thing
we
want
to
to
double
check
with
the
spec
committee
or
the
tc
is
that
device
is
strictly
meant
for
client
device
right
that
that
this
one
that
basically
we
could.
We
could
use
the
presence
of
these
fields
as
a
flag.
H
F
G
G
And
I
I
will,
I
will
push
back
against
using
like
repurposing
service
name
for
that,
because
I
think
it's
very
confusing.
I
know
that
like,
for
example,
if
you,
if
you
use
service
name
to
identify
the
app
name,
app
developers
are
going
to
get
very
confused
and
think
that
it's
they
should.
You
use
to
call
the
thing
that
they're
calling
the
back
end
that
they're
calling,
rather
than
the
actual
name
of
their
app.
G
G
And
I
guess,
along
those
same
lines,
we
have
in
the
service
name
space.
We
have
the
version
of
the
service.
We
probably
we
also
need
the
app
service
yeah
service
version.
So
I
think
basically
we
probably
need
the
same
for
everything.
That's
under
the
service
prefix.
We
need
something
for
the
client
app
or
something
whatever.
C
G
C
G
G
B
So
there
are
two
kinds
of
use
cases:
I've
heard
one
is
you
know
just
like
you
have
a
you
know,
back-end
application,
which
is
sort
of
you
know
it's
microservices-based.
We
have
lots
of
different
services.
You
do
try
to.
You
know,
sort
of
write
your
code
in
a
way
that
has.
B
B
An
example
of
this
would
be,
you
know,
let's
say
your
favorite
stock
trading
app.
There
is
a
part
of
it
which
has
cash
management.
A
separate
team
tends
to
own
that
and
they
consider
that
to
be
sort
of
a
sub
app
within
the
app
to
some
extent.
The
second
kind
of
categorization
is
how
app
packages
are
structured
within
your
own
code
base.
So
you
kind
of
want
to
see.
Oh,
you
know.
The
dart
telemetry
package
is
owned
by
one
specific
team.
The
dart
util
package
is
owned
by
a
separate
team.
G
J
G
G
H
E
G
Well,
the
instrumentation
can't
come
with
the
sdk,
the
instrumentation
will
just
be
using
the
api
and
the
sdk
is
provided
by
the
process.
That's
actually
using
that
library.
I
mean
the
in
some
ways.
The
instrumentation
library
name
and
version
captures
this
sort
of,
but
it
doesn't
really
capture
it
with
within,
like
within
an
application
where
you
have
just
modules
with
internet.
D
B
B
B
So,
like
both
use
cases
that
I
mentioned
right,
that
there
are
yeah
visual
modules
or
like
yeah
outcome
modules,
and
then
there
is
the
actual
packages
which
are
which
tend
to
be
different.
G
H
B
H
H
All
right
so
for
specifically
for
these
client
scenarios,
so
we
already
have
the
device
field.
We
went
over
that
we
need
to
check
with
the
spec
sig
just
to
make
sure
that
find
out
if
we
have
sort
of
for
these
scenarios
exclusive
use
of
this
or
if
there
are
any
other
scenarios
where
device
would
be
filled
in
and
and
the
sort
of
meta
question
here
is,
would
filling
in
the
device
details
be
sufficient?
H
Would
that
be
the
flag
that
back
ends
like
prometheus
or
splunk
or
new
relic
or
whatever
would
use
to
say
this
is
a
span
or
this
is
a
metric
from
a
from
a
client
device
as
opposed
to
from
a
backend
service,
or
should
there
be
something
a
little
more
explicit
that
should
drive
this,
because
maybe
there's
a
chance?
The
device
will
get
used
for
other
scenarios
like
I
mentioned
physical
machines,
but
there
might
be
other
ones.
So
that's.
I
think
one
question
that
we
should
ask
to
the
spec
sig.
H
The
next
was,
and
we
should
come
with
a
stronger
opinion
about
this.
We
need
an
equivalent.
This
is
john
what
you
mentioned.
We
need
equivalent
of
service
for
application
names
and
other
application
metadata.
H
I
don't
know
would
desktop
apps
be
handled
really
differently
than
mobile
applications.
I
mean
they're
both
running
on
an
operating
system,
the
actual
sort
of
metaphors,
at
least
as
a
developer.
That
I
think
are
are
fairly
similar.
I
mean
the
mobile
mobile
os's
are
more
closed
down,
but
fundamentally,
I
think
the
way
we
describe
them
would
be
the
same.
H
H
H
F
So
is
there,
is
there
a
distinction
needed
somewhere
for
the
type
of
the
device
like
if
it's
a
phone
or
tablet,
or
you
know,
desktop.
F
H
It
would
capture
the
model
name,
but
but
in
fairness,
then
everyone
who
analyzes
this
is
gonna
need
a
giant
map
of
device
names,
two
types:
if
they
want
to
use
this,
so
it
might
be
better
to
encode
it
directly
so
that
like
new,
relic
and
dynatrace
and
all
the
other
event
or
or
certainly
the
open
source
projects
like
prometheus,
don't
have
to
be.
The
maintainers
of
giant
like
is
a
is
a
lenovo
a12
a
phone
or
is
it
a
a
laptop
yeah.
E
G
G
Or
the
the
new
microsoft
duo,
which
is
like
it's,
you
know
it's
somewhere
in
between
all
these
things,
so
I
was
actually
to
that
end.
I
was
wondering
whether
we're
missing
things
on
device
like
the
screen
dimensions,
because
some
of
this
could
be
more
specifically
like
modeled
with
dimensions
and
dpi,
or
things
like
that.
B
So
there
are
a
bunch
of
other
screen.
You
know
attributes
that
people
tend
to
want
to
capture,
sometimes
it's
orientation
so
especially
on
a
form
or
a
tablet.
You
want
to
see
if
it's
you
know,
landscape
or
not,
and
there's
also
resolution.
C
I
Right,
how
would
you
capture
them,
so
you
would
capture
it
on
on
spend
basis,
because,
thinking
of
pcs,
the
resolution
could
change.
B
G
G
H
Technically,
you
can
now
on
some
fancy
expensive
vms.
The
cloud
vendors
offer
these
memory
optimized
ones,
but
I
don't.
I
don't
know
if
that,
like
our
end
users,
I
don't
know
if
they
care
to
track.
Yet
if
there's
an
expansion
like
mid
span
or
something
but.
G
H
It's
like
tracking
the
run
of
a
garbage
collector,
for
example,
right
like
it's,
it's
a
performance
impacting
change.
Okay,
yeah!
I
don't
think
that
hotel
captures
this
today.
We
definitely
yeah
I,
but
at
the
same
time
I
don't
know
if
these
vms
are
super
popular
yet,
but
I
remember
gcp
they
were
they
were
releasing
these.
When
I
was
when
I
was
there
last
year,.
H
G
H
H
G
H
That's
what
I
think
makes
the
most
sense
is
is
go
to.
The
next
call
would
be
tuesday
8
a.m
and
and
just
bring
these
up
and
have
carlos
and
bogdan
another's
way
in,
in
particular,
like.
I
suspect
that
this
will
be
an
interesting
topic
of
discussion
with
them,
where
it's
does.
G
Device
doesn't
really
make
sense
for
a
web
browser,
though
exactly
yeah
yep
yeah.
I
thought
but
yeah.
I
think
that
this
next
step
should
we
should
just
bring
up
this.
This
class
of
questions
to
respect
on
tuesday
expect
focus
on
tuesday,
okay
people's
heads,
and
I
think
that
I
think
it's
actually
talking
about
this
idea
of
changing
like
things
that
will
impact
the
performance
of
your
app,
such
as
like
screen
resolution
changes
and
things
like
that.
G
H
F
E
J
Yeah
yeah
on
that
front,
we
cannot
really
trust
anything
that's
sent
from
the
client
side,
but
but
the
location
is
one
of
the
really
key
factors
in
all
the
real
user
monitoring
platforms.
So
you
kinda,
need
to
represent
an
ideal
location
somehow
eventually.
F
And
I
guess
the
related
question
was
for
like
the
the
device
name
or
like
the
browser
identification,
those
will
be
sent
by
the
browser
itself
in
the
user
agent
header.
So
you
know
it
should
be.
Should
the
spec
allow
that
or
define
like
that,
it
doesn't
have
to
be
provided
if
the
if
it's
sent
that.
E
G
E
Which
header
you
are
talking
about
in
the
in
the
otlp,
in
the
request
sent
to
the
back
end
to
the
open,
telemetry
back-end.
E
F
F
So
I'm
just
asking
like,
if
I
guess
I
guess
it
would
be
better
like
if
he
just
explicitly
added
it
as
as
an
attribute
that
he
sent
and
not
rely
on
the
on
anything
that
the
then
that
the
agent,
the
user
agent
itself
sends.
E
Okay,
so
on
on
the
plan
forward,
I
I
didn't
follow,
did
you
john?
Did
you
talk
about
the
using
of
logs
to
represent
events
earlier?
We.
E
Okay,
okay,
so
I
was
wondering
how
to
take
that
forward.
If
we
here
in
this
group
agree
that
it
is
the
log
data
model
that
should
be
used
to
represent
events
outside
of
a
trace,
I
was
reading
the
log
specification.
E
I
think,
although
they
mentioned
that
the
log
model
should
be
used
for
events
too,
but
it
it's
a
subsection.
You
know,
so
it
should
be
highlighted
right
up
front
saying
you
know
the
log
data
model
is
to
be
used
for
logs
and
events
and
then,
as
a
subsection
a
they
should
talk
about
logs
and
subsection
b.
They
should
talk
about
events,
because
events.
G
H
I
don't
think
so.
I
think
there
are
some
but
yeah
and
we
we
should.
If
we
want
to
do
this,
we
also
need
to
work
with
some
of
the
people
on
the
ebpf
there's
an
eppf
sort
of
sega
group
within
open
plummetry,
and
they
they
want
to
have
a
event
proposal
as
well,
so
we'll
probably
want
to
pair
up
with
them.
E
E
But
what
would
the
proposal
be
for?
Because
the
logs
sig
already
agrees
that
it
can
be
the
logs
can
be
used
to
represent
events.
So
the
proposal
is
really
to
list
out
the
semantic
conventions
for
the
names
of
the
events.
E
What
what
we
need,
I
started
a
table
in
the
planned
dock.
We
could,
you
know,
you
know
offline,
fill
that
table
with
more.
F
F
No,
I
was
just
gonna
say
I
was
just
saying,
like
I
think.
Sometimes
I
started
putting
like
some
items
in
the
table
and
I
had
I
started
it
a
list
of
things.
I
think
that
I
thought
we
should
be
working
on
like
into
how
to
achieve
this
section.
F
So
as
far
as
events
like
I'm
also
wondering
like
you
know,
obviously
spans
have
a
concept
of
events
that
are
associated
with
the
span
so
like.
How
do
we
need
to
define
like
the
specific
events
that
would
be
represented
as
logs
as
opposed
to
events
and
spans
like
what?
If
what,
if,
like
the
let's
say,
some
event
happens
and
there's
a
span
in
progress
like,
but
otherwise,
if
there
wasn't
spam
in
progress,
you
would
capture
this
log.
J
F
Yeah
so
like
does
that
create?
Is
there
any
inconsistency
in
like
in
the
back
end
of
processing
that
kind
of
telemetry,
because.
E
F
E
F
So
let's
say
that
you
have:
maybe
you
need
a
separate
discussion
for
this,
but
you
don't
have
that
much
time,
but
you
know
like
let's
say
that
you
have
like
in
the
browser.
You
have
a
pain,
timing
event
and
then,
like
you,
you
want
to
calculate
like
you
know
some
some
averages
on
the
back
end.
Maybe
it
happens.
Maybe
that
event
happens
during
like
the
span.
That's
in
progress,
or
maybe
it
happens
later
like
when
there's
no
spending
progress.
G
F
So
I
think,
in
the
way
I've
I've
been
thinking
about
this,
like
you're
gonna
have
certain
measurements,
they're
gonna
be
metrics
and
certain,
but
they're
also
like.
If
you
wanna
capture
everything
like
in
that
session,
that
happens
in
the
session
for
like
a
session
session,
replay
kind
of
similar
to
a
trace,
then
you
would
capture
it
also
as
a
log.
J
Currently,
the
only
thing
that
could
probably
represent
this
dom
mutations
that
happen
there
is,
it
is
log.
It's
currently
also
what
kind
of
profilers
used
to
to
send
the
profiles
through
so.
F
H
So
I
think
I
think,
for
this
we
need
like
people
need
to
spend
our
time
in
it,
but
we
need
like
a
pretty
concrete
proposal.
What
I
suggest
is
we
put
one
together
with
our.
We
know
down
our
requirements
for
this
right,
the
different
sort
of
things
we
need
to
get
out
of
this.
We
can
sketch
up
a
a
data
format,
and
then
we
chat
with
the
the
ebpf
people.
Maybe
the
profiling
people
like
there's
a
few
other
groups
in
open
telemetry
who
have
all
been
petitioning
for
this.
H
E
Okay,
I
don't
know
if
we
have
time,
but
I
had
one
more
approach
question
quickly,
so
I
guess
with
the
metrics
signal
being
a
standard
one,
do
we
want
to
generate?
Let's
say
the
response
time
of
a
certain
api
call.
Do
we
want
to
we?
It
can
be
derived
on
the
back
end
from
the
span
or
it
could
be
sent
from
the
client
itself
as
a
measurement
object,
and
then
they
can
be
aggregated
into
a
metric
on
the
back
end.
H
There's
there's
benefits
to
doing
it
as
a
metric,
in
addition
to
a
span
just
because
in
some
solutions
spans
will
be
aggressively
sampled
and
the
metric
will
not
be
so
you
can.
You
can
have
a
much
more
accurate
depiction
of
latency.
E
That
is
not
applicable
to
the
client
side,
though.
So,
on
the
back
end,
there
is
a
hotel
collector,
which
would
do
the
sampling,
but
on
the
client
side
you
know
there
is
only
one
data
point
you
have
you
know
this.
E
You
either
take
it
or
drop
it
well,
the
sampling
is
still
applicable,
but
you
would
see
the
I'm.
What
I
meant
is
there
aren't
multiple
measurements
to
aggregate
and
then
compute
a
metric
right.
Those
are
individual
data
points.
You
know
you
would
still
need
to
send
them
across
to
a
common
source
to
compute
the
aggregate
metric.
H
Not
necessarily
for
every
span
so
because,
if
as
a
developer,
if
I
go,
let's
say
I
have
three
services
right
and
calls
coming
from
clients
to
service
a
a
calls
b
b,
call
c.
Then
it
bubbles
back
up
and
goes
to
the
client
and,
let's
say,
on
service
a
I
create
a
custom
span.
In
addition
to
the
one
that
tracks
the
rpcs,
I
create
one,
that's
unique
to
my
business
generally.
The
custom
span
will
not
automatically
have
metrics
generated.
I,
as
the
user
of
the
sdk,
is
the
end
user.
H
If
I'm
making
a
custom
span.
If
I
also
wanted
a
metric
from
that,
I'd
generate
a
custom
metric
or
tell
the
collector
to
go,
derive
one,
but
generally
the
instrumentation
for
like
grpc
or
http
and
and
and
whatever
is
automatically
capturing
those
service
to
service
calls
generally,
that
instrumentation
will
go,
create
a
metric
and
a
spam,
and
so
I
would
suggest
we
probably
do
the
same
here.
I.
H
There
are
various
configurations
of
open
telemetry
where
there
may
be
doing
span
sampling
within
the
sdk
or
within
the
automatic
instrumentation,
and
thus
deriving
a
metric
from
spans
will
not
be
highly
precise,
whereas
that
corp,
if
you
generate
a
metric
in
the
sdk
or
generate
a
metric
inside
of
your
automatic
instrumentation,
then
that
is
something
you
can.
You
can
make
statistical
inferences
on.
H
E
Well,
even
that
that
that
probabilistic
sampling
even
applies
to
sending
the
metric
as
well
right,
they,
at
least
for
the
client
side,
remember
see
on
the
server.
You
know
that
the
same
back-end
is
receiving.
Let's
say
hundreds
of
requests
right,
so
the
metric
computation
could
accommodate
or
take
into
effect
consideration
all
those
requests
and
the
metric
would
be
in
aggregate.
Oh.
E
H
E
E
H
All
right
I'll
add
this
note,
but
I
think
we're
done
see
if
anyone
wants
to
come
and
I
suggest,
as
many
of
us
go
as
we
can,
but
for
anyone
who
wants
to
come
to
the
meeting
with
the
spec
sig
that'll
be
on
tuesday
8
a.m.
Pacific!
It's
on
the
open,
telemetry
calendar!
We
are
now
the
first
item
on
the
agenda.
I
suspect
their
usual
metrics
update
will
be
the
first
item,
so
we'll
actually
be
the
second,
but
we'll
will
be
the
first
real
topic
of
discussion.