►
From YouTube: 2021-06-02 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
C
Not
last
week
I
think
josh
was
talking
about,
he
might
get
some
snow.
I
think
last
snow
we
got
was
early
may
like
the
first
week
of
may
so.
C
B
A
B
B
One
nice
well
ted
said
he
was
gonna
show
up,
but
he's
not
here
at
the
moment.
C
Yeah,
I
think
ted
was
interested
in
this
topic,
so
would
be
nice
if
we
showed
up,
but
I
I
also
am
interested
in
in
this
and
why
the
the
existing
no-op
pass-through
propagation
isn't
sufficient,
because
I
think
it's
still
going
to
require
the
end
user
to
deal
with
instrumentation
getting
instrumentation
registered
to
handle
the
server
side
extract
and
the
client
side
inject,
and
all
of
that
so
is
the
deserialization
and
re-serialization
really
that
much
overhead
yeah.
Are
we
talking
about
the
pass-through
property,
yeah
yeah.
A
Again,
like
these
are
all
small
numbers,
but
when
you're
talking
to
a
team
that
is
not
in
your
ownership,
all
these
small
numbers
can
help.
That's
my
main
motivation.
A
So
talking
to
amazon
internal
framework
teams
like
this
is
insanely
cheap,
so
we
should
just
do
it
by
default
versus
it's
pretty
cheap.
We
should
do
my
default.
That's
the
only
difference.
I
think
yeah
and
I
mean
I
get
like
it
is
waste
I
mean
if
you're
not
using
it,
it
is
a
waste.
That's
another
way.
To
put
it
also.
So
if
you
can
just
not
waste
that
sort
of
nice,
I
think.
A
B
What
so
your
goal,
I
know,
you've
you've
put
in
the
no
op
the
more
no
op
api
implementation
into
java.
As
a
as
an
experimental
thing.
Would
you
then
combine
this
with
that
to
get
the
minimum
possible
so.
A
A
They
can
replace
that
with
this
pass-through
propagator
to
have
the
cheapest
possible
propagation
mechanism,
while
other
users
are
still
just
using
the
no
op
and
then
if
they
want
to
do
this
for
active,
then
they
would
enable
sdk,
like
those
are
the
three
sort
of
types
of
users.
I
imagine
I
mean
ideally
everyone's
propagating,
and
so
in
that
case
I
know
up
isn't
as
important
but
like
as
a
framework
author
I'd
want
the
new
up
to
be
the
default
just
so
that
then
gives
that
choice
to
the
users.
A
A
So
by
pure
no
up,
I
think
we're
we
might
be
even
more
know
up
than
that,
like
every
single
method
in
the
open
timed
api
stubbed
out
to
do
nothing
including
context,
so
there's
no
context
propagation
either,
because
on
java,
especially
context
propagation
can
have
some
overhead
because
of
red,
local
and
so
making
that
the
real
default
just
allows
for
you
to
still
be
instrumented
you're
still
calling
into
the
openclumpdk.
But
it's
implemented
with
complete
no-ops
well
by
default,
openton,
jk,
propagates
context,
at
least
in
java.
A
A
C
Yeah,
I
think
that
was
that
was
the
original
design
of
the
noaa
api
implementation
right
was
that
there
there
was
absolutely
no
operations.
That
happened.
No
context
propagation
happened,
but.
A
A
C
A
C
Very
recently
that
we
added
the
no
but
propagate
the
span
context
through
context
in
the
go
sdk,
because
we
were
previously
just
no
op
and
you
you
try
to
to
create
a
new
span
and
sure
you
got
a
new
spam
on
the
nippy
span.
Context.
There's
no
information
there
at
all.
There
was
still
some
overhead,
it
wasn't
purely
noaa,
but
it
was
no
information
propagation
at
all,
and
we
just
recently
got
to
the
point
where
we're
propagating
and
extracted
span
context
all
the
way
through,
so
that,
if
you
don't.
C
But
you
do
have
propagators,
you
can
at
least
extract
a
context,
get
it
all
the
way
down
to
a
client
and
inject
it
at
that
point
and
pass
it
through,
as
if
you
had
just
picked
up
the
headers
and
moved
them
along
yep.
I
think
that
you
will
have
a
tough
job,
pushing
the
ball
back
up
the
hill
to
get
defaults
to
to
that.
Knowing.
A
So
that's
why,
like
in
java,
I
made
a
extension-
I
mean
I
don't
know
if
it's
going
to
stay
forever
for
a
long
time.
This
is
certainly
still
prototyping,
but
like
a
different
implementation
of
the
api,
it's
called
no
op
open
telemetry
that
implements
it
with
pure
no
op
operations,
but
I
don't
expect
to
change
the
default
yeah.
B
Sound,
I
mean
just
thinking
back
from
what
you
all
just
said.
You
know
it's
ringing,
a
bell
that
maybe
maybe
the
original
intent
of
adding
context
propagation
back
in
to
the
or
adding
it
to
the
api.
The
no
op,
the
quote,
unquote.
No
up
api
was
essentially
to
fulfill
the
same
purpose
where
you
would
get
the
propagation
through
transparently,
through
allegedly,
without
having
to
do
any
processing.
But
it
feels
like
this
is
a
lighter
weight
solution
to
that
same
problem,
which
is
have
a
propagator
which
just
passes
the
headers
through
the
well.
A
One
this
propagator
doesn't
work
with
that.
True
knot
right,
this
is
meant
for
the
default
open
tone,
3pi
right.
It's
just.
B
A
And
like
baggage
is
also
in
mind,
like
we've,
been
talking
about
baggage,
a
lot
of
aws,
and
I
mean,
if
there's
a
relatively
large
baggage
and
you're
not
going
to
do
anything
anyways
like
I
don't
I
mean,
maybe
baggage
requires
validating
the
baggage,
even
if
you
don't
use
it,
but
I
don't
think
I
would
expect
that
on
all
my
services
and
if
you
just
don't
want
to
deal
with
it,
just
pass
it
through
that'll
be
much
cheaper
than
actually
running
it
through
a
propagator.
I
think
we
do
a
lot
of
logic
in
the
baggage.
Propagator.
A
B
Yeah
I
mean
so
ted's
ted's
concerned.
If
I
can,
you
can
check
me
on
this.
If
I'm
recalling
it
correctly,
his
concern
was
mostly
that
this
might
be
yet
another
thing
that
users
could
misconfigure
that
and
also
the
real
question
was:
how
would
users
configure
this
with
the
api?
B
I
think
he
was
very
hesitant
to
introduce,
for
example,
environment
variables
that
would
only
be
used
by
the
api
rather
than
the
sdk,
and
so
the
real
question
was:
how
would
one
configure
this
hey
speak
of
the
devil
speak
of
the
devil,
hey,
and
here
he
is
yes,.
B
A
call
go
long,
you'll
do
it
so
we're
talking
about
no
op
or
lighter
weight
context.
Propagation,
oh,
yes,
cool!
So
I'm
going
to
stop
trying
to
remember
and
paraphrase
what
you
said
this
morning:
ted
and
let
you
say
it
yourself
yeah.
What
did
I
want
to
check
in
about?
Well
one?
I
had
some
concerns
about
anything
that
looked
like
configuration
management
ending
up
in
the
api.
B
B
So
I
was
just
curious
as
to
why
whether
or
not
this
would
just
be
an
alternative
sdk
or
like
an
sdk
feature
or
something
like
that.
B
A
B
Like
like
invars
and
things
like
that,
where
just
because
something
other
than
just
a
no-op
implementation
and
having,
if
you
pull
in
the
api
package
anywhere,
then
you've
now
got
you've
pulled
in
something
that's
going
to
reach
around
in
your
environment
and
do
other
things
just
because
the
api
package
goes
everywhere
and
maybe
the
thing
that's
embedded
directly
into
oss
libraries
and
things
like
that.
C
B
All
of
the
the
implementations
are
baked
into
the
api
package.
Yeah,
the
pro
the
v3,
w3c
baggage
and
jager
are
all
part
basically
they're
in.
A
B
B
I
guess
my
other
question
is
why
I'm
just
curious,
why
we
need
student
shouldn't
the
the
trace
contacts
and
b3
propagators
like
if
you
just
install
that
oh
right,
this
was
to
avoid
serialization
deserialization.
That
was
the
answer.
It's
that
question
really.
A
And
the
main
reason
is
when
you
have
services
that
are
reluctant
to
take
part
in
the
trace,
maybe
because
of
overhead
reasons,
and
so,
if
you
show
them
this
even
less
overhead
thing,
then
at
least
they'll
propagate.
If
they
don't
even
do
that,
then
your
trace
is
screwed
and
so
totally
that's
the
motivation.
B
Yeah,
I
think
I
guess
I'm
like
slightly
concerned
that
the
api
is
is
growing
environment
variables,
maybe
just
independently
of
this.
This
thing,
I
don't
think
I
don't
think
the
the
support
for
environment
configuration
is
part
of
the
api.
The
api
needs
to
support
arbitrary
propagators,
but
not
configurations.
C
A
B
And
java,
we
don't
even
have
it
in
the
sdk.
We
just
have
it
in
an
extension,
as
you
configure
the
configuration
extension
for
the
sdk
yeah,
okay,
yeah
yeah.
This
makes
makes
perfect
sense
for
me.
Would
this
be
like
a
blanket?
I'm
just
I'm
just
curious
how
you
configure
this
thing
since
there's
a
variety
of
different.
B
B
I
want
to
it's
almost
like,
like,
like
he's
not
on
the
call,
but
I
actually
want
to
blame
j
macd
for
for
that,
one
him
or
yuri
or
their
combine.
That
was
one
of
the
things
when,
like
I
showed
up
in
open
tracing
and
like
saw
those
lying
around
in
the
example
code-
and
I
was
like
this
is
terrible.
This
is
gonna
bite
you
guys
in
the
butt
so
much
down
the
line.
B
The
real
bummer
is
that
they're
now,
a
part
of
the
propagator
spec
in
open
telemetry,
like
the
fact
that
we
have
those
that
fields,
method
at
all
is
specifically
for
jaeger
to
be
able
to
handle,
handle
the
crazy,
crazy,
yeah
yeah.
It
actually
makes.
C
B
B
Like
the
pure,
the
pure,
no
op
implementation,
I
mean
they're,
they
don't
work
together,
which
makes
them
a
little
awkward
that
fellows,
but
tell
me
I
don't
know
if
you
were
here,
we
were
talking.
Also
onorag
has
a
experimental
package
for
java.
That
is
a
pure,
no
op
api.
B
B
C
B
I
mean
I
say
I
say
yes
because
my
I
think
the
api
includes
an
sdk.
It
just
includes
this
very
lightweight
sdk,
and
so
this
would
be
an
even
lighter
weight,
sdk
that
you
could
optionally
use
or,
though
or
a
slightly
heavier
weight.
I
don't
know,
I
guess
the
propagator
is
slightly
different
concern
yeah.
B
Maybe
they
don't
belong
together,
but
they
seem
very,
like
they're
related
to
the
same
idea
like
you
said
of
let's
get
people
to
be
more
accepting
of
instrumentation,
and
then
you
know
this
is
the
gateway
drug
like
we'll
give
them
the
given
the
first
one
for
free
and
then
hey.
You
know
if
you
just
set
the
bring
in
this
other
library
and
turn
this
environment
variable.
Look
you
get
tracing,
I
don't
know
or
something
like
that.
C
Yeah,
I
think
they're
kind
of
related
because
it
seems
like
the
default
api's
implementation
of
say,
like
a
tracer,
is
going
to
do
work
when
you
create
a
new
span
right
by
copying
that
content
the
span
context
that
wouldn't
be
there
if
you're
using
this
very
lightweight
header
forwarding
propagators,
you
would
instead
want
to
just
do
nothing
but
have
the
context
propagation
exist
so
that
when
you
get
to
a
point
where
you're
trying
to
inject
out
of
the
context,
you've
still
got
those
headers
available
yeah.
What
which
in
in
go
is
very
easy
right.
C
B
The
no
op
thing
is
going
to
be
generating
allocations
all
over
the
place
right
and
it's
possible
to
have
something
even
lighter
weight
than
that
that
generated
no,
it's
just
handing
you
back
the
same
thing
everywhere
or
something
that's
exactly
right.
That's
exactly
what
the
prototype
does.
Yeah.
C
B
You
know
you
pull
it
off
and
in
the
middle
you're
not
doing
doing
anything
other
than
forwarding
that
one
thing
along
but
you're
saying
because
it
becomes
a
memory
object.
Well,
there's
that
and
if
you
do
any
thread
hops,
you
have
to
then
move
that
context
around
the
in
and
out
of
the
thread
locals,
etc.
Well,
yeah
I
mean,
but
that
happens
anyways
right
like
with
any
of
these
things.
B
C
To
have
that
at
a
very
minimum
I
mean
I
just
looked
at
the
go
implementation
and
the
non-recording
span
just
adds
a
span
context
to
the
no
op
span.
So
if
you
try
to
set
attributes
on
it
still
no
longer,
you
may
still
allocate
those
attributes
if
you're
not
checking,
is
recording,
but
if
you've
got
instrumentation.
That
really
cares
about
performance.
That
much
you
should
be
checking
is
recording
on
your
spam
before
you
create
attributes,
anyways.
A
Like
the
way,
I
say
it
is
that
it's
to
decouple
the
decision
of
instrumenting
with
the
users
like
a
framework,
can
add
open
terms,
recalls
into
their
code
and
yeah.
But
no
one
pays
a
cost
because
it's
true
not
like
even
the
context
doesn't
propagate
and
then
once
a
user
wants
to
propagate
context,
then
they
can
activate
it,
but
that's
a
decision
that
the
user
makes
not
the
framework.
So
that's
the
point
of
the
no
app
it's
to
allow
frameworks
to
instrument
for
free,
basically,.
B
B
C
Yeah,
I
think
I
wouldn't
even
go
as
far
as
specifying
this.
I
would
just
say
that
this
is
a
a
custom
super
simple,
absolutely
no
op,
sdk
implementation,
it's
the
sdk
implementation,
you
use,
if
you
really
don't
want
tracing
or
contact
replication
or
any
of
this
at
all,
it's
just
another
implementation
of
the
api.
I
wonder.
B
B
B
A
The
same
some,
I
imagine
this
no
up
link
to
like
it's
the
default
value
of
a
final
field
inside
of
builders,
not
a
final
in
the
field
inside
a
builder
and
then
the
other
things
get
activated
like.
I
don't
know
if
people
would
explicitly
opt
into
this
thing
versus
it
being
the
default
provided
by
some
framework,
that's
sort
of
what
I
have
in
mind:
yeah
anyways,.
B
Yeah,
I'm
just
trying
to
imagine
if
it's
the
kind
of
thing
where
someone
could
literally
write
their
like
config
standard,
config
stuff,
like
configuring,
the
sdk
and
go
and
then
have
an
environment
variable
allow
a
service
to
like
turn
all
that
stuff
off.
I
don't
know
I
don't
know.
I
don't
know
if
that's
like
over
complicate
things
and.
B
That
the
sdk
is
configured
now,
whether
you're
doing
it
programmatically
or
re-environment
variables.
You
couldn't
do
it
without
the
sdk.
Like
I
mean
the
sdk
has
some
base
stuff
that
it
needs
to
operate,
that
you
have
to
figure
out
how
to
get
rid
of
in
that
case,
so
it
might
make
more
sense
to
do
it
only
via
environment
variables.
B
I
don't
know,
I'm
not
sure
yeah.
I
just
I'm
trying
to
think
of
whether
this
could
be
bundled
up
with
a
regular
sdk.
I
mean
it
seems,
like
you've
got
these
builders
that
spit
out
providers
and
things
of
the
option
and,
like
you
know,
at
the
end,
and
you
could
have
options
in
there
where
it
just
says.
You
want
me
to
spit
out
the
no
alok
provider.
Okay
here
here,
you
go
I'll
spit
that
one
out
for
you,
so
I
I
think
that
would
for
people
who
are
like.
B
I
don't
want
this
thing
to
do
anything.
They
should
just
install
the
no
eloque
one,
which
is
what
I'm
calling
it
from
that
one.
But
I
can
imagine
this
like
weird
middle
world,
where,
in
a
universe
where
all
of
this
stuff
is
bundled
up
in
some
centralized
place
in
an
organization.
B
Where,
if
someone
had
a
service
that
they
wanted
to
not
allocate
anything
and
just
be
a
for,
whatever
reason
they
could
still
have
a
place,
they
could
turn
it
all
off
without
having
to
like
gut
some
central
part
of
like
all
the
crap
that
they
they
get
as
part
of
being
a
standard
service
in
their
world.
That's
kind
of
a
weird
edge
case,
but.
C
B
Lets
the
operator
do
it
if
the
operator
is
like
this,
this
service
is
like
freaking
out
because
it's
running
all
this
like
tracing
stuff,
that
has
like
pushed
its
overhead
like
over
the
line.
You
know
over
some
threshold
and
if
they
just
google
around
like
oh,
I
just
set
this
environment
variable
and
that
overhead
goes
away
great
done.
I
don't
have
to
bother
a
developer
or
somebody
to
get
myself
out
of
some
situation
so
yeah.
I
could
see
that
being
useful
for
the
sdk
to
pull
in,
but
you
know
one
one
thing
at
a
time.
B
Nice
yeah,
I,
like
these
low
overhead
ones,
c,
plus
plus,
has
been
slow
to
get
going,
but
I
am
hopeful
at
some
point
for
people
to
have
cycles
to
try
their
hand
at
like
a
foreign
function.
B
Sdk
for
languages
like
python,
I
don't
like
go
thinks
sees
the
devil,
but
I
do
know
people
have
have
done
this
even
and
go
and
see
seen
a
performance
boost,
but
I'm
thinking
more
for,
like
the
pythons
and
the
the
rubies
of
the
world,
where
that's
like
a
normal
thing,
maybe
even
the
nodes
of
the
world.
B
You
would
build
it
and
no
one
would
use
it,
so
it's
irrelevant
whether
it's
helpful
or
not,
because
no
just
no
one
would
install
it.
The
same
way
like
go
plug-ins
are
like
theoretically
useful,
but
in
practice
it
doesn't
matter
because
no
one's
gonna
touch.
It.
B
B
Also,
like
php
is,
I
predict,
in
the
future,
going
to
really
benefit
from
being
able
to
switch
over
to
a
c
plus
plus
base
thing,
just
because
it's
not
not
just
for
performance
but
there's
just
a
whole
bunch
of
stuff
that
you
could
access
through
c
plus
plus,
so
that
a
lot
of
a
lot
of
fun
stuff
is
going
to
show
up.
B
Once
we
get
past
this
baseline
of
like
1.08
little
language,
sdks
yeah,
I
know
the
new
relic
php
php
agent
was
really
just
a
c
plus
sidecar
that
ran
alongside
it,
that
you
sent
data
to
yeah
yeah
you
you
want
to
integrate
with
fsm
and
all
whatever
the
kids
are
doing
in
the
php
these
days
and
a
performance
related
topic
ted.
But
you
might
be
somewhat
interested
in
this.
B
So
a
lot
of
these
options
that
we're
talking
about
here
are
things
that
we're
hoping
to
use
like
nikita
is
hoping
to
use
to
try
to
figure
out
like
what
the
actual
overhead
of
the
instrumentation
is
versus
the
overhead
of
the
sdk,
to
figure
out
where
performance
optimizations
can
be
made
yeah.
But
yes,
the
api
ain't
free,
and
especially,
if
you
use
it,
it
becomes
a
lot
less
free.
So
when
you
write
instrumentation,
it
has
cost
yep
yeah.
B
B
C
And
that's
my
understanding
of
what
I
think
jana
would
expect
as
well
and
she's
talked
about
pee
prof
as
a
signal
that
should
be
shipped
which,
from
from
the
gold
perspective,
that's
you
know,
you
use
the
existing
profiling
packages
and
it
exports
pprofs,
so
that
it's
just
a
thing
we
we
can
wire
up.
I
don't
know
how
it
would
work
in
other
languages,
whether
the
the
sdk
would
then
provide
some
translation
from
some
native
profiling
implementation
to
prof
or
if
that
would
be
handled
in
the
collector.
B
Yeah,
I'm
imagining
it
would
be
like
something
it
would
have
to
be.
You
know
the
same
kind
of
framework
separation
that
we
have
so
that,
if
you're
on
linux,
it
could
be
evpf
under
the
hood
doing
its
thing
and
then
producing
pprof
plus
I
mean
there's
also
like
the
stuff
flowmill
does
with
evpf
around.
Like
you
know,
network
monitoring
and
and
all
of
that
jazz
yeah
we've
got
some.
We've
got
some
flowmetal
experts
at
splunk
yeah.
B
B
Well
for
one
you
can't
it
has
to
be
baked
into
like
your
network
proxy
or
into
your
application,
runtime
and
you're
still
going
to
have
some
trickiness
around
like
tracing
being
this
level,
seven
thing
with
headers
and
stuff,
and
we
have
to
expand
our
conventions
today.
Even
without
that,
I
I
we
field
questions
on
a
regular
basis
from
people
who
are
like
trying
to
add
their
tcp
handshakes
and
stuff
onto
and
they're
like.
How
do
I?
B
B
B
Yeah
for
profiling,
yeah
yeah,
yeah
yeah.
No,
I'm
I'm
excited
to
see
profiling
get
added.
I
am
super
intrigued
to
see
like
kernel,
tracing
and
distributed
tracing,
get
like
linked
to
each
other
like
that
would
just
be
handy,
but
there's
like
trickiness
with
with
all
of
that
crap
the
last
time
left
there
was.
Actually
there
was
a
I'm
forgetting
his
name.
There's
a
graduate
student
from
france
who
did
his
like
research
paper
on
exactly
this
like
linking
either
evpf
or
dtrace,
or
something
like
that
to
distributed
tracing
and
was
like.
B
There
are
pitfalls.
Basically
like
timing
information,
for
example,
like
doesn't
it's
like
pretty
difficult
to
to
associate
those
two
things
so
figuring
out
where
we
staple
them
together,
so
that
the
timing
is
accurate
enough
that
it
would
actually
be
useful?
C
Yeah,
I
think
they
said
that
you've
got
it
within
the
application.
Runtime
like
people
at
least
in
go.
I
would
imagine
we
just
add
the
trace
id
there's
a
the
goprof
library
also
has
the
concept
of
spans
or
regions.
I
think
it
calls
them
and
we
had.
I
think
we
ended
up
getting
it
because
it
wasn't
necessary
for
stability,
but
we
had
a
span
processor
that
could
register
itself
as
a
region
handler
for
peeproff
so
that
you
could
add
events
to
spans
when
prof
started
and
stopped
a
region.
B
Here,
you
have
data
correlated
together
that
you
never
had
correlated
before
and
that
that's
gonna
be
hot,
so
hot,
really
exciting,
2022
gonna
be
a
great
year.
B
Probably
logs
is
like
a
funny
beast,
I
mean
they're
the
log
meeting
over
la.
I
have
like
a
conflict,
so
I
can't
generally
go
to
that
thing,
but
I
feel
like
to
a
certain
degree.
We
need
to
just
be
like
advocating
the
existence
for
what's
already
there
does
anyone
here
know
like
the
state
of
the
stanza
integration
and
the
collector
really
should
fight.
C
I
haven't
seen
anything
stanza
related
in
the
collector,
although
I've
been
focused
mostly
on
prometheus
stuff,
so
it
certainly
could
have
slipped
past
me.
B
I
believe
that
was
the
part
they
were
most
focused
on,
I
know,
is
getting
the
collector
turned
into
a
log
processor,
efficient
log
processor,
to
replace
so
that
people
could
stop
running
like
blue
bit
and
other
things
like
right
next
door
to
the
collector,
and
then
the
next
step
was
like
log
appenders
for
all
the
things
which
is
just
like
you
can
do
this
today,
but
it's
not
like
a
centralized
thing
you
just
have
to
like
people
have
to
just
go
out
there
and
write
log
appenders
that
either
start
taking
your
trace,
ids
and
stapling
it
onto
your
logs,
so
that
your
logs
can
go
off
wherever
they're
going
before,
but
now
have
better
indexing
and
then
log
appenders
that
can
take
your
logs
and
turn
them
into
trace
events,
so
that
you
can
funnel
all
that
information
into
your
tracing
system
and
like
there's
a
huge
amount
of
value
just
in
in
that,
and
those
things
are
like
simple
to
write,
but
there's
they're
they're
like
decentralized
right,
you
just
you
end
up
with
like
a
big
pile
of
them.
B
Trying
to
think
I
would
say,
ninth
robots
there,
you
go
it's
a
really
nice
way
to
put
it
yeah,
I'm
just
trying
to
figure
out
like
like.
I
would
like
to
write
a
logging
otlp
exporter
and
a
log
processor
for
the
java
sdk
yeah,
but
it's
really
like
the
the
logging
model
is
so
flexible
and
so
open-ended,
and
so
just
like
anything
goes,
it's
really
hard
for
me
to
know
how
to
build
an
api.
That's
going
to
be
useful
to
people
yeah.
B
I
I
feel
like
the
step.
They
were
looking
for
next
tigran's
kind
of
writing
hurt
on
this,
but
as
like
not
even
writing
an
api
next,
but
just
getting
an
sdk
like
a
processor
in
place
that
can
then
work
with
the
existing
logging
apis,
like
the
the
presumption.
Is
everyone
already
instrumented
their
stuff
with
some
kind
of
logging,
and
we
want
to
like
focus
on
getting
that
into
otlp
before
we
go.
Writing
yeah?
No!
No!
B
I
agree,
but
if
I
so,
if
I
were
going
to
be
writing
a
log
appender
for
log4j,
for
example,
that
that
would
then
talk
to
some
sort
of
open,
telemetry
log.
Sync,
like
the
data
model
for
that
log
sync
like
that
we're
going
to
have
to
expose
in
order
to
basically
get
everybody
like
the
least
common
denominator,
we're
going
to
expose
the
log
model
on
that
log.
B
Sync,
which
means
that
people
will
have
to
know
what
to
do
with
the
fact
that
the
body
is
defined
in
that
logging
can
be
literally
anything,
including
an
arbitrarily
large
map
of
data
like
how
do
I
build
a
log
sync
api?
That's
going
to
be
for
someone
who
isn't
like
intimately
in
this
project
every
day,
they're
going
to
be
make
any
sense
on
what
they're
actually
supposed
to
do
with
the
log.
The
simple
log
record
that
is
basically
a
string
plus
an
mdc
like
what
are
they
supposed
to
do
like
that's?
B
What
I'm
trying
to
even
it's,
not
even
like
a
user
level
api,
but
if
I'm
trying
to
teach
people
how
to
write
appenders,
it's
going
to
be
complicated.
It's
semantic
conventions
right!
It's
just.
How
do
we
map
map
data
onto
this
thing
from
existing
data
sources
like
yeah,
and
how
do
we
provide
an
api
that
makes
it
easy
for
people
to
do
that?
Who
aren't
us.
B
B
Is
an
api,
it's
not
an
instrumentation
api,
but
there's
still
an
api
that
people
are
going
to
have
to
write
to
and-
and
I
it's
unclear
to
me
how
to
make
that
usable
for
log
appender
authors
with
the
current
state
of
the
data
model.
So
anyway,
I
just
started
thinking
about
it.
So
there's
probably
a
solution,
but
so
far
it's
when
I
look
at
it,
I'm
like
holy
moly.
What
am
I
going
to
do
with
this
craziness
there's
a
lot
of
lot
there?
Is
it
part
of
it?
B
That's
that's
like
the
dumbest
api
that
could
possibly
work,
but
I
think,
but
as
soon
as
you
implement
as
soon
as
you
expose
that
people
are
going
to
be
like
what
am
I
supposed
to
do
with
this
dumb
thing,
where
I
can
put
any
literally
any
data
structure
in
the
world
into
it
like?
What
do
I
do
with
it?
B
How
do
I
take
the
things
that
I
care
about
and
put
it
in
the
right
place
so
that
I
know
everyone
else
is
putting
it
in
the
right
place,
so
that
back
ends
will
be
able
to
process
it
all
the
same
way
and
make
sense
of
it.
So
anyway,
I
just
think
of
right
now,
since
the
body,
if
the
body
were
a
string,
I
think
it'd
be
very
obvious,
but
since
the
body
is
essentially
can
be
anything,
it
becomes
a
lot
harder
to
design
an
api.
That's
simple
for
people
to
use.
B
B
B
A
B
B
I
kind
of
suspect
the
answer
is
the,
but
you
put
a
string,
you
message
string
in
the
body
and
then
you
put
your
structured
data
in
the
attributes
and
just
ignore
the
fact
that
you
could
put
a
bunch
of
other
weird
crap
in
there.
That's
like
unless
you're
like
actually
in
some
weird
situation,
where
you're
like
damn,
I
just
my
body,
isn't
a
string.
I'm
then
you're
like
oh
thank
god
they
they.
C
It's
been
a
while,
since
I've
looked
at
the
at
the
log
data
model,
but
it
is
my
recollection,
I
think,
was
that
there
was
a
set
of
attributes
like
at
the
top
level
that
were
log
record
oriented
like
time
stamp
and
and
the
like,
and
and
then
everything
else
that
would
be
user
provided
would
go
into
that
body
as
attributes
within
the
body.
So,
instead
of
just
saying
body
is
no.
No,
because
there's
also
attributes
there's
a
there's.
No
there's.
B
C
Would
say
just
you
know,
make
it
a
map
of
attributes
and
have
a
convention
for
log
dot.
Message
is
where
your
your
message
goes,
your
string,
valued
message,
but
yeah,
I
guess
tell
everybody
to
treat
us
as
a
string
and
put
all
the
attributes
and
attributes.
I.
B
Mean
probably
what
I
would
what
I'll
do
when
I,
when
we
get
to
this,
is
having
an
api
that
the
the
the
happy
path
is
you're,
writing
a
string
and
then
maybe
have
some
other
more
complicated
side
thing
where
you
can
say
well,
if
you
really
need
to
go
and
do
this,
then
you
can,
you
know,
add
this
crazy
stuff
to
your
body,
but
make
the
make
the
easy
obvious
happy
path.
Just
be
straight.
A
C
B
B
C
B
We
need
to
be
prepared
for
it
rather
than
trying
to
tell
people
they
can't
do
it
yeah
I
was.
I
would
I
completely
agree
whether
we
say
or
not
like
if
I
were
making
a
tracing
backhand,
I
would
just
presume
some
jackass
is
gonna.
Just
do
this,
that
my
system
shouldn't
like
explode,
if
that
shows
up
it's
a
little
bit
different
than
like.
Oh,
I
should
do
something
intelligent
with
this,
because
this
is
actually
a
feature,
not
a
bug.
I
guess
that's
a
little
different,
but
systems
that
literally
blow
up
like
yeah.
B
A
B
A
B
Are
you
I'm
wondering,
have
you
seen
any
examples
of
server
spans
needing
to
be
layered
on
top
of
each
other?
I
think
the
main
the
more
the
issue
is
not
that
they
need
to.
The
issue
would
be
like
in
the
java
world
that
your
neti,
your
low
level
like
nete
api,
might
create
a
server
spam
when
it
comes
in,
and
then
you
have
your
higher
level
rat
pack
api
that
also
that
instrumentation
is
independent
and
might
also
want
to
consider
the
thing
coming
in
as
a
server
span.
Yeah
though,
yes,.
C
There's
at
least
one
http
framework
instrumentation
that
has
middleware
that's
implemented
in
terms
of
the
raw
net
http
instrumentation,
which
creates
its
own
span.
I
think
that
the
framework
instrumentation
just
delegates
to
the
net
http
one,
so
it
doesn't
end
up
creating
two
spans
or
extracting
the
context
twice,
but
I
could
certainly
see
that
sort
of
thing
happen.
A
Yeah
yeah
I
mean,
and
that's
actually
mr
klein's
spins
aren't
as
big
of
a
deal.
It's
actually
the
students
of
wristbands
that
can
be
more
problematic
because,
usually
that
boring
transport
span
is
going
to
be
on
the
outside
and
that's
what
most
back-ends
will
sort
of
present
at
the
top
level,
the
tracer
in
the
service
map
or
whatever,
even
though
you
wanted
to
present
the
grpc,
so
that's
probably
where
actually
beckons
will
have
like
no,
no
they're
not
going
to
blow
up
they're
just
going
to
look
much
worse.
B
C
B
People
are
going
to
do
stuff
yeah.
I
think
what
we
need
to
do,
and
ted
and
ted
brought
this
up
earlier,
and
I
think
it's.
The
right
answer
is
that
the
specification
describes
like
what
I
wrote
like
it's
basically
like
this
stuff
is,
can
happen,
but
we
should
write
semantic
conventions
that
explain
what
you
should
do
and
what
how
the
things
should
be
structured,
but
we
all
need
to
be
aware
of
the
fact
that
people
are
going
to
do
instrumentation
on
their
own
and
they're
going
to
do
it
differently.
B
B
A
B
B
I
I
consider
that
the
pr
as
just
kind
of
the
start
of
a
discussion
that
is,
has
basically
not
happened
because
we've
had
this
weird
language
that
says
no,
it's
going
to
always
work
perfectly
in
this
magic
world
and
you'll
never
have
to
worry
about
it.
But
of
course
you
really
have
to
worry
about
it
a
lot.
B
So
my
hope
is
that
this
will
actually
then
enable
those
discussions
to
go
forward
so
that
we
do
worry
about
the
right
things
and
not
just
kind
of
sweep
them
under
the
rug
or
like
right
now,
everyone's
just
implementing
their
own
strategy,
like,
I
think
ruby,
I've
been
told
ruby.
Does
it
differently
than
java
does
like
it
chooses
the
the
other,
the
other
option
in
some
particular
case,
so
we
should
at
least
start.
You
know
codifying
how
well
how
instrumentation
should
be
written
in
these
cases
rather
than
leaving
it
up
to
everyone.
B
A
I'm
hoping
this
week
to
finally
have
some
time
to
write
a
note
up
also
for
the
instrumentation
api.
It's
been
on
my
mind
for
a
long
time.
But,
finally,
since
we
got
that
one
issue
about
adding
those
hooks-
and
I
didn't
mention
our
instrumentation
and
it
seems
like
there's
interest
anyways,
so
it's
probably
a
good
time
to
finally
write
something
up
about
that.
B
Try
to
let
this
be
yeah
you're
dear
to
ted's
heart.
I
think
yes,
yes,
we
really
need
attention
on
instrumentation,
but
yeah.
It's
it's
really
just
been
gated
on
people
having
having
time
to
focus
on
it.