►
From YouTube: 2021-08-31 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
Doing
okay,
you
know
what
I
was
trying
to
look
up
actually
and
I'm
just
gonna:
ask
you
shop
talk
here
to
avoid
clashes
by
other
companies,
okay,
looking
at
recommendations
for
application
developers
in
the
semantic
conventions,
the
name
is
specific
to
your
application
that
we
used
internally.
If
you
already
have
an
internal
company
process
that
helps
you
ensure
that
there's
no
name
clashes
and
happen
to
feel
free
to
follow.
Okay,
that's
what
I'm
gonna
do
we're!
You
know
like
working
on
our
some
of
our
guide
internally,
so
I
need
to.
A
A
With
semantic
conventions.
C
Okay,
I
was
like
wait
what
it's
probably
gonna,
be
later
tim
tim's,
not
gonna,
be
here
today
he's
on
a
train
or
something
francis
is
out
this
week
as
well.
So
oh
it'll
be
it'll.
C
Okay,
yeah,
I
I
don't
know
if
I
can
like
do
this,
but
I'm
hold
on
there's
a
cabin
and
a
lake
and
the
view
behind
me
is
actually
pretty
incredible.
It's
the
11th
largest
freshwater
lake
in
the
world,
so
it
kind
of
just
looks
like
when
you
sit
out
there.
You
just
see
water
and
nothing
just
water.
So
it's
very
peaceful.
A
B
A
A
The
one
thing
that
I
just
like
I
learned
today
and
I've
been
silly
about
doing.
We
came
up
in
conversations
that
today
and
are
like
the
work
review,
which
was
I've
been
naming
all
of
my
internal
attributes,
github
dot,
something
and
it's
like.
Oh
wait
a
minute.
What
does
the
specification
say?
It
says
it
recommends
that
you
use
the
reverse
stone
domain
name
for
your
application
level
attributes
and
I
was
like
well
that
makes
sense,
because
watch
one
day
somebody's
gonna
be
like.
B
B
Let's
go
ahead
and
see
how
exciting
this
morning
was
spoiler,
probably
not
very
but
we'll
see.
B
This
was
just
a
note
that
was
mentioning
that
there
that
hotel
hasn't
defined
semantic
conventions
for
essentially
like
rum,
real
user
monitoring
in
the
browser
and
they're
just
asking.
Is
there
an
object
to
add
this
and
it's
kind
of
pointing
out
some?
B
I
think
these
were
some
other
example
semantic
conventions
that
were
in
the
general
area,
but
there
has
been
some
discussion
about
real
user
monitoring
and
there
was
a
proposal,
even
that
came
in
it,
was
suggesting
adding
a
whole
new
telemetry
type,
and
it
did
not
seem
like
there
was
a
ton
of
appetite
for
doing
that.
But
apparently
splunk
has
already
been
doing
some
work
in
this
in
this
realm
and
they're
just
kind
of
using
what's
already
here.
They
just
think
that
there
needs
to
be
yeah.
B
B
So
I
think
the
discussion
was
that
there
is
an
instrumentation
and
being
that
this
is
an
instrumentation
effort.
It
would
be
a
good
thing
to
start
discussing
there.
C
B
We've
mentioned
the
probabilities
specification
stuff
the
last
couple
of
weeks.
These
otaps
are
still
open.
Those
are
the
ones
that
we
keep
talking
about.
The
new
thing
is
that
there's
a
spec
pr
now
to
basically
officially
add
spec
for
the
stuff
in
in
those
otaps,
so.
B
My
understanding
is
the
only
thing
that
we
actually
need
are
approvals.
Nobody
is
really
like
raising
any
issues
with
stuff,
but
not
enough.
People
who
are
green
check
approved
are
approving
things.
So
that's
what
this
happened
here.
B
There
was
a
brief
metrics
back
update,
the
api
has
been
feature
freeze
and
I
guess
the
next
step
will
be
that
will
be
marked
as
stable.
I
really
don't
know
what
the
difference
is
between
those,
but.
B
It
sounds
like
things
are
progressing
and
then
the
sdk
spec
is
going
to
have
an
experimental
release
in
a
couple
of
days,
so
enter
that
to
be
just
kind
of
like
a
milestone
in
in
the
development
of
the
sdk
spec.
This
is
probably
what
people
are.
People
who
are
prototyping
are
probably
prototyping
to
these
kind
of
experimental
releases.
B
And
I
think
we've
talked
about
this
a
little
bit
too,
that
there
is
a
separate
group
spinning
up
around
semantic
conventions
for
messaging.
This
person,
johannes,
is
going
to
head
that
up
and
he
just
kind
of.
B
This
could
be
relevant.
There
is
a
spec
pr
to
capture
http
headers
as
fan
attributes,
so
I
feel
like
we.
B
We
have
the
option
to
do
this.
If
I'm
not
mistaken,
for
our
rack
instrumentation,
it's
been
a
while,
since
I've
looked
at
it,
but
so
correct
me
if
I'm
wrong
there,
but
this
kind
of
formalizes
how
to
name
the
the
attributes
that
you
collect
there,
the
headers
that
you
collect
there
and
it
had
like
some
caveats
of
things
that
are
redundant,
that
maybe
you
should
not
collect.
B
B
There's
this
desire
to-
I
I
think
we've
talked
a
little
bit
about.
There
was
some
attribute
limits
that
were
introduced.
I
think
the
default
limits
are
infinite,
but
I
think
you're
supposed
to
have
like
some
configurable
length
for
them.
B
So
that's
the
motivation
behind
this
is
to
say
that
resource
attributes
are
exempt,
and
since
these
things
are
a
little
bit
more
resource,
attributes
kind
of
like
apply
to
the
the
process,
and
you
know
like
the
host
and
kind
of
more
more
static
things
things
about
the
application
environment
that
should
not
really
be
changing
at
runtime.
So
the
thought
was
that
you
have
a
lot
of
control
over
these
and
should
be
able
to.
B
Just
make
sure
to
only
attach
the
necessary
resource
attributes
and
in
a
format
that
you'll
be
able
to
live
with,
whereas,
like
spanish
attributes
are
a
little
bit
more
of
the
wild
west,
they
kind
of
come
in
as
the
application
is
running
through
through
various
means,
there's
just
a
lot
less
control
over
them.
So.
B
Yeah,
so
there
was
there's
this,
and
this
is
kind
of
the
core
issue.
Is
that
some
streams
of
metrics
you
need
to
uniquely
identify
the
thing
that
is
generating
them?
This
is
just
specifically
talking
about
prometheus,
but
I
think
it's
probably
applicable
to
many
other
like
time
series
formats,
but.
B
B
Classify
resource
attributes
as
identifying
and
descriptive,
and
you
know
descriptive,
descriptive
attributes
are
things
that
you
could
drop
or
modify
they're
they're
kind
of
useful
metadata,
but
they're,
not
these
identifying
attributes
where
you
would
end
up
having
trouble
distinguishing
between
the
resources
if
you
modified
or
dropped
them.
B
So
I
don't
yeah,
like
I
haven't
kept
up
with
this
issue
enough
to
understand
like
what
really
like
that
concrete
solution
looks
like.
Is
it
just
like
a
blob
of
yaml
or
something
else,
but
that
was
kind
of
the
overall
discussion,
so
so
yeah?
This
was
just
brought
up
as
as
being
related
and
possibly
another
way
to
solve
that
exact
same
problem.
C
We
we
have
like
a
like
our
whole
deployment
template
for
different
applications
of
shopify.
We
already
have
kind
of
a
designated
keyword,
that's
available
across
it.
So
like
something
like
this,
I
understand
why
it's
valuable,
but
I
wonder
if
other
organizations
already
have
their
own
like
what
they
call
it,
maybe
like
revision
or
service
version,
or
something
like
that
that
isn't
instrumentation
specific,
because,
like
we,
what
I
do
is
in
our
rapper
gem.
We
just
check
if
that
variable
set,
which
usually
is
and
then
we'll
we'll
assign
the
the
service
version
resource
attribute.
C
Based
off
of
that
I
get
it.
I
get
it
just
it's
weird
because
I
just
I
wonder
if,
like
different
companies,
will
have
this
concept
that
already
exists
now
they
just
have
to
add
it
again
to
satisfy
open
telemetry,
but
at
the
same
time
it
doesn't
necessarily
seem
like
a
bad
thing.
I'm
just
do
you
know
what
I
mean.
B
I
kind
of
feel
like
that
makes
it
makes
sense
to
kind
of
unify
on
a
name
that
you
can
just
expect
will
be
there
because
then,
like
I
don't
know,
other
things
from
open
to
open
telemetry
could
make
use
of
that
in
some
way,
which
is,
I
don't,
have
any
use
cases
to
rattle
off,
but
there
could
be
some
some
useful
things
that
could
be
done
with
your
with
your
service
version
by
things
that
that's
that
you
wouldn't
necessarily
write.
C
Yeah,
I
don't
think
it's
a
bad
thing,
I'm
just
like
trying
to
think
of
our
own
use
case
and
like
whether
or
not
we'd
like
I
don't
think
I'd
actually
probably
push
to
use
it.
I
just
keep
using
our
own,
but
I
guess
if
a
company
doesn't
already
have
one,
they
could
introduce
one
and
say:
okay,
let's
set
that
yeah,
that's.
A
Reasonable,
what
might
be
interesting
is
things
like
that
tie
back
to
the
metadata
of
the
original
like
source
code
repository
stuff.
So
in
our
case,
for
example,
service
version
is
a
sha
of
a
particular
release
of
an
application,
and
then,
but
we
also
do
situations
where
we
have
branch
deployments.
A
So
we
also
use
the
ref,
which
is
like
the
human,
readable
or
whatever
readable
name,
because
people
don't
look
stuff
up
by
shaws
in
back
end
systems
like
it's,
not
not
that
easy
to
disambiguate
it's
easier
for
people
to
see
like
I'm
on
this
tag
or
this,
the
human
readable
version
of
some
representation
of
a
sha,
so
that
that's
not
related
to
this.
But
it
isn't
an
interesting.
A
It
is
interesting
to
me
to
add
things
that
provide
a
more
human,
readable
experience,
a
more
symmetric
experience
and
configuration
because
right
now
I
know
at
least
you
know,
for
some
of
our
legacy.
Apps
we
have
to
like
map.
People
were
using
different
identifiers
for
service
version
before
hotel
and
we
go
into
light
step
and
we're
like.
Oh
I'm
gonna
configure
that
the
the
look
for
this
tag,
current
sha
or
something
like
that
to
symbolize.
A
You
know
so
that
you
know
what
service,
what
what
it
will
map
on
the
back
end,
the
server
style
version
going
forward,
and
I
would-
and
it
would
be
nice
to
have
something
that
was
symmetric
and
easy
to
follow,
and
we
can
migrate
everything
to
that.
Personally
speaking,
but.
A
I
guess
does
that
imply
an
api
change,
also
where
it's
like
read
the
environment
variable
if
it's
present
and
then
you
don't
have
to
pass
in
the
service
version
when
looking
at
tracer,
when
configuring,
the
the
sdk
and
assigning
the
service
version
resource
attribute.
C
Know,
there's
like
the
grab,
there's
the
grab
bag
and
then
there's
the
special
ones
like
service
name.
I
think
that
one
does
have
something,
but
it's
a
little
bit
different.
B
There's
this
comment
here
that
alludes
to
hotel
service
naming
special.
I
think
it
yeah.
I
figure
you
remember
some
conversations,
I
think
it's
around
like
precedence,
and
you
know
if
it's
set
in
multiple
places,
kind
of
as
environment
variable
and
in
code
like
which
one
wins
and
then
like
what
the
fallback
actually
is.
C
A
C
I
think
people
people
aren't
bound
to
do
it,
whether
or
not
you
deprecate
it
like
someone's
like
if
it's
possible
someone's
going
to
do
it.
So
at
least
this
disambiguates
the
behavior
and
someone
comes
in
and
says,
like
I
said
it
here.
Why
is
it
using
that?
It's
like
well
he's
set
in
two
places,
and
we
pick
this
one.
C
A
B
Yeah,
I
think
that
is
that's
all
we
have
for
the
spec
sig.
So
I
don't
know
if
anybody
has
strong
feelings
either
way
on
the
hotel
service
version
feel
free
to
no.
I
think.
C
I
think
adding
it
like
just
it,
it
makes
sense
it
just.
It
seems
like
it's
important
enough
that
it
could
have
its
own
little
thing
to
search
name,
but
at
the
same
time,
I
guess
it's
like
why
can't
it
get
smushed
into
hotel
resource
attributes
like
I
guess
what
what's
like
the
argument
for
it
having
its
own
standout.
B
Reading
into
this
a
little
bit,
I
think
maybe
the
question
is
like
is
hotel
service,
name
and
hotel
service
version.
Are
these
things
that
are
like
so
common
that,
like
every
application
is
going
to
have
them
and
more
or
less
kind
of
want
some
sort
of
value
there
and.
C
C
A
Hey
you
know,
what
does
heath
ledger
say
in
batman?
C
Yeah,
I
don't
know
I
I
wouldn't
fight,
I
wouldn't
fight
this
change
coming
in.
I
think
it's
reasonable
enough.
It's,
like
name
and
version,
seemed
like
a
nice
little
duo,
but
I
think
that
it
would
just
there
have
to
be
like
a
little
bit
of
friction
for
anything
after
this,
it's
like
you
kind
of
have
to
close
the
door
behind
you
yeah
right.
The
one
thing.
B
I
guess
the
one
the
one
thing
that
I
the
one
benefit
I
do
see
to
this
after
discussing
this
is
the
fact
that
this
whole,
like
named
tracer
situation,
have
having
a
way
to
like
formally
specify
like
the
name
and
version
of
your
app
makes.
It
really
easy
to
have
a
way
to
get
like
a
default
named
tracer
for
you
to
use
for
your
application
without
having
to
pass
any
additional
data
in
the
code,
which
I
don't
know.
I
think
that
could
be
nice
just
because
name.
Tracers
are
one
of
these
unique
things.
A
C
Right
but
typically,
you
only
have
the
one
tracer
provider
and
it
spits
off
all
the
tracer.
So
all
your
instrumentation
just
pulls
from
that
that
one,
that
assumed
global
tracer
provider
and
like
there's
that
implicit
thing
that
we
have
in
our
our
implementation,
that
it'll
pull
out
the
the
name
and
version
of
the
library
that
it's
being
used
so
like
when
we
refer
to
like
and
open
telemetry
instrumentation
rack
dot
instance
tracer.
C
A
C
Right
what
I
think,
sorry
I'll,
not
speak,
what
I
was
gonna
say.
I
think,
what
matt?
What
I
understand
matt
was
getting
at
there
is
that
you
could
now
quite
easily
introduce
a
default
tracer
for
your
application.
That
would
know
the
name
of
your
application
and
the
current
revision.
So
when
you
have
your
your
app
level
tracer,
it
would
have
that
information.
So
you're.
Looking
at
like
what
what
generated
the
span
you'd
say:
oh,
is
this:
it's
my
application.
C
Tracer
did
it
and
then
everything
else
might
have
your
auto
instrumentation
might
have
your
rack
tracer
your
registrator
things
like
that.
So,
like
that's
something
that
I
think
matt
has
talked
about,
the
past
is
like.
I
think
there
is-
and
I
have
one
too,
as
a
desire
for
a
default
tracer,
but
you'd
want
to
make
sure
that
it
has
the
information
associated
with
like
your
application,
it's
just
kind
of
like
that
that
ergonomic
for
someone
getting
up
and
running
with
tracing
like
a
developer
right
who
wants
to
just.
C
B
Yeah
yeah
that
that's
that's
exactly
what
I
was
getting
at
is
that
it
would
make
that
convenient
and
you
could
just
have
like
tracer
provider,
dot
default
or
something.
And
that
already
knows
your
your
application
name
and
your
version.
A
But
what
I
was
saying
was
that
the
but
the
the
tracer
api
itself
right,
the
tracer
provider
api,
which
says
tracer,
which
is
essentially
the
tracer.
You
know
factory
method
right
that
keeps
its
baggage
around
sorry,
not
baggage,
but
keeps
around
the
collection
of
tracers
that
are
segmented
by
the
instrumentation
name
and
version.
A
So
if
we
would
be
assigned
like
the
would,
the
implementation
of
the
global
tracer
be
as
simple
as
for
the
instrumentation
name
and
instrumentation
version
attributes
that
are
getting
passed
into,
that
tracer
function,
be
the
service
name
and
service
version
by
default,
because
right
now
it's
like,
if
you
don't
provide
those,
it's
print,
a
warning
right
to
say
you
shouldn't
be
generating
a
tracer
without
these
values.
A
A
C
Yeah
yeah,
I
think
yeah
that
makes
sense
like
and
just
like,
as
a
note
like
coming
from
like
an
application
or
like
a
previous,
like
instrumentation
framework
that
didn't
have
the
concept
of
like
these
menu
tracers
like
I
thought
it
was
a
little
bit
weird,
but
I
realized
we
were
doing
something
kind
of
like
hacky.
We
were
just
like
it
for
our
redis
instrumentation.
We
would
just
add,
like
a
component
tag
and
say,
like.
A
C
Right,
so
for
me,
this,
the
the
name
tracers,
I
think,
is
like
incredible,
because
when
you
look
at
someone's
face,
you're
helping
them
understand
like
read
through
it
and
it's
like
well,
this
instrumentation
actually
generated
this
information.
It
becomes
crystal
clear,
like
you
can
see
which,
like
which
part
was
responsible
for
filling
in
the
information
there
and
then,
if
you
do
have
an
issue,
and
you
want
to
drill
into
something
like
becomes
trivial
and
like
the
version
being
available,
is
wonderful
too,
because
it's
like
okay.
A
B
Yeah
yeah,
let's,
let's
run
down,
is.
C
C
C
We're
trying
to
kind
of
get
the
lay
of
the
land
of
what
should
be
the
outcomes
of
this,
and
I
think,
there's
some
ideas
around
what
kind
of
things
we
want
to
document
and
actually
put
into
the
specs
so
that
instrumentation
authors
don't
have
to
guess
or
come
up
with
it
on
their
own,
but
it
is
very
broad.
C
So
a
lot
of
it
is
like
interacted
that
that
otep
for
kind
of
that
java,
instrumentation
spec,
we
looked
at
it
a
while
back
and
andrew
left
a
bunch
of
comments
on
it.
That's
been
kind
of
like
a
recurring
discussion
point.
C
But
one
of
the
things
that
kind
of
like
the
conversation
went
off
the
the
rails
a
bit
there
was.
We
talked
about
things
like
defaults
for
the
database
like
we
recently
did
some
work
of
like
making
the
configuration
options
consistent
for
database
statements
like
what
what
should
be
the
actual
value
for
that
configuration
option
b.
So
that's
something
that
I'm
proposing
that
we
kind
of
actually
codify
as
what
it
should
be.
C
C
They
call
it
sanitize,
and
everyone
was
for
that
until
I
kind
of
suggested
that
we
have
developers
that
use
choicing
in
their
local
environment
and
they
don't
need
to
do
that
and
in
fact
they
like,
when
they
can
see
the
full
database
statement
because
on
their
machine
it's
safe
and
it's
exciting
because
they
get
all
the
information
right.
C
I
I
mentioned
briefly
like
how
ariel
you
noticed
some
concerns
about
the
performance
of
obfuscating,
and
then
they
were
kind
of
leading
a
little
towards
like
we
don't
want
to
be
poorly
performant,
but
we
still
like.
Let's
say
we
pick
the
default
obfuscate.
We
would
still
want
to
do
that,
because
we'd
want
to
error
to
the
side
of
the
caution
and
then,
if
it
becomes
a
performance
issue,
obviously
we
should
fix
that
if
we
can,
but
also
the
team
could
like
disable
whoever's,
the
application
owner
could
disable
it
right.
They
could
not.
C
They
could
include
it
or
omit
it
or
pick
whatever
alternative
is
appropriate
for
them.
The
conversation
kind
of
went
back
and
forth
between
should
it
be
a
global
option
like
because
I
think
the
way
they
they
were
looking
at
it
is
they
have,
I
think
this
here,
so
they
have
this,
this
value
that
they
can
set.
But
if
you
have
multiple
instrumentation
libraries
that
have
database
statements,
this
is
kind
of
like
a
global
config
across
instrumentation.
A
A
I
get
that
I
get
that,
and
I
kind
of
also
like
looking
at
it
from
a
different
perspective.
Also
is
there's
already
like
a
a
concept
in
obfuscation
in
the
collector,
with
the
notion
of
the
attribute
processor,
and
perhaps
what
we
might
one
propose
or
consider
is
looking
at
is
reusing
some
of
the
thinking
from
the
attribute
processor
for
the
purposes
of
symmetry
and
reusing
that
configuration
on
the
sdk
side.
A
I'm
saying
if
the
configuration
or
the
configuration
options,
perhaps
maybe
they
should
be
the
same
on
both
sides,
so
use
the
same.
Configuration
style
keywords
whatever
it
is
strategy.
A
The
way
that
you
configure
it
in
the
collector
would
be
the
same
way.
You
would
configure
it
on
the
client
side
and
declare
it
in
the
same
way
that
way,
you're
not
stuck
with
this.
Oh,
I
have
to
use
this
configuration
on
sdk.
Oh,
I
got
to
go
and
use
the
this
configuration
on
the
collector
that
symmetry
can
make
it
easier
for
the
operators
to
say.
Oh,
I
want
to
deploy
this.
A
You
know,
I'm
you
know
speaking
pie
in
the
sky.
This
might
not
be
as
easy,
but
the
there's
no
mental
shift
between
attribute
processing
on
one
side
and
attribute
processing
on
the
other.
C
So
so
that's
an
interesting
point,
and
I
was
recently
as
recently
as
last
week
when
I
was
on
this
meeting
made
aware
of
competing
camps.
So
I
think
it's,
the
ted
was
referring
to
tigran,
who
is
saying
that
he
is
afraid
that
the
sdk
will
become
a
collector
basically
another
like
another
form
of
the
collector,
because
you'd
have
your
app
level
collector
that
forwards
to
your
actual
collector.
So
that's
one
of
his
concerns
is
that
basically
you'll
just
have
collectors
all
the
way
down
and
I
don't
want
to
misattribute
it.
A
Looks
like
starlink
has
had
an
interruption
in
capabilities.
I
don't
know.
A
Sorry,
robert,
you
know
just
now
you
came
back
to
us.
Starlink
lost
to
you
for
a
second,
oh.
A
C
That
shop
fight,
so
when
did
you
lose
me?
I
don't
know
we.
C
Oh
okay,
so
apparently
tigran
is
of
the
opinion
he's
concerned
that
the
the
sdk
will
become
a
collector.
It
would
be
like
another
form
of
the
collector,
so
like
you'll
have
basically
like
collectors
all
the
way
down.
Like
your
span,
processors
at
your
collector
level,
you'll
be
doing
all
the
work
that
you
could
be
doing
in
the
collector
right
at
the
sdk
and
the
sdk
is
going
to
take
on
more
responsibility
to
the
cut
out
again.
C
Okay,
just
like
basically
you'll
just
be,
you
have
a
effectively
be
running
like
a
collector
that
forced
another
collector,
and
I
I
see
what
like
I
see.
I
understand
like
what.
C
Concern
could
be,
but
there's
also
there's
someone
else
on
the
call,
and
I
I
don't
want
to
miss,
attribute
them,
because
I
don't
remember
exactly
who
said
it,
but
they
were
like
their
hopes
were
that
the
sdk
eventually
just
became
another
collector
right
that
you
could
do
all
that
work.
A
At
least
I
I'm
a
big
fan
of
symmetric
architecture,
even
if
it's
like
like
it,
it
doesn't
make
sense
for
like,
for
example,
it
doesn't
make
sense
for
the
golden
sdk
to
not
be
the
same
source
code
as
the
collector
source
code.
It
just
seems
weird
to
me
from
the
exporter
side,
from
like
the
pipeline
to
the
batch
processing
to
the
exporter
side,
how's
that
not
the
same
code
like
it's,
the
same
programming,
language,
yeah,.
D
C
A
A
Because
there's
like
a
vision
of,
we
want
the
collector
to
be
a
first,
the
the
the
core
component
of
the
infrastructure,
and
we
want
to
try
to
minimize
the
amount
of
code
that
goes
into
the
sdks,
because
then
we
introduce
bugs
right
by
spreading
them
out
into
multiple
programming
languages,
but
the
the
truth
is.
There
are
some
concerns
that
people
have
like
myself,
who
we
don't
run
a
collector
and
the
sdk.
We
want
to
make
sure
that
data
that
leaves
the
sdk
it's
okay
for
it
to
go
somewhere
right.
A
So
my
whole
point
is
the
way
that
we
can.
A
Choosing
configuration
options
for
that
sdk
if
we
can
make
them
as
symmetric
as
we
can
to
the
collector,
then
there's
no
conceptual
divide
and
no
context,
switching
mentally.
For
an
engineer.
It's
like!
Oh,
if
I
configure
attribute
processor
here,
I
can
configure
an
attribute
processor
here
and
we're
good
kind
of
thing
yeah,
but
that's
again,
it's
all
about
the
data
processing
and
what
you
can
emit
versus
what
you
can't.
B
But
I
do
think
that
it's
super
interesting
and
I
don't
know
part
of
me
kind
of
does
like
that
idea
of
like
you.
Can
you
can
have
your
collector
in
process
written
in
in
your
language
and
it
kind
of
does
the
same
as
your
external
collector,
which
which
you
should
probably
use.
But
you
know
different
situations,
call
for
kind
of
different
deployments,
but.
B
Yeah,
the
one,
the
one
downside
I
would
say
is
that
having
written
some
of
this
processing
code
and
trying
to
be
clever
with
it
in
the
past,
it's
one
of
the
problems
is
just
like
trying
to
kind
of
look
at
this
span
data
as
it
flies
by
and
figure
out
like
what
it
is
where
it
came
from
and
what
you
can
do
to
it.
I
think
with
our
named
tracers,
that
makes
stuff
a
lot
easier,
but
sometimes
it's
just
easier
to
be
in
the
instrumentation
and
it's
like
it's
the
reddest
instrumentation.
B
B
C
Another
part
that
was
discussed
a
bit
and
some
of
it
was
on
the
call,
and
some
of
it
was
later.
I
talked
about
it
with
francis,
so
I'll
just
share
like
kind
of
the
the
interesting
bits,
but
it
was
talking
about
the
subject
of
first
party
instrumentation.
C
They
refer
to
it
like
you'll,
see
in
the
notes
there.
Therefore,
it
was
like
native
instrumentation,
but
it's
just
like
I'm
trying
to
make
instrumentation
directly
into
google
cores
api,
for
example,.
C
My
current
pr,
I
opted
to
just
use
the
api,
but
what,
if
you
don't
want
that
instrumentation?
How
do
you
disable
it?
If
you
don't?
You
don't
have
the
option,
we
are
forcing
it
on
you.
So
originally
I
had
suggested
we
put
the
base
instrumentation,
so
that
would
get
pulled
in
and
they
would
use
all
the
kind
of
config
options
that
we're
all
familiar
with
in
disabling
it,
which
sounds
fine,
but
talking
to
francis
about
this.
C
But
if
you're
a
rails
developer,
would
you
expect
your
rails
information
instrumentation
configuration
options
to
be
in
the
open,
telemetry
sdk?
Or
would
you
expect
it
to
be
in
the
typical
places
you
would
look
for
rails
like
let's
say
it's
baked
right
into
rails
at
this
point,
and
that
was
the
kind
of
the
example
that
for
him
pushed
me
over
to
being
unsure,
because
originally
I
thought
I
was
like
dope.
C
Let
me
show
you
put
everything
all
in
the
open
telemetry
bucket,
but
if
I'm
configuring
rails,
I
probably
want
to
configure
rails
the
way
I'd
normally
configure
rails
and
if
rails
has
the
option
for
open
telemetry
tracing
probably
would
turn
it
on
in
my
rails
configuration
and
so
then
it
kind
of
creates
this
bit
of
a
divide
of
like
how
do
you
solve
this,
because
your
first
party
instrumenters
will
they
use
consistent
configuration
options?
Will
they
use
friendly
defaults?
C
Can
we
does
it
this
conversation?
How
much
does
it
matter
like
if
they
can
just
do
whatever
they
want?
No
matter
what
right,
obviously
I
do
think
it
matters,
because
we
want
to
provide
guidance
and
make
it
easy
and
create
friction
around
doing
the
wrong
thing,
but
it
is
interesting-
and
I
I
am
once
again
undecided.
A
There's
also
like
language
specific
constraint
here
too,
because
you
know
for
example.net:
they
don't
use
those
apis
directly.
I
don't
think
right.
Net
uses
what's
built
into
the
language
which
is
system
diagnostics
package
and
you
report
everything
to
system
diagnostics,
same
thing
with
rust,
it's
using
its
annotations
and
using
the
telemetry
package.
That's
in
the
language
like
it
has
those
concepts
built
into
it.
For
the
ruby
there
isn't
a
concept
of
telemetry
built
into
the
core
center
library.
I
and
there
isn't
a
concept
like
we
we
have
the
the
battle
of
is.
A
Are
you
using
a
framework?
Are
you
using
a
library
and,
I
would
say,
ubiquitously
rails
people
are
using
frameworks
on
our
side,
so
they're
looking
at
framework
configuration
whereas
in
go.
You
would
not
look
at
it
that
way
right,
because
you
tend
to
have
not
used
frameworks
in
the
language
liko,
which
again
does
not
have
a
concept
of
telemetry
in
it.
A
C
I
I
know
it.
I
think
this
is
really
interesting.
I
think
this
is
really
going
to
be
difficult,
but
I
think
there's
areas
where
we
can
do
the
right
thing
is
in
languages
or
like
when
appropriate.
I
think
the
language
is
going
to
have
to
be
pretty
loose
in
this
spec.
C
I
think
there's
going
to
be
a
lot
of
maze
instead
of
musts,
but
providing
like
a
an
sdk
or
or
sorry
like
a
language
implementation
may
provide
helpers
for
instrumenting,
say
like
databases
or
networking
libraries
or
messaging
frameworks,
like
I
think,
that's
probably
where
it's
going
to
land,
because
the
variability
between
languages
and
ecosystems
seems
pretty
drastic,
but
I
think,
having
common
helpers
around
like
they're
saying,
like
surfacing
sanitizer
obfuscator,
that
should
be
part
of
this
instrumentation
api
that,
like
can
be
reused,
so
that
not
every
language
has
to
be
implemented
right
and
then
the
talk
about
pulling
in
people
who
are
experts
in
certain
technologies
to
establish
what
these
conventions,
what
the
required
attributes
should
be
for
a
span
coming
up
right
is
like
what
should
this
actually
look
like,
instead
of
people
kind
of
suggesting
what
they
think
it
should
be?
C
Who
actually
work
on
this
technology
and
weigh
in
on
it,
which
is
useful?
So
I
think
this
is
like
these.
These
meetings
are
really
really
in
the
early
stages.
Right
now,
there's
some
more
stuff
about
like
configurations
around
suppressing
instrumentation.
Like
the
easy
examples
like
how
do
you
make
a
health
check
go
away?
I
use
the
example
like
we
have
a
rack
option
for
untraced
endpoints
and
I
was
thrown
back
with
the
the
answers
like.
C
Why
isn't
that
just
a
custom,
sampler
and
I
was
like-
oh-
I
don't
know-
it's
probably
a
good
reason
why
it
isn't,
but
that
that's
interesting
subject
that
I
think
needs
to
be
explored
more
is
like
making
sure
that
people
can
suppress
noisy
instrumentation
because
there
is
cost
associated
with
it
right.
C
So
is
this
like
going
over
the
stuff
valuable
or
is
it
too
open-ended
that,
like
we're
just
kind
of
talking
out
into
the
air.
B
Yeah,
no,
I
think
I
think
we
can
always
get
into
like
great
discussions
about
all
this
stuff.
So
like
it's,
it's
pretty
pretty
interesting
yeah
I
was
gonna,
say
one
thing
about
the
configuration
and
would
you
expect
to
be
able
to
configure
in
rails
or
hotel
and,
like
I
don't
know,
I
I
part
of
me
really
likes
instrumentation
base,
or
at
least
the
concept
of
instrumentation
base,
or
maybe
some
derivative
of
that,
where
your
you
can
have
this
object.
B
That
holds
the
configuration
that
really
either
one
of
them
could
configure
like
rails
could
set
the
configuration
options,
and
this
is
something
that
hotel
can
discover
just
kind
of
through
the
same
mechanism
that
instrumentation
base
are
already
works
or
you
could
set
it
in
in
hotel.
I
think
I
think,
there's
a
way
where
you
could
you
could
have
both.
I
guess
I
think,
then
your
problem
would
be
like
how
to
keep
everybody
from
stepping
on
each
other's
toes
or
is
that
just
okay,
just
don't
configure
it
in
two
places?
B
If
you
don't
want
a
problem,
but
I'm
just
gonna
throw
that
up
there.
C
C
B
Yeah,
like
I
was
kind
of
thinking
of
it
as
like
the
way
it's
implemented,
maybe
it's
a
little
bit
too
concrete
as
being
something
that
is
more
applicable
to
like
a
third-party
instrumentation
but
like
in
general.
I
want
to
think
of
that
as
just
being
that
same
mechanism
that
we're
using
there's
just
being
like
a
instrumentation
descriptor
or
something
for
like
any
instrumentation,
that's
in
your
app
first
party
or
third
party,
and
it
kind
of-
has
some
basic
properties
on
it
like
this.
This
is
the
names
the
configuration.
B
This
is
whether
or
not
it's
the
tracer
yeah,
the
tracer,
all
that
common
stuff-
and
I
feel
like
if
you
did
that
I
feel
like
it-
would
be
like
a
good
interface
between
hotel
and
first
party
instrumentation,
as
well
as
third-party
instrumentation,
and
I
have
to
imagine
that
this
general
idea
can
be
applied
in
other
programming
languages.
It
might
be
like
a
little
less
automatical,
because
it's
kind
of
working
through
that
inherited
hook
right
now,
but
it's
basically
like
a
fancy
registry.
B
You
just
don't
have
to
actually
call
like
register
on
a
thing,
so
I
don't
know.
C
There
is
one
thing:
it's
a
two-parter
and
tim
is
taking
a
crack
at
splitting
out
the
active
support
notifications
out
of
action
view
so
that
it
becomes
reusable
across
like
usable
in
itself
like
I
just
want
to
subscribe
to
notifications
like
make
it
generic,
but
also
reusable
against
other
instrumentations.
C
C
Not
this
pr
action
view,
but
more
specifically,
I
believe
it's
the
notification
subscriber.
I
don't
know
if
it's
some
internal
code
we
have
or
if
there's
something
with
the
two
or,
if
it's
just
a
really
unfortunate
interaction.
I've
just
blanket
dissolved
disabled
it
because
it
was
killing
logs
and
a
bunch
of
older
apps
for
us.
A
Oh,
my
god,
okay!
Well,
I
haven't
looked.
We
haven't
used
this
yet
so
I
don't
have
any
feedback
to
give
we're.
Still
on
rc
two
I
started
rolling
the
upgraded
rc3.
As
you
noted,
helping
me
rubber
duck.
It
see
all
right
matt.
Take
it
easy
that
that's
all
I
guess.
Okay,
I
don't
know
where
andrew
is
at.
C
That's
okay!
I
I
I
think
it's
just
a
good
heads
up
for
you,
so
I
guess
we've
since
mostly
moved
away
from
it
internally,
but
there
was
like
some
older.
I
don't
even
know
if
I'll
call
it
old
right.
There's
code,
I'm
unfamiliar
with
that
uses
instrumentation,
like
the
active
support.
Sorry
active
support
notification
to,
I
think,
hook
on
to
like
controller
actions
for
logging
or
something
like
that.
C
I've
only
like
looked
at
the
surface,
it
doesn't
raise,
it
doesn't
scream
anywhere,
but
I
do
know
that
when
apps
migrated
to
our
release
that
had
this
instrumentation
active,
they
lost
a
huge
swath
of
logs,
because
that
was
no
longer
active,
but
only
one
person
actually
noticed
like
a
couple
days
later.
Unfortunately,
they
thought
it
was
open
telemetry
and
because
it
was
really
hard
to
figure
out
otherwise,
because
it
didn't
make
any
noise,
it
made
the
absence
of
noise,
so
we've
disabled
it
internally.
C
I
need
to
look
into
it
see
if
it's
just
again
an
unfortunate
interaction
between
these
two
implementations,
but
I
I
am
a
little
bit
more
leaning
into
it
being
the
action
view
thing
just
because
it's
the
newer
one
and
the
other
one
has
been
around
for
a
while,
and
I
think
raphael
might
have
wrote
it.
So
I
have
a
bit
of
confidence
there.
A
Sure
thing
sure
thing,
my
friend,
okay,
your
eyes
are
moving
so
you're.
Still
there
robert
thanks
a
lot
for
everything.
I
wanted
to
ask
you
some
stuff,
but
I
you
know
it'll
be
probably
through
slack
specifically
about
the
http
utils
for
sharing
common
attributes
and
the
configuration
of
pure
service
for
faraday
are
y'all
using
the
peer
service
configuration
at
all.
C
A
So
one
challenge
I've
run
into
is
that
it
looks
like
the
only
way
I
can
configure
pure
service
is
at
the
sdk
configuration
level
and
not
on
the
individual
bucket
of
not
on
the
individual
faraday
connections
themselves.
C
If
you
remind
me
on
slack,
I
think
it
is
like
not
a
lot
of
code.
He
was
looking
at
potentially
open
sourcing
it
or
putting
it
up
it.
I
don't
think
it
really
fit
into
the
instrumentation
library.
I
think
it's
more
I'll
find
the
code
and
I'll
show
you
an
example,
because
it's
super
it
should
be
super
generic.
C
It's,
like
you,
add
a
middleware
and
just
an
extra
argument
and
then
for
each
of
your
connection,
you
just
like,
say
what
it
is
and
then
you
get
the
desired
behavior
of
like,
because
I'm
assuming
you
have
multiple
connections
that
you
want
to
set
the
pure
service
to
right,
and
so
they
did
something
like
that,
and
it
was
like,
like
a
20-line
change
of
code
or
something
like
that,
it's
like
tiny,
it's
just
it
was
just.
He
did
it
as
like
a
little
faraday
middleware.
A
Interesting,
so
we
would
because
we
would
have
the
current
span
at
that
point,
we
can
amend
the
peer
service
attribute
to
the
current
span,
because
it's
part
of
the
brac
that
faraday
middleware
has
been
inserted
in
the
beginning
of
the
faraday
middleware,
so
this
ban
exists
first
by
the
time
it
gets
to
me.
So
my
next
question,
for
you
is
the
http
attribute
utilities
that
shares
the
attributes.
A
D
A
A
C
And
you
say
any
network
calls
made
within
this
yield,
or
this
block
should
just
tack
on
these
attributes
and
so
what
I
think
they
did
and
again
I
have
to
look
at
I'm
not
super
familiar
with
faraday's
they
just
like
they
set
up
something
that
happens
before
this
that
so
when
they
establish
a
new
connection,
they're
just
like
hey
attack
on
the
pure
service
and
then
in
all
the
different
client
calls.
They
just
specify
who's
who
right.
A
Yup
yup
totally
understood,
and
then
so
it
made
me
think
about
other
instrumentation
and
and
if
a
concept
like
this
would
be
useful,
which
is
essentially
to
have
like
a
scope
to
attach
a
you
know,
a
context:
entry
to
attach
the
same
attributes
across
all
the
child.
Instrumentations.
A
I'm
thinking
about
this
in
the
case
of
like
I've
got
the
database
driver,
one,
the
you
know
the
database
adapter
and
then
like
the
active
record
and
should
all
those
have
some
sort
of
scope
that
gets
attached
to
all
the
the
the
child
spans
or
like.
If
there's
some
sort
of
user-defined
data
that
I
want
to
be
able
to
propagate
to
all
the
child
spans
and
attack.
A
Yeah,
like
essentially
to
say
like
within
this
context,
I
want
to
share
all
these
attributes.
That's
not
something
that's
part
of
the
api
right,
but
it's
something
I
I
think
about
because,
like
here's,
a
use
case
like
I
want
all
of
the
you
know,
calls
to
service
b
that
have
this
attribute.
This
band
attribute
associated
with
it,
as
opposed
to
I,
I
suppose,
that's
the
baggage.
A
C
A
Just
yeah.
C
I'm
just
trying
to
think
of
like
the
generic
version,
because
we
we
did
not
do
that
intentionally
because
we're
like
we
want
this
to
be
a
little
bit
more
targeted
like.
I
could
see
a
version
of
this
existing
for
like
databases,
but
it's
like
there
may
be
between
the
point
I
make
this
call
and
this
gets
merged.
There
could
be
other
spans
that
are
generated
or
other
spans
that
are
generated
the
context,
and
I
don't
necessarily
want
to
like
tack
on
pure
service
to
all
of
them
right
yeah.
So
no.
C
A
On
like,
like
a
repository
id
or
something
that
would
be
associated
with
all
so,
I
could
say
like
I
want
all
calls
to
the
service.
I
have
this
repository
id
in
it
from
the
caller
side,
as
opposed
to
from
the
you
know,
but
that
you
know,
but
I'm
also,
assuming
that
I
couldn't
infer
that
from
other
semantic
attributes
that
are
in
there.
But
you
know
the
place
to
put
them
would
be
in
the
client
context,
attributes
essentially,
okay,.
C
Yeah,
but
to
your
point,
though,
talking
about
like
end
user
id,
that's
something
I
am
thinking
about
right
now
because,
like
we
obviously
have
our
monolith
and
it's
usually
the
entry
point
for
a
lot
of
other
applications.
C
It's
like
it
would
be
easy
if
this
tenant
id
was
present
anywhere,
it
could
be
for
analysis,
but
maybe
I'm
holding
it
wrong,
something
I'm
gonna
be
talking
about
with
like
francis
next
week,
when
he's
back.
A
A
But
the
question
is
then:
well:
how
big
does
the
baggage
get
if
every
application
is
appending
stuff
to
it
versus
something
that's
like
scoped
to
where
I
want
to
be,
which
is
just
within
my
application
boundary
and
then
are
there
things
that
are
there,
parameters
that
are
getting
passed
through
like
the
apis
between
these
two
systems
and
is
the
end
user
id
information
included
in
that
api
call
it's
hard
to
tell,
but
in
my
case
it's
like,
I
know
specifically,
I
want
a
specific,
like
a
request
id
that
is
separate
from
the
trace
id,
because
some
systems
will
support
it.
A
Another
and
you
probably
gotta,
go
because
now
it's
an
hour
and
ten
minutes,
but
I'll.
Let
you
get
out
of
here.
I
got
like
in
my
head
that
I
need
to
get
out
and
yeah.