►
From YouTube: 2021-06-30 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
We're
one
of
the
modern
crew
we're
we're
mostly
a
pfizer
household
excited
for
my
wife.
C
D
Yeah
likewise,
I
apologize
for
my
very
infrequent
attendance
of
this
meeting.
I'm
going
to
try
to
hit
it
more
regularly.
C
Be
I
was
looking
over
our
notes
from
this
morning's
sig
meeting
to
to
identify
things
that
might
be
interesting
points
to
discuss
in
this
smaller
group.
I
don't
know
if
that
feels
like
a
good
use
in
this
meeting.
B
D
D
It's
the
gears
move
slow,
but
it
does
sound
like
we're
starting
to
get
interest
from
microsoft,
google,
amazon,
splunk
and
hopefully
others
to
actually
work
on
instrumentation
by
bringing
on
more
people
to
help
work
on
it,
not
just
dumping
more
work
on
the
existing
core
group
who,
frankly,
are
at
their
limit
as
far
as
what
they
can
take
on.
So
I've
been
trying
to
get
more
people
involved.
But
you
know
we
need
guidance
here,
and
I
think
the
work
honorag
is
doing
is
is
great.
D
Basically,
I
I
do
have
I'm
not
entirely
sure
that
the
specific
instrumentation
api
that
you
propose
there
is
is
the
the
right
approach,
but
the
general
concept
of
a
higher
level,
higher
level
construct
that
takes
in
some
kind
of
configuration
language
and
then
executes
a
variety
of
metrics
and
other
things
based
on
having
based
on
there
being
a
trace
present
and
based
on
the
span
being
kind
of
like
the
unit.
D
The
the
closure
in
which
all
of
this
stuff
is
occurring,
I
think
that's
the
right
approach
and
also
having
something
having
it
be
explicitly
tight
as
to
what
kind
of
span
it
is
to
some
degree,
or
at
least
having
some
kind
of
explicit
concept
of
a
semantic
convention
type
I
feel
like.
We
need
a
name
for
this
thing
where
the
person
writing
the
instrumentation
can
be
really
guided
on
some
level
as
to
what
information
they
are
trying
to
what
what
the
required
information
is.
D
Basically
in
order
for
that
piece
of
instrumentation
to
execute
properly,
and
I
feel
like
you're
thinking
about
all
of
that
stuff
and
that's
all
present
in
that
otep.
So
I
want
to
thank
you
for
doing
that.
Work.
B
D
The
only
reason
why
I
balk
at
type
span
is
that
you
will
sometimes
want
to
put
potentially
put
more
than
one
invention
on
a
single
span.
That's.
C
D
Been
my
my
concern
with
just
having
it
typed
the
classic
example
is
database
client
that
functions
over
http
like
and
all
that
stuff.
Where
you
would
I
mean,
maybe
this
is
part
of
what
we
have
to
hash
out.
I
think
with
instrumentation
are
some
of
these
more
complicated
cases
of
you
know,
but
I
think
that's
a
classic
example
where
I
think
you
would
want
one
span,
ideally
that
all
the
database
information
on
it
and
all
of
the
http
information
on
it
at
a
lot.
One
logical
span
that
had
all
of
that.
D
B
So,
what's
should
I
share
the
hotep,
then
you
want
to
talk
to
it
or.
D
Yeah
absolutely
you've
gotten
a
fair
amount
of
feedback
on
that.
So
I'd
be
curious
to
hear
what
your
current
thoughts
are
based
on.
You
know,
rather
than
potentially
just
repeat
some
stuff,
other
people
have
been
sitting
in
there.
B
Yeah
I
mean
I
never
again
the
biggest
open
question
I
wrote,
though
tip
was:
does
this
api
apply
to
other
languages,
and
so
the
big
point
of
feedback
that
came
back
was
probably
not,
which
makes
sense,
because
language
is
so
different,
but
I
do
want
to
stress
the
features
that
are
proposed
over
the
actual
epay
itself,
and
so
maybe,
if
this
goes
into
the
spec,
we
wouldn't
go
to
detail
like
open
tomorrow
jp
we
have
the
interfaces
defined
here.
It
might
not
be
quite
so
much.
B
It
could
just
be
more
guidance
like
we
want
to
make
sure
the
each
sort
of
names
like
each
type
of
spanner
like
trait.
I
guess
right.
So
this
each
span
trait
is
defined.
You
know
multiple
of
them,
users
can
configure
it.
Users
can
add
their
own
custom
stuff
if
they
need
so
that
maybe
I
should
rewrite,
though,
to
have
less
code
in
it
and
just
be
more
about
just
talking
through
these
concepts.
D
Yeah,
I
would
like
to
submit
that
we
could
potentially
stick
with
existing
interfaces
and
basically
have
these
instrumentation
objects
be
builders
essentially
or
rather.
This
is
something
that
replaces
the
tracer
potentially
because
the
on
you
know
basically
start
and
end.
D
It's
basically
a
span,
and
when
you
get
to
the
fact
that
the
end
user
is
going
to
want
to
to
do
regular,
spanny
things
with
it,
you
might
as
well
just
have
it
implement
the
entire
span
interface,
so
they
can
add
events
to
it
and
add
add
attributes
at
places
other
than
the
start
and
the
end,
and
things
like
that
might
as
well
just
have
it
go
ahead
and
implement
the
full
span
interface,
because
it's
not
really
that
different
and
then
the
other
question
as
far
as
the
run
time
like
leaving
configuration
aside
is
just
how
do
we
handle
these
like
using
types
or
some
other
form
of
guidance
to
help
users
build
up
these
conventions
and
the
feedback
for
that
particular
one
is
that
I
do
kind
of
agree
with.
D
Is
it's
very
java
it?
I
can
see
how
that
works,
fine
in
java
and
how
like
it?
It
will
really
struggle
in
languages
like
it
kind
of
relies
on
being
able
to
implement
classes
and
some
amount
of
generics
and
some
other
things,
and
I
wonder
if
there's
a
way
we
could
just
do
this
with
like
a
simple
struct
or
something
anyways.
I
maybe
I
don't.
D
I
don't
want
to
jump
into
solutionizing,
but
I
guess
maybe
the
one
point
I
want
to
make
is:
I
think
we
could
stick
to
the
existing
interfaces
for
now.
Maybe
there's
a
question
of
and
there's
just
a
question
of
like
how
do
we?
D
Maybe
it's
a
one,
a
question
of
how
do
we
help
the
users
fill
out
the
right
fill
out
the
form
correctly
and
potentially
you
be
able
to
have
some
safety
mechanism.
I
don't
know
if
we
can
really
do
that,
but
the
degree
to
which
we
can
ensure
that
they
don't
leave
a
gap.
D
B
B
D
D
The
the
thing
about
the
span
is
the
span
actually
does
provide
some
amount
of
context
right,
there's
this
closure
of
the
operation
that
is
represented
by
the
span
and
yeah.
You
could
lift
that
up,
but
then,
at
the
end
of
the
day,
people
are
doing
things
like
it's
almost
you
end
up
creating
like
the
same
object,
but
calling
it
something
else
or
or
you
kind
of
have
it
the
way.
D
D
When
we
were
doing
all
of
that
work
extracting
context
like
we
went
round
and
round
and
round
on
on
this
a
bunch
of
times,
and
it
kept
feeling
like
there's
this
core
bit
of
complexity
and
all
we
were
doing
was
like
squeezing
it
out
of
like
one
spot
and
then
it
would
all
go
blorp
into
some
other
spot
and
you
squeeze
out
there.
It
will
blurp,
but
there
was
there
was
no
way
to
really
can.
I
recap.
C
What
I
so
thank
you
for
catching
me
up
both
of
you,
so
so
I
do
see
a
span
builder
here
as
well,
just
to
confirm
what
I
hear
ted
saying
it's,
but
but
it's
that
the
the
hotel
span
or
the
open
tracing
span
model
that
we
got
from
the
sort
of
beginnings
is
almost
too
low
level.
It's
very
much
a
like.
So
you
want
to
spam.
C
Well,
you're,
going
to
start
it
stop
it
you're
going
to
have
some
attributes
and
that's
like
an
assembly
like
level
of
interface
for
spanning,
but
what
we
all
have
seen
in
our
large
code
bases
and
I've
seen
it
too
is
like.
Not
only
do
I
want
to
create
a
span,
I'm
probably
handling
a
request.
I
want
to
metric
it.
I
want
to
duration
it
I
want
metrics
from
it.
C
I
want
to
have
an
error
log
if
it
fails
in
a
particular
group
of
error
codes,
and
I
want
it
to
be
like
one
line
of
code
and
there's
like
two
or
three
metrics
in
there
there's
at
least
one
potential
optional
log
message,
as
well
as
payload
logging,
which
covers
a
lot
of
sensitive
stuff
like
pii
as
well.
So
there's
like
all
the
all
the
things
kind
of
cross
through
this
one
very
opinionated
builder
pattern
for
creating
some
code.
C
That's
like
higher
level
than
just
I
have
a
span,
and
I
know
how
to
to
make
spans.
I'm
just
confirming
I've
seen
this
pattern.
White
stuff
has
a
piece
of
code
that
I
wrote
and
go
five
years
ago,
and
it's
it's
it's
so
hard
to
remove.
But
it's
it's
doing
more
than
we
want
now
and
it's
it's
because
once
you
have
an
easy
to
use,
instrumentation
pattern,
people
who
just
use
it
like
crazy
and
then
you
have
too
much
instrumentation.
B
B
Some
people
are
using
open
telemetry,
which
is
awesome,
but
it's
very
hard
to
write
good
instrumentation,
if
you're,
only
using
the
open
file
maker
api,
because
it
doesn't
tell
you
what
to
do
and
so
as
like.
There's
handling
the
pi
and
there's
doing
all
these
things,
and
so
a
high
level
api
to
make
it
that
one
line
to
write
good
instrumentation.
That's.
D
Missing,
I
should
say
from
our
current
span
api
that
yours
has
is,
unfortunately,
we
did
not
add
the
ability
to
pass
attributes
and
other
things
as
part
of
the
end
like
the
end
function,
signature
on
the
span
doesn't
have
the
ability
to
be
like
end
with
this
pile
of
attributes
and
stuff.
Isn't
it
used
to
somehow.
D
Option
to
be
able
to
say
here's
the
information
I
grabbed
in
the
middle
somewhere,
and
I
don't
want
to
like
put
it
in
the
box
and
like
cart
it
around
and
wait
till
end.
So
you
end
up
with
those
and
then
also
the
ability
to
put
events
which
again
because
they're
like
time
stamped
things,
you
probably
don't
want
to
force
people
to
collect
the
events
and
their
time
stamps
up.
D
C
B
B
C
I
really
like
this
now
that
I
get
what
you're,
what
you're,
what
you're
after
I
want
to
support
what
ted
said
and
support
what
you're
going
after
then
and
and
something
about
these
events
turns
out
to
be
pretty
important,
and
I
I've
been
struggling
with
one
of
my
own
tips
about
sampling
and
I've
come
to
a
point
where
there's
it's
like
there's
something
that
lightstep
has
been
doing,
that
it's
not
quite
clear
that
anyone
else
wants
to
do
and
I'm
trying
to
try
trying
to
probe
into
that,
and
I'm
also
trying
to
figure
out
well.
C
It's
sort
of
like
a
two
for
one,
and
it's
really
hard
to
sell
that
message
out
there,
because
the
open
source
world
knows
about
prometheus,
which
has
cumulative
metrics,
and
it's
really
hard
to
take
these
high
cardinality
deltas.
That
are
like
spans
that
are
sampled
spans
and
turn
them
into
cumulatives,
or
you
run
out
of
memory,
and
so
it
doesn't
quite
work.
C
C
If
I
need
to
see
a
transaction
or
a
single
unit,
as
ted
was
saying,
so
I'm
trying
to
support
the
idea
that
spans
are
the
primitive
of
open
telemetry
and
they
one
span
event
is
a
bunch
of
metrics
and
a
bunch
of
logs
and
a
transaction
around
a
context,
or
something
like
that,
and-
and
I
don't
want
to
see
us,
try
and
invent
another
thing.
That's
like
a
spam.
B
I
wouldn't
say
that
this
is
trying
to
invent
this
fan
because-
and
I
completely
forgot
to
mention
my
docs-
that's
a
good
point
to
add,
but
the
idea
was
that
this,
like
especially
based
on
the
instrumentation
we've
seen
in
the
java
repo
most
of
them,
don't
use
events.
Maybe
they
should
that's
one
aspect,
but
if
you
need
to
do
more
stuff,
you
can
always
like
you
have
the
span
in
the
context.
B
You
can
the
same
api
works,
you
just
get
the
span
out
and
add
events
that
could
possibly
be
made
easier,
but
that
it
hasn't
we
haven't
found
events
used
enough
for
it
to
be
abstracted
away
or
anything
like
that.
At
least
I
haven't
like
one.
We
haven't
seen
it
enough
to
know
what
abstractions
might
work,
and
so
it's
more
just.
If
you
need
the
events,
you
can
still
do
them
because
the
span
is
there,
and
this
just
tries
to
take
care
of
the
easy
case.
B
C
That
makes
sense
too.
I
mentioned
it
only
in
connection,
because
you're
also
working
on
sampling
right
now
and
I've
been
trying
to
justify
why
we
care
so
much
about
sampling
rates
on
every
span.
It's
because
we
want
to
count
them
and
why
don't
we
just
do
do
metrics,
and
the
answer
is
because
we're
trying
to
count
something
that
includes
a
variable
number
of
events
that
are
like
all
tied
together
in
one
unit
or
one
transaction.
C
So
keeping
that
context
span
connection
feels
important.
B
D
Something
I've
been
trying
to
wrap
my
head
around.
I'm
wondering
if
you
thought
about
this
honorable
or
anyone
else
on
the
call
is
the
efficiency
aspect
of
it
one.
D
Basically,
if
it's
untyped,
let's
say
where
you're
just
let's
say
we're
using
the
generic
span
interface
or
something
like
it,
and
I'm
passing
this
thing
just
like
attributes
like
I
don't
I
can't
get
them
all
at
the
same
time,
there's
a
lot
there's
a
certain
amount
of
checking
that
goes
on.
D
Maybe
let
me
let
me
back
up
put
it
another
way,
so
you've
got
you're
building
up
something
like
a
span.
Data
object
under
the
hood.
I'm
talking
sdk
implementation
now
so
you'd
be
building
up
like
this
span,
data
object
or
something
like
it,
then,
on
end,
you
need
to
sort
of
flush
that
data
to
the
metrics
objects
that
have
been
created
at
startup
right
this
thing's
holding
on
to
a
reference.
So
like
all
the
metrics,
that's
gonna
metrics
objects.
D
C
The
one
I'm
aware
of
is
having
to
do
with
going
all
the
way
back
to
open
census.
There
was
notion
of
a
batch
stats
record
operation
and
things
morphed
quite
a
bit,
but
we
still
had
it
in
the
original
metrics
prototype
and
spec
that
we
had
a
year
ago,
and
it
was
aimed
at
saying
you
know.
We
know,
there's
high
overhead
in
metrics,
often
associated
with
building
up
a
set
of
attributes
and
therefore
we
dedicate
a
lot
of
the
interface
machinery
to
that.
C
But
I
also
could
essentially
output
a
measurement
because
all
of
my
instrumentation
api
is
in
the
context
of
a
single
attribute
set
so
that,
at
the
end
of
my
my
request,
I
now
have
one
effective
attribute
set
that
was
built
up
of
all
my
resources
and
all
the
operations
that
extract
attribute
extractors.
That
happened
and
now
I've
built
up
some
metrics
events
and
I'm
finishing
my
request
and
I
actually
finally
added
in
my
my
response-
error
class
attribute.
C
I'm
done
now
and
now
I'm
in
output,
seven
measurements
with
one
label
set
and
I'd
like
to
use
my
batch
record
operation,
which
means
I'm
only
going
to
pay
one
cost
of
building
up
a
label
set,
and
this
to
me
also
now
connects
with
an
older
otep,
where
I,
a
year
ago,
wrote
about
how
programmers
want
to
stick
their
attributes
into
the
into
the
context
and
just
keep
going
like.
I
want
to
say
I'm
I'm
now
in
leaving
my
requests
and
I've
got
all
my
attributes
are
in
the
context.
C
C
And
I,
I
think
also
what
I'm
seeing
hearing,
especially
when
you
talk
about
http
servers
is
well.
F5
has
been
raising
this
point
about
wanting
multivariate
metric
outputs.
Imagine
instead
of
having
an
aggregator
applied
to
every
metric
instrument
on
the
way
out,
like
we
do
with
very
traditional,
with
prometheus
you're
going
to
output,
one
event,
which
is
all
your
measurements
and
all
your
attributes.
It's
a
single
event
that
includes
some
attributes
and
some
measurements
and
instead
of
aggregating
those.
C
Now
you
just
put
them
into
a
stream
and
then
you
can
aggregate
them
later
and
you
can
compress
them
using
fancy
column.
I
o,
but
the
point
is
that
for
my
efficient
instrumentation
package,
I'm
going
to
start
a
request,
I'm
going
to
add
some
attributes,
I'm
going
to
add
some
measurements,
and
I'm
done.
I
have
a
duration,
and
now
I
output
one
event,
which
is
a
span
like
thing,
but
it
has
many
metrics
measurements
that
were
included
it's
one
event
and
then
you
encode
it
once.
C
D
But
all
of
this
is
like
under
the
hood
to
some
degree
or
maybe
not,
but
I
think
the
end
being
able
to
just
call
on
end
on
a
thing
and
then
yes,
it's
going
to
you,
you
have
your
constructor
at
the
beginning.
D
That
is
the
thing
that
you
call
onstart
on
that
produces
the
thing
call
it
a
span.
Call
it
whatever
that
you're
going
to
call
on
end
on
that
static
object.
Much
like
a
tracer
is
going
to
be
able
to
hold
on
to
all
of
the
reusable
bits
like
across
across
transactions.
D
C
I
was
thinking
also
of
like
action
specific.
Currently
we
have
a
scan
api.
That
says
add
event.
I
could
just
imagine
a
span.
Api,
that's
add
measurement
which,
which
would
be
saying
at
the
end
of
my
span.
I
will
but
I've
added
up
a
bunch
of
measurements
that
are
part
of
my
span
and
then
finishing.
That
span
will
be
a
set
of
attributes
set
of
measurements,
a
duration,
a
set
of
events,
and
that's
your
span
includes
metric
events.
D
Right
like
you,
don't
need
to
make
a
span
and
add
a
bunch
of
metrics
to
it
every
every
single
transaction
right
like
oh,
I
get
it
so
yeah,
oh
okay,
like
those
metrics
objects,
you
tend
to
create
those
at
startup
time
and
then
reuse
them.
You
don't
like
on
every
transaction,
say
new
counter
and
then
count
once
with
it.
No,
no.
C
C
Would
create
this
is
also
reminding
me
of
a
yuri
filed,
an
issue
called
a
prepared
span.
He
was
thinking
about
where
you
say
this
is
the
stand,
and
it
has
this
these
exact
attributes
and
we'll
also
have
these
measurements,
and
then
you
know
to
do
a
bunch
of
encoding
work
up
front
and
you
just
fill
in
the
values
at
the
end
of
your
span,
and
it
has
a
schema
effectively.
That
includes
some
metrics
that
that's
what
this
instrument
object
is.
C
I
see
I'm
interested
in
this
more
because
in
go
so
there's
one
question
about:
how
do
you
efficiently
build
and
maintain
these
attribute
sets
and
then
there's
a
separate
question
about?
How
do
you
build
and
maintain
these
sets
of
measurements
and
the
sensor
measurements
in
the
traditional
api
that
I've
got?
For
example,
it's
like
you've
declared
your
instrument
up
here.
C
I'm
talking
about
go
of
course,
and
for
the
one
I'm
interested
in
the
segment
I
o,
where
they
have
a
batch
measurement
interface,
where
you
don't
give
three
counter
three
instruments
and
three
numbers:
you
create
a
struct
with
a
bunch
of
struct
tags
and
the
struct
tags
are
like.
This
is
my
counter
field.
It's
my
second
counter
field
is
my
gauge
field
and
they
they
have
field
names,
but
they
also
have
like
metadata
in
their
struct
tags.
C
It
says
counter
gauge,
histogram
or
whatever,
and
then
at
the
end
of
your
request,
or
even
at
the
beginning
of
your
request,
which
is
what
you're
saying
ted
you
say:
here's
a
template
for
my
my
measurements
in
this
particular
instrumentation.
It's
got
three
fields,
it's
counter.
It's
a
counter.
It's
a
gauge
and
then
building
that
prepared
span
includes
registering
three
instruments
which
are
going
to
be
effective,
like
implied
when
you
finish
this
instrumentation
request,
so
that
you
would
never
have
to
allocate
three
instruments.
C
B
Yeah,
I
think
one
so
while
I
was
working
on
the
metrics,
I
could
imagine,
for
example,
having
http
server
metrics,
which
is
sort
of
the
collection
of
all
metrics
based
gp
server
and
then
db
metrics.
If
there's
something
like,
I
imagine,
there's
semantic
metrics.
Also,
we
haven't
spec
them
out
very
well
yet,
but
in
that
sense.
B
C
And
we
want
to
measure
the
duration
of
spans,
and
so
there
will
be
two
options.
One
is
a
sort
of
like
the
old-school
way
of
just
like
brute
force
count
everything,
and
so
you
install
a
metrics
library
and
every
hd
span
gets
counted
at
some
cardinality
and
then
there's
a.
I
guess:
lower
cost
more
approximate
approach,
where
you
say
I'm
going
to
sample
my
spans,
I'm
going
to
include
that
probability
score.
That's
really
important
to
us,
I'm
going
to
send
it
to
a
collector
and
the
collector
can
be
configured
with
different
queries.
C
That
will
then
approximately
count
those
spans
as
if
you
had
a
metrics
library
in
the
first
place,
it
seems
like
an
opportunity
to
not
have
to
specify
double
sets
of
conventions.
Yep.
B
D
I
I
wonder
whether
I
I
guess
there's
like
two
ways
we
can
go
with
this
one.
Is
that
we're
building
more
surface
area
for
end
users
to
comprehend,
and
maybe
this
new
surface
area
we're
building,
is
fundamentally
simpler
in
some
way
and
so
going
back
to
our
user
base
and
being
like.
D
So
we
showed
you
all
of
the
existing
apis
and
told
you
how
to
use
them,
but
forget
we
said
anything
about
that
and
use
this
new
api
instead,
but
also
you
may
need
to
crack
these
things
open,
sometimes
so
they're
also
still
hanging
around
in
some
way.
D
So
that's
that's
one
approach
and
it
could
be
that
there's
a
way
of
doing
this
where
everything's
stored
in
the
context
you
access
the
context
implicitly
in
most
languages
or
you
pass
it
explicitly,
and
that
looks
normal
because
you're
go
in
which
case
you
have
something
like
what
you're
doing,
except
rather
than
calling
it
an
instrument.
D
But
instead
you're
saying
like
what
I'm
doing
is
I'm
creating
an
operation
level
scope.
So
we
have
kind
of
like
a
transaction
level
scope
and
then
an
operation
level
scope,
and
when
this
scope
ends
it's
going
to
produce
a
bunch
of
stuff
and
in
the
meantime,
when
I'm
in
that
scope.
If
I'm
just
saying
log
log
log,
those
logs
are
getting
appended
to
that
particular.
C
Scope,
you
just
reminded
me
of
some
trouble,
though
ted
and
I
I
posted
a
link
to
the
otep,
where
I
wrote
up
a
lot
of
this
same
idea-
that
there's
a
resource
scope
that
you
can
enter
and
exit,
and
it's
a
lot
like
the
instrumentation
scope.
The
way
we
used
it,
but
the
way
we
I
have
this
one
liner
again
it's
in
go
it's
used
across
life
such
code.
It's
called
report
method.
The
idea
is
that
you're
you're
instrumenting
one
method,
and
then
we
end
up.
It
was
too
expensive.
C
So
we
created
a
report
method
light
which
was
the
lighter
weight
version
of
the
same
thing
where
you
could
turn
down
something.
A
bunch
of
stuff
and
report
method
had
a
way
to
add
attributes
in
this
call
site
in
this
scope.
C
That
would
not
leave
the
scope,
so
those
become
span
attributes,
but
it
also
had
ways
to
add
new
context
variables
that
were
going
to
be
entered
as
context
variables
that
would
propagate
into
children,
and
it
was
really
hard
to
explain
to
users
how
they
had
two
choices
of
injecting
attributes
at
this
one
call
site
with
options
to
say,
add,
scope,
variables
and
add
context
variables,
and
it
blew
people's
mind
and
no
one
understands
it.
So
I'm
worried
I
just
got
worried
when
I
heard
ted
well,
I
I've
run
out
of
time
here.
C
D
Yeah,
okay,
so
anyways.
I
think
that's
that's
one
approach,
but
I
I
just
want
to
say
I
have
beat
around
that
bush
with
josh
and
other
people
for
including
yuri
and
and
a
lot
of
other
people
in
the
community
for
a
while
trying
to
find
some
way
to
make
it
simpler
and
make
the
span
object
like
kind
of
go
away
somehow,
and
we've
never
been
able
to
really
do
it
at
the
end
of
the
day,
you
could
end
up
just
effectively
recreating
all
the
things
the
span
current
for
better.
D
For
worse
all
the
things
the
span
and
the
tracing
system
currently
do
in
open
telemetry,
and
so
my
only
concern
about
not
just
saying
this
is
a
thing
that
implements
that
span
interface.
So
this
is
just
tracing
plus
plus,
where
you've
got
your
trace
going
and
your
operational
level
scope,
and
it's
also
generating
metrics
and
things
out
of
the
attributes.
D
You're
handing
it
and
there's
a
way
to
hand
it
typed
objects
that
help
the
end
user,
like
record
the
right
data
or
for
common
objects,
even
automatically
record
them
sort
of
like
in
your
java
example,
where
you
could
say
like.
I
just
want
to
be
able
to
feed
like
and
go.
It
would
be
like
the
standard,
http
request
and
response
object
into
this
thing
and
not
have
to
think
about
anything
else.
D
But
then
I
have
to
make
a
typed
version
of
that
for
every
http
gizmo
anyone
ever
wrote
at
the
end
of
the
day.
D
It
seems
like
to
me
just
sticking
with
this
fan
interface,
because
it
seems
like
the
only
extra
api
surface
area
we
would
really
have
to
add,
would
be
this
way
of
having
like
typed
conventions
or
like
convention
helpers,
and
this
way
of
constructing
this,
like
instrumented
tracer,
like
the
configuration
language
for
that
thing.
So
you
have
like
how
do
I
configure
this,
this
big
beefy
guy
and
what
are
the
ways
of
like
feeding
it?
B
So
I
I
still
like
the
word
instrument
just
for
the
meaning,
what
it's
doing,
but
really
it's
just
a
context.
Builder.
Okay,
like
I
find
this
approach
currently
to
be
quite
minimal
because
it
is
like
it.
The
end
result
is
a
context
of
the
span
inside
it
there.
It
is
open.
Palmetto
api,
I
would
say,
is
just
building
that
context
more
easily
for
library,
instrumentation,
yeah
yeah.
I
I
think
like
maybe
just
like.
Is
there
something
concretely,
you
find
that's
too
different
from
the
open
thumb
jpeg
in
well.
I
think.
D
Well,
the
one
thing
I
noticed:
it's
like
almost
the
span
api
and
the
things
that
make
it
different,
I
would
say,
are
the
way
it's
currently
handling
semantic
conventions,
but
the
problem
is
the
way
it's
currently
doing.
That
is
very,
very
java,
specific
yeah
and.
B
D
D
Is
it
wouldn't
be
able
to
look
like
that
so
much
in
other
languages
necessarily
or
it
will
kind
of
look
like
that,
but
you're
gonna
have
to
write
like
a
bunch
of
adapter
objects,
anyways
and
once
you've
got
this
like
adapter
object
that,
like
that
adapter
object,
could
just
have
a
like
record
generic
record
method
that
took
a
took
a
span
or
a
context
right,
and
so
you
don't
need
the
typed
arguments
to
on
start
and
on
end
anymore,
and
so
I
wonder
once
you
do
that,
and
then
you
have
the
inevitable
issue
of
the
end
users
coming
back
and
being
like
yeah,
but
I
want
to
add
some
other
attributes
to
this
thing
and
I
want
to
be
able
to
log
some,
and
actually
I
can't
give
you
the
stuff
at
the
beginning
or
the
end.
D
I
got
to
give
it
to
you
in
the
middle,
because
that's
where
I
have
the
route
slug,
I
have
the
route
slug
at
this,
like
other
piece
of
the
framework
that
calls
me
back
here,
and
so
my
concern
is
like
once
once
those
inevitable
requests
start
coming
in
you'll
end
up
with
effectively
either
having
all
of
the
span
methods
added
back
to
it
or
telling
the
user
to
juggle
two
objects
that
like
look
very
similar,
which
and
I'm
not
sure
if
that's
simpler
and
if
the
way
the
typing
works
is
those
typed
objects
are
separate
and
they
just
have
a
generic
record
method
on
them.
D
B
D
D
Above
the
hood
like
at
the
api
layer,
like
is
this
instrumentation
object,
implemented
by
the
sdk,
or
is
this
something
that
sits
like
purely
on
top
of
the
api,
and
if
it
sits
purely
on
top
of
the
api,
then
yes,
the
way
you
have.
It
would
make
sense
where
this
thing
has
an
on
start
and
on
end,
and
it
remembers
the
pile
of
metrics
and
things
that
it
created
using
the
api
methodology
for
doing
all
of
that
stuff.
D
You
could
think
you
use
the
span
data
object
as
like
the
storage
and
then
being
able
to
just
slam
those
labels
into
the
metrics,
and,
if
you're
doing
this
like
on
top
of
the
api,
I
feel
like
you
would
end
up
having
to
like
store
that
data
in
like
a
third
spot
and
hand
it
around
to
all
of
the
things.
I
could
be
wrong
about
that,
but
that
I
guess
that
was
my
efficiency
question.
If
it
works,
then
cool.
This
is
now
like
totally
api
level.
D
Abstraction
thing,
the
sdk
writers
don't
have
to
to
think
about
this
thing
and
that'd
be
cool,
but
I'm
a
little
worried
that
that
might,
if,
in
the
process
of
trying
to
implement
that
thing,
the
implementation
of
the
instrumentation
object
starts
to
get
bloated
and
weird.
D
B
D
But
you're,
you
know
what
it
like.
You
have
a
thing.
That's
like
this
instrumentation
object
that
you
built,
you
know,
works
the
same
as
span,
but
that
probably
won't
confuse
anyone,
especially
if
we
we
hand
them
we're,
also
handing
them
convenience
for
all
of
the
operations
they
would
be
performing
along
the
way.
D
D
D
You
end
up
with
this
this
other
package,
this
convenience
package
that
we've
been
talking
about
that
is
like
this
instrumentation
object,
and
then
these,
like
one-liner
helpers
around
and
it's
like
all
sitting
on
top
of
these
lower
level
apis
and
then
that's
ultimately,
what
we're
giving
to
end
users.
So
you
have
this
thing,
this
operation,
that
you
start
and
end
and
then
you're
just
saying
record,
attribute
and
log
and
etc
along
the
way,
and
also
here's
a
pile
of.
D
Resource
converters
right,
like
like
you,
need
a
name
that
isn't
semantic
conventions
that
is
such
a
mouthful
but
like
a
way
to
like
object.
Recorders,
I
don't
know
just
just
ways
to
like
record
these
convention
types.
D
Yeah
I
like
it.
D
Yes,
yeah.
I
think
I
would
really
want
to
see
this
in
like
well.
I
definitely
want
to
see
him
go
and
then
I
would
want
to
see
it
in
probably
python
I
want
to
say,
or
maybe
javascript
just
go
straight
to
the
straight
to
the
hard
ones.
D
I
just
sometimes
worry
where,
like
maybe
javascript
is
just
like
nothing's
ever
going
to
be
good
there
because
javascript,
we
can't
like
worry
too
much,
but
one
of
those
things
probably
is
the
correct
thing.
Maybe
python,
maybe
just
whoever
is
able
to
actually
do
prototyping.
C
D
That's
that's
what
I'm
thinking
there's
a
a
proposal
that
I'm
gonna
give
some
comments
to
after
this
meeting
and
that's
that's
kind
of
due
the
first.
It's
getting
that
proposal.
You
can
see
it
in
the
instrumentation,
there's
a
hotel,
instrumentation
channel
and
slack
and
there's
a
proposal.
That's
put
there
for
like
scope
of
work.
D
D
D
The
the
thing
that
we
haven't
talked
about
here
that
I
think
is
ultimately
going
to
be
the
biggest
bug
bear.
Maybe
is
the
configuration
language
for
all
of
this
stuff,
and
it
would
be
great
to
really
think
that
through
deeply
in
my
ideal
world,
we
think
it
through
deeply
enough
that
you
know
you
can
go
all
the
way
to
like
a
config
file.
D
The
same
config
language
is
like
what
you
would
ultimately
configure
the
sdk
with
and
your
metrics
and
your
sampling
and
all
the
other
things.
I'd
really
like
to
see
that
and
then
be
able
to
maybe
take
something
like
that
and
also
have
it
be
somewhat
similar
to.
D
So
it
would
be
great
if
we
could
come
up
with
some
cohesive
way
that
the
end
user
configures,
what
the
hell
they
want,
because
we'll
be
able
to
hand
them
defaults.
That
are
saying,
but
it's
super
clear,
that
they're
going
to
want
to
change
the
defaults
they're
going
to
want
to
build
these
for
non-standard
conventions,
their
own
internal
stuff.
D
You
know
once
once
people
realize
that,
like
rather
than
peppering
ins,
metrics
instrumentation
all
around
their
application
code,
they
like
don't
have
to
do
that.
They
can
just
like
get
the
get
the
context,
propagation
working
and
then
like
in
a
configuration
file
somewhere
write
down
what
things
they
want
recorded.
D
D
D
Yeah,
there's
no
need
to
wait
until
the
15th
to
be
working
on
this.
That's
just
like
we're
we're
having
to
plan
out
a
bit
in
order
to
be
able
to
give
managers
a
chance
to
like
take
this
scope
of
work
document
back
the
company
and
be
like
I'm
gonna
allocate
these
engineers
to
working
on
this
thing,
and
this
is
the
thing
they're
going
to
be
working
on.
So
we'll
see
people
trickle
in.
B
D
When
we
start
that
instrumentation
sig,
that
one
should
be
in
pacific
time-
and
we
should
just
be
like
this
one's
in
pacific
time-
and
if
it
ends
up
meaning
some
people
can't
come
to
the
meeting,
we
could
maybe
think
about
setting
up
a
secondary
meeting
that's
in
the
morning.
But
I
would
like
to
to
keep
this
work
centered.
D
But
maybe
we
can
just
have
a
weekly
bump
the
bump.
This
meetings
cadence
up
to
once
a
week
instead
of
bi-weekly.
D
B
D
A
It's
a
very-
and
I
will
just
say
this
mobile
is
a
very,
very,
very
different
thing
than
instrumenting
a
bunch
of
server
code.
It
just
works
completely
like
like
yeah,
it's
just
completely
different.
It's
like
the
concerns
are
so
different
that
it's
been
interesting
to
wrap
my
head
around.
So
oh
and
I
I
don't
think,
like,
I
think,
a
bunch
of
our.
A
I
know
that
at
least
one
person
has
been
trying
to
like
start
the
talk
about
spanning
conventions
around
mobile,
but
I
think,
there's
actually
a
bigger,
bigger
issue
around
instrumentation
of
mobile
and
what
should
be
captured
and
what
kinds
of
things
should
be
captured
and
how
it
should
be
captured,
because
it's
not
the
same
as
what
you
do
on
a
server.
A
A
I
don't
know
I
mean,
but
but
again
when
you're
talking
about
a
mobile
device,
the
amount
of
data
you
want
to
limit
the
number
of
protocols
you
send
data
out
with
right,
like
you
want
to
have
that
be
very
limited
and
the
amount
of
data
you
send
out,
but
very
limited,
also
because
you're
using
the
customer's
money,
like
the
user's
money,
rather
than
just
like
someone
running
a
big
server.
So
anyway,
yeah
there's
a.
A
D
A
A
A
I
don't
know
I
that's
it's
interesting
yeah
I
mean
aren't
those
just
more
conventions,
essentially,
maybe,
but
again,
I
think
different
drum
solutions
have
different
ways
of
visualizing
that
stuff,
it's
not
just
a
span.
Waterfall
right
like
there's
a
whole
bunch
of
other
different
kinds
of
ways
to
look
at
that
data,
and
that's.
A
Been
using
the
open,
telemetry
apis
for
java,
basically,
a
hundred
percent
just
using
that
and
then
putting
some
extra
layers
on
top
of
it
to
make
it
right.
D
That's
good
to
know
that
that
that
all
is
fully
functional.
It's
just
that
writing
instrumentation
turns
out
to
be
crazy-making.
It's.
A
Just
a
different
way
of
thinking,
I
mean
it's
just
it's
a
different
model
like
you're,
not
dealing
with
thousands
of
requests,
a
second
you're
dealing
with
the
user
clicking
on
some
stuff
here
and
there
yeah
scrolling
through
things
yeah
and
in
a
lot
of
ways,
a
lot
of
ways
thinking
about
context,
propagation
within
the
process.
A
It
just
doesn't
matter
like
because,
like
you
just
generate
some
spans,
they
can
be
totally
disconnected
and
it's
still
going
to
be
fine,
because
you'll
be
able
to
see
exactly
what
the
user
did
like
the
the
causal
relationship
between
them
is
irrelevant.
It's
just
when
they
happen.
That
really
is
the
only
thing
that
matters
so
there's
some
interesting,
interesting
things.
A
Actually,
I've
been
using
all
of
the
context
stuff
and
it
actually
gets
confusing,
because
there's
things
that
happen
on
background
threads
that
you
may
not
like
that
are
intuitively
connected
to
what's
going
on,
but
you
can't
connect
them
and
then
these
other
things
that
aren't
intuitively
connected,
but
because
the
ui
there's
only
one
ui
thread,
they
end
up
being
using
the
context
and
having
nested
spans
that
don't
even
make
sense
in
that.
In
that
way,
yeah
anyway,
it's
a
it's
a
definitely
a
different,
a
different
world.
D
Yeah
definitely
a
ways
away
from
that
right
now
I
imagine
I
mean
front
end
like
javascript
is
like
I'm
a.
I
have
a
feeling
like
that,
sits
somewhere
in
the
middle
you're,
exactly
correct.
It
does
that's
perfectly
true,
yeah
yeah.
As
soon
as
you
get
this
kind
of
reactor
pattern
going,
which
really
is
much
more
in
your
face
on
mobile
and
in
apps
than
it
is
on
servers
where
it's
it's
not
like.
There's
a
transaction.
D
It's
like
there's
this
reactor,
that's
just
like
going
in
a
cycle
and
like
slamming
out
a
frame
buffer
into
the
graphics.
You
know,
and
just
just
like
spinning
there
in
the
background
and
that's
like
and
like
things
are
happening
and
changing
what
it's
doing
and
it's
responding
to
those
things
and
gc
happens.
It
pauses
the
whole
thing
and
I
can
see
how
the
relationship
to
why
did
the
gc
pause?
Because
that's
actually
what's
slowing
this
thing
down,
it's
like
well
tracing's
not
going
to
really
tell
you
that.
A
C
A
They
want,
they
really
want
all
the
android
devs
to
use
that
to
monitor
their
apps
and
they
don't
expose
any
of
the
apis
or
any
of
that
data
to
user
space
at
all.
So
yeah
I've
been
talking
with
I've
started
chatting
with
josh
sureth
to
try
to
see
if
he
can
rope.
Some
android
folks
in
to
you
know,
come
into
the
community
and
start
thinking
talking
with
the
rest
of
us
about
how
to
how
to
do
this
long
term.
Yeah.
A
B
A
D
We're
really
at
max
and
it's
why
I
like
punted
on
the
sampling
sig
for
so
so
long,
because
there's
like
a
bunch
of
people
like
sampling,
but
when
I
would
talk
to
them,
they're,
like
they're,
all
interested
in
different
stuff,
basically,
and
even
like
the
stuff,
they
were
interested
where
it
overlapped
implementation,
wise.
D
It's
an
overlap
and
I
was
like.
I
don't
think
it
would
be
wise
for
this
thing
to
be
rolling
along
on
its
own,
without,
like
some
tc
attention
like
josh
or
somebody
being
able
to
ride,
hurt
on
it
just
to
make
sure
we
don't
end
up
with
some
kind
of
weird
cluj,
but
we
were
able
to
get
the
the
jaeger
people
to
kind
of
hold
it
down
so
that'll.
I
gotta
run
but
good
to
chat.
B
So
I
will
hopefully
find
a
volunteer
to
help
with
prototyping
on
the
instrumentation
stuff
I'll
try
to
address
like
I'll
try
to
incorporate
some
feedback,
especially
there
isn't
enough
detail
about
the
interaction
with
the
current
api,
which
I
sort
of
miss
like
how
you
add
events
and
whatnot.
So
that'll
do
yeah.