►
From YouTube: 2022-04-26 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
B
Hello,
hello,
how
are
you
man
I'm
doing?
Okay,
although
maybe
I
should
need
to
be
like
product
sponsoring
tito's
vodka
here.
So
maybe
I
could
cover
up
my
thing
like
this,
so
I
don't
get
free
free
sponsorship
from
me.
B
I
think
I
think
tito's
is
corn
corn
mash
from
from
the
u.s.
B
Yeah,
I
don't
think
we,
I
don't
think
we
have
any
potato
vodka
makers
here
in
in
texas
at
all.
So
I
think,
that's
mostly
like
eastern
european
style
vodkas.
A
B
Corn,
vodka,
not
that
the
the
folks
in
you
know,
on
the
internet
or
on
youtube,
need
to
know
this,
but,
like
I
won
this
hat,
because
I
wanted
a
case
of
tito
vodka
at
a
raffle,
so
you
know
there's
that
I
didn't
drink
it
all.
B
B
So
where
is
everybody
who
normally
comes
to
these
meetings?
I
wonder.
B
So
one
I
think
eric
can
mention
that
he's
stepping
away
from
doing
the
active
development
on
anything
because
he
switched
off
of
the
observability
team,
where
he
you
know,
and
his
current
employer-
and
I
know
that
I
thought
andrew
was
gonna-
be
coming
on
a
more
regular
basis,
since
he
is
doing
that
like
what's
the
role,
I
guess
you
call
those
like
not
developer
evangelists.
B
What
do
you
call
those
develop
advocates
right,
yeah,
the
kid
he's
responding
right
now,
sam
usually
has
been
coming
on
a
regular
basis,
and
robert
kind
of
I
don't
know.
A
B
A
B
Oh,
oh,
oh
kirk,
haynes,
yeah,
okay,
yeah,
yeah,
yeah.
I
haven't
met
him
yet,
but
interacted
with
him
yeah
all
right.
Well,
I
guess
it's
just
you
and
I.
What
do
you
want
to
talk
about.
A
Yeah
good
question:
what
how
can
we
make
the
best
use
of
this
meeting?
I
know
we
have
the
trib
split
out
in
progress.
Eric
was
your
partner
in
crime,
but
he
has
given
up
his
life,
a
crime
for
for
other
things.
So
I
think.
B
Yeah,
okay,
I
mean
I
could
give
you
like
an
overview
of
where
I'm
at
with
that
to
let
you
know
kind
of
like
what
my
thought
process
was.
A
Yeah
yeah,
I
wasn't
letting
you
know
we
did.
We
did
get
to
a
sam
handler
replacement,
I'm
not
sure
if.
B
We
haven't
touched
a
base,
yet
so
what
I
shall
do
is
I
will
share
my
screen.
I'm
gonna
have
to
like
close
out
these
other
private.
You
know
nda
requirements
right,
so
here's
some
little
secrets
that
you
don't
know
about
github,
but
when
you're,
when
you
work
here,
you
get
all
these
cool
little
tools
that
give
you
like
diagnostic
information
about
the
site.
B
So
don't
tell
anybody,
except
for
youtube
that
that's
what
we
that's
built
into
our
application
anyway,
long
story
longer,
so
we
got
a
couple
of
pr's
that
are
here
and
one
of
them
is
this
hotel
test
helper
gem,
so
I
opened
up
a
request
to
create
it,
because
I
think
that
this
this
is
gonna
stay
in
the
upstream
repository
and
it
looks
like
this
was
something
that,
on
those
were
factored
out
of
the
existing
testing
suites
and
getting
reused
everywhere.
B
So
what
my
plan
was,
you
know
once
this
one
is
released,
then
I
can
start
on
the
process
of
removing
the
references
in
the
code
base
itself.
So
looking
at
the
instrumentation
directory
as
an
example,
all
of
these
have
local
references
to
the
gems
that
are
in
the
current
path
right
so
like
this
is
saying.
Instead
of
resolving
the
api
jam
remotely,
I
want
you
to
resolve
the
api
gem
locally
in
this
repository
through
this
path,
to
decouple
ourselves
from
that.
B
What
we
would
do
is
remove
those
paths
and
only
rely
on
published
versions
of
the
gems
so
that,
when
they're
extracted
out
and
moved
into
them
into
the
other
repository,
I
can
delete
them
without
them
breaking
anything
essentially
right.
So
that's
that's
one
of
the
that's
one
of
the
things
and
as
I've
already
mentioned,
this
test
helpers
gem
was
new
and
it
was
introduced
but
never
released.
B
So
the
other
bit
is
we're
trying
to
replace
references
or
coupling
between
the
sdk
and
the
base
gem.
So
the
instrumentation
in
base
gem
there's
like
a
circular
dependency
here
where
it's
like
the
base.
Gem
depends
on
the
sdk
implementation
and
the
sdk
depending
on
the
base,
and
that's
why
we
extracted
the
registry
gem.
B
So
my
plan
here
would
be
to
say:
have
the
sdk
depend
on
this
registry
and
then
have
the
instrumentation
based
depend
on
the
registry,
and
the
base
can
also
depend
on
the
sdk
so
that
it
can
run
its
tests
as
a
because
right
now,
it's
doing
them
more
as
like
a
macro
test,
as
opposed
to
micro
tests
more
almost
going
through
the
motions
of
like
installing
the
instrumentation
via
the
sdk
configurator
hooks.
B
So
that
would
always
necessitate
sort
of
you
know:
release
of
the
sdk
itself,
and
so
those
are
the
the
next
bit
of
steps,
and
I
started.
B
I
started
the
approach
you
know
in
this
pr,
which
is
what
ended
up
breaking
realizing:
hey,
there's.
No
that's
what
revealed
to
me
that
there
was
a
missing
a
gem.
This
test,
helper's
gym.
B
B
But
I,
but
I
paused
on
them
for
a
little
bit,
so
I'm
gonna
look
back
at
another
one
and
I'm
gonna
occupy
all
of
your
time
with
things
that
I'm
working
on.
So
francis
gave
me
some
feedback
here,
because
essentially
what
I'm
trying
to
do?
We
have
this
observer
class.
We
call
a
metrics
reporter
that's
getting
injected
into
the
batchband
processor
and
getting
injected
into
the
otlp
exporter.
B
B
This
this
change
is
well.
Why
don't
we
actually?
Let's
look
at
the
code
on
the
branch
instead,
that
might
be
a
little
easier
to
view.
So
what
happens
when
you
configure
the
exporter?
Is
that
there's
a
bunch
of
conditional
logic
and
there's
conditional
construction
depending
on
what
version
you're
using
right?
And
we
have
like
this
fetch
exporter
function
which
actually
doesn't
return?
B
An
exporter
returns
a
batch
band
processor
with
the
exporter
injected
into
it,
but
only
the
otlp
exporter
supports
this
metrics
reporter
observer,
essentially
that
we
use
to
publish
statistics
about
the
success
and
failure
rates
and
latency
of
the
otopx
border
yeah.
Those
are
not
implemented
in
the
collector
exporter
and
the
exporter,
which
causes
a
little
bit
of
this
conflict
here
and
complexity.
I
think
so
my
desire
to
make
it
possible
for
an
end
user
to
inject
an
ex
this
metrics
exporter.
B
An
implementation
of
the
metric
exporter
through
the
configurator
made
me
realize
that
you
know
what
this
asymmetry
here
and
this
lack
of
functionality
here
makes
that
really
difficult,
because
it
ends
up
just
adding
more
conditional
logic.
Was
this
collector
exporter?
B
Is
this
the
jager
collector
exporter?
If
so
use
the
metric
do
not
use
the
metrics
reporter
and
so
on
and
so
forth.
So
I
think
I
want
to
work
on
adding
similar
functionality
of
the
metrics
exported
to
so
the
message
reporter
to
these
two
other
exporters,
so
the
jager
one
and
the
zip
and
one,
and
that
should
give
us
the
symmetry
that
we
need
to.
B
A
A
So
I've
been
kind
of
fine
with
that,
but
are.
Are
we
formalizing?
This?
Is
this
something
that
every
exporter
will
have
to
implement
in
the
future
going
forward,
or
is
this
just?
Will
this
just
be
convenient
for
at
least
the
core
exporters
that
we
have,
and
I
don't
know
in
the
end?
Is
it
just
easier
for
us
to
have
this
functionality
in
these
exporters
and
then
just
have
like
a
bunch
of
conditional
logic
about
like
whether
or
not
you
can
have
a
reporter
wired
up
for
them?.
B
So
those
are
do
those
are
good
questions.
One
it'd
be
interesting
to
see
what
the
metrics
sdk
and
how
it
interplays,
with
reporting
like,
if
there's
any
functionality
that
we
should
be
supporting
in
sdk,
officially
right
this
on
the
books
thing,
because
we
haven't
done
any,
we
haven't
had
any
proposals
so
far,
as
far
as
I
know
to
say
how
do
we
measure
the
client
sdk
performance
right
like
we
do,
with
the
collector
like,
or
at
least
like
there
is,
with
the
collector
these.
B
Any
custom,
spam
processors
or
exporters
in
this
block-
I
don't
know
that
we
require
it
of
other
people.
So
say
you
had
your
own
implementation
of
exporter
and
you
were
using
the
batchman
processor
provided
by
the
sdk.
B
You
could,
and
you
were
aware
of
the
fact
that
the
metrics
report
was
something
that
was
useful
to
you.
Then
you
can
implement
it
and
inject
it
yourself.
In
this
case.
This
would
be
only
for
the
built-in
exporters
and
only
if
you're,
using
the
environment
variable
to
determine
whether
or
not
you're
going
to
con.
You
know
to
use
it
for
the
configuration
and
construction
of
your
spam
processing
pipelines.
A
A
A
Just
will
will
not
be
impacted
by
this.
If
I'm
understanding-
yes,
that's
right
and
yeah
so
like
right
now,
I
think
you
would,
for
example,
like
have
there's
no
like
stock
implementation
of
a
metrics
reporter.
A
You
would
other
than
probably
something
that's
not
operational,
but
you
would,
as
an
end
user,
potentially
provide
your
own
custom
implementation
that
emits
stuff
in
like
stash
d
or
prometheus,
if
you're
a
little
bit
more
of
a
hipster,
and
I
guess
in
the
future,
like
we'll,
probably
be
able
to
have
an
an
otlp
based
one
or
one
that
just
like
uses
like
a
straight
up
metric,
a
a
meter
provider-
and
I
just
want
to
make
sure
like
the
door
is
open
for
the
open,
telemetry
based
kind
of
like
I
don't
know,
I
think
in
the
collector.
A
They
call
this
like
the
obs
report.
It's
like,
I
think,
we're
kind
of
like
have
like
the
beginnings
of
this
for.
B
You
know
this.
This
is
like
pointing
out
sort
of
like
the
asymmetry
between
the
client
sdk
and
the
collector
report.
The
the
collector.
I
don't
understand
why
the
architecture
is
different.
B
Right,
like
we
have
the
notion
of
pipelines
and
in
the
collector,
but
not
a
notion
of
pipelines
in
the
sdk
like
they're,
conceptually
the
same
thing
right
because
we're
taking
the
source
data,
but
the
absence
site,
with
the
exception
of
the
fact
that
the
sdk
doesn't
have
receivers
to
in
its
own
sense,
like
the
propagators,
is
the
only
entry
point
for
the
sdk
and
how
to
link
itself
to
other
traces.
B
But
the
rest
of
the
pipeline
is
about
the
same
conceptually
right.
We
have
the
the
the
span,
processors
and
the
exporters
that
are
connected
to
one
another,
and
so,
if
we've
got
that
you
you
did
you
set
it
in
the
word
escapes.
You
know
the
obs
components
in
the
collector.
Why
don't
they
exist
officially
in
the
sdk?
That's
something
that
is
unusual
to
me.
Still.
A
I
think
part
of
the
problem
is
you
have
different
groups
of
people
working
in
in
different
projects
and
if
everybody
was
working
in
all
of
them,
I
think
they
would
probably
be
pretty
uniform
and
comparable.
So
I
think.
A
I
think
there
is
kind
of
like
this
on
unfinished
work
in
terms
of
having
like
what
what
is
the
terminology
that
they've
used
better
diagnostics,
and
I
think
this
falls
under
that
umbrella
and
it's
kind
of
like
I
don't
know
there
was
a
an
initiative
to
get
like
tracing
to
1.0,
and
I
think
there
was
like,
with
the
understanding
that
we're
kind
of
deferring
a
few
things-
and
I
think,
like
sampling,
was
one
of
the
things
I
got
kind
of
got
left
behind,
as
did
like
1.0
of
instrumentation,
but
also
like
diagnostics,
got
left
behind.
A
So
I
feel
like
this
thing
is
still
like.
It
is
a
known
thing
that
needs
to
be
addressed,
so
I
think
you
know,
I
think
it
makes
sense
for
us
since
we
are
interested
in
having
you
know,
ops
report
for,
for
our
sdk,
like
I
know,
there's
the
obvious
board
in
the
collector.
B
B
It's
like
right
right,
so
looking
at
the
obs
report
processor
to
try
to
collect
some
information.
A
B
B
So
it's
also
another
thing
that
people
are
clamoring
for
it's
just
something
that
I'd
like
to
do
so.
B
I
could
take
out
some
of
the
custom
code
that's
built
in
like
we,
we
kind
of
like
have
our
own
wrapper
library
that
provides
some
sensible
defaults
for
the
otosdk
and
we
throw
that
in
a
rail
tie
and
one
of
the
things
that
I'm
trying
to
get
away
from
is
continue
to
add
this
custom
block
I'd
like
to
try
to
make
the
configuration
as
simple
as
possible
and
by
exposing
the
metrics
reporter
through
the
configurator.
B
B
A
Yeah
yeah,
so
I'm
just
throwing
that
out
there
as
food
for
thought.
I
know
you
and
francis
have
been
going
back
and
forth
on
this,
so
I
don't
want
to
like
derail
or,
like
add,
you
know,
send
you
off
on
some
some
other.
Oh
no,
that's
fine!
I.
B
I
do
love
expeditions,
so
I
will
look
at
azrapur
more
closely
and
see
if
we
can
extract
a
similar
interface-
and
maybe
you
know,
apply
the
same
model
or
the
same
thinking
in
some
way,
so
that
it
simplifies
this.
A
Like
I
guess,
since
we
are
kind
of
exploring
this
need,
I
don't
know
if
other
stakes
are
doing
this,
I
haven't
really
heard
of
it.
So
if
I
think
there
there
is
this
initiative
eventually,
I
think
there
will
be
like
a
better
diagnostic
sig
that
springs
up.
So
I
think
you
know
if
we
have
ideas
there
or
if
we
kind
of
are
loosely
kind
of
putting
together
our
own
framework.
A
B
A
there's
the
one
signal
that
I'm
that,
if
I
recall
correctly
in
the
otlp,
is
the
the
otp
report,
the
batch
report.
It
has
the
drop
spans
attribute
right.
A
B
A
B
And
that's
essentially
what
we're
doing
with
our
with
our
metrics
reporter,
but
everything
that
you
said
yes
makes
total
sense
to
be
thinking
about
the
big
picture
rather
than
the
small
and
and
we
should
be.
B
A
Yeah,
that's
that's
that's
kind
of
where
I'm
heading
with
things
and
like
at
the
same
time
like
I
don't
want
to
like
hold
up.
You
know
adding
functionality.
That's
that's
good
enough
for
a
lot
of
people
in
the
short
term.
I
just
want
to
make
sure
that
we
like
leave
the
door
open
for
for
the
future,
and
it's
like
not
going
to
like
get
us
like
stuck
in
a
bad
position.
So
a
little
bit
of
everything
think
think
about
the
big
picture.
A
B
Yeah,
you
know,
another
thing
that
I
had
been
thinking
about-
and
this
is
not
related
to
anything-
is
the
way
that
we
kind
of
signal
errors
and
logs
and
all
the
features
internally
in
the
sdk.
B
B
We'll
write
a
dynamic
blog
message:
exporter
failed
to
export
10
spans
without
any
other
contextual
information,
because
we're
not
using
a
semantic
logger
in
any
way-
and
I
was
thinking
to
myself
like
internally-
the
sdk
might
want
to
use
a
similar
structure
like
an
event
like
this
fan
event
object
similar
to
it
where
internally,
we
use
semantic
structures
and
delegate
to
something
that
is
like
the
error
handler,
but
is
rather
receiving
like
semantically
structured
messages
at
different,
potentially
different
levels.
B
I
say
like
this
occurred
and
this
occurred
and
this
occurred,
and
then
you
know
by
default,
our
default
implementation
can
be
a
log
that
kind
of
just
like
inspects
the
hash
and
writes
it
out
to
the
log
or
whatever,
but
people
can
add
their
own
sort
of
like
observer
or
an
event
processor
of
some
sort
or
even
handler,
so
that
they
can
get
more
detailed
information
because
I
see
it
just.
It
feels
a
little
bit
asymmetric
internally
how
we
kind
of
like
handle
diagnostic
information,
and
this
is
included
in
that
in
that
model
right.
B
A
Yeah
and
as
you're
talking
about
this,
are
you
kind
of
hinting
at
the
fact
that
if,
if
we
actually
had
an
hotel
logs
implementation,
our
logger
could
use
that
potentially,
and
it
could
just
default
to
like
a
ruby
logger
that
you
know
outputs
to
file
or
standard
out
or
or
whatever.
But
it
could
also
be
something
where
you
could
provide
your
own.
B
I
mean
it's
very
close
in
the
sense
that,
like
we
just
need
it,
we
need
something
that,
whether
it's
a
logger
or
not,
that
has
an
interface
that
accepts
semantic
key
value
pairs
and
an
event
name,
because
internally,
I
can
say,
like
hey
here's.
My
event
at
you
know,
error
exception
and
the
semantic
convention
already
defines
like
these
fields,
like
exception
type
exception
message,
exception,
backtrace
or
whatever
that
gets
reported
as
part
of
a
spam
event.
B
That's
already
like
a
no
like
a
like
a
a
known
interface,
a
well-known,
an
understood
interface,
and
then
we
have
the
other
notion
of
like.
B
But
it
has
a
different
output
or
a
different,
different
different
result,
whereas
one
is
kind
of
like
giving
you
diagnostic
information
and
the
other
one's
trying
to
record
a
measurement
which
is
kind
of
interesting,
you
know
so.
B
Are
we
missing
like
some
sort
of
a
concept
there
where
it's
like
there's
an
event
type
and
the
event
type?
Is
a
measurement
and
here's
the
key
value
pairs
are
sort
of
associated
with
that
measurement,
or
this
is
an
event
type
and
it's
an
exception
and
here's
the
semantic
key
value
pairs
for
what
we
record
as
an
exception
anyway,
for
logs
right
for
for
spans.
A
We
just
want
this
event
stream,
where
you
can
literally
just
like
give
the
thing
a
name
and
then
a
bunch
of
attributes
about
it,
and
you
can
kind
of
all
components
should
publish
their
messages
over
that
stream,
and
then
you
can
register
anything
to
actually
listen
for
those
and
it
might
just
want
to
log
them.
It
might
want
to
send
them
off
to
some
other
backend
system,
and
it's
just
kind
of
it
is
like
a
very
flexible
active
support
notifications,
maybe
even
but
yeah.
A
I
don't
know
I
was
trying
to
fix
something,
and
I
have
somehow
gotten
led
into
creating
this
way
to
kind
of
at
least
allow,
like
the
health
check
extension
to
be
able
to
get
notified
directly
from
different
components
when
they
have
hit
some
error
states
so
that
it
can
be
a
little
bit
more
nuanced
about,
like
you
know,
right
now,
it
just
tells
you
collector
is
up
200
or
500.
Your
collector
is
not
doing
great
and
it
doesn't
really
have
component
level
visibility.
B
Yeah,
because
I
might
my
take
away-
and
I
could
be
you
know
mistaken
about
this-
but
the
notion
that,
like
the
hotel,
log
librarian
or
at
least
all
of
the
working
implementations
of
say,
like
the
auto
log
library,
is
really
about
extending
or
using
existing
log
libraries
and
and
providing
custom
offenders.
B
B
Then
that
interface
is
like
mushy,
where
the
log
message
still
becomes
this
dynamic
value
that
I'm
sending
through,
and
that's
not
what
I
want.
I
want
to
be
able
to
have
semantic
structures
that
I
could
use
to
process
them,
which
leads
me
more
towards
wanting
the
event
style
interface,
which
lines
up
more
with
the
span
event
interface,
which
lends
itself
more
towards
a
structured
blogger
like
semantic
logger
for
ruby,
or
you
know,
pick
your
other
programming
languages.
You
know
I
logger
or
or
zap
you
know,
but
again
it's
like
it's
not!
A
Yeah
yeah,
I
feel
like
I
feel,
like
I've,
heard
some
like
similar
discussions.
I
think
you
know
back
in
the
earlier
hotel
days.
There
was
just
kind
of
like
at
least
talking
about
like
spam
events
and
just
like
well
what
if
something
is
happening
like
outside
of
a
trace.
A
How
are
you
record
that-
and
I
think
I
don't
know,
I
think
things
were
still
kind
of
early
on-
and
people
didn't
want
to
think
about
this.
So
they're
like
that'll,
just
be
like
hotel
logs
when
it's
ready
or
you
know
something
else,
but
I
do
think
that
diagnostics
is
like.
It
is
a
frontier
that
we,
that
is,
that
will
be
kind
of
like
worked
on
at
some
point
and
I
think
yeah,
it
sounds
like
you
have
a
lot
of
good
ideas
around
this
and
I've
been
thinking
about
it.
A
So
I
would
encourage
you
to
continue
to
think
about
it
and
talk
about
it
and
if
you
feel
like
you,
I
don't
know
if
you
feel
like
you
have
something
to
say
at
least
like
write
it
down
somewhere
and
I
will
I
will
be
on
the
lookout
for
for
for
interest
in
diagnostics
and
if,
if,
if
at
any
point
in
time,
you
feel
like
you
have
the
time
and
energy
if
yeah,
if
all
this
brainstorming
turns
into
something
that
you
have
passion,
time
and
energy
for
and
diagnostics
hasn't
happened.
B
B
Moving
in
a
direction
where
it
makes
it
easier
for
you
to
contribute-
and
it's
like
right
now-
the
contributions
is
the
most
important
thing.
So
I
need
to
like
focus
on
getting
people
helping
us
out
and
moving
these
moving
these
instrumentations
forward
right,
so
that
we
can
attract
more
people
to
using
nasty
cray.
A
We
can
choose
the
things
that
we
can
work
on,
just
because
there's
such
limited
time
and
so
many
things
to
do
so,
yeah,
okay,
so
sorry.
B
That
thank
you
for
listening.
A
A
A
The
impression
I
was
getting
is
there's
a
lot
of.
It
seems
like
it's
almost
like
a
one
of
these
ternary
booleans
where,
like
one
means
sampled,
zero
means,
definitely
not
sampled,
but
there's
some
gray
area
in
between.
So
like,
I
guess,
like
the
the
zero
value
for
this,
which
means
definitely
not
sampled
like
doesn't
work,
so
they
would
want
to
have
like
optional.
So
it's
like
if
it's
ambiguous,
that
it
wasn't
sampled,
it
should
just
kind
of
be
like
unset.
B
Well,
that
could
that
caught
me
by
surprise,
because
I
didn't
realize
that
the
hotel
p.
B
Messages
lacked
the
sampling
flag
or
the
trace
flags.
I
should
say
yeah.
B
B
You
know
hold
on
was
it.
Is
this
the
span
message
that
you're
looking
at
right
now.
A
A
B
That's
because
most
sdks
are
implementing
head-based
sampling,
essentially
where
it's
like,
as
they
see
the
incoming
whatever
their
sampler
is
set
to.
So
if
their
sampler
is
set
to
parent
and
they
receive
a
trace
contacts
that
has
the
the
default
value
set,
that
means
do
not
continue
the
trace.
B
A
B
B
A
Well,
I
mean
he's
just
mentioning
that
otlp
can
be
handy
for
storing
fans
not
only
transmitting
them,
so,
okay
for
transmitting
spans
from
sdk
collector.
We
do
not
anticipate
any
non-sample
spans,
however,
someone
someone
might
need
to
serialize
and
deserialize
non-samples
fans,
for
example,
to
debug,
in
which
case
this
data
will
be
lost.
B
B
A
I
don't
know
I
feel
like.
Maybe
this
is
not
so
much
a
an
sdk
concern
because
it's
he
was
still
kind
of
stating
that
you
don't
expect
that
you
would
transmit
unsampled
fans,
but
at
the
end
of
the
day
I
think
just
looking
for
a
way
to
be
able
to
encode
this
information.
A
That
that
information,
that
you're
able
to
at
least
restore
what
was
there
to
begin
with
yeah,
I
think
I
would
like
to
understand.
A
B
Right,
but
so
so,
let's
go,
but
but
the
thing
is
that
it's
got
to
get
to
the
state
where
it
needs
to
be
converted
to
a
proto
and
right
now.
Our
sdk
implementation
would
never
allow
that
to
happen
right,
because
if
the,
if
the
trace's
sample
is
the
trace
sampling
flag,
is
essentially
disabled
right,
we
only
have
like
a
notion
of
sampled
or
not
sampled,
and
when
it's
not
sampled,
the
sdk
doesn't
produce
new
spans
it
does
it
doesn't.
Even
I
don't
think
that
it
gets
added
to
the
batchman
processor
at
all.
B
I
think,
like
it
essentially
returns
the
invalid
span
yeah
and
that
doesn't
even
get
queued
into
the
that
doesn't
get
cued
at
all
into
the
batchband
cube.
B
I
could
be
wrong
about
that
with
the
look
at
the
code
again,
so
what
you
would
end
up
with
in
those
cases
would
be
a
bunch
of
essentially
like
invalid
spans,
I
think,
with
no
attributes
with
no
anything,
at
least
in
the
current
implementation.
I
mean
I
could
be
totally
wrong
about
this
right
now,
but
that's
how
I
that's
what
I
think
I
mean
again.
B
Only
there's
only
evidence
to
look
at,
but
sorry
I
don't
mean
to
be
dragging
this
conversation
on
you
already
made
your
point.
A
A
Going
back
to
like
this
first
bullet
point,
I
think
he
got
here
through
links
which
might
be
which
might
be
the
inside,
that
we
need
it's
handy
when
holding
a
link
to
be
able
to
tell
if
it
points
to
a
sampled
or
non-sampled
span.
A
A
A
A
Yeah,
maybe
this
is
something
to
do
some
more
work
on
it.
A
Briefly,
there's
yeah,
I
guess
log
attribute
key
naming
conventions.
I
think
you
are
supposed
to
use.
Log's
data
model
recommends
prefixing
company,
specific
fields
with
fully
qualified
domain
style,
identifiers,
com.google.star.
A
And
the
question
here
was
for
like
first
class
clouds,
could
you
potentially
use
abbreviations-
and
there
was
quite
a
bit
of
bike
shedding
about
this.
A
B
A
It's
like
really
the
same
thing
but
yeah
metric
attributes,
namespace
or
not
so
apparently,.
A
I
think
that
is
now
this
trebek
was
checking
out
some
metric
receivers
and
found
that
some
of
them
were
namespacing
their
attributes.
Others
were
not,
and
I
guess
originally,
like
metrics
used
a
different
data
type.
They
were
called
labels
and
labels
didn't
necessarily
have
to
be
prefixed,
but
attributes
which
are
on
spans
are
supposed
to
be
prefixed,
so
it
seems
like.
A
A
Are
these
gonna
be
like
really
long
names
and
are
these
going
to
start
to
cause
some
problems,
and
I
think
people
were
at
least
saying
compression
should
solve
the
bites
issue
so
be
interesting,
see
how
that
plays
out
and
one
minute
left
the
one.
Maybe
saving
grace
here
would
be
scope
attributes
this
one
is
actually
somewhat
interesting
to
me,
but
so
there
was
like
this.
Really.
A
There
was
the
rename
from
instrumentation
library
to
instrumentation
scope,
which
I
think
everybody
is
still
dealing
with,
has
been
pretty
inconvenient
for
the
most
part,
and
it
seemed
like
it
really
like
was
adding
no
new
value.
It
was
really.
B
A
Until
now,
so
this
one
actually
adds
in
scope
attributes.
So
if
we,
if
we
move
down
here
and
if
you
whip
out
the
magnifying
glass
you'll,
see
that
instrumentation
scope
has
a
name
and
a
version
which
it
had
before,
but
now
it
has
repeated
key
value.
Attributes.
B
And
that's
something
that
we've
all
been
clamoring
for
right,
like
we're,
we've
been
clamoring
for-
and
this
is
the
carry
like
this-
was
the
the
spike
that
the
kid
rob
kid
was
working
on
with
me,
which
was
to
introduce
the
notion
of
this
carry-on
context,
which
was
a
context
that
would
be
shared
attributes
across
an
instrumentation
scope
essentially,
and
what
we're
seeing
extracted
from
db
utilities
and
http
contacts
and
yada
yada
yada
wards
like
a
set
of
key
value
pairs
that
are
are
scoped
to
the
instrumentation
itself.
B
A
I
think
so
I'm
trying
to
figure
out
all
right,
so
the
api
training
changes,
get
tracer.
Api
will
be
extended
to
add.
The
following
parameter
attributes
specifies
the
instrumentation
scope
attributes
to
associate
with
emitted
telemetry.
Oh
that's
different.
Okay,
so
it
seems
like
it
will
be.
It
will
be
bound
to
your
tracer.
B
A
That
seems
to
be
how
it's
written
right
now,
but
it
is,
it
is
an
open
pr,
so
I
feel
like
if
you
wanted
to
start
to
engage
with
what
could
we
make
these
dynamic?
Could
there
be
a
scope,
attributes
provider.
B
Different
tiers,
though
right,
it's
kind
of
like
we
kind
of
do
this
already
in
the
sense
that
each
instrumentation
like
like
each
each
like
the
rack,
tracer
right
when
you
set
the
rack
tracer
up,
you
have
a
set
of
key
value
pairs
that
we're
injecting
into
every
single
trace,
but
they
there's
no
semantic
conventions
for
them.
B
Thank
you
for
letting
me
be
so
like
exploratory
here.
B
B
So
there's
this
notion
of
the
tracer
in
you
know
that's
associated
with
the
instance.
So
this
is
the
instrumentation
scope
tracer
and
it
is
going
to
have
a
set
of
static
attributes
associated
with
it
right,
which
are
the
attributes,
as
described
by
instrumentation
scope
there,
because
to
so
some
effect
we
memoize
the
construction
of
the
tracer.
The
only
two
attributes
that
we
give
that
tracer
right
now
are
the
name
of
the
instrumentation
scope
and
the
version
of
the
instrumentation
scope.
B
A
So
all
right,
there
are
two
known
use
cases
according
to
this
document,
add
support
for
meter
short
name.
I
guess
so,
I'm
not
sure
what
exactly
the
meter
naming
requirements
are,
but
maybe
it's
something
like
a
fully
qualified
domain
name,
which
I
think
is
maybe
how
we
got
here.
A
Fixes
that
and
then
the
other
one
is
add,
support
for
differentiating
the
type
of
data
emitted
from
the
scopes
that
belong
to
different
data
domains.
So
profiling
data
emitted
as
log
records
or
client-side
data
emitted
as
log
records
is
different
differentiated.
So
it
can
easily
be
routed
and
processed
differently
in
the
back
ends.
A
B
Hey
man,
you
are
great.
Thank
you
for
your
patience.
I
appreciate
you
like
letting
me
ramble
on
for
an
hour
and
seven
minutes.
I
guess
we
started
late,
so
we're
right
on
time.
A
B
B
Take
care
of
yourself-
and
you
know,
keep
me
posted
on
the
conferences
you're
going
to
so
that
we
could
maybe
sync
up
at
one
of
them.