►
From YouTube: 2021-12-01 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
The
alternate
proposal
was
that
it
is
actually
an
instrumentation
library
name,
it's
just
that
the
instrumentation
library
isn't
actually
instrumentation
library.
The
intent
was
that
it
is
instrumentation
scope.
So
if
that's
the
intent,
then
logger
name
actually
fits
that
definition.
It's
blogger,
a
logger
is
sort
of
a
scope
which
whoever
is
emitting
the
log
records,
wants
to
wants
to
communicate
to
to
the
recipient
of
that
log.
A
B
Well,
I
mean
I,
I
don't
have
to
agree,
that's
fine,
but
it
feels
to
me
like
it's
a
it's,
a
very
different
thing
right,
both
that
you
know
who's
making
that
choice
and
it's
not
really
an
instrumentation
like
it's.
It's
it's
the
application,
author,
not
somebody
who's,
doing
something
instrumentation
later,
like
that's
so,
okay,.
A
B
Of
but
okay,
so
a
couple
ways
that
I'm
looking
at
it.
B
One
of
them
is
that
there's
a
useful
bit
of
information
of
how
did
this
log
get
here
and
you
know,
there's
something:
some
sort
of
open,
telemetry
bit
of
code
that
actually
pulled
that
from
log4j,
which
in
turn
pulled
it
from
you,
know
slf
for
j,
which
is
what
the
application
author
wrote
right,
so
that
piece
of
code
that
went
from
log
for
j
to
open
telemetry
is
something
that
might
need
troubleshooting
that
that's
the
place
where
it
kind
of
hits
the
biggest
bump
going
over
the
speed
bump
right.
B
You
know
kind
of
going
off
of
you
know
the
the
what
I've
posted
in
that
comment
from
the
instrumentation
of
the
java
instrumentation
repo
they're
they're.
Looking
at
that,
as
as
that
troubleshooting,
so
there's
just
a
big
mismatch
there.
The
other
thing
is
kind
of
the
the
cardinality
piece
to
me
that
you
know
one
application
is
going
to
have
hundreds
of
loggers,
whereas
where
other
places
were
using
instrumentation
name,
it's
one
piece
of
instrumentation
to
pull
one
instrumentation
column
into
into
our
pipeline,
so
it
it
just
seems.
C
So
using
the
logger
name
as
instrumentation
scope
or
instrumentation
name
whatever,
it
is.
The
first
thing
that
you
mentioned
was
that
there's
no
place
to
put
kind
of
the
adapter
piece.
So
the
thing
that
is
translating
along
for
j2
to
open,
telemetry
and
that's
true,
there's
no
top
level
field,
but
that
doesn't
preclude
us
from
putting
it
in
an
attribute
or
somewhere
else.
B
No,
I'm
not
saying
we
can't
capture
that
I'm
just
saying
that
this
is
what
we
use,
that
for
in
other
things
like
that's
what
we
use
it
for
in
traces.
The
instrumentation
name
is
that
that
piece
of
code
that
pulled
the
traces
from
wherever.
A
A
B
A
Log4J
is
simply
an
intermediary
there.
Well,
arguably,
the
thing
that
I
want
to
call
the
instrumented
scope.
Let's,
let's
use
the
word
scope,
let's
say
right
that
what
was
the
intent?
The
instrument,
its
scope
in
this
case,
isn't
log4j,
it's
actually
what
calls
log4g,
what
calls
look
for
js,
api,
okay,.
B
So
in
in
that
case,
we're
looking
at
a
scope-
that's
not
kafka!
We're
looking
at
kafka's
like
sub
sub
subsystem,
one
class
of
that.
So
you
know.
A
A
Implementation,
you
have
this
cat
logger
call
which,
which
uses
the
the
class
name
or
whatever,
to
obtain
a
logger
right,
that's
a
traditional
way.
So
that
is
the
thing
that
we
are.
We
should
be
probably
considering
the
part.
That
is
the
scope
right.
No,
I
I
don't
know
it's
kind
of
arguable
right,
you're,
saying
your
argument
is
that
log4j
is
the
thing
that
we
are
instrumenting
by
providing
an
open,
telemetry,
appender.
B
What
what
I'm
trying
to
say
is
that
I
guess
what
I
would
tie
it
down
to
is
that,
from
you
know
what
I,
what
I
read
in
the
instrumentation
library,
we're
looking
at
the
instrumentation
name
as
being
metadata
on
the
open
telemetry
data,
whereas
the
logger
is
an
attribute
of
the
source
data.
B
So,
like
I
just
see
those
as
two
different
things
like
one
of
them's
metadata
on
the
transport.
One
of
them's
aspect
of
the
the
the
core
data.
A
B
Like
I
said
I
don't
have,
I
don't
have
to
agree.
I
just
it
feels
like
a
mismatch
to
me
and,
and
you
know,
if
my
arguments
aren't
landing,
that's
then
that's
fine.
I'm
I'm
happy
to
say
that.
C
The
thing
that
convinced
me
and
yeah
like
I
agree
that
we
don't
have
to
agree,
but
the
thing
that
convinced
me
that
using
the
logger
name
as
instrumentation
scope
or
name
was
the
right
way
to
go,
is
thinking
about
the
s
slf
for
j
api
as
a
stand-in
for
an
open,
telemetry
api.
So,
like
you
know,
we
don't
have
an
open,
telemetry
log
api,
so
we
have
an
sdk.
C
The
slf4j
is
the
stand-in
for
that
and
in
that
library
the
thing
that
is
closest
to
or
in
that
slr
for
j
api.
The
thing
is
that
is
closest
to
our
notion
of
an
instrumentation
name
is
like
the
logger
name
that
you're
using
to
initialize
to
get
that
logger
instance
yeah.
A
I
think
that's
that's
also
how
I
see
it's
not
exactly
the
library
name
when
you
call
it
a
library
name.
There
is
a
bigger
mismatch
there,
but
as
soon
as
you
agree
that
it's
kind
of
the
scope
name
kind
of
starts
fitting
a
bit
better,
there
yeah-
I
I
I
I
accept
your
point
that
you
lose
this
piece
of
information.
The
fact
that
how
the
logs
were
propagated
through,
like
l4
ox4j
or
whatever
library
was
used,
but
jack
is
right.
You
can
record
it
as
an
attribute.
D
Thanks
yeah,
I
was
just
gonna,
I
mean
I.
I
agree
with
that.
I
think
what
is
the
consensus
here
that
that
we
can
use
the
logger
name
and
put
that
in
the
instrumentation
library
name,
but
it
definitely
went
into
the
conversation
a
couple
weeks
ago.
It
was
completely
the
opposite
opinion
and
what
changed
my
mind
was.
D
Okay,
now
I
think,
there's
a
point
to
the
cardinality
too,
where,
like
maybe
logger
name,
is
going
to
be
much
much
more
granular
than
on
than
like
a
tracer
would
be
I'm
not
I'm
not
super
familiar
with
tracing,
so
maybe
maybe
not,
but
in
some
cases
at
least
I
would
imagine
there
there's
a
huge
number
of
logger
names
in
a
in
an
application
and
others
it'll
be
just
a
couple
or
just
one,
even
but
either
way
if
we
define
it.
As
that
like
bring
me
to
the
code,
that's
that's.
Definitely
solving
that
purpose.
B
Yeah,
I
I
I
think
that
makes
a
lot
of
sense
and
you
know
I
think
what
that
argument
and
jack's
argument
make
yeah
that
that
pulls
me
over
into
that
camp.
My
my
main
anxiety
is
that
if,
in
the
other
signals
this
is
kind
of
metadata
on
the
transport
you
know,
logger
is
just
so
important
for
people
that
are
actually
using
the
logs,
and
so
I
don't
want
it
to
get
hidden,
but
I
guess
that
kind
of
is
up
to
to
the
companies
that
are
accepting
the
data.
So
I
guess
it's.
E
So
I
I'd
also
like
to
try
and
pull
this
out
a
little
bit
to
the
user's
perspective
of
like
an
instrumented
library,
because
from
their
perspective,
it's
a
little
bit
immaterial.
That
log4j
to
an
adapter
is
is
collected
in
that
data
because
they
need
to
know
where
they
tie
in
from
kind
of
where
their
library,
where
their
code
ends
with
the
library
and
then
tie
that
to
a
particular
message,
so
that
it
goes
through
log4j
and
an
adapter
and
maybe
like
a
collector
or
three.
E
That's
that's
less
important
to
the
end
user.
So
while
it
might
be
something
that
may
be
worth
capturing
or
or
giving
the
option
to
capture,
I
don't
know
if
that's
necessarily
like
where
we
want
to
put
our
primary
focus
on,
because
at
the
end
of
the
day,
we
need
no
log
message
to
where
it
was
emitted.
Exactly.
B
And-
and
that's
exactly
why
I
was
kind
of
concerned
about
this,
because
you
know
the
logger
name
is
extremely
important
and
you
know
for
traces.
The
instrumentation
name
is
something
that
might
not
even
get
captured
like
it's
just
such
a
you
know
it's
a
troubleshooting
for
open,
telemetry
sort
of
value,
so
I
don't
want
to
get.
I
don't
want
logger
name
to
get
relegated
to
something
like
that.
C
I
get
as
a
representative
for
one
vendor.
I
can
say
that
we
do
not
throw
away
that
information,
so
it's
it's
treated
just
the
same
as
any
other
metadata,
something
that
you
can
search
and
filter
on.
I
I.
E
A
B
One
word
one
way
or
another:
I
I
pull
back
my
my
yeah,
I'm
good
with
this.
A
Okay,
I
guess
then
the
other
question
is
jackie.
I
think
you
you
mentioned
that
you
don't
see
much
benefit
in
redefining
the
logging
sdk
api
for
logometer
to
to
not
be
associated
with
the
library
name
and
instead
include
that
in
every
immediate
log
record
you
don't
see
the
benefits
of
that.
Can
you
maybe
expand
on
that?
A
bit.
C
Yes,
I'm
working
on
some
benchmarks
right
now
that
that
compare
the
two
approaches
directly,
so
you
know
approach
one.
Is
you
obtain
a
log
emitter
instance?
Every
time
you're,
you
know,
processing
a
log
event
and
you
you
obtain
that
with
the
logger
name,
and
so
essentially
you
have
to
do
a
lookup
and
a
map
to
say:
okay,
does
this
log
emitter
with
this
name
already
exist?
If
so
use
the
one
that
already
exists,
if
not
create
a
new
one.
C
So
and
then,
once
you
have
that
log
emitter,
you
know
emit
the
log
through
that,
so
I'm
comparing
that
approach
to
the
one.
This
alternative
approach,
which
is
just
you,
have
a
single
log
emitter
and
as
a
part
of
building
up
your
log,
your
your
log.
You
include
the
instrumentation
library
info,
the
like
the
name,
the
version
and
the
schema
with
each
log
that
you're
producing,
so
you
bypass
that
map
lookup,
and
so
I
think
you
know
we're
trading
a
little
bit
of
fixed.
C
You
know
a
constant
times
lookup
in
a
map
for
some
memory
allocation,
because
you
know
with
the
alternative
approach.
You
have
to
create
a
new,
at
least
in
java,
instrumentation
library
info
instance,
for
each
one
of
these
things
and
kind
of
comparing
them,
and
I
don't
think
there's
going
to
be
a
big
difference.
C
I
can
let
you
know
when,
when
the
benchmarks
are
done
the,
but
you
know
this
look
up
in
a
map,
is
it's
it's
constant
time
it's
over
one,
but
it's
going
to
the
actual
amount
of
time
is
going
to
vary
based
on
the
cardinality.
So
if
there's
a
massive
massive
number
of
loggers
and
your
hash
map
gets
really
big,
it's
going
to
take
more
time
to
do
that,
look
up
than
if
it's
a
small
number.
So
that's
going
to
be
something
to
think
about
so.
A
A
I
guess
what
I'm
saying
is:
if
we're
doing
the
aggregation
already,
then
we're
already
paying
the
cost
of
the
lookup
of
the
by
the
by
the
name
of
the
library
right.
So
if
that's
the
case,
then
we
can
eliminate
the
other
look
up
because
we're
they
will
be
doing
two
lookups
in
this
case.
Essentially
so.
E
E
Yeah,
so
in
the
go
exporters,
I
don't
believe
it
actually
does
any
kind
of
re-aggregation.
It
just
takes
the
collection
of
messages
and
flattens
it
out
into
the
otlp
format.
It's
close
enough.
A
E
No,
you,
your
exporter
is
tied
to
a
particular
instrumentation
library,
so
it
will
send.
D
E
C
A
C
Yeah
I'll
is
there
a
ticket
for
this,
or
should
I
just
I.
A
A
A
C
So
one
thing
that
I
would
say
is
that
you
know
for
it
to
be
useful,
at
least
in
the,
in
the
way
that
I
think
that
it
should
be
so
I
I
think
that
we
need
to
define
it
as
like,
like
a
low
cardinality
classification
of
like
the
type
of
log,
and
so
if,
if
it's
not
defined
that
way
and
and
folks
use
it.
A
Is
it
is
it
says
that
so
we
shouldn't
have
the
varying
bits
of
whatever
the
log
record
should
contain?
That's,
I
think,
that's
how
it
let
me
see
what
exactly
the
wording
on
that
is.
Where
is
that,
so
it
says.
C
D
A
C
Yeah
yeah
and
you
know
the
other
approaches
that
folks
have
been
talking
about.
You
know
having
this
type
of
field,
this
low,
cardinality
categorization
and
an
attribute
those
work
as
well,
but
if,
if
there's
appetite
to
put
it
as
a
top
level
field,
that
worked.
That's
that's
better
for
me,
but.
A
A
D
D
Probably
that's
not
relevant
all
right.
E
D
A
F
Yeah
I
was
participating
in
a
discussion
and,
if
you
recall
originally,
it
was
why
we
even
have
like
attributes
on
the
rituals
level
on
the
log
level
and
then
in
the
body.
The
database
could
present
that
there
as
well-
and
we
concluded
that
we
want
to
keep
attributes
in
body
only
when
you
are
making,
for
example,
transformation
from
one
format
to
another
via
yeah.
So
you
could
preserve
the
information
that
those
attributes
were
in
the
body
rather
than
as
separately
as
attributes.
F
A
D
A
D
The
last
well
second
last
sentence
in
the
body
description.
First
party
applications
should
use
a
string
message:
okay,.
D
D
Okay,
that's
good
enough
for
me.
I
will
close
the
issue
and
close
the
pr,
and
I
think
we
can
close
the
issue
as
well
make
a
note
on
it.
D
D
Okay,
the
other
two
I
think
we're
just
waiting
on
people
to
review
or
validate
again.
The
only
reason
I'm
going
over
these
is.
These
are
really
the
last
items
that
we
have
open.
That,
in
theory,
are
blocking
us
from
calling
the
data
model
stable.
So
yeah
just
wanted
to
keep
touching
on
these
until
they're
done
the
trace
flags
question:
do
we
we've
asked
a
couple
times
for
people
to
validate?
Do
we
just
assume
they
don't
care
and
close
it?
A
D
Okay
and
then
the
google
logging
mode
is
just
waiting
on
josh
stereth.
I
have
to
say
I
don't
I'm
not
entirely
clear
that
this
is
actually
blocking
our
data
model.
A
D
Okay,
well,
should
we
shall
we
just
at
least
remove
the
the
label
then
from
the
issue,
so
we're
not,
I
think
so.
A
Yeah,
let
me
do
that.
I
think
there
was
another
one
right.
There
should
be
two
one
is
the
log
name
and
the
other.
What
was
the
other?
There
were
two
that
we
were
waiting
for,
josh
to
comment
on
I'll,
find
the
other
one.
I
think
there
was
a.
There
was
already
a
pr
associated
with
the
issue,
which
maybe
I
did
the
piano.
I
remember
there
should
be
two
pr's
and
both
were
waiting
for
josh
to
to
comment
on
yeah.
Do
the
other
one
is
20
93
to
093.
A
And
it's
again
it's
similar
and
I
don't
think
that's
a
broker
either.