►
From YouTube: 2021-08-25 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).
B
Oh,
no,
you
should
get
on
the
horn
with
your
github
friends.
A
Oh
wait:
like
the
tenth
try
worked,
I
was
trying
to
update
the
branch
protection
rules
so
that
we
still
had
for
those
cherry
pick
prs.
We
still
had
the
original
setting
where
the
pr
had
to
be
up
to
date
before
you
could
merge
it.
B
You
know
when,
when
a
back-end
service
is
having
trouble
trask,
the
best
thing
you
can
do
for
it
is
to
make
sure
you
click
lots
and
lots
of
times.
So
it
has
more
stress.
B
Oh
well,
there
was
discussion,
it's
worth
talking
about
the
semantic
convention
stuff
that
I
brought
up,
but
they
are
gonna.
Do
a
patch
release
with
the
semantic
convention
fixes
put
in
so
hopefully,
when
that
happens,
I
can
get
my
pr
correct
and
not
have
to
put
in
a
bunch
of
hacks
to
change
the
names
of
the
constants.
B
B
B
B
B
I
guess
instrumentation,
when
you're
using
your
resource
anyway,
anyway,
there's
a
whole
issue
about
it.
There's
a
lot
about
it.
At
the
moment
I
haven't
followed
it
all.
A
I
tried
the
cherry
picking
version,
but
one
of
the
cherry
picks
updated
the
yaml
file,
the
build
gmo
file,
and
so
it
wouldn't
let
workflow
a
workflow
update
the
workflow
files.
C
B
C
C
A
A
C
Oh
no,
this
is
the
one
crossed
out
their
names,
for
this
meeting
actually
does
seem
like
a
concept
that
makes
sense.
A
A
E
E
Just
getting
back
from
vacation,
so
I
don't
even
have
anything
interesting
to
say
today,
but
I
I
was
poking
a
lolita
to
try
to
figure
out
what
was
happening
in
general
with
these
meetings,
because
it
seemed
like
microsoft
and
aws
were
kind
of
running
with
the
ball
around
like
the
semantic
inventions
and
all
of
that.
But
but
then
it
seemed
like
it
like
it.
Hadn't
been
moving
forwards,
so
I'd
like
to
see
those
meetings
get
get
get
actually
created
and
rolling,
but
that
didn't
anything
to
do
with
this
meeting.
E
I
think
this
meeting
is
about
instrumentation
work,
but
again
I
just
got
back
today,
so
I
haven't
gotten
any
answers
yet
about
any
of
those.
Those
things.
C
E
D
C
To
make
sense,
of
course,
making
instrumentation
easy
to
write
is
important,
but.
C
C
And
so
the
next
step,
I
think
for
java
we
have
written
like
we
have
many
different
instrumentation
with
knobs,
but
still
haven't
made
sort
of
a
standard
contract
for
what
configuration
knobs
are
available
in
each
instrumentation
library.
So
I
was
going
to
try
to
write
a
base
class
for
sort
of
a
builder,
which
is,
of
course
I
could
figure
stuff
in
java,
and
so
what
knobs
we
support
and
then,
after
seeing
that,
we
can
try
to
look
at
maybe
a
more
declarative
way
as
well.
Rather.
D
C
E
Yeah,
I
think
that
that
also
relates
to
native
instrumentation
right,
because
with
native
instrumentation
you
don't
you
don't
have
that
programmatic
knob
anymore,
really
right,
like
the
instrumentation
is
just
there.
It's
not
a
thing.
You
you
register
or
choose
not
to
register.
C
Yeah,
I
think,
we're
ex.
So
that's
what
we
need
right,
that
we
need
to
make
sure
the
native
instrumentation
can
also
expose
the
knobs
that
we
sort
of
expect
instrumentation
to
expose
yeah.
So,
for
example,
if
this
tracing
builder
is
published,
then
we
want
native
instrumentation
to
be
using
this
in
their.
D
E
Yeah
yeah,
I
think
that
providing
these
these
helpers
and
abstractions
my
hope
is
like
well-
will
help
with
that.
This
is
the
thing
that
was
kind
of
coming
up
in
the
spec
meeting
this
morning
is
we're
seeing
various
groups
as
they
start
in
integrating
open,
telemetry
they're,
starting
to
kind
of
like
fill
some
gaps,
that
open
telemetry
has
around
things
like
registration,
registering,
plugins
and
controlling
stuff.
This
is
maybe
more.
E
I
think
the
example
this
morning
were
more
like
services,
that,
like
black
box
services,
that
want
to
have
open
telemetry
as
part
of
it
and
because
they're
a
service
right
like
they
have
to
pre-package
whatever
open
telemetry
things
are
going
to
be
available
because
it's
not
like
the
end
users
going
to
have
like
a
compile
opportunity
like
in
their
application
to
choose,
say
like
which
exporter
they
want
to
use,
and
things
like
that,
and
so
they
were
having
to
kind
of
build
like
their
own
sort
of
plug-in
registration
system.
E
You
know
they
there,
just
like,
isn't
any
any
language
level,
dynamic
concept
for
being
able
to
manage
this
stuff,
and
so
they
were
having
to
build
like,
like
their
own
kind
of
wrapper,
around
open
telemetry
for
choosing
like
what
stuff
gets
turned
on.
How
do
you
configure
it
and
all
of
that,
because
we
don't
really
have
anything
written
down
in
the
open
telemetry
spec?
For
for
how
you
would
do
that,
we
have
an
ever-growing
pile
of
environment
variables.
E
That
are,
you
know
not
particularly
cohesive,
but
that's
not
that's
not
like.
Wasn't
really
clearly
isn't
enough,
so
I
think
there's
a
related
effort
to
figure
out
what
is
like
configuration
look
like
for
open
telemetry
in
general.
C
The
would
probably
look
very
different,
but
I
do
feel
like
there's
the
general
direction
that
every
language
is
going
to
need
to
provide
an
instrumentation
api
of
some
sort
which
the
other,
like
instrumentation
instrumentations,
probably
shouldn't
use
the
open
telemetry
in
general.
Just
because
that
doesn't
provide
these
configuration
aspects.
It's
really
just
data
collection,
yeah
and
so
like
the
languages
would
probably
need
to
provide
a
library
as
well
that
instrumentation
native.
D
D
C
D
I
was
saying
like
for
the
ruby
implementation
we
kind
of
ran
into
that
and
we
started
like
we
have
for
our
third-party
instrumentation.
We
have
a
registry
so
like
all
these
libraries
that
we
maintain
they
pull
it
in
and
inherit
from
it,
so
they
register
it
and
they
all
have
a
kind
of
a
common
configuration
language.
D
But
when
we
started
looking
at
pushing
first
party
instrumentation
or
native
instrumentation,
we
were
a
little
apprehensive
to
say:
you
should
depend
on
this
kind
of
abstraction
because
it's
not
specked
out.
So
we
kind
of
pull
back
and
say
just
depend
on
the
api
for
now,
and
we
kind
of
did
a
guided
approach,
but,
like
you're
saying,
is
how
how
do
they
provide
the
knobs
and
levers
to
say
for
a
consumer
of
this?
This
dependency?
D
E
And
I'm
not
sure
how
much
of
this
is
like.
Certainly
for
for
things
like
is
the
instrumentation
on
or
not?
Is
that
something
that
like
pieces
of
instrumentation,
can
figure
or
is
that
something
that
is
configured
in
the
sdk
in
some
like
more
generic
sense.
D
D
D
E
I
mean
the
declarative
stuff
in
general
seems
nice,
but
can
get
unwieldy
very
quickly.
I
think
declarative
programming
like
designing
declarative
programming
is
actually
really
difficult.
It's
it's
under
appreciated
how
difficult
it
is
to
to
do
it
while
retaining
some
level
of
simplicity
or
cleanliness.
Unless
your
problem
is
truly
like
really
simple,.
E
A
E
Yeah,
I
I
think
it
is
hard
it.
It
does
seem
to
me
to
be.
If
it's
a
thing
we
can
do
well,
it's
it's
very
valuable
for
this
project,
just
because
it
if,
for
no
other
reason
it
gives
operators
control
right
like
if
you
have
to
do
things
programmatically,
then
you're.
You
need
to
do
it
at
code
writing
time
right,
like
that's
the
problem
with
doing
things
programmatically,
and
so
it
limits
it.
That's
like
that
itself
is
like
pretty
limiting
for
us
to
come
back
to
people
and
say
like
well.
E
Just
just
do
it
programmatically.
If
you
want
to
do
a
certain
thing,
the
the
more
declarative
we
can
make
this
stuff,
the
the
better
it's
gonna,
be.
D
To
touch
on
guidance
a
little
bit,
things
like
configuration
defaults
like
we'll,
eventually
establish
some
sort
of
conventions
and
one
of
the
ones
we've
kind
of
come
into
or
right
across
already
is
for,
like
a
database
say
you
have
the
db
statement,
whether
you
include
it
or
omit
it
or
say:
oh,
you
might
want
to
obfuscation.
D
What
is
the
default?
Should
we
be
opinionated?
There
should
be
pushing
that
on
instrumentation
authors,
saying
like
if
you're
gonna
add
instrumentation
for
a
database,
your
default
should
be
obviously
the
database
statement
or
omitting
it
right
like
what
do
we
think
do
how
how
opinionated
do
we
want
to
be
on
that?
Does
anyone
have
like
any
sentiments
towards
that?
Because
that's
a
discussion?
That's
come
up
a
few
times
for
us
and
we've
kind
of
went
towards
like
we
should
be
trying
to
protect
the
users
and
say
like
there's
going
to
be
a
default.
A
Yeah
in
java,
in
the
java
instrumentation,
we
have
we
default
to
sanitize.
We
call
it
sanitizing
and
we
default
to
sanitizing
all
queries.
B
C
Like
I
think
this
sort
of
behavior
should
be
documented
in
the
semantic
conventions.
If
some
question
comes
up,
we
can
probably
file
issues
but
like
how
to
fill
in
attributes
that
we
can
standardize
and
make
sure
that
all
the
languages
are
filled
in
in
the
same
way
to
make
sure
beckons
get
a
consistent
view.
D
E
E
E
I
don't
know
to
what
degree
we
can
fully
provide
tooling
to
every.
You
know,
database
vendor,
who
wants
to
bake
this
stuff
in,
but
if
we
can
at
least
provide
them
guidelines
like
that's,
that's
a
big
step
forward.
C
D
B
C
E
This
is
again
probably
something
easier
in
java
than
another
language,
but
I
wonder
like
especially
for
native
instrumentation.
How
do
you
pass
this
configuration
info
to
it.
A
E
A
loading
issue
problem
right,
like
it
would
be
possible.
Let's
say
for
open
telemetry
to
like
expose
an
api
for
being
able
to
to
read
like
let's
say
we
come
up
with
an
open,
telemetry
configuration
format
and
that
gets
like
could
get
fed
into
the
system
through
a
variety
of
ways:
config
file,
environment
variables
whatever,
but
at
some
point
it
resolves,
and
then
you
could
ask
to
read
it
through
an
api,
but
you're
gonna
still
have
like,
like
that
sounds
like
loading
hell,
trying
to
sort
out
how
to
do
that.
A
A
I
mean
that
this
all
requires
then
programmatic
creation
of
the
builders
and
explicit
passing
that
in
so.
If
you
want
to
have
like
a
loose
binding
extension
model,
then
yeah
you
end
up
having
those
ordering
issues
yeah,
but
at
least
in
java
I
mean
we
have
some
spi's
already
that
deal
with
that
ordering
issue.
A
A
I
guess,
if
you
don't
want
manual
injection,
you
have
the
java
agent
and
the
java
agent
controls
since
it
starts
up
at
the
beginning.
It
has
full
control
over
ordering
and
injection
and
all
that,
so
it
becomes
not
as
big
of
a
problem.
E
Yeah
I
mean,
maybe
we
don't
have
to
solve
it
all
at
once.
It
sounds
like
like
step.
One
is
figure
out
what
kind
of
configuration
we
want
to
offer
people,
and
certainly
in
every
language
you
could
offer
the
advantage
of
having
the
standardized
is.
There's
at
least
you
know,
an
object
or
a
class
that
everyone
can
agree
upon,
represents
the
configuration
and
then
various
libraries
and
things
can
come
up
with
what
whatever
the
most
effective
way
is
to
like
pass
that
information
to
it.
E
But
at
least
the
information
there
they're
getting
passed
is
something
that's
not
not
something
they're
inventing
right,
it's
something
that
they
can.
They
can
reference
from
open,
telemetry
right
now.
Those
projects
are
kind
of
like
inventing
their
own
configuration
options
in
their
own
configuration
language
which,
like.
D
E
D
A
C
E
And
is
that
sanitizer
itself
like
how
that
sanitizer
works?
Is
that
a
thing
that
potentially
is
like
the
kind
of
thing
that
should
go
into
the
hotel,
spec
or
something
that's
expect
elsewhere?
That
I
mean
ideally,
you
know,
sql
is
equal
rights,
ideally
we're
sanitizing
it
this
the
same
way
everywhere.
C
A
E
E
Yeah
yeah
that
all
sounds
like
nice
things
to
like
get
get
into
like
the
spec
or
something
I
mean
the
the
advantage
also
is,
if
we
write
it
down
in
some
way
like
that,
it
would
be
easy
to
get
like
experts
from
those
communities
right
like
people
from
those
companies
to
say
hey.
Can
you
like
th?
This
is
how
we're
doing
sanitization.
Does
this
look
right
to
you?
Could
you
improve
this
slash
own
this
so
that
we're
not
guessing
over
here?
E
I
don't
I
don't
think
so.
Yet
this
is
where
I'm
a
little
unclear,
because,
like
right
now,
it's
it's
microsoft
and
aws
kind
of
like
meeting
and
private,
and
so
I'm
not
totally
sure
what
what
they're
up
to
yet.
But
my
impression
is
that
we
would
be
starting
these
meetings.
I
don't
know
if
we
want
to
call
them
all
separate
cigs,
but
we
would
be
starting
these
meetings
as
we're
able
to
get
subject
matter.
Experts
to
like
show
up
and
help.
E
E
But
yeah
I'd
like
to
learn
more
about
what
what
their
plan
is
and
if
a
leader
someone
there
is
like
running
these
things
or
are
they
expecting
me
me
to
run
them
for
them?
So
I'm
trying
to
get
that
figured
out
today.
A
Well,
I
can
come
back
to
this
meeting
next
week
and
with
a
list
of
basically
the
configuration
options
that
we
have
in
java.
C
B
A
I'm
not
sure
if
there's
like
that,
sanitizer
was
a
good
call
out
robert.
I
don't
have
to
look,
I'm
not
sure
if
we
have
any
other
kind
of
good,
similar
concepts
in
our
instrumentation
api.
That
would
be
worth
sort
of
standardizing.
E
And
in
terms
of
applying
these
configurations
in
java,
is
that
currently,
just
is
it
just
kind
of
like
blanket
like
like
sanitization
is,
is
on
or
off
like
everywhere,
for
for
all
simple
clients,
or
is
there
a
way
to
to
do
like
more
specific
targeting.
A
D
Yeah,
that's
interesting
because
we
like
we
took
the
opposite
approach,
different,
like
different
approach,
where
we
made
it
uniform
that,
like
the
db
statement,
configuration
option
is
you
can
kind
of
expect
it
on
like
any
sort
of
database
gem
like
your
mysql
or
postgres,
but
you
have
to
configure
it
per
instrumentation
library.
It's
not
assumed
that
you
set
it
once
and
sets
everywhere.
D
You
have
to
specify
it
for
each
of
them,
but
we
also
specify
default
behaviors
right,
so
you
don't
actually
have
to
do
any
of
the
configuration
that's
going
to
lean
back
into
these
defaults
that
we
believe
are
best.
D
Like
just,
for
example,
like
kind
of
like
a
use
case
that
we've
seen
in
practice
is
like,
obviously
we
want
to
or
not
obviously
we
want
to
obfuscate
like
or
my
sql
statements
but
say
redis,
maybe
first
certain
application.
We
don't
care
right,
like
maybe
they
do
want
to
see
the
actual
db
statement
there.
D
So
we
want
to
allow
them
to
include
it
or
maybe
they
want
to
omit
that
one
entirely
and
for
our
configuration
option
for
that,
it's
it's
actually
just
like
kind
of
up
you
either
say
pass
it
over
include
or
obviously
right.
D
And
then
the
the
defaults
are
inconsistent
right
now,
which
is
not
good
right
now.
Some
of
them
include
some
of
them
in
a
confiscated,
so
we
have
to
make
that
uniform,
but
one
of
our
bigger
consumers,
like
I
think
it's
github,
is
reporting
issues
with
the
confiscation
code
for
mysql
or
something
like
that.
I
think
it
was
my
sequel
and
so
we're
like
do.
D
We
want
to
put
that
as
a
default
if
it's
causing
problems
right,
I
know
like
github's
rails
model
is
probably
an
outlier
compared
to
most
consumers
of
this,
but
still
like
it's
like
that
balance
of
being
defensive
right,
like
you,
don't
want,
like
our
kind
of
the
attitude
that
comes
out
of
like
our
rogue
working
group
is
like,
we
don't
want
someone
to
try
to
adopt
open,
telemetry
and
bring
down
their
application
and
then
be
like
this
sucks
right.
D
E
Yeah
I
mean
you
could
default
to
omit,
but
the
unfortunate
side
effect
of
that
is
I've
definitely
seen
users
if
like
by,
if
you're,
if
we're
conservative
by
default
and
the
amount
of
data
we
produce,
then
they
look
at
their
first.
Experience
is
like
there
isn't
very
much
data
and
they're
kind
of
like
well
this.
This
sucks.
D
So
and
there's
definitely
different
kinds
of
users,
like
not
every
company
controls
like
their
full
pipeline
right,
like
we're
fortunate
in
our
group
that
we
own
it
all
right.
So
in
our
collectors,
that's
where
we
either
obfuscate
or
redact
right.
So
when
we
leave
it
to
the
default
to
include
it's
good
for
us,
because
anybody
who's
doing
tracing
in
the
local
environment,
they
can
see
the
full
statements
on
their
machine
while
they're
debugging,
which
is
really
great.
That's
like
the
kind
of
experience
and
that's
good
for
adoption
as
well
right,
yes,.
E
D
It's
it's
hard,
like
that's
one
of
the
things
that
I've
been
like
struggling
with,
like
being
more
firm
on.
I
think,
if
we're
gonna
lean
somewhere,
it's
probably
gonna
be
obfuscated
just
because
nobody
wants
to
deal
with
like
some
sort
of
pii
incident.
I
think
everybody
dreads
that
I
know
I
do
so
trying
to
protect
people
is
really
important.
There.
A
A
We
were
lucky
in
the
java
group
to
have
john
blay,
implement
the
senate
to
the
sanitization
of
sql,
who
has
like
20
years
of
experience
in
this
doing
the
same
thing.
D
D
Yeah
we
we
for
the
one
we
have.
We
tentatively
had
it
sort
of
donated
by
new
relic
informally.
Someone
from
gorilla
was
participating.
They
said
that,
like
yeah,
it's
open
source
right,
so
we
can
pull
the
code.
That's
been
kind
of
battle
tested
there,
but
yeah
just
on
top
of
mine,
just
like
throw
another
curveball
and
talk
about
like
configuration
files
and
things
like
that.
For
for
ruby,
we
have
the
common
rack,
which
is
like
the
web
server
middleware
right
and
a
use
case
that
comes
up
pretty
often
is
like.
D
I
don't
want
to
trace
my
health
check,
endpoint
right,
so
you
have
like
that's
an
option
to
specify
I'm
traced
to
endpoints
pretty
easy.
You
can
pass
in
a
string,
but
I'd
say
it
was
like
less
than
a
week
after
we
added
that
option.
Someone
said
well
what
if
I
want
to
untrace
it
based
off
of
a
header
or
some
sort
of
query,
parameter
or
some
sort
of
infinite
possibilities
and
start
there,
so
we
allow
passing
a
prompt,
so
you
can
decide
whatever
you
want.
You
just
pass
in
a
process
right.
D
Your
configuration
values
for
tracing
the
endpoint
like
and
it'll
return,
true
or
false,
and
based
off
what
you
supply,
you
can
add
a
lot
of
customization
there,
but
obviously
that
doesn't
really
fit
in
the
realm
of
like
a
config
file.
Right,
like
I,
don't
know
how
to
huge.
E
I
would
say
in
this
case
it's
it's
the
same
thing
just
because
I
feel
like
there's
like
this
special
case
of
I
want
to
suppress
data
collection
and
when
you're
saying
like
I
want
to
suppress
data
collection,
it
turns
out
there
just
like
happens
to
be
a
couple
different
places.
E
You
could
do
that
because
we
have
like
a
sampler
and
like
sampling
is
about
happens
to
be
about
like
suppressing
things
and
so
far
the
only
complicated
use
case
has
been
around
suppressing
stuff,
but
that
wouldn't
work
if
they
were
trying
to
do
custom.
Targeting
of
like
something
else-
and
I
don't
know
how
complicated
we
need
to
make
things,
but
it
does
seem
to
be
like
there
is
a.
E
There's
at
least
one
use
case
where
there
needs
to
be
the
ability
to
do
some
kind
of
targeting.
Josh
has
brought
this
up
as
around
views
so
like
from
the
metrics
side.
There's
this
concept
of
views
right,
where
your
your
kind
of
metrics
has
a
lot
of
this.
Like
configuration
issues
around
like
what
labels
do
you
want
on?
It's
not
like
tracing
where
you
can
just
hand
the
user,
all
the
data
and
say
like
have
fun
right,
like
the
more
the
more
data
you're
handing
them,
the
more
you're,
actually
changing
the
metric.
A
And
then,
where
you're
blowing
out
their
metrics
costs,
we
got
this
reported
yesterday.
A
E
And
so
metrics
yeah
metrics
has
this
actual.
Like
has
this
kind
of
complex
configuration
issue
of
like
well,
we
could
come
up
with
like
a
good
set
of
of
defaults
for
like
what
the
label
sets
should
be
for
various
metrics
that
are
probably
like
fine
defaults,
but
it
seems
super
obvious
that
everyone's
going
to
start
coming
back
to
that
and
wanting
to
change
those
label
sets.
E
And
he
was
noticing
that
there
seems
to
be
like
some
commonality
to
like
that
kind
of
targeting,
and
the
kind
of
targeting
you'd
want
to
be
doing
for
like
suppressing
instrumentation,
and
it
seems
kind
of
similar
to
the
targeting
we'd
want
to
be
doing
for
some
of
these,
like
micro,
targeted
configuration
things
like
you
know.
For
for
this
end
point
I
want
these
status
codes
to
be
marked
as
errors
or
like
like
I
want.
I
want
this.
E
This
set
of
things
to
result
in
an
error,
and
I'm
a
little
concerned
that,
like
the
more
and
more
we
go
down
that
road
bogdan
was
pointing
out
it's
like
eventually
you're
gonna,
like
turn
every
sdk
into
like
a
collector,
essentially
in
terms
of
like
the
kind
of
processing
is
doing,
and
that
seems
bad,
so
there's
probably
some
kind
of
cutoff
that
we
have
to
make
when
it
comes
to
like
configuration
and
declarative
control
over
this
stuff.
E
If
we
don't
want
to
turn
every
sdk
into
into
a
collector
with
like
a
processor
pipeline
and,
like
you
know,
like
it'll,
just
end
up
looking
like
the
collector,
basically
right
collectors,
where
we
have
that
really
complicated
declarative
like
thing
going
on.
C
Just
so
many
people
that
hate
running
demons
and
so
like
the
collector
is
convenient
to
have
all
this
functionality
first
for
all
the
languages,
but
as
I'm
going
to
support
more
collector
functionality
at
prevent
it
allows
the
use
case
of
not
having
the
collector,
which
is
convenient.
I
think
so.
I
sort
of
thought
that
maybe
it's
just
a
timing
issue
that
collector
it's
easier
to
get
out
first
and
then
the
stick
is
thrown
off
more
of
that
functionality
over
the
long
term,
but
maybe
not.
A
And
I
think
it's
okay,
if
different
languages
go
to
different
degrees
in
supporting
those
as
long
as
those
who
do
do,
those
have
all
do
it
in
the
same
way.
E
Yeah
yeah,
maybe
that
is
a
way
to
allay
some
of
bogdan's
concerns,
because
I
mean,
I
guess,
I'm
a
little
concerned
about.
Perhaps
the
innate
overhead
of
having
this
stuff
baked
into
the
sdks,
there's
probably
a
way
to
to
do
it
where
it
doesn't
necessarily
incur
a
lot
of
overhead,
but
like
all
of
that,
the
the
more
complex
the
targeting
and
the
more
the
more
of
this
we
make
like
the
more
overhead
there's
gonna
be
right,
but
yeah.
I
think
you
have
a
great
point
to
ask
which
is
like
whatever
we're
gonna
do.
E
If
it's
in
this,
if
we
can
just
spec
it
out
and
have
it,
you
know
whichever
languages
are,
willing
can
have
it
and
then,
if
end
users
show
up
and
they're
like
wait,
that's
not
available
here,
there's
kind
of
an
easy
place
to
point
them
being
like.
Well,
if
you
want
to
like
come
help
make
that
a
reality
like
you
know,
here's
here's
the
target
to
shoot
for
and
then
it
doesn't
feel
like
the
maintainers
are
suddenly
being.
I
think
maintainers
would
be
a
little
bit
scared
if
this
like
stuff
started
going
into
the
spec.
A
Because
up
to
this
point,
most
of
the
stuff
going
into
the
spec
has
been
sort
of
required.
A
Yeah
we
had
a
when
we,
when
john
had
initially
done
the
sanitizer
implementation
that
that
was
brought
up
of,
should
it
that
be
done
at
the
collector
side
again
from
both
the
performance
perspective
and
a
just
build
it
once
perspective,
but
yeah.
We
kind
of,
I
think
multiple
people
felt
that
same
way
of
we
have
customers
who
are
not
using
the
collector
who
this
is
important
for
yeah.
E
Yeah,
so
that's
that's
like
another
aspect
of
this,
but
I
think
we
could
probably
punt
on
that
and
just
just
stick
with
saying,
like
we're.
E
Gonna
come
up
with
a
declarative
way
of
managing
this
stuff
and
right
now
it's
just
universal
and
the
use
case
of
like
and
maybe
just
explore,
like
suppression,
instrumentation
suppression
is
kind
of
like
a
special
case,
which
would
like
include
the
health
check
issue
right
like
because
that
does
seem
to
be
a
place
where,
like
like
information,
suppression
is
sort
of
like
micro,
targeted
by
nature
to
some
degree,
and
it's
possible
to
do
that
in
a
kind
of
centralized
place
like
the
sampler
like
the
sdk,
can
can
do
that
in
a
sort
of
centralized
fashion
and
not
not
worry
about
that.
A
A
Are
very
concerned
very
adamant
about
the
instrument,
the
the
amount
of
data
that
we
send
so
yeah.
This
is
this
is
my
one
of
my
more.
D
E
Stuff
yeah,
which
is
like,
I
think
why
health
checks
come
up
too.
I
mean
not
just
like
it's
just
people
are,
being
I
mean:
either
it's
cost
money
or
they're,
being
annoyed
by
just
they're
being
overwhelmed
by
data.
They
don't
care
about
for
whatever
reason,
and
so
it
just
happens
to
be
that
http
health
checks
are
a
common
common
form
of
that.
D
As
soon
as
we
added
the
first,
I
think
message
I
got
like
the
next
day
is
like
someone's
looking
at
their
traces
and
they're
like
what
is
this
crap
and
how
do
I
get
rid
of
it.
So
we're
obviously
don't
want
to
suppress
it,
because
it's
super
useful
to
us,
but
anyways
yeah.
So
I
can
definitely
appreciate
like
the
the
concerns
around
like
things
that
are
noisy.
D
E
E
This,
like
you
know
the
the
collector
pipeline,
comes
to
the
sdks,
but
comes
to
it
in
kind
of
like
a
specific
part,
which
is
we
just
want
to
say
that
end
users
should
have
we.
We
want
to
develop
a
way
to
give
end
users,
fine
grain
control
over
data
collection,
as
opposed
to
something
like
super
coarse
grained,
which
is
just
like
enable
or
disable
like
all
the
netty.
E
You
know
everywhere,
which
is
the
the
the
easier
probably
the
easier
way
to
do
it
right
like
you,
don't
have
to
have
much
of
a
con
declarative
language
to
to
pull
that
off.
That's
that's
simpler,
yeah!
That's
this.
E
A
E
Just
yeah
right
just
turn
this
on
or
off,
but
you
know
for
the
example,
the
most
common
thing
that
doesn't
fall
into
that
is
like
no,
no,
no!
No!
I
want
I
want
http.
I
want
I
want
nettie
on.
I
just
don't
want
like
this
set
of
like
attributes.
When
I
see
this
set
of
attributes
on
on
an
http
span,
I
that
means
I
don't
I
don't
care
about
that
span,
or
it
might
mean
I
don't
care
about
that
trace,
which
is
the
other
kind
of
thing.
I
wonder
about.
C
A
We've
had
a
couple
questions
recently
in
the
java
repo
about
essentially
people
wanting
tail-based
sampling
of
being
able
to
decide
they
will
they
want
to
capture
it
if
it's
an
error
or
if
it's
slow,
yeah.
E
D
We
have
a
team
internally
that
put
a
buffer
in
front
of
our
backstab
processor,
so
they
could
force.
Add
the
like
sampling
priority,
like
we
have
a
flag
to
force
the
sampling
priority
and
they
basically,
if
it's
slower
than
whatever
amount
of
time,
and
if
it's
any
of
these
errors
or
if
there's
like
one
other
qualifier,
that
they
deem
interesting,
they're,
effectively
doing
tail
sampling
in
the
application
and
then
otherwise
they
respect
the
parent
sampling
decision.
D
C
About
the
protocols
exporter
protocols
was
anyone
there
at
the
beginning,
yeah
yeah.
I
was
there
for
that.
So
I'm
surprised
by
this
direction
of
defining
more
exporters,
mainly
because
it
we
have
all
these
other
variables
to
configure
each
exporter.
The
grave
hotel
otlp
underscore
traces
underscore
endpoint.
C
E
I
I
think
the
the
middle
ground
we
were
shooting
with
is
that
like
for
the
time
being,
those
different
exporters
would
just
share
the
same
configuration
variables,
which.
E
So
so
the
the
issue
is
in
most
languages.
Those
different
protocols
actually
are
separate
exporters.
E
So
it's
just
it
actually
is
separate
exporters,
and
so
it
was
kind
of
confusing
people,
because
they're
saying
like
how?
How
are
we
supposed
to
manage
this
environment?
Variable
of
like
otlp
exporter
protocol
configuration
versus
this
other
environment,
variable
of
which
exporter
is
installed
because
we
don't
have
like
an
x,
an
otlp
exporter?
That
like
has
these
different
options.
C
D
E
I
mean:
doesn't
it
it,
it
seemed
to
me
a
little
bit
like
it
was
six
one
way:
half
a
dozen,
the
other
right
like
we're,
not
offering
there's
no
way.
In
neither
scenario
are
we
offering
people
to
install
both
a
otlp,
json
and
otl
grpc
and
configure
them
to
talk
to
separate
endpoints
by
environment
variables,
right
like
what
someone.
C
E
I
feel
like
the
the
next
step
would
be
to
allow
people
to
configure
it
correctly,
and
I
feel
like
this
kind
of
gets
into
they're,
starting
to
be
just
this
general
angsty
sense
that,
and
that
was
part
of
what
was
driving,
that
conversation
of
like
we're
just
kind
of
coming
in
and
like
packing
on
more
and
more
environment
variables,
but
it
doesn't
feel
see
robert.
E
It
doesn't
feel
like
we're
we're
sitting
down
and
trying
to
like
come
up
with
like
a
coherent
configuration.
Experi
experience.
Like
you
know,
all
the
environment
variables
are
like
fine,
but
because
they're,
all
just
kind
of
like
it's
like
feels
like
death
of
a
thousand
paper
cuts,
is,
is
happening.
E
So
it
could
be
that,
like
yeah,
this
decision
we
made
this
morning
like
actually
wasn't
the
right
decision,
but
it's
sort
of
like
this
is
like
kind
of
what
happens
when
yeah.
These
things
are
just
kind
of
coming
up
and
we're
just
kind
of
like
shooting
from
the
shooting
from
the
hip
a
little
bit.
C
E
So
I
would
love
to
see
like
so
another
way
of
putting
it
is
we
we
don't
have
like
in
general,
we
haven't
defined.
This
is
the
other
thing
that
came
up
besides
just
this
particular
little
environment,
variable
of
like
which
one
is
it
for
this.
E
There
is
one
because
you
could
like
pass
it
like
a
list
of
you
know,
protocols
or
plugins
that
that
you
want
it
to
use,
but
we
don't.
We
haven't
actually
like
written
anything
down
in
the
spec
around
saying,
like
it
should
be
possible
to
have
a
sdk
load
up
several
exporters
and
then
at
runtime
through
configuration
choose
which
of
them
it
wants
to
use,
for
example,
or
samplers
or
propagators.
E
We
haven't
really
defined
that
that
should
be
a
thing
or
how
it
works,
and
part
of
that
is
like
well.
For
the
most
part,
people
just
are
like
manually
installing,
like
whatever
plugins
it
is
that
they
want,
and
that's
that
so
the
ones
that
are
there,
the
ones
they
want.
E
But
if
you're
thinking
about
distributions,
I
think
the
the
black
box
services
are
like
an
example
that
shows
up
where,
for
whatever
reason
like,
we
want
to
like,
have
a
distribution
of
an
sdk
that
that
bakes
in
several
different
options,
because
actually
it
makes
sense
to
configure
this
stuff
at
runtime.
E
E
I
assume
you've
done
this,
like
bacon,
say
being
able
to
like
export
x-ray
and
export
otlp
as
like
options
that
are
just
like
bundled
into
the
aws.
E
You
know
go
distro
or
something
like
that
and,
like
you
know,
we
have
like
the
light
step
launchers
and
at
the
distro
level,
we're
kind
of
like
controlling
that
stuff.
We've
written
our
own
little
rapper.
That
takes
in
some
configuration
that
people
give
us
and
then
manage
it
by
just
only
installing
the
plugins
that
they
said.
They're
gonna
use
like
at
runtime.
E
A
E
A
E
But
for
like
sdk
plugins
like
exporters
right
like
do
you
all
like
ship,
the
zipkin
exporter,
the
jaeger
exporter
and
like
the
otlp
exporters
like?
Are
they
kind
of
like
all,
bundled
in?
And
then
the
user
uses
like
a
configuration
language
of
some
time
kind
to
to
choose.
E
The
plethora
of
environment
variables,
yeah
yeah,
so
that's
a
thing
that,
like
most
of
the
languages,
don't
don't
have
a
way
of
like
respecting
that
necessarily,
and
so
I
think,
that's
why
they're
they
get
a
little
confused
by
some
of
these
options
so
like
in
ruby,
there's
matt
from
ruby
who
was
saying
like
so
there's
this
option
of
saying,
like
which
one
of
these
things
do
I
want
like
json
or
proto
or
grpc,
but
the
answer
is
the
the
one
that
they
included
because.
D
E
Yeah
and
that's
partially,
because
we
haven't
like
described,
you
know
I
mean
I
think
this
gets
down
to
like
different
languages
might
work
differently.
But
even
if
you
have
like
a
totally
manual
language
like
go,
it
should
be
possible
to
like
programmatically
load
it
up
with
a
bunch
of
plugins,
be
like
I'm
just.
E
These
five
exporters
and
then
here's
my
configuration
file-
that's
telling
you
like,
actually
which
exporters
should
be
in
the
pipeline
and
here's
the
configuration
for
those
exporters
yeah.
You
don't
have
anything
like
that
and
so
they're
starting
to
get
real
confused
about
all
these
environment
variables
that
are
coming
in
and
like
makes
sense
what
they're
supposed
to
do
with.
A
A
Hey
there
was
one
topic:
anorak
brought
up
last
week
that
I
was
going
to
bring
up
in
the
maintainer
meeting
yesterday,
but
I
was
busy
interviewing
college
college.
Students
is
the
spring.
Have
you
seen
the
spring
observability
announcement?
A
Well,
maybe
it
wasn't
maybe
maybe
they're
holding
it
under
wraps.
I
was
assuming
it
would
have
leaked
but
they're
at
their
big
annual
spring
one
conference
in
like
a
week
and
a
half
for
a
week
or
two
now
they're,
making
a
big
announcement
about
spring
observability,
which
is
basically
do
you
know
spring
cloud
sleuth.
C
A
It's
basically
that
rebranded
as
spring
observability
under
a
new
namespace
and
packaging,
and
so
it's
unfortunate
that,
but
I
mean
anyway
just
wanted.
A
So
they
have
a
john
john.
Has
different
people
have
worked
with
them
on
the
hotel?
You
know
the
the
shimmy
knit
and
because
obviously,
that
it's
built
on
brave
zipkin
originally-
and
so
I
mean
they're-
definitely
planning
to
support
open
telemetry.
A
It's
just
unfortunate
that
it's
another
in
the
java
ecosystem,
especially
a
big
player
with
their
own
api
that
will
people
yeah
yeah.
It
is,
unfortunately
that
will
be
bridged
and
weird
things
will.
You
know
happen.
E
Yeah
yeah,
I
mean,
I
think,
it's
a
bummer,
I'm
also
kind
of
not
surprised.
I
used
to
work
at
pivotal,
not
I
was
working
on
cloud
foundry,
so
it
was
like
next
door
to
the
spring
people,
but
I
am
aware
about
how
things
run
inside
of
that
place,
and
so
it's
like
not
it's
not
not
like
super
duper
shocking
that
they're
kind
of
like
doing
their
own
thing,
and
it's
a
little
like
out
of
joint
with
what
other
people
are
doing.
E
But
yeah,
oh
well,
I
mean
the
the
thing
I'll
say:
that's
like
I
think
unfortunate
for
them
is
like
it's
kind
of
fine,
but,
like
I
imagine
in
their
world
like
the
spring
ecosystem
is
so
big.
E
It's
like
spring
is
everything,
but
the
thing
we're
doing
is
like
much
bigger
than
java
spring,
and
I
don't
really
see
how
the
thing
they're
doing
can
extend
very
far
beyond
java
spring
and
that
to
me
is
like
why
it's
like
kind
of
unfortunate,
because
they
are
like
a
big
enough
part
of
the
java
ecosystem,
that
it's
a
little
unfortunate
that
they're
that
things
might
be
just
like
an
awkward
fit
for
that
particular
particular
piece.
A
A
E
E
Questions
so
yeah.
I
guess
it
would
be
great
if
we
knew,
but
what
open
telemetry
integration
story
was
gonna
be
with
them.
You
know,
I
don't
know
how
much
like
blog
writing
time.
You'll
have
on
the
java
team,
but
if
something
like
that's
coming,
it
would
probably
be
it
might
be.
I
don't
know
the
current
state
of
things,
but
it
might
be
a
good
time
to
like
release
like
a
open,
telemetry,
blog
post,
about
open
telemetry
in
spring
or
like
at
some
point
when
the
story
is
good.
E
Being
able
to
like
have
like
a
public
thing
like
that
that
you
know
we
can
point
people
at
so
we
don't
have
to
keep
saying
the
exact
same
thing
over
and
over
again
and
customer
meetings.
E
E
Great
yeah
I
mean
so
maybe
just
as
simple
as
that
is
being
like
here's
this.
You
know,
we've
got
lots
of
good
spring
stuff.
Like
I
don't
know,
I
don't
know
that
has
to
be
like
a
rebuttal
to
what
they're
doing,
because
I
don't
think
it's
a
rebuttal.
But
if,
if
if
we
know
we're
gonna
be
getting
a
lot
of
like
questions
on
this
subject,
it
might
be
good
to
to
have
a
public
thing
reinforcing
our
support
for
spring.
E
Cool
okay!
Well,
thanks
for
the
heads
up,
that's
good
to
know
all
right!
Well,
good!
Talking
I'll,
try
to
get
josh
to
come
to
the
next
meeting
to
talk
about
view,
configuration
stuff,
yeah
it's
yeah
and
see
if
there's
some
overlap
to
like
the
kind
of
language
they're
trying
to
develop
for
that,
and
whether
that
would
be
a
good
language
also
for
like
instrumentation
suppression,
because
he
felt
like
they
were
pretty
pretty
similar
targeting
targeting
requirements
so
cool
all
right.