►
From YouTube: 2020-10-29 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
A
C
A
D
B
Is
this
some
inside
jokes.
B
All
right,
I
am
completely
not
prepared,
but
it
looks
like
they've
got.
Oh
maybe
I
did
have
some
agenda
items.
I
know
we
had
some
things
from
previously
that
we
didn't
chat
about.
B
B
B
B
I
think
I
saw
you,
sir
yeah,
you
wanna
talk
about
active
system,
metrics.
E
E
Yes,
I
think
that
we
would
like
to
like
speed
up
this
issue
and
to
have
it
in
the
next
release,
so
yeah
I
can
maybe
help
if
it
just.
I
can
understand
how
how
I
can
how
we
can
enable
it.
B
E
B
B
Well,
we
don't
really
have
any
metric
instrumentation
anyway,
but
it
seems
a
lot
more.
I'm
wondering
about
having
a
separate
package
still
of
that
you
could
use
if
you
want
oshie.
B
B
Yeah
and
if
that's
what
we
want
for
the
oshi
because
like
to
me,
the
I
don't
know
the
the
agent
I
always
think
of
as
this
code
list,
something
you
can
attach
to
your
app
without
having
to
modify
your
app.
Oh,
I
remember
discussing
this
with
honorable.
He
was
thinking
that
so
you
could
still
codelessly
just
add
oshi.jar
to
your
class
path
like
at
the
command
line.
When
you
do.
B
And
then
we
need
to
bridge
because
it's
well,
we
already
have
the
metrics
bridge
so
sergey.
Approximately.
I
think
what
you
would
do
is
you
would
oh,
we
need
to
detect
because
we
don't
even
know
that
it's
going
to
get
loaded,
so
we
can't
listen
for
oshi
classes
to
be
loaded.
We
actually
have
to.
B
In
our,
I
think,
almost
in
our
classroom
class
loader
instrumentation,
where
we
do
a
couple
of
things
there
one
is,
we
force
loading
our
bootstrap
classes
through
the
bootstrap
class
loader
to
make
sure
that,
because
sometimes
osgi
class
loaders
don't
delegate
to
the
bootstrap
class
loader,
except
for
like
specific
java
classes
and
the
other
thing
we
do
there
now
is.
B
I
we,
I
think,
that's
where
we
inject
yeah.
We
have
the
resource
injection.
Now
that
honorag
had
added
for
being
able
to
automatically
sort
of
like
pick
up
meta-imp
services,
java,
spi
resources.
B
B
If
check
a
specific
oshie
class,
you
know
try
get
resource
on.
B
That
and
if
we
find
that.
B
Oh,
I
still
yeah,
I
guess.
If
we
find
that,
then
we
can.
B
F
F
F
B
F
H
E
That's
the
thing,
so
we
don't
call
or
so
we
don't
expect
any
calls
of
the
osha
library.
Yes,
we
just
need
to
detect
that
this
library
exists,
then
we
will
use
it
in
the
metrics,
so
we
will
call
oshay.
B
B
We
can
inject
stuff
that
runs
in
there,
but
the
question
we
have
to
detect,
detecting
that.
Oh
she
is
on.
There
is
harder
well.
H
B
Over
yeah-
something
like,
I
think,
that's
similar
to
this
idea
when
we
see
a
new
class
loader
check
so
alt
class
for
name,
let's
see
if
hershey
present.
B
Potentially,
like
in
class
loader
instrumentation,
it's
sort
of
like
something
we
want
to
run
once
for
like
we
instrument
class
loader
load,
so
maybe
we
could
keep
a
flag
around.
If
we've
already
checked
this
class
loader,
it
gets
a
little
complicated.
B
B
Yeah,
what
about
having
our
own,
like
you,
know
how
we
have
hotel
exporter
jar?
B
F
B
System
yeah,
I
I
kind
of
think
this
might
something
with
this
might
work
sergey,
because
we
certainly
have
the
ability
to
run
stuff
in
the
system
class
loader
I
mean
our
do.
Do
we
think
it's
okay
to
say
only
if
it's
in
on
the
system
class
loader
versus
like
we
wouldn't
necessarily
detect
it
if
it
was
in
a
war
file,
class
loader.
B
B
Yeah
I
mean
people
have
to
muck
with
the
command
line
jvm
args
anyway.
F
B
H
Right
but
to
I
think,
to
reiterate
what
nikita
was
saying
is
that
by
having
like,
if
somebody
wants
to
use
system,
metrics
they're
going
to
do
it
for
the
jvm
at
the
system,
class
loader
right
and
not
deploy
it
as
part
of
their
war
file,
I
would
think
yeah
yeah.
B
Right
if
say,
you're
on
a
jboss
wildfly
that
would
what
I
was
wondering
is
thinking
is
that
would
potentially
that's
going
to
be
on
your
system
class
path
for
all
your.
F
F
B
Right,
I
just
mean
that
in
this
this
one
we
shade
right.
We
shade
everything
so
that
we
won't
conflict
with
people's
anything
in
the
users
war
files,
whereas
this
is
not
shaded,
which
I'm
wondering.
If
you
know,
maybe
I
mean
we
could
publish
this
as
a
separate
module
that
is
shaded
also,
as
opposed
to
saying
use
the
use
the
default
oshi
jar.
E
B
E
E
B
Yeah,
so
if
you
can
do
this
instead
of
in
the
agent
class
loader,
if
we
can
do
all
of
this
basically
in
the
system
class
loader,
then
we
would
have
access
to
this
and
we
could
use
our
shaded
open,
telemetry
metrics
api
directly.
B
Oh,
if
you
use
you
just
use
the
regular
open,
telemetry
api
like
the
way
that
our
other
instrumentation
does
and
then
we
shade
it
at
build
time
the
advantage
there
versus.
If
we
inject
this
into
the
user's
class
path.
Well,
I
guess
we
could
still
use
the
shaded
metrics
api
since
it's
our
code
and
we
don't
have
to
deal
with
the
bridging,
which
is
good.
B
Cool
so
yeah
give
give
that
some
thought
and
then
I'm
sure
we
left
out
lots
of
important
things
that
are
still
going
to
be
problematic,
so
post
yeah
post
to
that
issue
with
more
questions.
G
Yeah
so
after
some
time,
I've
started,
I've
started
to
use
again
java,
instrumentation
and
I've
updated
to
the
newest
release,
and
I
found
in
logs
that
I'm
getting
errors
sending
metrics
to
the
open,
telemetric
collector,
and
I
was
let's
say
surprise
because
I
didn't
expect
metrics
to
be
enabled
there
by
default.
G
So
my
question
is:
is
it
I
don't
know
requirement
from
open
telemetry
specification
and
it's
the
reason
why
they
are
enabled
by
default,
or
there
is
a
magic.
I
don't
know
a
flag
trick
to
disable
them,
mostly
because
of
an
ugly
error
in
the
logs,
like
unknown
node,
name,
etc,
and
also
our
our
customers
were
a
little
bit
surprised
when
they,
when
they
started
to
use
the
java
instrumentation
auto
instrumentation,
and
they
then
they
also
seen
this
error
and
were
asking
us
why
this
error
is
there
etc.
G
So
it's
not
clear
for
let's
say
newcomers
to
the
open,
telemetry
and
the
people
of.
I
I
think
from
from
the
experience
with
customers.
I
think
they
are
not
aware
of
of
metrics
enabled
by
default.
So.
B
F
Far,
yes,
if
you,
if
you
take
a
open,
telemetry
java
agent
by
default,
it's
it
uses
otlp
exporter,
which
exports
both
metrics
and
traces,
but
oftentimes.
When,
when
you
take
open
geometry
collector,
the
default
configuration
of
the
collector
only
has
tracer
receiver
configured
yeah
so,
and
so
you
have
a
reporter
trying
trying
to
export
metrics,
but
no
receiver,
and
you
you
see
very
confusing
error
messages
and
exceptions
in
java
agent,
logs
yeah.
So
that's
that
that's
the
reason
for
that.
G
Okay
and
yeah
otl
ps
default,
but
is
there
a
way
to,
I
don't
know,
have
a
flag
to
disable
sending
metrics.
B
G
B
Was
broken?
We
didn't
quite
get
this
right
again.
E
G
B
G
B
All
right-
annie-
oh
hey,
hey
I
forgot
to
did
I
oh
I
did.
When
did
I
put
my
name
there?
Sorry
people
I'm
losing
it.
Anybody
else
have
anything
they
want
to
chat
about.
F
Yes,
I
I
have
a
question,
do
do
we
have
any
estimates,
will
we
release
0-10-0
next
week
or
not.
A
Yeah
and
I
have
that
splunk
has
that
day
off,
so
I'm
currently
working
on
release
notes.
A
Yeah
we
have,
we
have
tuesday
off
in
the
us
for
voting,
even
though
we've
already
voted
yeah
and
there's
a
whole
new.
I
don't
know
if
carlos
you've
seen
there's
a
whole
new
release
process
that
honorag
has
built
using
github
actions.
A
F
B
A
Yeah
for
people
who
don't
know
oteno
of
the
api
break,
it
breaks
everything,
so
we
I
mean
well,
especially
it
breaks
everything
because
we've
moved
all
of
the
classes
into
a
new
package
into
the
api
package.
So,
no
matter
what
everything's
going
to
be
broken.
A
F
B
F
B
B
We
had
even
a
tracking
issue
for
that,
because
when
I
did
the
original
context
bridge,
I
took
a
lot
of
shortcuts
and
so
we
lacked.
We
didn't
have
a
lot
of
coverage
yeah
but
honor.
I
that's
the
pr
honor
I
just
landed
last
night.
A
I
don't
know
how
the
agent
is
setting
up
propagators
for
the
sdk,
something
to
something
to
look
at
it'd,
be
good
to
have
that.
B
B
I
see
yeah
one
line
had
baggage
propagator
bonus,
add
baggage
bridge
because
yeah,
if
somebody
in
uses
hotel
api
to
try
to
add
stuff
to
the
bridge.
Currently,
that's
not
going
to
interrupt
with
us.
B
Yep
good
topic
anything
else
from
anyone.
F
F
Yeah,
I
I
I
kinda
understand,
but
that
baggage
bridge
that's
more
of
all
more
complicated.
B
Oh,
the
baggage
bridge,
yeah
yeah.
This
is
way
more
complicated.
B
A
Trask
said,
if
somebody
uses
the
api
to
try
to
modify
or
add
baggage
to
the
context
it
wouldn't
I
guess
it
probably.
Wouldn't
I
don't
know
what
would
happen
this
wouldn't
work.
A
B
B
Nice
anybody
else
have
thoughts,
ideas,
questions.
J
I
have
a
quick
question
yeah.
What
is
the
the
policy
for
accepting
prs
for
like
additional
exporters
into
the
repo
like
if
we
submitted
a
pr
for
like
the
new
relic
exporter?
Would
that
be
accepted,
or
is
that
doesn't
know?
I
thought
it
was
no.
I
think
this
came
up
in
the
past,
but
I
wasn't
on
the
meetings
back
then.
B
Yeah,
so
the
latest
there's
been
some
discussion
in
the
spec
repo
recently
about
what
third
party
stuff
would
be
accepted
and
where
and
like
the
open,
telemetry
collector
contrib
repo
has
lots
of
exporters
vendor-specific
exporters
there.
So
potentially
we
do
have
a
java
contrib
repo,
that's
underused
at
this
point,
so
we
could
put
it
there,
but
the
other
vendors
are
currently
hosting
it
themselves.
H
B
Yeah,
the
I
know
originally
like
in
the
dotnet
repo
also
there
were
lots
of
vendor-specific
things,
but
that
those
are
all
gonna
go
away
at
least
go
into
contrib.
A
So
it's
it's
definitely
something
that
needs
to
be
maintained
by
the
vendors
who
are
responsible
for
it,
and
this
has
been,
I
think,
I
know
quite
contentious
in
the
collector
contrib
repo,
even
because
people
have
been
having
to
maintain
exporters
that
they
don't
really
know
anything
about
and
how
they're
supposed
to
work
and
what
their
constraints
are.
B
B
This
was
a
pretty
interesting
discussion
here
on
normalizing
sql
queries,
and
so
it
started
with
sort
of
this
example
of
normalizing.
You
know
the
the
in
lists
which
are
common,
I
know
at
least
from
hibernate.
B
You
know
like
usage
and
you
do
a
big
endless
and
the
variable
number
of
question
marks,
and
so
those
balloon,
your
your
cardinality,
and
so
there
was
a
interesting
discussion
and
some
suggestions
about
so
in
particular,
let's
see
john
yeah,
so
this
was
john
had
some
interesting
thoughts
from
past
experience,
and
so
we
already
we
have
two
places.
We
store
this.
We
have
db.statement
semantic
convention
and
that's
going
to
be
like
that
can
be
high
cardinality.
B
You
know
sensitive
data,
so
we're
gonna,
we
scrub
all
of
the
constants
and
throw
in
question
marks,
but
then
the
span
name
is
where
potentially
we
could
do
heavier
normalization
since
that's
supposed
to
be
the
low
cardinality
part,
and
so
there
was
some
thoughts
here
like
even
taking
column
like
extending
this
from
in
lists
to
arbitrary
lists
of
you
know,
comma
separated
things
which
would
then
cover
like
column
lists,
other
things
which
both
expand
the
cardinality
and
also
are
just
make.
B
These
span
names
really
long,
which
is
not
that
awesome
in
the
ui
and
so
just
curious.
What
folks
think
there
was
some?
There
was
also
another
option
for
the
span
name
for
the
low
cardinality
part
portion
is
just
doing
so.
You
know
just
the
operation
name,
which
I
don't
tend
to
think.
That's
very
useful.
I
think
at
least
like
select
table
name
insert
into
table.
Name
would
give
you
know.
I'm
thinking
of
in
the
ui
like
is
that
top
slowest
x
queries
view
that
most
products
have,
which
is.
F
We
just
today
talked
with
john
about
that
and
the
problem
with
that
high
heavy
normalization
in
asia
is
first
resource
usage
or,
if
you,
if
you
go
beyond
the
simple
lecture
and
start
to
parse
and
extract
table
names
and
whatnot,
that's
that
cpu
cycle
and
and
the
second
problem
is
that
that's
complicated
code,
which
is
quite
hard
to
update
or
maybe
hard
to
update
because
well,
it's
it's
probably
quite
easy
to
to
make
such
normalization
for
like
80
percent
of
the
use
cases.
F
But
then
the
the
corner
cases
will
start
appear
and
to
push
those
updates
to
java
agent,
maybe
well
it
it
may
make
they
make.
They
may
take
time
and
the
third
problem
that
is
right
now
thought
of
is:
if
we
do
very
heavy
normalization
in
agent,
then
different
languages
will
will
have
very
different
span,
made.
F
Because
we
cannot
like,
if
we
have
re
a
really
complicated
and
advanced
span,
name
normalization,
then
well
port,
that
to
all
supported
languages
and
then
fix
for
all
supported
languages
is
a
separate.
B
B
But
sure
yeah
it
would
be.
I
think
that
would
be
nice
to
update
in
the
spec
sort
of
even
have
a
a
recommended
spam
name
for
sql
queries
so
that
you
know,
even
if
it's
not
a
must.
B
F
Not
specifically,
but
again
well
extracting
table
names.
It's
it's
certainly
useful,
but
it's
not.
K
Easy,
I
think,
extracting
just
table
names.
It
will
be
really
much
simpler
than
trying
to
trim
all
the
lists
and
detect
where
one
list
ends
and
the
other
starts
and
so
on.
So
if
we
want
to
compare
two
options
like
the
one
that
job
origin
john
originally
proposed,
with
this
division
and
just
taking
out
the
table
name,
I
think
that
statement
is
much
much
simpler.
K
K
I
B
Yeah
yeah
this
is
this
is
the
the
classic
problem
right
which
table.
B
Pick
here,
ideally,
ideally,
you
would
pick
w,
but
that
requires
more
work.
K
Yeah,
but
even
if,
in
this
example,
I
think
it
could
be
done
pretty
easily
like
medium
level
of
complexity
with
just
alexa,
but
when
you
want,
if
you
want
to
handle
a
similar
example
with
the
you
know,
just
this
edition,
you
know
trying
to
remember
which
list
you're
currently
on
which
level
of
nesting
it's
now
is.
It
will
be
hard
code
to
read.
Okay,.
F
And
I
would
like
to
bring
one
more
consideration
on
the
table
and
that
is
we
have
73
issues,
markers
required
for
ga
and
like
tons
of
issues
without
any
markings
are
they
required
for
j
or
not
so
that
proper
debate
statement?
Normalization
is
certainly
a
nice
feature
to
have,
but
how
does
it
fear
against
our
ga
goal?
B
So
to
me
this
is
pretty
I
mean
important
just
because
jdbc
instrumentation
is
so
heavily
used.
It's
so
common
that
it's
you
know
a
lot
of
users,
see
it
and
experience
it.
B
It
would
be
nice
but
yeah.
It's
not
a
required.
B
F
B
B
F
A
little
bit
in
check,
but
but
any
anyway,
I
think
we
do
need
that
3r,
because
we
have
no
idea
how
far
we
are
from.
F
B
Address
yep
all
right,
so
I
I
agree
that
that
it
would
be
great
to
have
a
meeting
that
is
just
purely
dedicated
to
this,
that
we
don't.
F
B
B
Once
we
get
caught
up,
maybe
15
minutes
for
sure
the
we're
behind.
So
it's
gonna
take
some
catching
up.
Wow.
F
B
I
wanted
to
mention
this,
so
the
open
telemetry
collector
has
these.
Has
this
cool
features
of
attribute
and
span
processors
that
you
configure
that
are
configurable
just
in
the
the
yaml
configuration
and
you
can
do
interesting
stuff
like,
for
example,
the?
Well,
you
can
redact
pii
data
on
sensitive
data?
B
You
can
change
the
span
names
to
be
something
like
you
know
how
our
span
names
sometimes
devolve
into
something.
You
know
very
generic,
like
http
get
for
outgoing
http
client
requests
and
you
can
map
you
can
do
like
regex
extraction
of
http
url
and
put
that
into
the
span
name.
B
And
nice
features
that
we're
for
we're,
adding
something
like
this
into
our
agent
configurable.
You
know
that
doesn't
require
writing
your
own.
You
know
java
based
spam
processor,
basically
following
the
exact
same
kind
of
syntax
and
structure
of
the
open,
telemetry,
collector
processors.
F
I
think
that
we
should
not
duplicate
that
functionality
from
the
collector.
If
you
want
to
introduce
something
agent
specific
for
some
reason
and
make
that
configuration
based,
not
code
based,
that's
fine,
but
I
don't
see
that
we
should
duplicate
collector
functionality.
B
Okay,
yeah,
that
was
the
that
was
what
people
had
felt
the
last
time
we
had
discussed
this
a
long
while
back
and
that's
fine.
We
just
don't
we're
just
not
using
the
collector,
so
we're
kind
of
stuck
with
having
to
duplicate
that
in
our
agent.
B
B
All
right,
let's
skip
over
lambda
instrumentation
strategy
and
winter
time
for
next
sig.
Yes,
the
time
for
people
on
daylight
savings
changes.
This.
B
Can
you
join
the
sick?
Can
you
join
the
will
the
tuesday
evening,
pacific
time,
meeting
work
for
you
then.
F
B
This
is
the
sorry
yeah
I
I
I
said
tuesday
and
I
meant
the
thursday
6
p.m:
pacific,
not
that
yeah,
sorry
yeah,
my
bad
so
yeah
I
mean,
I
think
the
goal
is
to
keep
these
times
the
same
and
hopefully
the
the
6pm
one.
What
is
the
yeah?
We've
got
nine
hours
in
between
those
yeah
and
we
do
we
do
in
the
6
p.m.
On
thursday
we
do
go
over.
You
know
all
the
stuff
that
we've
discussed
and
it's
a
good.
B
You
know
chance
to
for
folks
to
bring
up
things
and
chat
with
honorog.
B
Weekly
digest
and
wow
yeah.
That's
a
lot
of
merged
prs
in
the
last
week.
B
Yeah
this
one
we
were
talking
about.
This
is
a
a
big
improvement
in
terms
of
our
interop
story
with
the
manual
instrumentation
and
manual
context,
propagation,
I'm
just
I'm
going
to
skip
over
a
bunch
of
stuff
and
several
normalizing
queries
particularly
stripping
out
sensitive
data.
We
were
capturing
a
lot
of
parameters,
so
thank
you,
matthias
customers,
don't
like
that!
B
Nikita's
been
playing
whack-a-mole
with
our
with
our
build.
Thank
you
nikita.
We
kind
of
fell
behind
on
on
on
the
on
on
our
bill
on
the
master
build
latest
dependency.
Build
onorag
has
been
keeping
us
up
to
date
with
these
massive
changes
on
the
api
side
that
has,
with
our
bridge
and
and
also
our
internal
implementation.
So
that's
been
a
lot
of
work.
B
I'm
sure
I'm
skipping
over
important
things.
Some
lamb
cool,
lambda
stuff
contributed
by
splunk,
not
amazon,
so
that's
cool,
more
sensitive
data
scrubbing
more
sensitive
data,
scrubbing
ooh,
we're
using
more
sharing
of
stuff
sort
of
build.
Infra
and
dev
work.
B
Street
dev
work
space
stuff
between
the
two
java
projects,
so
love
to
see
that
and
yes
and
we
have
a
system
metrics,
malefiev,
malefic,
sergey,
contributed
the
we
have
library
instrumentation
for
the
oshi
and
that's
what
we
were
talking
about
today,
of
how
to
turn
that
now
into
also
agent-based
instrumentation,
oh
yeah,
and
the
context
root.
B
B
And
one
minute
to
spare,
so
I'm
sure
everybody
has
places
to
be
things
to
do
thanks
for
spending
time
here
today,.