►
From YouTube: 2021-08-24 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
You
are,
it
is
not
my
favorite
name,
I
would
say
other
things,
but
we
are
being
recorded.
I
think
the
name
is
he
needs
work
but
yeah.
That's
the
new
gig.
B
I
think
so
literally
because
they
do
industrial
refrigeration
control
systems,
so
literally
cool
if
they're
doing
their
job
right.
B
But
yeah
it's
neat
it's
kind
of
like
a
under
under
under
invested
in
area
that,
like
they
like
they
do
like
energy,
optimization
and
like
cloud
control
of
hardware
and
stuff
like
that,
and
it's
there's
basically
been
no
like
the
computer
revolution
passed
these
places
by
in
a
lot
of
ways.
So
there's
a
lot
of
like
really
interesting
sort
of
stuff
to
do
there,
trying
to
like
wire
that
up
for
modern,
modern
anything
really.
B
B
It's
it's
definitely
like
in
the
same
realm
like
the
the
stuff
that
we're
doing,
I
think,
has
a
lot
of
overlap
with
with
iot
stuff
for
sure
it's
cool,
I
like
it.
It's
it's
an
interesting,
interesting
area,
not
really
a
ruby
shop.
Unfortunately,
so
it's
gonna
be
maybe
maybe
I'll
change
that
eventually,
but.
C
I
think
we
do
have
the
the
usual
crew
around
so
maybe
start
in
with
the
usual
agenda
run
through
the
spec
sig
run
through
the
ruby
sig.
Hopefully
has
some
good
discussions
along
the
way
feel
free
to
yeah
feel
free
to
speak
up
or
help
pull
me
back
on
track.
If
I
get
too
far
off,
let
me
get
a
screen
share.
C
C
So
there's
this
discussion
about
like
what
to
do
about
it
and
I
think
the
the
two
avenues
of
discussion
were
like
well,
maybe
we
can
accommodate
these
kind
of
things
with
spaces
or
things
starting
with
numbers,
but
ultimately
they're
kind
of
like
these
are
supposed
to
be
semantic
conventions,
and
I
think
the
problem
is
that
the
ones
that
were
merged
were
not
very
conventional.
C
So,
like
updating,
build
tools
to
be
able
to
accommodate
this
thing
seemed
like
not
a
great
option
and
I
think
they
just
wanted
to
kind
of
release
a
at
least
a
patch
fix
and
kind
of
just
allow
people
to
skip
this
one,
if
it's
being,
if
it's
a
problem
for
them,.
C
But
I
believe
we're
generating
our
semantic
inventions.
We.
B
C
B
Released
a
1.6.0
but
oh
well,
I
don't
think
anyone's
actually
really
using
it.
So
you
know,
I
think
the
any
possible
file
fallout
here
is
like
super
limited.
C
So
this
issue
here
I
feel
like
it,
just
keeps
coming
up
and
I
kind
of
keep
saying
the
same
thing
every
time
around
and
I
started
this
conversation
and
I
don't.
It
really
turned
into
a
can
of
worms
and
I
felt
like
I
was
being
like
not
the
most.
C
I
don't
know
like
I
felt
like.
I
was
just
slightly
being
a
thorn
in
the
side
of
these
proposals,
but
ultimately
like
the
the
goal
is
to
have
these
to
be
able
to
configure
your
otlp
exporter,
protocol
by
environment
variable
and
I'm
just
kind
of
mentioning
from
like
ruby
and
javascript,
and
I
guess
go.
C
I
guess
we
don't
have
multiple
packages
yet
so
like
when
I
bring
up
ruby,
it's
kind
of
like
a
weird
example
but
javascript
and
go
definitely
have
this
set
up,
and
I
believe
we
will
have
the
same
setup
when
we
have
multiple
protocols
supported.
But
it's
really
on
a
per
package
basis.
It's
kind
of
like
the
package
that
determines
the
protocols
there's
like
a
separate
package
for
otop
json,
separate
package
for
otlp
grpc,
and
yet
a
third
package
for
otlp
proto
over
http
and
generally.
C
The
reason
to
put
these
at
separate
packages
is
to
kind
of
limit
package
size
limit
dependencies
that
you
want
to
pull
in.
I
know
like
a
lot
of
the
people
who
prefer
json
for
all
of
its
problems,
like
I
think
they
like
kind
of
the
footprint
they
don't
want
to
pull
in,
like
a
protobuf
dependency
or
a
grpc
dependency,
for
example.
C
So
I
was
just
kind
of
like
raising
a
concern
that
there's
like
this
huge
kind
of
like
coupling,
I
would
say,
between
these
environment
variables
and
like
your
gem
file
or
your
package
json
or
your
godot
mod
whatever,
and
that
kind
of
was,
I
don't
know
rubbing
me
the
wrong
way
to
some
degree,
and
I
guess
the
conversation
did
kind
of
spin
over
to
like
well
what,
if
you
wanted
to
ship
mini
exporters,
could
you
do
that
in
these
languages
and
I'm
like?
Well,
you
could
include
all
three
packages
if
you
wanted
to.
C
It
seems
like
a
very
unusual
use
case,
not
not
a
useless
use
case,
but
not
probably
like
the
common
one,
and
if
you
did
do
that,
these
would
work
like.
I
think,
that's
true,
but
I
don't
know
it
just
led
to
like
this
huge
can
of
worm
discussion
where.
C
I'm
not
really
sure
what
the
exact
outcome
is
other
than
people
wanting
to
think
a
lot
more
about
how
how
we're
handling
configuration
in
general
and
just
kind
of
the
explosion
of
environment
variables,
but
yeah,
I
don't
know
like.
C
I
guess
I
guess
I
would
like
to
get
the
sig's
opinion
on
it,
because
I
was
at
least
brought
up
ruby.
As
an
example.
Do
these
things
seem
like
useful
environment
variables?
If
we
have
these
things,
if
we
end
up
having
support
for
multiple
protocols
in
separate
packages,
or
is
there
kind
of
just
a
better
way
to
do
this?
I
kind
of
like.
E
If
I'm
not,
am
I
mistaken
that
there
is
a
coupling
between
the
protocol
and
the
endpoints?
Also
in
some
cases
where,
like
the
the
trace's
endpoint,
for
example,
has
to
be
include
a
version
url
for
http,
where
the
grpc1
doesn't
so,
I
kind
of
feel
like
you
can
easily
mess
the
configurations
up
and
just
get
you
like
confused
to
get
things
going.
It's
almost
as
if,
like
I'm
not
sure,
I
understand,
I
guess
in
some
cases,
kind
of
like
the
mime
type
is
included
in
the
media.
E
C
Yeah
I
I
was
just
I
think
my
reservation
was
you
can
kind
of
like
configure
things
that
you
can
try
to
configure
things
using.
You
can
look
at
these
environment
variables
back
and
you
can
try
to
configure
something
expecting
it's
going
to
work,
not
realizing.
There's
like
this
coupling
with
your
gem
file
actually
and
like
this
configuration
file.
This
configuration
option
only
works.
If
you
have.
You
know
this
in
your
gem
file
and
I
don't
think
there's
like
it's
like
that's
like,
maybe
not
a
great
pattern.
C
I
think
that
that
scenario
will
exist
to
some
degree,
but
I
would
much
rather
kind
of
have
like
the
configuration
be
like
on
like
a
per
exporter
basis
and
like
if
the
exporter
is
here,
then
it
follows
it.
But
if
kind
of,
if
that
package
is
there,
then
it
follows
the
configuration
for
some
reason.
The
package
isn't
there
and
you
set
up
this
configuration
it's
just
kind
of
like
ignored
and.
E
Right
so
so
is
it
more
similar
to
like
the
jager
specific
configurations
with
the
air
specific
environment
variables,
and
then
we
would
have
like
otp
exporter,
http,
otlp
hdp,
whatever
potentially,
and
it's
like
here's
some
sp
configs
for
that.
C
I
feel
like
that's
how
it
would
work
a
little
bit
better
and
then
because
I
think
the
other
thing
yeah.
C
I
think
you
there
would
be
a
world
where
you
might
want
to
use
like
otop
and
jaeger,
like
I
don't
think,
there's
a
world
where
you
would
really
want
to
use
like
otop,
json
and
otlp
grpc,
like
from
the
same
process
like.
I
just
don't
see
that
as
like
a
use
case
at
all.
So.
F
That
would
be
a
product
of
like
distinguished
export
like
if
you're
sending
to
it.
If
you're
sending
otlp
somewhere
you'll
probably
only
need
one
protocol,
an
exporter
going
to
a
vendor.
That
supports
a
particular
thing.
You
got
to
configure
that
exporter
to
use
whatever
protocol
it
uses,
but
when
it
comes
to
otlp
we've
been
seeing
somebody
pick
one
and
go
with
it.
F
The
ability
to
pick
one
is
a
thing
that,
if
a
if
a
language
sdk
supports
more
than
one
of
these
protocols,
you
got
to
be
able
to
like
distinguish
between
them,
and
there
are
cases
where
people
want
http
like
straight
up:
http,
not
hp2
grpc,
because
they're
going
through
enterprise
proxies
and
they
don't
support
grpc.
Yet.
F
So,
like
I'd,
say,
sdks
need
to.
We
need
some
way
to
be
able
in
an
sdk
that
supports
multiple
protocols,
pick
which
one
you
want
the
exporter
to
use,
but
I
I
haven't
seen
cases
of
people
wanting
a
single
instance
of
an
sdk
running
with
multiple
otlp
export
protocols
selected.
It's
usually
when
in
operation
only
once
running
was
that
the
is
that
what
you
meant
by
the
we
only
see
one
chosen
for
a
particular
process.
A
It
gets
interesting
it.
It
really
gets
interesting
if
you
have
metrics
as
well
explored
over
otlp,
which
we
don't
support.
Yet
maybe
we
don't
have
elementary
school
in
sdk,
but
the
the
way
the
spec
evolved.
A
It
assumes
that
you
have
separate
exporters
for
metrics
and
for
traces
rather
than
having
a
kind
of
common
package
that
is
running.
You
know
a
single
background
thread
and
doing
the
things
so
there
you
actually
need
to
configure
them
independently
and
potentially
you
could
have
one
exporting
json,
maybe
and
the
other
one
doing
grpc.
You
could.
A
Am
I
mistaken
thinking
that
there's
actually
two
json
variants
for
otlp,
one
that
is
protobuf,
sorry
json,
encoded,
protodolf
and
one
that
is
some
actual
explicitly
specified,
json
thing
or
the
second
one
of
those
disappear.
C
I
think
there
is
only
one
json
one
otp
json,
but
it's
not
actually
stable
and
for
a
lot
of
its
life
it
was
kind
of
the
jsonified
protobuf,
but
I
think
last
summer.
Actually
it
was
the
the
id
format
was
changed.
So
I
think.
C
Those
were
yeah,
they
were
changing
the
json
to
be
kind
of
the
hex
encoded
id,
whereas
if
you
get
the
json5
profoto,
I
forget
exactly
how
those
encode,
but
they
encode
us
like
bytes,
there's
they're
slightly.
What
is
it
a
different
format
that
you
could
convert
into
the
hex
id?
So
that's
kind
of
the
only
deviation
from
the
jsonified
proto
at
this
point,
but
there's
been
a
huge
reluctance
to
kind
of
mark
it
at
stable,
which
I
understand
because
as
soon
as
you
do,
that
you're
kind
of
stuck
with
it.
A
Yeah,
I
think
maybe
ejs
was
the
only
one
that
actually
implemented
it.
F
I
think
certainly
browser
instrumentation,
like
client-side
stuff
is
where
that
is
most
desired,
but
also
hard
to
stabilize
yeah.
C
Yeah,
I
think,
there's
an
issue
on
the
proto-repo.
I
think.
C
So
yeah
this
has
been
discussed
as
discussed.
I
I
keep
bringing
it
up
because
people
from.
C
People
using
javascript
from
the
browser
really
want
this
and
the
last
activity
on
this.
C
Anyhow,
I
guess
bringing
this
back
to
kind
of
the
issue
at
hand
like.
I
do
concede
that
if
you
have
like
multiple
exporters
in
in
process,
these
environment
variables
are
kind
of
useful
but
but
yeah.
It
does
seem
weird
to
me
that,
like
these
are
like
really
tightly
coupled
with
your
gem
file,
and
they
may
not
make
sense
for
a
lot
of
gem
files-
and
I
think
that
ultimately
is-
are
they.
A
So
the
coupling
is
there
because
we've
chosen
to
well
right
now:
we've
only
chosen
implement
one
thing
which
is
protocol
over
http.
Our
plan
is
that
the
grpc
exporter
is
going
to
be
a
separate
gen,
and
that's
so
that
you
can
avoid
taking
a
dependency
on
grbc.
A
A
F
F
Okay,
I'll,
if
we
put
do,
we
have
the
hooks
in
sdk
dot,
configure
to
check
for
this
value
and
then
do
you
have
the
right
gems
that,
like
we
could
we
could
throw
a
mis
configuration
if
you've
got
something
specified
here,
but
a
gem
that
doesn't
implement
it.
A
Yeah,
my
recollection
is,
we
do
so
we
were,
and
I
think
we
were
anticipating
something
like
this.
It's
just
the
irritation
is
that
you
have
to
change
two
things
right.
You
need
to
change
your
gen
file
to
pull
in
a
different
exporter,
and
then
you
also
need
to
change
this
environment
variable
or.
F
A
I
missed
that.
It's
not
added
it
was
there
previously.
I
guess
so
it's
basically,
there
is
a
default.
It's
not
actually
part
of
the
spec.
What
the
default
is
the
default
is
whatever,
so
we
would
pick
one.
I
guess
the
question
is,
which
one
do
we
pick
if
you
haven't,
have
a
gen
file
or
like?
If
you
happen
to
pull
in
all
three
gems,
which
one
do
you
get.
G
G
I
was
actually
just
raising
my
hand
to
support
before,
but
yeah
we're
in
paper
dropping
it
like.
I
know
I've
kind
of
owned
it
in
the
past,
but
even
recently,
like
we
pinned
it
to
an
earlier
version
that
we
knew
didn't
have
issues
and
when
someone
was
trying
to
build
that
they
were
actually
blocked
from
using
our
later
libraries,
because
they,
I
think
they
yanked
the
safe
version
so
like
it,
really
put
us
in
a
bad
spot
where
we
had
to
even
unpin
it
and
do
some
additional
work
to
like
anyways.
F
Well,
I
I'm
as
a
person
as
a
vendor
who
has
to
who
has
had
to
deal
with
helping
customers
of
hotel
a
variety
of
hotel,
sdks
and
collectors.
F
Configure
things
being
able
to
get
specific
is
handy
that
there's
some
flexibility
where,
as
the
ruby
sdk
maintainers,
we
can
decide
if
you've
got
all
three
pres,
all
three
exporter,
gems
present
the
ruby
default
is
whatever,
and
if
and
if
you
and
we
document,
if
you
don't
like
that
default,
you
can
override
it
or
don't
include
those
other
gems
got
options.
G
G
Yeah,
that's
the
one
I've
been
kind
of
complaining
about,
but
just
yeah,
so
everyone's
aware
that
it
is
fine
right
now.
So
it's
it
has
been
a
cause
of
issues
but
like
in
its
current
state.
We
have
a
lot
of
applications
using
it
without
any
issues.
So
I
think
that's
really
fair
that
I
point
that
out.
A
So,
just
jumping
back
to
this
issue
for
a
second
one
problem
is
that
most
of
the
configuration
options
for
the
otlt
exporter
are
interpreted
by
the
exporter
itself.
A
This
option
would
need
to
be
interpreted
by
the
configurator.
Instead,
it's
pretty
obvious
way
to
do
that,
but
it
does
mean
like
it's
easy
for
an
environment
variable
for
handling
environment
variables,
but
if
somebody
actually
wanted
to
pass
it
in
explicitly
they,
there
is
no
direct
sort
of
representation
of
this
protocol
selector.
Instead,
you
would
have
to
pick
the
exporter
that
you
wanted
and
pass
that
exporter
in,
which
is
just
a
little
bit
different
right.
A
So
not
a
big
deal,
but
it
it's
going
to
require
some
documentation.
The
the
other
thing
this
brings
up
is
that
otlp
is
the
one
export
format
right
now
that
where
the
spec
actually
supports
multiple
things
right,
so
it's
logs,
metrics
and
traces
right
now,
we've
called
our
package.
A
Just
you
know,
gld
exporter,
and
we
just
have
this
class
exporter
there,
where
it's
not
abundantly
clear
that
this
is
a
trace
exporter,
so
once
we
actually
implement
metrics,
we
may
need
to
rework
that
package
a
little
bit
and
at
that
point
we
would
also
want
to
rework
the
way
we
configure
things.
F
Would
you
would
you
picture
multiple
exporters
of
those
three
types
or
just
a
refactoring,
of
the
existing
otlp
exporter
to
support
the
three
types
I
don't
know
yet.
A
Okay,
yeah
sorry
yeah
yeah.
Probably
I
think
it's
a
good
question.
It
depends
on
the
apis.
I
don't
know
if
the
interface
for
metrics
exporters
also
looks
like
export
and
then
you
know
metric
data,
because
if
it
does,
then
we've
got
that
problem
of
distinguishing
distinguishing
between
metric
data
and
span
data.
A
C
C
We
yeah,
we
would
be
able
to
support
whatever
comes
out
of
this,
but
I
I
think
there
was
this
kind
of
recognition.
I
guess
that
the
deuce
there
does
seem
to
be
like
two
worlds
and
I
feel
like
this
is
coming
from.
Perhaps
the
java
world,
which
I
think
is
also
very
similar
to
kind
of
the
collector
world
where,
like
it,
is
common
to
have
all
three
of
these
exporters
like
available,
it's
not
like
an
explicit
dependency.
C
You
have
to
pull
in
so
this
environment
variable,
I
think,
just
makes
a
lot
of
sense
there
and,
as
you,
I
think,
ruby
javascript
and
go
are
all
the
same
boat
where
it's
kind
of
like
whatever
exporter
you
pull
in
kind
of
determines
the
protocol.
C
But
then
there
is
kind
of
this
other
use
case
where
maybe
you
have
some
kitchen
sink
distro
that
just
bundles
everything,
and
then
this
kind
of
makes
sense
again.
C
But
my
gut
feeling
is
that,
like
most
users
are
not
going
to
be
event
in
that
area,
maybe
maybe
some
vendors
could
be
if
you
wanted
to
like
have
a
distro
that
was
gave
your
customers
all
of
the
option
or
something
I
guess
this
holds
true
for
observability
teams
as
well,
but
it
just
seems
it
seems
a
little
bit
less
likely
of
a
use
case,
but
I'm
just
I'm
just
kind
of
guessing
on
that
too,
which
is
kind
of
my
my
gut
feeling
on
on
the
matter.
C
Let
us
move
on
and
yeah
I'll
keep
everyone
up
today
on
where
this
goes.
I
didn't
get
the
impression
that
people
thought
that
there
there
must
be
a
better
way
and
we
do
need
to
kind
of
obtain
configuration
a
little
bit,
so
I
think
people
were
going
to
mull
on
this
a
little
bit
more
before,
jumping
or
yeah
before
moving
forward
with
this
exact
proposal.
C
So
much
like
the
smart
commuting
that
conversation
actually
took
up
like
a
ton
of
time.
It
seems
complicated
and
a
lot
of
people
have
different
opinions,
and
I
think
people
are
just
kind
of
used
to
slightly
different,
like
ecosystems,.
C
C
Yeah
and
these
nebulous
comments
kind
of
point
towards
the
outcome
I
was
just
trying
to
describe
there
metrics
update.
There
is
an
exemplar
spec
and
it
needs
more
eyes
on
it.
That
was
pretty
much
the
extent
of
what
was,
except
for
that
there
is
a
pull
exporter
and
multi-exporter
spec.
C
Sampling
update
there
is
a
propagation
tap.
I
think
we
keep
pulling
these
things
off
each
time,
but
they
are
getting
some
approvals.
C
They
are
also
pretty
detailed,
but
but
yeah
the
two
things
that
that
we
need
to
propagate
are
in
some
way
the
trace
sampling
probability,
and
there
are
various
representations
of
that
that
have
been
on
the
table.
I
think
the
thing
that
they're
talking
about
is
an
adjusted
count.
C
And
I
think
possibly
I
am
like
yeah.
I
think
they
are
very
interested
in
these
they're,
very
interested
in
these
power
of
two
inverse
power
of
two
sampling
rates,
and
it's
because
it's
a
very
compact
way
to
represent
a
a
sampling
probability,
and
I
believe
that
there
was
a
proposal
to
to
add
this
to
the
w3c,
transparent
header
at
one
point
in
time,
but
because
things
move
slow
in
sanders
world
and
because
you
have
to
kind
of
get
buy-in
from
the
group.
C
And
josh
mcdonald
who
opened
this,
he
did
kind
of
come
to
this
last
w3c
meeting
to
discuss
a
future
where
this
could
be
in
in
trace
parent
and
people.
Listen
they're
thinking,
so
so
there
might
be
a
future
where
this
could.
F
C
Like
an
additional,
an
additional
either
two
or
four
characters
on
on
the
trace
parent
there's
a
couple
of
ways
to
to
either
minimize
or
represent
some
of
the
data
in
the
transparent
header.
But.
C
I
think
it
probably
deserves
a
full
read
and
then
the
other
half
of
this
is
how
to
actually
put
this
on
the
span.
So,
and
this
is
where
the
span
will
get
a.
C
And
I
believe
the
adjusted
count
it's
it's
derived
off
of
the
sampling
probability,
but
I
think
the
the
way
this
is
supposed
to
be
represented
and
correct
me
if
anybody
knows
that
I'm
wrong,
but
I
think
this
is
like
you
just
kind
of
run.
The
numbers
such
that
this
span
is
equal
to
10.
so
like.
If
you
had
like
a
a
one
in
ten
probability,
then
the
adjusted
count
is
just
ten.
So
you
just
know
that
you
can
multiply
this
event
by
the
adjusted
count
and
get
kind
of
the
total.
D
A
I
feel
like
a
lot
of
people
are
waiting
for
this
to
land.
This
is
gonna,
be
useful
and
interesting.
You
know
there's
a
couple
of
vendors.
A
You
know
one
one
prominent
vendor
who
may
be
represented
on
this
call,
who
has
something
pretty
similar
to
this
functionality
very
similar
to
this
and
it'll
be
good
to
have
it
like,
formerly
specked
and
implemented
everywhere,
because
it's
a
it's
a
useful
feature,
particularly
at
scale.
We
have
a
lot
of
services
where
we,
the
traffic,
is
the
traffic
volume
is
low
enough
that
we
want
to
just
sample
everything.
A
We
want
to
trace
everything,
but
then
we
have
a
few
like
a
really
small
handful
of
services
that
have
an
insane
volume
and
like
we
want
to
heavily
head
sample
those,
but
then
trying
to
derive
things
like
snows.
Sorry,
slis
from
those
traces
is
pretty
hard.
If
you
don't
know
what
the
original
sample
rate
was,
especially
if
you
have
a
service,
that's
traced
at
100,
making
a
request
to
a
service
that
is
traced
to
two
percent
and-
and
you
want
some
indication
of
what
the
original
sample
rate
was.
A
So
you
can
say
that,
yes,
this
request
represents,
you
know
50
similar
requests,
whereas
this
other
one
over
here
represents
one.
C
Yeah,
I
think
I
think
a
lot
of
people
are
in
agreement
that
they
would
love
to
see
this
thing
land
so
yeah.
I
know
I
keep
trying
to.
B
C
Optimistic
that
this
stuff
looks
like
it's
going
well
and
it
should
land
soon.
C
I
think
we
should
land
soon.
I'm
gonna
continue
the
optimism
like
I.
I
don't
see
that
there's
like
a
lot
of
like
pushback
or
or
issues.
I
think
it's
just
yeah,
getting
all
the
approvals
dotting
the
eyes
crossing
the
tees.
C
Yeah,
I
haven't
been
going
to
the
sig,
but
there
was
this
note
that
they
decided
to
cut
support
for
tail
sampling
from
the
proposals.
So
maybe
that
was
one
of
the
things
that
is
slowing
things
up
just
trying
to
kind
of
settle
too
much
at
once.
C
Yeah,
it
has
to
do
with
the
logs
data
model
and
it's
proposing
adding
a
a
receipt
timestamp.
So
there's
kind
of
a
time
stamp
for
like
when
the
event
happened,
but
there's
not
a
time
stamp
for
when
the
event
was
actually
received.
C
Think
the
conversation
was
unresolved.
I
think
there
was
a
lot
of
questions
about
why
this
additional
timestamp
was
needed.
I
think
some
of
the
answers
that
was
it
is
like
a
fairly
standard
piece
of
data
in
in
other
systems.
So
for
that
reason
we
may
want
to
consider
it,
but
I
think
I
think
there
are
some
actual
use
cases
that
are
trying
to
be
solved
here.
C
I
don't
know
if
we
have
any
opinions
on
this,
because
we're
kind
of
I
don't
really
know
the
maturity
of
like
logging
implementations
across
hotel.
But
I
don't
hear
about
them
all
that
much.
D
I
work
at
a
logging
company,
I
guess-
and
a
metrics
and
traces,
but
yeah
we've
seen
a
bunch
of
people
not
about.
I
don't
know
a
handful
of
people
ask
whether
they
could
ship
the
slogs
with
like
italox.
I
think
people
are
starting
to
use
it
in
whatever
I
don't
even
know
where
it's
implemented
the
stanza
stuff.
Apparently
they
had
done
the
vlogs.
D
Some
of
my
coworkers,
who
work
more
closely
on
the
log
stuff,
had
done
sort
of
like
a
brief
check,
the
box
list
of
the
stanza
stuff
that
was
donated
and
found
it
to
be
pretty
good.
I
think
it
was
stanza
donated
their
agent,
I'm
blanking
on
the
company
that
donated
the
logging
agent,
but
I
think
it
was
pretty
fully
featured,
so
I
think
it's
coming
along
and
tigran
from
the
collector.
D
I
think
works
close
to
full
time
on
the
log
stuff
at
this
point
so
yeah
it
should,
I
hopefully
not
to
mention
it
again,
yeah
yeah.
So
anyway,
that's
my
only
an
anecdotal
evidence
to
add
here.
E
So
are
they
so
because
of
the
stanza
donation?
Stanza
is
a
competing
product
with
fluent
and
does
not
use
the
phone
photo
protocol.
All
right.
D
Yeah
yeah
yeah,
it's
not
the
they
have
a
receiver
for
fluent.
You
know
a
bit
or
fluency,
but
yeah.
I
think
it's
oto
like
otlp,
is
a
separate
protocol
from
that
for
sure.
E
E
D
D
Yeah,
I
think
so
I
don't
think
they
ever
started
it
I
apologize
for
interrupting.
I
bet
that's
all:
okay
yeah.
I
think
I
think
I
understand
it
just
now.
Yeah
I
don't
know
if
they
ever,
maybe
others
have
more
context
ever
really
gave
a
more
than
like
a
college.
Try
at
integrating
the
fluent
stuff.
It
was
more
just
like
here's,
a
cncf
log,
shipper
and
we'll,
and
here
it's
fine
and
it
works
fine
and
moving
on
and
like
so
but
yeah.
It
seems
like
they're,
certainly
like
the
repo
structure's
a
little
weird.
D
It's
the
way
it's
and
I
think
everything's
still
like
labeled,
pretty
heavily
experimental,
but
it
seems
like
there's
real
production
users
out
there
in
at
least
one
or
two
languages,
and
that
is
where
they're
yeah
at
this
point.
If
the
tigran's
the
maintainer
the
collector,
so
he
appears
to
be
spending
most
of
his
days
on
their
log
stuff,
so
they
certainly
are.
If
they're
you
know
putting
the
one
of
the
maintainers
on
it,
then
I
would
assume
it's
a
pretty
fully.
You
know
fledged
approach.
Yeah.
A
Splunk,
of
course,
has
an
interesting
involvement
and
he
is
like
the
collector
has
a
lot
of
support
for
for
logs.
My
understanding
is:
there's
no
api
for
logs.
It's
instead
intended
just
to
be
an
sdk
component
that
can
plug
in,
but
ultimately
the
collector.
A
B
A
A
E
D
Yeah
that
sounds
I
felt
like
there
was
slightly
more
yeah.
That
sounds
about
right,
but
part
of
the
donation
was
like
many
of
these
mappings
were
done
close
to
you
know
we're
done,
and
maybe
they
need
to
be
all
trued
up
or
like
whatever,
but
there's
there's
a
lot
of
prior
art.
I
know
I
they're
not
starting
from
scratch
with
a
lot
of
the,
but
I
don't
think
it's
also
like
yeah.
I
think
it's
a
big
project.
F
F
I
think
it
is
one
of
his
one
of
the
alternatives
is
just
stored
on
an
optional
attribute
like
I
don't.
I
don't
know
that
everybody
has
this
problem
or
I
guess
how
does
this
and
is
this
even
a
spec?
Is
this
maybe
a
thing
that
we
that
we
would
go,
teach
the
collector
to
like
this
because
he
mentions
the
file
log
receiver,
specifically,
which
is
a
collector
component
right.
F
D
C
Well,
yeah,
unless
we
have
any
more
discussion
here,
we
are
kind
of
getting
down
to
the
final
final
eight
minutes,
so
I
did
want
to
save
a
little
bit
of
time
for
for
our
repo,
I'm
gonna
see
if
we
have
anything
worth
discussing
here.
If
there's
any
final
comments
on
that,
I
have
to
talk
about
those
as
well.
E
Nothing,
our
users
are
like
constantly
asking
me
for
documentation,
so
I
copy
and
pasted
the
golang
getting
started
guide
and
I
threw
it
into
a
web
pr
and
I
started
getting
comments
on
it
and
I'm
like
I'm
still.
E
This
is
the
largely
copy
paste,
I'm
just
like
copying
and
pasting
like
code
samples
in
there
too,
but
I
will
I'm
gonna
try
to
flesh
this
out
as
soon
as
I
can,
because
again
my
users
are
asking
me
for
it,
the
other
bit
I'm
working
on
it.
I
I'm
trying
to
get
the
code
ql
configuration
right.
It
looks
like
I
have
it
right,
it's
just
that
it
doesn't
get
enabled
until
it
gets
merged
based
on
the
configuration
of
our
have
configured
the
actions
on
that
pr.
E
So
I'm
gonna
try
to
get
that
short
up,
so
we
can
get
it
emerging,
working
and
stuff
like
that
and
yeah.
The
code
is
perfect
because
we've
got
no
errors
right
then.
This
is
like
all
kind
of
like
administrative
stuff
right
working
on
getting
rc3
rolled
out
to
github.com.
E
Hopefully
I
can
get
that
out,
but
until
we
can
give
you
all
some
information
on
like
our
canary
clusters
and
whatnot,
see
how
it's
looking
I
mean
it
is
still
humming
along
doing
an
awesome
doing
more
than
what
I
expected
still
like.
E
You
know
something
like
88
million
spans
a
minute.
It's
incredible.
This
sdk
is
amazing.
I
got
no
complaints
so
far
and
I
have
any
other
vrs
on
there
that
I
wanted
like
jibber-jabber
about.
I
don't
think
so.
E
G
Just
to
because
you
said,
you're
getting
started
rolling
out,
the
rc3
we
have
that
partially
rolled
out
like
apps,
are
starting
to
pick
it
up
now.
So
hopefully
it
gives
you
a
little
bit
of
confidence.
Nobody's
been
ran
into
anything
scary.
Yet,
just
like
little
things
here
and
there
that
pr
open,
I
am
committed
to
looking
at
that
today
and
barring
anything
weird,
I'm
probably
just
gonna
bring
it
in.
It
looks
great
in
terms
of
code.
I
just
want
to
make
sure
that
the
patch
flies
correctly.
G
I
did
this
is
like
I
don't
know.
If
I
did
pay
in
carlos,
he
said
he's
going
to
take
a
look
over
the
repo
again.
I
just
got
that
message
today
and
then
I
also
this
is
like
not
related
to
anything
to
particularly
the
code.
I
went
to
the
instrumentation
sig
last
week.
It
was
like
the
first
unofficial
one.
It
was
still
partially
the
spectate
for
a
different
time
zone.
G
I'm
scared.
I
came
off
as
maybe
a
little
hostile.
I
basically
said
more
proposals.
I
was
like
because
they
asked
how
I
felt
about
the
the
proposal
that
was
shared
a
while
back
by
anarag,
like
what
did
you
think
I
was
like?
I
don't
want
to
write
java
code
in
ruby.
G
I
was
like
that's
what
it
feels
like
a
lot
and
I
think,
like
my
girlfriend,
can
hear
me
through
the
walls
when
I
talk
and
she's
like,
were
you
mad
at
someone?
So
that
was
alarming,
but
it
seemed
to
be
well
received
because,
like
the
follow-up
comments,
look
good,
but
then
I
think
there's
gonna
be
some
expectation
that
we
come
up
with
our
own
kind
of
like
proof,
concept
of
like
what
we
think
it
should
look
like.
I
know
some
of
the
interpretive
languages
are
doing.
G
The
same
ted
is
working
on
the
go
one.
I
think.
Obviously
the
java
one
exists
so
we're
probably
gonna
try
to
compare
notes.
I
do
I
am
committed
to
going
to
this
meeting
and
I'm
gonna.
I
think
today
is
the
first
official
one.
If
anyone
else
is
interested,
I'm
gonna
try
to
take
notes
and
bring
that
back,
but
it
is
like
dinnertime,
which
sucks
other
than
that.
That's
all
I
had
to.
C
G
Yeah,
I
think
that
there's
a
lot
of
really
good
things
that
can
potentially
come
out
of
there
that
are
incredibly
relevant
to
the
things
we
talk
about
regularly
around,
like
configuration
stuff
like
that
and
what
it's
looking
like
and
you
know,
there's
some
concerns
that
configuration
is
starting
to
get
unrealily
and
some
of
the
implementations
or
like
it
might
get
unwieldy.
But,
like
everybody
that
had
something
to
say,
is
like
it's
already
gonna
start.
G
You
know,
there's
already
a
lot
of
ad
hoc
options
so
and
then
just
like
a
lot
of
things
like
that,
yeah
I'll
come
back
with
better
notes
next
time,
but
it
was.
It
was
good.
It
was
interesting.
So
if
anyone
is
interested,
I
think
that
this
will
be
just
as
interesting
as
the
stuff
that
goes
on
here,
but
a
little
bit
more
abstracted
away
from
ruby
so
very
curious.
C
I
did
notice
we
have
this
pr
around
as
well
looks
like
francis
is
already.
A
You
have
anything
this
last
bit
here.
Actually
it's
more
below
this,
but
it's
basically,
he
was
using
the
the
default
propagator,
so
he
is
recording
tags
as
column
separated,
key
value
pairs
in
an
array
and
which
is
fine.
I
mean
that's
how
okay
needs
the
needs
attacks
presented,
so
I
pointed
him
at
providing
a
custom
setter
which
makes
this
way
easier.
A
It
turns
out,
though,
that
the
custom
getter
is
awful
and
is
just
adding
unnecessary
abstraction
and
that
that
also
simply
hides
the
fact
that
you're
still
allocating
a
hash
and
parsing
the
data.
So
I
think
using
a
getter
is
not
useful
here,
but
it
also
highlights
that
the
structure
of
the
api
is
not
well
suited
for
this
use
case.
Anything
where
you
need
to
actually
pause
data,
as
opposed
to
just
like
having
a
hash
of
key
value
pairs.
A
It's
just
not
great.
Now
I
don't
know
if
I'm
just
missing
a
an
obvious
way
to
improve
this,
but
I
don't
think
so.
I
think
it's
just
a
really
inconvenient
api
because
ultimately,
propagators
just
call
get
and
they
pass
in
the
carrier
and
if
carrier
happens,
to
be
an
array
of
things,
then
you
need
to
either
iterate
through
it
or
your
getter
needs
to
cache
the
way
this
is,
but
if
you're
caching,
then
your
getter
is
not
stateless
anymore
and
you
need
to
make
sure
you
use
a
new
getter
every
time.
A
B
C
Okay,
so
yeah
it
sounds
like
this
is
pointing
at.
I
feel,
like
the
getter
has
not
gotten
a
lot
of
a
lot
of
exercise
in
the
real
world.
I
do
think
we
are
using
it
as
a
way
to
abstract
between,
like
a
carrier
with
like
rack
based
keys
or
like
non-rack
based
keys,
and
it
seemed
to
work
all
right
for
that.
I
don't
know,
maybe
it's
crappier
than
I
remember,
but
I
I
I
feel
like
that
was
working.
C
A
Yeah
I
mean
it,
it's
not
working
great,
but
this
is
respect
right.
This
is
the
way
it's
spec,
so
maybe
the
answer
is
that
you
need
to
define
a
propagator
for
this
instead
of
having
a
actually,
I
don't
know.
A
Yeah,
maybe
I
need
to
revisit
the
propagation
api
and
see
if
there's
a
cleaner
solution
than
using
the
getter
or
having
to
hack
it,
to
convert
to
a
hash.
First
yeah
he's
converting
to
the
hash,
because
it's
more
efficient
to
just
pass
the
data
once,
but
it
would
be
nicer
if
you
could
actually
pause
the
data
and
extract
the
stuff
that
you
needed
all
in
one
go
and
not
have
to
store
this
intermediate
hash,
but
that
would
require
some
changes.
C
Yeah,
I'm
always
interested
in
these
real
world
use
cases
that
show
that
an
implementation
is
not
ideal,
because
I
feel,
like
they
kind
of
help
us
us
drive
towards
a
better
one.
So
if
there
is
something
that
we
can
do,
if
there's
something
that
we
can
do
and
maybe
if
it
even
kind
of
dances
on
the
edge
of
being
spec
compliant
with
something
that
we
could
help,
you
know
improve
the
spec
on.
I
think
I
think
this
would
be
interesting.
C
I
don't
have
any
amazing
ideas
off
the
top
of
my
head,
but
if
anybody
does
or
if
I
kind
of
look
through
this
and
have
any
ideas
I'll,
I
will
bring
them
up
but
yeah
like
I.
I
always
feel
bad
when
our
apis
are
not
like
holding
up
to
something
and
always
hope
to
be
able
to
improve
that
and
don't
want
to
always
just
have
to
kind
of
like
raise
up
our
hands
and
be
like
that's
not
spec
compliant.
A
C
Cover
sounds
like
no
all
right,
it's
good
seeing
everybody,
and
we
will
see
you
all
next
week
around
online.