►
From YouTube: 2021-08-05 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
Yeah
so
there's
the
smoke
really
high
aloft
from
the
fires
to
the
south,
so
our
aqi
is
actually
really
good
here
at
the
moment,
but
there
is
smoke
high
up
in
the
high
up
in
the
atmosphere.
A
All
right,
yeah,
it's
a
little
very
reminding
remembering
of
the
smoky
days
from
last
year.
C
A
This
one
we
were
talking
about
this
on
in
tuesday's
meeting
lori
and
we're
wondering
if
you
or
oh
nikita,
wasn't
there
this
week
right
also
remember
so.
We
know
nettie
instrumentation,
our
client
instrumentation
can't
correlate
correctly
if
http
pipelining
is
used,
because
we
can't
link
the
request
and
response
correctly
and
so
the
line
for
others
that
our
our
long-term
desire
is
to
not
enable
neti
instrumentation
by
default,
but
that
will
require
instrumenting,
potentially
more
http,
clients
that
use
directly
that
use
neti
under
the
hood.
A
D
A
Yeah,
I
think
it
came
up
in
the
context
of
rat
pack
instrumentation
also
so
on
that,
if
we
were
to
remove
the
neti
server
instrumentation
by
default,
we
would
need
to
capture
server
spans
in
like
rap
pack
and
play
some
others
that
use
that
rely
on
neti.
Currently
that
rely
on
the
neti
server
instrumentation.
D
A
A
Still
waiting
to
see
if
matej
and
nikita
show
up
for
a
couple
topics,
does
anybody
have
topics
they
want?
Oh,
we
add
it
down,
got
it
john.
B
Yeah,
so
in
my
android
work,
I'm
trying
to
figure
out
how
to
do
context
propagation
into
ok,
http,
async
calls
and
trying
to
figure
out
how
to
how
to
make
that
work.
So
I've
been
trying
pouring
through
http
apis.
It
looks
like
they
have
a
dispatcher
api
that
you
can
override
that
allows
a
custom
executor
service.
So
maybe
there's
a
way
to
do
that.
Like
just
have
the
context
propagation
at
the
executive
service
level.
Do
we
have
library
instrumentation
for
executive
services
there's
something
somewhere,
but
I
can't
remember
where
it
is.
A
Not
for
executor
service
but
there's.
E
B
E
B
Doesn't
well
you
can't
it
doesn't
context
like
if
I'm
doing
manual,
I'm
writing
all
manual
instrumentation
right,
so
I
need
to
get
the
context
from
the
main
thread
propagated
into
the
async.
Whatever
the
executor,
that's
dispatching
the
actual
http
calls
oh
and
the
library
instrumentation.
Doesn't
it
doesn't
handle
any
of
that
kind
of
thing?
B
Maybe
it
should
maybe
it
should
provide
a
dispatcher
that
will
do
that.
That
might
be
a
handy
bit
and
as
a
in
addition
to
the
interceptor,
but
that
is
one
thing
that
it
doesn't
do
out
of
the
box
at
the
moment.
B
A
Yeah,
you
might
also
look
at
the
rat
pack,
library
instrumentation.
A
A
A
Okay,
does
this
it's
something
like
this?
I
think
he
hooked
into
the
rat
pack
threading
mechanism
to
propagate
context.
A
See
we've
got
materiash,
so,
let's
cut
sorry.
I
was
a
bit
late,
no
worries,
let's
chat
about.
F
A
F
F
F
F
In
my
case,
I'm
also
writing
some
with
programmatic
instrumentation
in
azure
sdk
libraries
and
it
like
duplicates
with
the
auto
instrumentation.
F
F
Again,
let's
leave
aside
questions
whether
we
should
just
have
one
or
multiple
of
them,
but
let's
agree
it
could
be
interesting
and
the
configuration
is
not
really
part
of
this
idea.
But
then
two
http
layers
are
have
no
interest
to
customers
most
likely
because
they
probably
are
the
same
and
then
underneath.
Maybe
there
is
some
extra
layer,
like
maybe
dns
or
whatever,
and
it's
different,
it's
not
http,
so
it's
also
could
be
interesting
to
customers.
F
Okay,
so
far,
so
good.
Okay.
So
then
I've
sent
a
pr
and
thank
you
all
for
your
comments
and
suggestions.
It
makes
it
makes
out
of
sense.
So
what
they
came
up
with
is
basically
the
instrumentation
type
thing
that
knows
that
owns
a
strategy,
how
to
suppress
different
spans,
so
trust
if
you
open
it.
F
Yeah
so
basically,
currently
it's
limited
to
a
few
types
that
we
know
that
we
have
semantic
conventions
for
nothing,
stops
us
from
adding
more
and
nothing
stops
us
from
allowing
instrumenters
to
declare
their
own
types.
But
I
I
don't
have
this
functionality
now.
So
basically,
we
have
http
database
messaging.
Car
pc
generic
is
the
one
that
we
never
suppress.
This
is
like
internal
spends
or,
like
let's
say
it's,
a
mixed
type
of
instrumentation.
We
don't
know
what
is
it
probably
it's
very
custom,
so
we
are
not
going
to
suppress
it
and
none.
F
It's
actually
a
current
behavior,
it's
suppressing
all
of
client
spends
and
if
we
look
into
internal
span,
spender
line,
17
and
server
or
consumer
span
line
18
the
first
one
we
never
suppress
the
server
spend
with
suppress
all
the
servers
spend.
If
they
are
nested,
we
can
have
a
separate
thing
for
consumer,
but
well
that's
easy
to
change
so
and
then
the
instrumenter
class.
Now
it
just
okay,
so
the
one
another
interesting
piece
here
so
that
instead
of
clients,
pen
servers,
pen
and
consumer
span,
I
created
this
ugly
suppressing
spawn
wrapper.
F
It
can't
store
span
in
the
context
under
the
key,
which
is
either
server
or
consumer
or
the
client.
This
certain
type.
F
So
this
is
the
mechanics.
I
have
some
open
questions
that
I'm
not
sure
about.
Do
you
folks
any
have
have
any
questions
before
I
get.
A
F
Cool,
thank
you
yeah.
So
the
open
questions
are
the
first
one
is
basically,
how
do
we
configure
this
instrumentation
type,
so
I
have
currently
two
different
ways.
First,
one
is
explicit:
any
instrumenter
can
say
optionally
if
they
want
to
instrument
provide
instrumentation
type
or
if
users
enable
this
through
system
property,
then
instrumentor
builder
attempts
to
figure
it
out
based
on
the
extractor,
the
attribute
extractor
type.
F
So
I
think
I
would
like
to
have
just
one
way
and
avoid
the
magic
here,
because
it's
a
bit
too
magical.
So
is
there
it's
fully
magical
or
it's
not
magical
at
all,
but
currently
it's
both
so
and
I'm
looking
for
suggestions.
What
would
we
prefer
here,
but
then
I
want
every
instrumenter
to
set
instrumentation
type,
because
if
somebody,
some
of
them
do
and
some
of
them
don't
it
will
be.
F
F
G
Kind
of
so
one
more
question:
what
what
about
the
system
property,
then
I
mean
you
mentioned
configuring
between
all
the
new
behavior
with
some
sort
of
property
or
configuration.
G
So
I
initially
thought
that
you
would
just
have
like
two
modes
of
operation
like
the
first
one
is
all
clients
are
the
same,
so
the
current
behavior
and
the
new
one
is
is
with
the
those
types
or
labels
that
you
have
different,
essentially
different
types
for
db,
clients
actually
declines,
and
so
on.
So
it
wasn't.
This
behavior
chosen
by
the
system,
property.
F
Yeah
so
by
default
like
if,
if
instrumenter
does
not
obtain
they
are,
they
currently
follow.
Sorry,
they
follow
current
behavior,
it
suppress
all
nested
client
spends.
Then,
if
users
decide
to
opt
in
into
the
future,
then
we
are
trying
to
figure
out
instrumenter
type
based
on
the
extractors
attribute.
Extractors
then
use
instrumenter
can
opt
in
and
then
regardless
of
user
choice.
They
will
oh
this.
This
is
a
problem.
I
guess
so.
F
If
if
this
is,
if
this
is
disabled,
then
with
instrumentor
obtained
and
we
should
still
preserve
the
current
behavior,
but
I
will
fix
it.
It's
a
good.
A
A
A
It
I
like
the
detection
from
the
attribute
extractors
since
people
have
to
add
these
anyway,
and
it
seems
like
that
they're,
if
they're
using
http
app
http
attribute
extractors,
it's
an
easy
way
for
us
to
know
that
it's
http.
A
F
A
F
Oh,
I
see
interesting,
I
I'll
I'll
look
for
it,
that's
a
good
feedback
and
it
sounds
reasonable
to
start
this
magical
way
and
just
one
instrument,
one
extractor,
and
if
we
will
feel
a
need
for
us
explicit
configuration,
we
can
always
add
it
later.
It
doesn't
seem
like
it.
It
could
be
a
breaking.
A
Change
cool.
Did
you
have
any
other
open
questions.
F
Yeah,
I
have
a
big
one,
so
I've
been
trying
to
make
it
work
across
the
repo
and
pass
test
and
what
I
found
that.
F
G
F
G
F
F
F
B
F
A
Cool
yeah
I'll
ping
justin
to
wrap
up
the
last
couple
comments
and
we
will
get
that
merged.
A
I'm
fine
with
not
yeah,
yes,
totally
agree.
F
Okay,
so
I'll
check.
If
this
is
this
spam,
pr
solves
all
my
issues
and
I'll
see
if
I
can
keep
tracers
away
from
this
change.
A
A
G
I
have
one,
let's
say:
open
concern:
we've
been
wanting
to
do
to
bridge
the
server
clients
and
context
keys
between
the
agent
and
the
application.
G
So
if
we're
replacing
that,
I
probably
would
like
for
it
to
be
as
easily
instrumental
as
possible,
because
up
till
now,
all
those
contest
keys
were
basically
static
fields
and
in
some
classes.
So
it
was
very
easy
to
obtain
them
and
compare
which
one
is
the
same
on
the
agent
and
the
application
and
if
we're
making
them,
I
don't
know
values
in
the
map,
or
instance
fields,
and
you
know
the
suppressing
span.
Wrappers
instances
can
be
dynamic,
then
it
will
be
much
more
difficult
to
determine
which
one
is
which
one.
G
F
G
Yeah
so
one
way
or
another,
the
context
keys
should
be
available
in
in
a
static
context,
so
they
can
be
a
field
of
object
that
is
static.
That
should
be
fine
too.
I
guess
but
yeah
that
that's
just
one
thing
to
remember:
if
we,
if
we
make
this
too
complicated
and
or
too
dynamic,
then
it
will
be
possibly
instrumental.
F
I
think
currently
it's
totally
doable
so
and
it
doesn't
seem
too
hard,
so
it
would
be
like
instrumentation
type
dot.
Http
get
context
key.
Something
like
that.
I
can
do
this.
A
Cool
and
for
context
for
other
folks,
what
we're
talking
about
the
bridging
is.
A
This
picture,
where,
if
the
user
brings
their
own
say
that
brings
our
instrumented
libraries
or
the
instrument
or
api
in
their
app
and
internally
in
the
agent
we're
using
it
also.
A
We
bridge
this
to
avoid
version
conflicts,
and
so
this
is
kind
of
a
tricky
component
and
so
to
make
this
these
context
keys.
We
already
bridged
the
open,
telemetry
api,
but
this
is
like
a
new
sort
of
a
new
concept,
so
we
want
to
bridge
that.
A
Also,
all
right,
we
got
nikita.
I
Call
for
feedback,
I
know
some
people
are
interested
in
this
topic
about
filtering
out
spans
based
on
urls.
So
please
read
the
commentary,
read
the
questions
and
share
your.
A
I
I
I
A
H
I
Okay,
capturing
http
url
is
actually
certainly
not
ideal
because
in
the
majority
of
case
well,
in
a
lot
of
cases
we
reconstruct
url
actually
from
the
pieces.
Some
some
libraries
provide
the
whole
url,
but
at
least
half
of
them
provide
just
pcs,
and
so
we
create
new
url,
which
quite
expensive
operation
anyway,
and
and
then
for
that
sampler.
For,
for
example,
it
may
be
that
we
actually
don't
want
the
url,
and
then
we
we
take
that
url
from
the
span
from
the
attribute
which
is
already
streamed.
I
I
I
Cool
just
a
small
notice
that
that
pull
request
is
in
concrete,
so
it
probably
even
if
it
gets
approved
and
merged
it
will
not
be
readily
usable
in
auto
instrumentation,
because
there
is,
there
will
be
no
way
to
actually
configure
that
for
the
end
user,
because
that's
a
totally
separate.
I
So
the
the
question
is
so
that
sampler
has
to
have
a
delegate
sampler
to
delegate
to
when
the
when
there
is
no
http
or
url
for
the
spam
and
how
you
to
configure
that
url
via
environment
variables.
Nobody
knows
how
you
configure
matching
urls
via
environment
variables.
Nobody
knows
so,
and
we
can't
do
that
in
open,
intelligent
repo
without
any
sort
of
standardization,
that
across
languages
and
well.
That
will
take
time.
I
A
I
F
A
Is
there
would
it
work
as
an
extension
or
is
there?
Are
you
saying
that
it
would
be
problematic
as
a
using
the
dumping
that
into
an
extension
also.
I
I
I
I
I
A
I
wanted
to
call
out
the
extension
stuff
because
this
is
we've
started.
I
started
exploring
this
for
a
customer
also,
and
I'm
very
thankful
that
you
started
building
this
out.
I
think
it
is
very.
A
J
Yeah
I
had
a
small
one:
ron
is
joining
who's
working
on
the
logging
implementation.
So
I
just
he
just
wanted
to
give
a
little
update
and
I
don't
know
if
he's
met
y'all
so
but
yeah.
K
K
Hey
I'm
fine
jonah,
so,
first
of
all
hello,
everybody,
it's
my
first
time
meeting
here
and
so
a
bit
excited
and
also
like
kind
of
like
the
first
real
open
source
project
I'm
working
with.
So
it's
a
lot
to
to
learn
and
catch
up
to,
and
so
basically
we
are
working
on
the
logging
sdk.
We
are
writing.
Essentially
we
are
doing
a
poc
for
a
log4j
and
login
instrumentation,
and
so
currently
we
are
writing.
We
are
actually
implementing
the
logo
exporter
in
the
java
library
and
that's
it.
K
We,
we
kind
of
started
to
work
way
on
it
not
too
long
ago.
So
there
are
not
too
many
new
stuff
we're
trying
to
get
familiar
with
the
data
objects,
the
protobuf
objects
and
currently
I'm
implementing
something
called
the
in
in
the
span
and
the
metrics.
They
have
the
span
and
metric
metric
adapter.
That
adapts
like
the
metric
data
and
the
span
data
to
and
protobuf
and
like
serial
serialized
data
to
a
prototype
object.
So
I'm
currently
working
on
that
and
that's
it.
H
Yeah,
so
in
our
last
week's
sig
I
put
a
couple
of
links
to
some
of
the
logging
work
and
hopefully
that's
been
shared.
Have
you
seen
those
links?
Yeah?
Okay?
I
sent
them
to
ron
yeah
great
yeah
yeah.
I
mean,
I
think,
the
main
takeaway
there
is
just
to
ensure
that
we
have
some
separation
between
the
protobuf
objects
and
our
true
domain
objects.
K
True,
so
I
will
ask
jonah
again
for
those
links
or
try
to
see
the
reference
and
yeah
there
are
some.
There
are
a
bit.
It
looks
like
some
of
the
protobuf
objects
are
named
the
same
as
the
the
source
objects.
For
example.
K
I
saw,
I
think
logo
record
might
be
one
that
is
like
also
in
protobuf
in
there,
so
I
need
to
kind
of
get
get
an
understanding
of
what's
going
on
what's
going
on
there,
and
also
something
that
I
saw
is
that
the
current
log
record
object
does
not
expose
or
hold
the
resource
and
the
instrumentation
library
info.
K
So
I
might
need
to
understand
if
that's
something
we
need
to
head
there
and
for
all
the
like
conversion
to
resource
logs
object
yeah,
but
we
just
started
to
work
on
it,
so
it's
like
currently
just
for
me
at
least
it's
just
like
to
understand
the
environment
kind
of
like
map
in
my
head.
What's
going
on,
there.
K
B
Yeah
I
mean,
I
think,
the
only
thing
that
I
wanna
I
just
wanna
reiterate
is
we.
I
think
we
really
want
to
make
sure
that
our
our
sdk,
the
api
that
we
expose
in
our
sdk
is
as
simple
as
we
can
make
it
and
not
just
kind
of
exposing
the
entire
protobuf
api,
just
because
it's
there
like.
I
think
we
want
to
have
something.
That's
a
little
bit
more
java,
centric
and
simple,
if
at
all
possible.
So
that's
that's.
My
main
goal
is
to
make
it
something
like.
B
I
know
that,
like
the
big
thing
is,
of
course,
the
the
log
message
body
in
the
protobuf
supports
the
arbitrary
objects
essentially,
and
I
don't
think
there's
any
need
for
that
in
the
java
in
any
of
the
java
logging.
Appenders
that
need
would
need
to
be
written.
Like
string
is
good
enough
for
the
message
body.
B
K
B
Something
so
I'm
trying
to
remember
what
the
what
the
api
looks
like
in
the
current.
The
current
sdk
has
some
code
in
it.
Let
me
hold
hold.
Please
set
up
something
real
quick.
What
do
we
have?
We
have
a
log
record
right,
yeah,
so
the
log
record
right
now,
the
body
is
this
any
value
thing,
and
I
would
like
that
the
body
to
just
be
a
strength
and
not
have
not
expose
any
value
from
the
photograph.
K
Yeah
one
thing
specifically
about
the
log
record
is,
as
I
just
mentioned
before.
K
I
saw
that,
if
I
understand
correctly,
the
you
can
say
sort
of
equivalent
to
the
log
record
in
the
metric
and
span
is
the
span,
data
and
metric
data,
and
there
I
saw
that
and
they
have
when
they
do,
the
conversion
to
the
protobuf
object.
They've
actually
explored.
They
actually
export
like
extract
the
get
resource
and
get
the
instrumentation
library
info,
which
currently
we
do
not
have
in
the.
F
K
Record
so
I
so
I'm
just
trying
to
understand
if
it's
something
that
I
need
to
add.
Currently
I
I
did
like
edit
it
there,
but
I'm
just
playing
around
and
trying
to
see,
and
so
there
is
a
lot
of
news.
There
are
a
lot
of
new
things
there
so,
but
just
like
to
put
it
out
there.
So
maybe
the
next
time
I'll
have
more
like
knowledge
or
better
question
to
to
ask
about
that.
Yeah.
B
Jason,
what
did
you
I
don't
remember
what
you
ended
up
doing
with
with
the
instrumentation
library
in
the
resource?
Do
you.
H
C
H
H
K
That's
it
the
resource
logs,
adapter,
okay,
let's
see.
K
Okay,
so
probably
do
not
have
access
for
that.
No,
you.
K
K
I
I
I
guess
you
could
say
you
will
be
able
to
set
up
when
there
is
something
that
is
actually
like,
of
course
feasible,
but
yeah,
I'm
I'm
attempting
to
to
do
that.
H
So
it
looks
like
their
path,
it
looks
like
the
attributes
are
passed
in,
but
there's
this
convert
convert
resource
attributes
that
takes
inner
resource.
So
it's
like
it
happens
when
the
thing
is
constructed,
which
is
part,
does
our
log
entry
have
the
resource
in
it?
It
does
not
no,
and
that
was,
I
think,
that's
what
ron
was
talking
about,
but.
A
B
K
Yeah,
so
so
is
it
something
that
I,
by
the
way,
I'm
not
familiar
with
the
splunk
repository,
but.