►
From YouTube: 2022-09-01 meeting
Description
Instrumentation: Messaging
B
C
B
A
A
A
A
D
C
E
A
A
A
Those
have
been
copied
to
this
just
from
last
week
also
armin
had
like
a
copy
of
the
the
old
goat
notes
from
almost
exactly
a
year
ago,
so
we've
got
like
august
19th
to
our
2021,
all
the
way
back
to
the
beginning,
but
obviously
comments
are
gone
and
anything
in
the
past
year
has
gone
so
yeah.
I
I
I
don't
know.
A
A
A
Yeah,
okay,
I
reached
out
just
on
the
offhand
that
he
was
the
old
owner,
but
I've
got
a
suspicion
that
the
owner
has
left
a
company
that
they
were
at.
That
was
the
one
that
was
hosting
the
stock,
so
whoever
I
find
is
probably
not
going
to
be
working
wherever
they
were
before
so
just
the
way
it
is
okay,
but
that
being
said,
we
can
probably
jump
in
here.
So
these
are
the
new
notes.
If
you
don't
have
them,
I
posted
them
in
the
chat.
A
A
First
item
is:
I
just
wanted
to
ask,
though,
if
you
do
have
a
copy,
so
just
like
in
google
docs
themselves,
sometimes
like
there's
just
a
copy
that
you
made,
if
you
wouldn't
mind,
checking
and
finding
out,
if
you
have
anything
more
recent
than
august
19th
from
last
year,
if
not,
it's
not
the
end
of
the
world,
but
yeah
just
kind
of
a
request
to
go.
Take
a
look
other
than
that
we
can
kind
of
jump
in
here.
Let's
see,
I
think
we
have
the
metrics
sdk
alpha
progress.
A
A
Go
to
the
project
board,
just
to
kind
of
like
make
sure
everything's
up
to
date.
We
did
merge
the
or
this
synchronous
span
instruments.
I'm
sorry
the
synchronous
instruments,
and
I
think
with
that
we
have
the
ingest
part
of
the
sdk
complete
right,
aaron
yeah,
so
I
mean
we're
we're
really
close.
In
fact
like
we
can
start
using
it.
A
So
what
we
have
is
the
otp
metrics
exporter
is
still
pending,
and
I
wanted
to
ask
a
little
bit
about
this,
because
these
two
pr's,
I
think,
have
been
in
a
reviewable
state
for
the
past
week
and
there
hasn't
been
much
activity
on
them
and
I
do
know-
and
I'm
not
going
to
be
shy
about
the
fact
that
they're
a
thousand
lines.
So
that's
when
I
see
that
it's
hard
to
review
those
kinds
of
code.
A
I
do
know
that
both
of
these
there's
slight
modification
to
them,
but
they
are
copies
from
main,
at
least
like
80,
maybe
a
little
bit
more.
So
I
thought
that
was
somewhat
relevant,
but
I
also
want
to
like
double
check,
because
these
these
are.
You
know
these
we're
on
the
final
stretch-
and
I
don't
know
if
it's
just
that
everyone
doesn't
have
time
to
review,
and
that
can
definitely
be
the
case.
I
know
yeah.
Sorry
josh.
A
I
know
you
took
a
look
at
the
grpc
one
and
it
looks
very
familiar
because
it
is
it's
it's.
It
shouldn't
actually
be
too
different,
but
I
just
want
to
know
if
I
needed
to
like
close
these
and
reopen
them
in
like
smaller
increments
or
what
we
can
do
to
try
to
help
progress.
These
pr's,
because
I
mean
this
is
this-
is
kind
of
like
the
final
hurdle.
So
just
looking
for
info
on
that.
E
B
B
A
Okay,
cool
all
right,
all
right,
then
I'll
I'll
leave
these
then
and
I'll
move
on
from
there.
I've
also
like
I've
kind
of
given
a
little
bit
of
an
overview
like
there's
just
a
few.
We
have
prs,
I
think,
addressing
all
of
the
clients.
Integration
testing
is
up
as
well
hooking
that
integration
testing
up
to
the
grpc
and
http
clients
still
needs
to
be
done.
So
it's
just
kind
of
a
heads
up,
there's
probably
going
to
be
two
or
three
more
prs
on
top
of.
A
A
A
A
A
Yeah,
absolutely
okay
cool,
so
if
the
prometheus
export
also
in
work,
those
are
things
that
are
gonna,
be
like
again.
This
is
the
tail
end
of
trying
to
get
this
alpha
release
out.
I
did
unblock
the
change
log.
I
think
at
this
point
we
could
start
because
we
have
the
ingest
pipeline
or
the
the
creation
pipeline.
All
unblocked.
A
We
can
start
documenting
from
the
end
user's
perspective,
things
that
we
need
to
do
or
need
to
include
in
the
change
log
unless
there's
any
opinions,
otherwise
yeah,
okay,
the
exporter
code.
Still.
Actually,
I
think
this,
I
would
say
this
moves
over
here,
not
like.
It
makes
too
big
a
difference.
The
sdk
metrics
package
still
needs
to
get
documented.
This
is
pretty
minor.
I've
got
a
few
other
things
I'm
working
on,
but
otherwise
I'll
try
to
pick
this
up.
A
If
you
want
to
pick
it
up
just
comment
on
the
issue
or
assign
it
to
yourself.
That
sounds
good.
The
example
code
we
just
talked
about-
we
have
an
owner
here
so
once
the
exporter's
unblocked,
but
then
other
than
that
we're
down
to
the
merge
and
then
the
delete
of
the
development
branches.
But
so
we're
getting
close
just
getting
it
over
the
line,
so
I
guess
the
thing
that
really
would
help
at
this
point
is,
is
the
reviews
I
think
that's
probably
going
to
be
key.
A
D
Hotel
in
it
it
looks
weird-
and
I
don't
I
don't
know
if
there's
a
kind
of
torn
on
that,
so
I
guess
a
couple
of
things.
I
know
I
I
haven't
been
here
in
at
least
a
week.
Maybe
a
couple
of
weeks
just
had
some
different
things
going
on
but
wanted
to
touch
base.
We
had
put
out
a
alpha
or
beta
release
of
like
a
honeycomb
specific
version
tied
to
the
like
the
work
in
progress
branch
to
start
getting
some
feedback.
D
I
had
mentioned
that
one
of
the
last
meetings
just
to
see
is
this
crazy?
Is
this
a
shot
in
the
dark?
We
have.
We've
only
had
a
couple
of
people
look
at
it
as
far
as
the
feedback
we
have
so
far.
It
is
positive,
but
we
don't
have
a
ton
yet
part
of
it
being
because,
obviously
it's
not
it's
not
a
merged
in
thing,
yet
right,
because
our
first
step
is
getting
the
design
agreed
upon
and
then
moving
on
to
the
actual
package.
D
D
Most
of
the
comments
or
questions
or
suggestions
that
were
on
the
design
dock,
with
the
notable
exception,
I
guess
of
whether
we
wanted
to
discuss
further
what
david
had
mentioned
about
being
concerned
about
having
another
interface.
Another
thing
to
support,
I
guess-
and
I
had
updated
the
doc
to
include
a
what
it
isn't
section
that
we
talked
about
to
try
and
be
more
clear
about.
This
is
something
to
easily
streamline
and
make
this
easier
for
those
folks
who
are
new
to
it.
D
A
Yeah
I
haven't
found
the
time
to
take
a
look
at
this
just
yet.
Well
I
mean
the
responses
that
you've
made
in
the
updates.
I'm
just
quickly
looking
over
it
right
now,
and
it
looks
definitely
like
it's
deserving
of
another
review,
so
I
I
will
try
to
prioritize
some
time
to
take
another
look
at
this.
I
would
love
it.
Has
anybody
else
had
the
time
to
to
dig
into
this.
E
E
Vendors
like
us
can
basically
say
to
our
customers:
do
these
couple
of
lines
of
code
and
poof
you're
sending
hotel,
and
so
we
were
trying
to
say
here's
a
vendor-neutral
way
to
do
this
and
then
vendors
can
then
add
their
own
sugar
on
top
of
it,
to
make
it
work
for
them
specifically,
but
even
without
the
vendor-specific
chunk,
you
still
have
a
reduced
amount
of
initialization
code
to
get
basic
hotel,
instrumentation
working.
So
that's
what
we
were
after
and-
and
so
it's
not
like
coverall
bases-
do
everything.
D
And
I
think
one
of
the
things
we
talked
about
in
a
previous
meeting
was
that
the
ideal
end
state
may
ultimately
be
that
this
initialization
is
part
of
just
the
core
sdk
when
you're
using
hotel
go.
This
is
how
you
get
started
and
we're
able
to
reduce
all
of
it,
and
I
think
we
had
talked
about
the
idea
that
that
is
an
ideal
end
state,
but
to
get
there
is
a
lot
of
extra
steps.
A
lot
of
assumptions
a
lot
of
hopefully
we're
right
on
some
of
these
things.
D
So
by
having
it
here
in
the
contrib
and
having
it
released
to
get
more
of
that
feedback
and
work
out
some
of
the
rough
edges
that
makes
it
an
easier
candidate
down
the
road
to
start
moving
it
up
to
the
core
sdk
and
I
think,
there's
been
prior
art
on
that,
at
least
in
other
languages,
where
it's
been
decided
hey.
This
is
so
important.
We
need
to
move
it
out
of
this
extra
package
and
up
to
the
core,
and
so
once
we're
able
to
get
it
into
contrib.
D
A
Yeah
that
all
sounds
in
line
with
what
my
expectation
was
as
well.
I
I
think
I
think
this
is
great.
I
think
people
should
definitely
be
aware
and
spend
some
time
on
looking
at
this.
I
don't
know
how
much
more
we
can
talk
about
it
here,
but
I
definitely
think
it's
worth
to
bring
it
to
everyone's
attention
to
go
back
and
take
a
look
at
it.
I'll
also
try
to
think
of
a
name
for
bike
shedding.
I've
got
some
in
mine,
but.
G
F
F
D
And
one
thing
I
thought
of-
and
I
I
don't
mean
to
cut
you
off,
because
I
want
your
feedback
on
this
too.
I'm
thinking
about
based
on
what
you
wrote
and
what
anthony
just
said
is.
Is
there
the
in
between
state
of
is
the
interface
too
large
and
we
reduce
some
of
those
encode
things
and
rely
more
on
environment
variables,
because
the
nice
thing
about
the
environment
variables
is
it's
still
along
the
same
lines
of
less
lines
of
code?
So
could
part
of
the
compromise
be?
Well?
D
Maybe
we
don't
add
with
endpoint
as
an
example,
I
don't
know,
if
that's
a
good
example,
but
what,
if
we
don't
add
in
the
code
surface
of
with
endpoint,
but
we
still
accept
the
environment,
variable
of
otel,
exporter,
otlp,
endpoint,
or
whatever
else
does
that
reduce
the
amount
of
lines
of
config
of
code
surface
that
we
have
to
support
while
still
achieving
the
goal
of
less
lines
of
code
and
making
it
easier
to
eventually
port
to
the
core.
Just
thinking
out
loud
on
that.
E
You
can
basically
have
a
stable
api
for
what
the
initialization
function
looks
like
it
takes
a
collection
of
those,
and
so
by
having
by
having
that
it
means
that,
when
you
add
features
later
on
logs
or
whatever
they
might
be,
it
becomes
relatively
easy
to
add
them
without
forcing
all
the
upstream
people
to
go.
Okay,
now
I
need
a
new
version,
and
now
I
have
to
change
the
signature
of
some
basic
initialization
function
in
every
application
that
uses
this
and
so
we're.
E
You
know
part
of
part
of
the
vision
here
was
to
try
and
like
I
I
would
say
this
argument
actually
reduces
code
surface
rather
than
increasing
it.
A
lot
of
little
with
functions
are
easy
and
cheap
a
you
know.
Maybe
they
don't
end
up
in
a
standard,
but
but
the
idea
of
having
an
option
a
packet,
an
option
pattern
for
initialization,
I
think
is-
is
a
really
useful
way
to
think
about
it.
G
That's
we
already
use
the
functional
options,
pattern
pretty
much
everywhere
in
our
code
base,
so
we're
we're
there.
I
think
you
can
look
at
the
scope
attribute
changes
that
tyler
has
made
recently
to
see
how
that
functions.
When
we
do
have
to
expand
right,
we
just
add
some
new
option
types
and
things
carry
on.
F
H
G
I
think
we've
got
a
lot
of
that
right.
We
do.
We
don't
evangelize
it
as
much
as
we
should,
but
many
of
the
standard
environment
variables
for
configuring.
The
exporters
are
available.
What
we
don't
have
is
exporter
selection,
through
environment
variable.
We
don't
have
like
span
processor
selections
for
environment
variables,.
F
F
I
think
the
question
mainly
is
like
what
additional
environment
variables
or
options
are
we
thinking
of
introducing
with
this
and
then
asking
the
question
of
whether
we
like
them
enough
to
add
them
into
core
or
if
we
are
uncertain
enough
of
their
long-term
use,
that
we
want
them
to
be
separate
for
now.
I
think
that
seems
like
the
main
question
to
me.
E
After
what
happens
in
the
sql
space,
where
you
import
the
sql
package
in
go,
and
then
you
import
a
driver
for
a
particular
kind
of
sequel
you're
using.
So
it's
that
same
that
same
principle,
we
were
trying
to
follow.
We
want
to
make
sure
there
was
room
for
vendors
to
be
able
to
add
their
own
enhancements
without
forcing
them
down
the
throat
of
somebody
you
know
having
to
carry
that
throughout
their
entire
code
base.
C
C
I
think
the
functional
option
pattern
that
that
anthony
described
where
there's
defaults
that
pass
an
empty
list
or
you
can
generate
a
set
of
good
defaults
from
environment
variables
and
then
single
function
to
apply
all
those
defaults
and
completely
configure
an
sdk
which
has
been
something
coachell
never
talked
about.
What's
the
setup
for
an
sdk
expect
to
be
like,
we
don't
need
to
write
a
spec,
we
just
need
to
do
what
makes
sense
for
the
vendors.
C
G
And
I
don't
think
we're
far
off
from
having
a
mechanism
where
vendors
can
bring
their
own
sdk
configuration
right.
So
no
new
tracer
provider
takes
a
list
of
tracer
provider
options.
Vendors
can
come
with
a
function.
You
call
that
returns
a
list
of
tracer
provider
options
set
up
for
their
preferred
way
to
set
up
that
tracer
provider,
including
the
batchband
processor
and
exporter,
to
use
and
all
of
those
things.
A
Yeah-
and
I
think
that's
a
good
point,
I
think
what
this
is
trying
to
do
is
to
consolidate
that
to
a
single
call
and
the
option
pattern
would
still
be
like
every
place.
You
set
up
a
tracer
provider
and
then
register
it
globally.
You
would,
you
would
pass
an
option,
the
meter
provider
same
thing,
the
propagators
same
thing.
C
One
of
the
hard
problems
that
I
think
ought
to
be
solved,
though
it's
just
one
of
the
reasons
why
there's
a
lot
of
difficulty
here
is
to
avoid
unnecessary
imports
when
you
don't
want
them.
So
you
know,
I
don't
particularly
need
to
link
in
the
prometheus
exporter
if
I'm
not
going
to
use
it.
Likewise,
there
are
custom
resource
detectors.
A
A
For
for
people
who
are
like
experts,
I
think
that's
kind
of
something
we've
talked
about
previously
with
this
design
like
people
who
don't
want
their
binary
sizes
to
be
bloated
by
imports
they
aren't
going
to
use.
I
think
that
that's
something
that
we've
said
this
shouldn't
apply
to,
and
I
think
that's
kind
of
important
because,
like
I
think
I
think
the
user
that
we're
trying
to
target
with
this
is
the
person
who
just
heard
about
otel
through
some
blog
and
they're
like.
Can
I
use
that
like
how
hard
is
it
gonna
be
to
set
up?
A
And
you
know
when
they
see
that
you
need
to
like
write
50
lines
to
get
something
configured,
it's
a
barrier
that
they
may
not
be
willing
to
to
handle,
especially
like
those
50
lines.
Don't
work
for
them,
but
you
know
if
they
can
write
one
line
in
it
and
it
just
starts.
You
know
sending
traces
to
whatever
their
determined
back
end
is
or
metrics,
or
something
like
that.
I
think
they're
they're
going
to
be
a
static
right.
They
don't
care
that
it's
importing,
grbc
or
protobuf
or
prometheus,
or
anything
like
that.
A
They
just
care
that,
like
it
started
to
work,
but
to
your
point
josh,
I
think
that's
that's
important,
like
what
is
what's
the
translation
like
so
what
happens
when
you
take
that
you
know
sre
or
some
dev,
who
did
that
presented
at
their
company
and
they're
like
yeah?
Let's
adopt
this
now
and
they
go
like
okay.
Well,
how
do
I,
you
know,
hit
the
requirements
of
my
company
to
say
like
yeah,
this
binary
size
is
optimized
or
something
like
that.
I
think
that
I
think
that's.
The
key
thing
is
like
how
what's
that
translation?
C
Could
probably
come
up
with
a
like
single
package:
that's
like
the
uber
import
that
contains
every
dependency
for
that
one
liner
to
work,
but
it's
really
one
import
statement
and
one
configuration
call
right
right
exactly
and
then
maybe
there's
another
package,
which
is
the
minimum
version
where
you
have
to
use
underscore
imports
to
get
the
functionality
that
you
need.
So
like
I
underscore
import
the
base
initialization
layer.
I
call
the
standard
function
that
I
was
going
to
call
before.
C
G
Then
we
can
have
this
uber
package
that
just
does
all
of
those
imports
for
side
effects,
gets
all
of
the
things
and
makes
them
available
and
provides
you
a
function
that
says
here:
you'll
get
a
meter
provider
tracer
provider,
whatever
you
want,
that's
configured
out
of
your
environment
from
everything
you
have
the
choice
of,
and
that
also
then
provides
a
guide
for
those
those
power
users
who
want
to
pare
it
down
to
say:
okay.
Well,
how
is
this
implemented?
Oh,
I
can
do
that.
It's
really
it's
a
bunch
of
importance
in
five
lines.
G
So
how
how
about
this
as
a
way
to
move
forward,
jamie
and
kent?
Would
it
seem
reasonable
for
or
would
you
guys
be
willing
to
work
on
an
auto
exporter
and
auto
resource
detector
packages
as
next
steps
and
see?
How
would
it
look
like
to
try
to
build
a
one-line
sdk
initialization
built
on
top
of
those.
D
I
think
the
idea
makes
sense.
I
don't
know
if
I
can
say
right
now-
a
timeline
on
yes
or
not,
but
I
think
that's
something
we
can
bring
back
to
the
team
and
say
that
this
is
this
is
the
ask
for
next
steps,
for
that
is
to
have
the
auto
exporter
and
resource
detector
package?
That
was
the
two
that
you
mentioned
right.
A
G
Those
are
things
we
would
want
to
do,
regardless,
whether
we
go
with
the
the
model
of
launcher
you've
proposed
here
or
something
that
is
only
built
on
top
of
those
because
for
for
more
advanced
users,
we
want
to
give
them
that
flexibility
to
be
able
to
build
their
own
with
a
limited
set
of
things.
I
mean,
I
think,
that's
the
pattern
for
that.
E
A
Yeah,
I
think
that's
a
a
good
idea.
Overall,
I
was
a
little
like
hesitant
to
say
that
we
should
do
that
just
because
it
seems
like
this
design
is
one
step
beyond
that,
but
I
think
it's
for
an
iterator
perspective.
I
think
it
would
also
give
us
all
a
better
idea
as
to
what
that
would
actually
look
like
man.
I
have
no
idea
where
I
put
this
thing.
I
wanted
to
show
kent.
A
Yeah,
okay,
that's
right,
yeah,
not
a
problem,
but
yeah
it's
it's!
It
should
be
pretty
straightforward.
Essentially
like
this.
This
is
a
like
a
function
that
creates
you
know
something,
but
it
uses
all
these
environment
variables
and
it
does.
You
know,
based
on
this
registration
import
and
this
registry
is
essentially
like
a
global
registry
of
all
the
propagators
that
have
been
loaded
all
the
default
ones,
essentially
anything
in
the
trib
or
in
the
main
repo
over
here.
So
it
would
look
very
similar
for
the
exporter.
A
G
A
A
Yeah-
and
I
think
that's
actually
a
really
good
approach.
I
know
with
the
auto
prop
package
I'd
seen
it
done
in
like
two
or
three
places,
so
I
wrote
that
package
also
users
were
asking
about
it,
but
we
ended
up
like
splunk,
I
think
just
using
it,
because
I
had
such
similar
code
in
in
the
splunk
distro
that
I
was
just
like.
Well
I'll
just
use
this,
and
I
can.
A
I
can
see
that
being
the
case
for
most
vendors
eventually,
like
you
know,
they're
just
wrapping
auto
prop
they're,
just
wrapping
auto
export.
You
might
as
well
try
to
unify
that
rapping
right,
like
they're,
already
all
doing
the
same
thing.
So
I
think
this
is
a
great
next
step
is
to
like
just
you
know,
building
blocks.
A
Okay,
I
will
still
try
to
take
a
look
at
the
design
doc.
I
think
that
there's
been
some
great
effort
on
that,
so
I'll
still
try
to
prioritize
a
look
at
there.
Otherwise,
I'm
looking
at
the
agenda.
We
are
at
the
end
of
what's
listed
on
the
agenda,
so
I'll
just
pause
here,
see
if
there's
something
else,
somebody
wanted
to
bring
up.
A
I
guess
yeah,
I
don't
know,
there's
a
few.
I've
got
in
the
works,
but
maybe
next
week
I'll
talk
more
about
them,
but
okay,
well
cool.
I
guess
with
that.
We
can
probably
end
it
here.
I'm
super
excited
to
get
this
metrics
sdk
out.
I
know
josh
is
excited
to
get
another
release
out.
So
there's
excitement
building
is
what
I
will
say
at
this
point
in
the
in
the
developments.
It
totally.
A
C
A
A
I
didn't
want
to
jinx
it,
but
I
I
I
agree:
that'd
be
it's
ambitious,
but
I
think
we
could
do
it
yeah
well,
cool,
I'm
glad,
I'm
glad
the
excitement's,
not
just
on
my
end.
Everyone
seems
to
be
sharing
it.
So
yeah,
I'm
looking
forward
to
keeping
this
work
going
thanks.
Everyone
we
can
edit
here
I'll,
see
you
all
virtually
or
same
place
same
time
next
week,
bye.