►
From YouTube: 2021-11-16 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).
C
B
Yeah,
so
I
put
the
first
item
there.
Let
me
tell
what
is
it
about
so
the
log
sig
is
currently
working
on
stabilizing
the
log
data
model
and
one
of
the
unclear
bits
is
the
logger
name.
B
So
let
me
explain
what
it
is
when
when,
when
you,
when
you
emit
a
log
statement
in
your
application,
you
typically
get
a
logger
somehow
and
then
and
using
that
logger
you,
you
start
generating
log
records
right
and
then,
when
you
try
to
obtain
a
logger,
usually
the
logging
libraries
ask
you
to
provide
a
name
for
the
logger,
which
is
which
is
an
identifier
for
that
for
for
the
logger,
and
if
you
obtain
it
more
than
once
you
get
using
the
same
name,
you
get
the
same
instance
of
a
logger.
B
One
of
the
proposals
that
I
made
was
that
the
logger
name
is
actually
a
field
in
the
log
record.
We
just
record
that
there
right
the
name
becomes
part
of
the
the
every
log
record
and
the
alternate.
I
believe
if
I
understood
that
correctly,
that
program
suggested
it
was
that
no,
we
don't
need
that
because
we
have
the
instrumentation
library
name.
That
is
already
part
of
the
data
model
that
we
already
meet.
We
have
in
the
protocol
and
we
do
that.
So
the
argument,
I
guess,
was
also
that
we
do
that.
B
B
B
It
is
quite
common
to
use,
for
example,
class
names
as
longer
names
in
java,
for
example,
and
you
usually
pass
the
class
name
there
and
that's
not
an
instrumentation
library,
that's
actually
a
class
name
so
and
also
the
logging
libraries
typically
don't
define
what
you
put
in
the
logger
name.
It's
it's
a
free
format,
thing
usually
perhaps
hierarchical
in
some
way
where
you
can
do
filtering
based
on
that,
but
usually
it's
not
limited
to
the
name
of
the
library,
and
often
it
is
not
often
it
is
some
other.
B
The
kind
of
construct,
logical
element
of
your
source
code
of
your
code
base
that
you
would
like
to
combine
the
log
records
based
on
on
that
single
thing
right.
So
that's
the
context.
The
question
is:
what
do
we
do
about
this
I'd
like
to
know
what
people
think
about
this?
B
B
Right,
that's
that's
a
good
question
if
we
don't
put
the
logo
name,
what
goes
there
right
and
I
guess
there
is.
There
is
one
possible
reasonable
choice
there.
If
we
are
going
with
the
logging
sdk
approach
like
like
we
proposed
for
open,
telemetry
logging,
then
you
have
the
appender
implemented,
for
example,
for
log4j,
and
you
are
doing
all
your
logging
through
log4j,
then
the
instrumentation
library,
possibly
is
log4j.
E
Sorry
one
last
comment
that
is
part
of
the
resource
we
have
library,
name
and
stuff
in
the
resource
and
the
log4g
will
be
in
the
resource.
B
E
E
E
E
F
B
B
G
So
the
name
of
the
class
that
implements
the
appender
is
called
open.
Telemetry
appender
and
I
put
in
the
name
of
that
in
the
instrumentation
library
name.
Yes,.
B
B
E
Right
yeah,
but
I
don't
think
that's
reasonable,
because
let
me
explain
something
if,
if
you
instrument,
so
if
you
instrument
a
producer
of
telemetry,
is
different
than
sorry,
if
you
instrument
the
source
of
telemetry
is
different
than
if
you
instrument
the
producer
of
the
element.
E
B
E
B
B
G
Yeah,
I
think
I
say
what
bogdan
is
where
bogdan
is
coming
from.
So
you
know,
in
this
case
of
log
for
j,
the
logger
is
essentially
akin
to
a
tracer
or
meter
in
the
metrics
and
trace
apis
and
so
in
the
metrics
and
trace
apis.
The
name
that
you
assigned
to
the
meter
or
the
tracer
ends
up
in
the
instrumentation
name,
and
so
you
know
for
symmetry
shown
at
the
name
that
you
assigned
to
the
logger.
You
know
log
for
j's.
Api
is
a
stand-in
for
open
telemetry,
not
having
a
log
api.
B
Exactly
that's
that's
the
argument.
The
question
now
is:
can
that
be
the
instrumentation
library
name,
because
it's
explicitly
the
name
of
the
instrumentation
library,
but
the
logger
names
are
not
limited
to
that.
They
can
be
other
things,
they
can
be
class
names,
they
can
be
arbitrary
strings
that
describe
a
feature
or
a
module
or
a
package
or
another
logical
unit
of
thing
in
inside
your
code
base
right
and
we
put
that
thing
inside
the
name
of
something
that
is
explicitly
called
instrumentation
library.
E
B
E
B
E
Right
and
later
you
may
want
to
do
filter
a
day
scope
or
whatever
you
want
to
do.
Some
certain
information
is
based
on
that
name
like
there
was
a
use
case
at
one
point
to
say,
be
able
to
have
a
sampler,
for
example,
for
traces
that
does
not
create
spans
for
this
specific
name,
because,
whatever
reason
so
it
was
a
connection
between
the
code
and
the
in
the
tracer.
B
Right
right
right,
I
think
I
I
think
that
was
the
intent
now.
Unfortunately,
we
have
this
situation
when
that
thing
is
actually
called
instrumentation
library.
So
do
we
think
that
this
will
not
cause
more
confusion?
If
we
actually
put
the
logger
name
in
the
instrumentation
library
name
is
we
is
it?
I
don't
think
we
can
at
this
point,
rename
the
concept
of
instrumentation
library
to
something
else.
It's
probably
too
late
right.
It's
everywhere
like
it's
not
going
to
fly
at
this
point,
it's
going
to
stay
instantiation
library.
E
That
so
unity,
so
yeah,
but
let's,
let's
think
about
instrumentation
library
as
a
name
when
you
are
instrumenting
a
class.
The
name
of
that
instrumentation
library
is
that
class.
So
if
you
are
creating
the
logo
per
class,
the
instrumentation
library
that
you
do
is
the
class
name.
If
you
are
using
a
logger
per
package.
That
is
the
same
thing
if
you
are
using
a
logger
per
grpc
per
library
across
multiple
packages,
multiple
classes,
then,
is
the
name
of
that
library.
So
I
still
don't
see
a
problem.
B
With
him
too
much
now,
the
the
problem
is
only
that
it
says
library
where
the
word
library
you,
you
probably
can't
argue
that
the
class
is
a
library
class
is
a
different
thing,
especially
it's
not
just
the
class.
It
can
be
anything
right.
It's
it's
very
common,
also
to
use
not
a
class
name,
but
something
else
like
a
feature.
I
have
a
feature,
and
I
want
logs
of
all
everything
that
is
related
to
that
feature
to
be
emitted
using
one
logger.
It
can
be
scattered
across
classes.
It
can
be
functions.
B
Maybe
I
don't
have
even
classes,
maybe
I'm
not
using
classes
at
all.
I
it's
it's
essentially
a
broader,
broader
type
right,
the
broader
domain
of
values
possible
for
the
logger
name.
Then
it
is
implied
by
the
name
of
the
thing
that
we're
using
you
know.
Instrumentation
library
is
a
narrower
concept
right,
it's
something
significantly
more
specific.
B
So
does
that
mean
that
we
are,
if
we
put
it
there,
do
we
make
a
clarification
in
the
specification
to
explain
the
intent
like
this
is
instrumentation
library,
but
you
put
other
things
there
as
well,
and
that's
that's
fine
you're
not
limited
to
just
that
and
I'm
guessing.
Similarly
for
traces
and
metrics
right,
you
shouldn't
probably
be
limited
just
to
instrumentation
libraries
there
as
well.
You
could
do
the
same
there.
B
I
So
when
between
logging
and
tracing
and
metrics,
the
way
we
have
it
today
is
that
spans
have
names
and
metrics
have
names.
So
if
statements
have
names,
I
think
we
could
couldn't
pass
this
discussion,
it
seems
like
a
long
name
is,
is
being
used
as
a
stand-in
name
statement
so
that
you
can
select
statements
from
a
compilation
unit
and
if
logs
had
names,
I
think
we
could
move
past
this.
B
I
There's
another
issue
for
that
as
well.
It
seems
like
the
way
people
are
using.
Logger
name
is
as
a
combination
of
instrumentation
library
and
statement,
name
and,
and
I
believe
we've
discussed
how
it
seems
that
people
want
to
use
these
hierarchically.
The
library
is
a
containment
container
of
a
bunch
of
classes
that
all
contain
log
statements,
and
since
we
don't
generally
have
an
api
to
name
the
log
statement,
we're
using
the
logger
name.
B
Do
you,
but
that
is
that
typical,
I
don't
think
well,
I
haven't
seen
such
a
use
case
for
for
using
the
logger
name
with
the
intent
of
naming
individual
statements.
They
they
typically
are
very
different
right.
You
get
a
logger
with
a
specific
name,
but
then
you
emit
a
bunch
of
log
statements
which
look
very
very
different.
Each!
E
B
H
In
in
go
something
similar
is
often
done
by
adding
context
to
a
logger
right,
you
draw
a
logger
from
another.
You
add
some
context
to
it,
so
that
you
know
in
this
portion
of
the
code.
Now
all
of
the
log
records
that
I
emit
have
some
identifier
for
the
portion
of
code
that
it's
in,
I
think,
that's
functionally
equivalent
to
a
logger
name.
At
least
it
sounds
like
I'm
hearing,
that's
what
a
logger
name
is
used
for
in
other
languages.
E
It's
kind
of
so
last
exercise
by
the
way
tigran
that
I
want
you
to
do
is
if
you
come
up
with
a
different
semantic
convention
for
logger
name.
Think
about
how
you're
gonna
design
the
api,
because
I
I
bet
that
the
api
will
look
very
similar
with
you
will
have
a
logger
provider
you'll,
have
it
get
by
name
or
whatever
you
take
say,
which
is
now
going
to
be
the
instrumentation
library
name,
because
you,
you
need
to
be
consistent
with
the
other
signals
and
then
you'll
have
another
way
to
specify
the
logarithmic
the
other
one.
B
B
I
I
think
I
disagree
with
bogdan's
statement
that
you
would
offer
an
api
that
looks
a
lot
like
the
provider
model
we
have
today.
I
I
feel
that
what
your?
What
is
that
your
names
have
hierarchy,
so
there
is
an
implementation
library
that
encapsulates
many
logger
names
and
if
you,
if
we
had
a
semantic
convention
for
the
syntax
of
the
actual
instrumentation
library,
we
could
say
this
is
the
instrumentation
library
name,
and
this
is
its
component
or
something
like
that.
I
It
seems
that
the
logger
name
contains
two
fields
to
me:
it's
the
package,
the
instrumentation
library
and
some
other
selector
that
you
described
lots
of
feature
selectors
like
within
this
instrumentation
library.
There's
features
I
can
sub
select
and
so
on.
So
I
think
you
would
end
up
with
an
interface
that
says,
give
me
your
entire
hierarchical
name,
which
is
rooted
at
an
instrumentation
library,
and
it
includes
more
features
or
more
sub-components.
B
So
it's
fairly
symmetrical
consistent
with
how
you
do
it
with
the
tracers
today
it
is
implemented
in
in
java
and
python
right
now,
so
we
have
prototype
implementations
as
well,
and
there
is
no
separate
logger
name
different
from
instrumentation
library
name
past
there.
We
could
change
that.
So
I
guess
we
could
do
that.
Nothing
prevents
us
from
doing
that,
but
I.
E
I
Tried
only
I
tried
to
answer
that,
because
log
statements
don't
generally
have
names,
there's
not
an
interface
that
is
standard,
that
every
one
of
us
knows
for
making
a
log
that
you
say
log.info
and
you
split
some
stuff
in
there.
I
want
log.name
my
name
to
log
statement
dot
info
so
that
I
can
select
my
name
log
statement.
I
can
turn
off
my
named
log
statement.
B
B
Correct
that's
different
right.
If
the
logging
apis
don't
have
that
that
practice,
then
you're
suggesting
that
you
get
an
entity
a
proxy
of
some
sort.
You
name
that
proxy
you
give
it
a
name,
and
then
everything
that
is
emitted
through
that
all
statements
get
that
name
right.
That's
what
you're
suggesting.
B
I
don't
disagree
with
you,
but
I
think
that's
a
separate
concern.
To
be
honest.
This
is
this
is
a
concern
about
scoping
your
log
records
by
some
logical
element
of
your
code
base,
which
is
the
logger
name,
is
in
in
the
logging
world.
That's
what
it
is.
You
scope
your
log
records
by
your
class
name
by
your
package,
name,
your
library
name
or
whatever,
whatever
you
choose
as
an
interesting
scope
for
a
set
of
different
log
statements,.
H
B
That's
that's
one
of
the
ways
you
scope
right.
A
log
level
is
usually
not
a
code
based
scope
right,
it's
not
associated
with
an
area
of
your
code
base
or
an
a
logical
unit
of
of
some
feature
in
in
your
application
right.
That's
how
logger
name
is
different,
for
example,
from
a
log
level,
but
you're
right.
Those
are.
There
are
many
dimensions
across
which
you
can
scope
the
log
records.
This
is
one
of
the
dimensions,
the
the
the
logical
unit
of
your
code
base.
B
B
It
is
something
that
is
useful
for
you
to
group
the
log
records
by
right,
but
there
is,
there
is
only
one.
The
logging
libraries
don't
provide
you
more
than
one
dimension
to
to
group
this.
There
is
the
built-in
ones
like
the
log
level.
Maybe
there
are
others,
but-
and
that
is
one
that
you
choose
yourself.
B
There
is
additional
functionality
that
comes
with
that
usually
so
the
filtering
typically
allows
you
to
specify
some
sort
of
sort
of
hierarchical
filters
where
you
or
you
can
have
a
dot
notation
for
the
for
the
logger
names,
but
that's
that's
kind
of
incidental,
I
would
say
in
a
sense
right.
The
important
part
here
is
that
it
is
a
scoping
concept
for
a
set
of
statements
which
you
would
like,
as
an
application
developer,
to
combine
together
in
some
way
later
to
be
able
to
query
to
to
filter
on
using
that
name
now.
B
I
think
that
fits
in
a
sense
very
nicely
with
the
original
idea
beyond
the
instrumentation
library,
which
was
even
called
components.
Initially,
we
lost
that
at
some
point,
and-
and
now
I
have
this
this-
this
problem
of
trying
to
reconcile
that
with
how.
How
does
the
logger
name
work
with
this?
That's
that's
the
problem
that
I
have.
I
I
just
feel
like
you
couldn't
you
could
imagine
every
one
of
these
problems
happening
in
a
tracing
api,
so
I
want
to
group
my
spans
and
then
so
I
have
no
way
to
do
that.
So
I
put
them
in
an
instrumentation
library
and
then
I
start
using
prefix
names
like
a
slash
b
is
one
span
and
a
slash
c
is
another
span,
and
now
I
have
a
prefix
name,
a
slash
that
I
can
query
on
and
it
seems
like
in
the
logging
interface.
I
What
we're
doing
is
saying
never
mind
all
that
we're
gonna
have
a
logger
name
which
consists
of
instrumentation
library
and
prefix,
and
now
any
statement
that
you
make
automatically
gets
the
prefix,
which
is
not
the
same
as
the
instrumentation
library,
and
I
I
mean
that's
how
I
see
it.
I'm
not
saying
we
should
do
it,
but
I
do
feel
that
if,
if
there
was
a
practice
of
using
logger
names,
you
know
go
back
25
years,
we
might
not
have
logger
name,
we
might
have
statement
name.
B
B
That's
that's
very
typical
if
you're
doing,
if
you're
writing
an
instrumenting
library
for
some
other
instrumented
library,
but
that's
not
the
only
use
case
for
a
tracer
right.
If
I'm
writing
a
first
class
like
like
an
application
without
libraries,
I
want
to
get
tracers
for
parts
of
my
code
base.
What
do
I
name
the
tracers
then.
E
Yeah
that
that's
exactly
the
reason
one
of
the
problem
was
we
designed
this
from
from
the
idea
that
we'll
always
instrument
other
libraries
instead
of,
if
us
being
the
writers
that
will
will
write
the
code.
With
this
thing,
that's
not.
H
Name
that
I
give
it
is
the
name
of
the
package
that
is
being
instrumented.
The
instrument,
instrumented
library
and
instrumentation
library
then
becomes
the
same
in
that
case,
but
I've
still
got
a
package
name,
and
you
know
I'm
I'm
in
go.
So
everything
has
a
package
name,
there's
always
a
package
name
that
you
can
use
to
refer
to
the
thing
that
you're
instrumenting.
B
So
you
use
the
ghost
package
name
as
the
instrumentation
library
name
to
obtain
a
tracer
right.
That's
what
you
did.
Yes,
yes
and
that's
a
package
name
to
let,
let's
be
very
clear:
that's
not
a
library
name!
Maybe
your
entire
library
is
composed
of
multiple
packages,
but
you
used
the
one
package
name
to
obtain
the
tracer
for
the
instrumented
code
that
you
used
inside
that
package
right
and
you
could
probably
equally
well
use
whatever
the
the
structure
name,
the
object
name
or
whatever
something
else
to
obtain
a
tracer.
B
If
you're
writing
instrumenting
code
in
your
application,
you're,
not
writing
a
library,
you're
writing
an
application
right.
This
is
my
application
source
code,
I'm
getting
a
tracer.
I
need
a
name
for
that
tracer.
What
do
I
put
there?
My
application
name
or
maybe
a
class
name?
I
think
we
allow
this.
Then
we
solve
the
problem
with
the
logger
as
well.
Then
it
becomes
completely
consistent
and
uniform.
B
You
put
typically
the
instrumentation
library
name,
but
it
can
be
something
else
as
well
right.
The
package
name
the
class
name,
and
we
allow
that
not
just
for
the
logs,
but
for
traces
and
metrics.
As
well,
I
do
not
know
if
there
is
any
problem
as
a
result
of
that,
but
if
we
try
to
do
that,
what's
what's
the
implications
like?
Is
there
a
problem?
I
think
no,
and
it
would
solve
my
problem
as
well
with
the
loaders.
H
Perhaps
there's
a
disconnect
in
the
concept
of
library
here
then,
because
I
view
library
and
packages
being
synonymous
right,
you
may
have
a
collection
of
libraries.
That
is,
you
know,
a
meta
library.
You
know
a
thing
that
has
a
larger
name
for
it,
but
each
package
can
go
to
me
as
a
library
and
very
rarely
do.
I
actually
create
a
tracer
for
the
main
package
right
because
you're
not
tracing
the
main
application,
vacation,
you're,
tracing
requests
or
processing
of
data
that
flows
through
and
those
all
do
flow
through
some
sub
library.
B
Right,
I
I
I
agree
with
you
especially
in
this
context.
I
think
that's.
That
was
the
intent
at
least
right,
but
if,
if
that
is
true,
could
you
stretch
that
a
bit
more
and
say
that
it's
not
just
library
name,
not
just
package
name
but
any
unit
of
code
or
any
logical
concept
right
could
be
used
as
the
name
of
the
logger
as
the
name
of
the
tracer
or
the
name
of
the
meter?
H
Of
course,
the
thing
that's
important
to
me
about
a
package
name,
though,
is
that
it
it
allows
me
to
identify
the
code
that
generated
and
go
directly
to
that
code.
If
you
can
have
arbitrary
names,
if
I
can
call
my
instrumentation
library
foo
that
isn't
identifying
of
anything
to
me,
I
don't
know
what
foo
is,
and
I
don't
know
how
to
go,
find
the
thing
that
generated
foo.
C
So
I
have
just
a
question
to
kind
of
aid
in
this.
I
know
we
can't
really
rename
things
at
this
point.
Most
of
this
is
stable,
but
would
it
be
better
understood
of
instead
of
instrumentation
library,
we
called
that
instrumentation
scope
and
would
that
all
have
just
solved
this
and
I
think
yeah.
C
If
that
was
the
case
like.
Could
we
have
some
kind
of
just
clarifying
notes
somewhere,
probably
everywhere
that
says?
Yes,
this
is
called
instrumentation
library.
We
are
beholden
to
that
name
because
of
our
stability
requirements,
but
think
of
this
as
just
the
scope
of
what
the
instrumentation
covers
and
then
it
it
would
fall
out
that,
like
instrumentation
scope
name
is
the
name
of
whatever
scope.
C
It
is
so
even
if
to
anthony's
point,
even
if
they
did
call
it
foo,
there's
probably
only
one
thing:
creating
the
foo,
instrumentation
scope
and
whatever
is
consumed
in
that
scope.
You
would
go
find
that
named
foo
scope
that
wouldn't
be
helpful
for
in
consumers,
but
it
would
mean
that
you
have
to
kind
of
dig
in
for
that.
C
But
you
know
the
intent
would
be
the
instrumentation
library
that
created
this
span
or
log
or
or
or
or
the
part
of
the
application
that
created
this
same
span
or
log
or
metric
all
is
encapsulated
in
the
instrumentation
library,
scope,
name.
E
Yeah
also
also,
I
think,
the
using
of
package
or
or
class
name
or
something
like
that-
is
a
recommendation
from
us.
We
we
we
don't
have
in
place
right
now.
We
don't
have
any
guard
of
somebody
just
using
foo
for
the
tracer
name,
for
example,
and
that
doesn't
mean
anything
and
user
can
still
use
that
because
it's
a
string
there,
it's
not
a
it's,
not
a
language
stack
trace
package,
something
that
we
check
or
anything
it's
just
as
simple
as
a
string.
E
It's
a
recommendation
that
comes
from
us
that
you
should
use
something
that
is
connected
with
the
code.
J
B
J
B
Okay,
so
am
I
hearing
it
correctly
that
we
are
okay
with
making
this
clarification,
not
just
for
the
logger,
but
even
for
the
tracer
name
and
meter,
name
that,
yes,
it's
named
historically
an
instrumentation
library,
but
the
intent
is
that
you
capture
the
the
scope.
I
think
the
scope
is
a
good
word
there
right
of
the
instrumentation,
and
then
we
make
a
recommendation
that
use
a
fully
qualified
name,
etc.
It's
a
tragedy
to
make
sure
it's.
It's
unique.
It's
possible
already.
E
E
The
instrumentation
library
yeah,
so
if
a
proposal
to
change
that
to
instrumentation
scope
would
be
accepted,
can
we,
for
example,
change
the
protos?
Probably
yes,.
E
B
H
I
think
if
we
do
that,
there
needs
to
be
a
strong
recommendation,
that
the
scope
name
be
identifying
of
the
thing
that's
produced
in
the
telemetry.
There
should
be
a
way
to
go
from
that
and
say:
okay,
I
know
where
that's
coming
from,
especially
as
more
and
more
things
start
to
instrument
with
open
telemetry
and
the
instrumented
library
and
instrumenting
instrumenting
library
become
the
same.
E
E
My
point
is:
we
already
have
that
to
be
named
with
the
package
from
the
from
the
library
and
stuff
like
that,
but
we
can
revisit
to
be
more
more
strong,
more
strong
and
more
clear.
If
that's
not
the
case,.
B
Okay,
we
have
maintainers
here,
what's
the
feeling
about
actually
renaming
instrumentation
library
to,
for
example,
instrumentation
scope?
Is
that
going
to
be
a
breaking
change
in
the
api?
Do
we
expose
the
instrumentation
library
as
a
symbol
somewhere
in
the
api?
I
think
it's
get
tracer.
It's
an
argument
to
get
tracer
or
get
meter.
E
B
E
It's
in
the
sdk,
it's
in
the
implementation
exposed,
at
least
when
you,
when
you
in
the
exporter
on
the
exporting
part,
we
give
you
the
instrumentation
library
to
do
whatever
you
you
want
to
do
with
that.
So
there
are
a
couple
of
places
in
the
sdk,
not
too
many,
but
there
are
a
couple
of
places
where
it
is
exposed.
I
think
another
one
is
in
the
sampler
we
pass.
E
We
pass
it
to
the
sampler
to
be
able
or
filter
or
whatever
you
call
it
in
logs
to
be
able
to
filter
or
or
do
something
decision
based
on
on
this.
B
Okay,
so
yeah
to
answer
your
question:
aaron.
B
B
Anybody
from
logging
seeing
against
this
if
we
go
go
with
this,
are
you
okay,
with
this
decision?
Who
do
we
have
from
logging
sig.
F
I'm
okay
with
it.
I
do
have
one
question:
perhaps
this
is
obvious
to
others,
but
just
going
back
to
the
log4j
example,
let's
say
that
open
telemetry
provides
a
custom
appender
which,
in
using
a
different
definition,
might
have
been
called
the
instrumentation
library.
F
E
B
F
Similar,
I
mean
look.
I
I'm
just
trying
to
discard
my
previous
conception
of
what
this
field
was
supposed
to
mean,
and
what
I
had
attributed
it
to
is
is
that
it
conveys
something
important
about
the
structure
of
the
signal,
and
so
even
with
just
log
for
j,
you
could
have
two
different
appenders
each
which
converts
the
signal
to
otlp,
but
in
a
different
way-
and
I
think
probably
you
know
toboggan's
point-
it's
probably
not
not
that
important,
but
I
want
to
put
this
put
this
out
there
in
case
anyone
else
from
the
log.
F
A
F
D
B
Yeah,
I
think
we
can
move
forward.
I
think
we
have
enough
to
to
make
progress
on
this,
at
least
right.
So
let
me
let
me
try
to
summarize
this
thing
summarize
this
offline,
and
we
can
continue
that.
I
think
we're
good
for
now.
D
K
It's
from
sirio,
so
the
question
is:
should
exemplar
be
enabled
by
default,
and
I
I
think
josh
surish
has
a
strong
opinion
that
it
should
be
undefault
and
the
the
thinking
is
in
open
telemetry.
We
try
to
give
people
the
correlated
things
across
different
pillars
of
observability
the
there.
There
are
multiple
folks
thinking
that
it
should
be
off
by
default.
They
were
more
coming
from
the
current
fact
that
most
of
the
metrics
backend
don't
have
exemplary
support
and
the
only
popular
one
seems
to
be
permissive
and
even
for
promises.
K
It
is
not
on
by
default.
Today
you
have
to
use
the
openmetric
protocol
and
enable
some
some
flag
on
the
premises
server.
So
this
is
why
we
briefly
discussed
last
week
and
and
most
of
the
folks
joining
that
meeting.
They
think
it
should
be
off
by
default,
but
job
storage
has
a
strong
belief.
It
should
be
owned
by
default.
So
you
can
see
some
conversation
here
and,
and
my
gut
feeling
is,
we
probably
need
more
opinions.
I
figure
we
don't
have
enough
people
joining
this
discussion.
K
K
That's
the
only
issue-
and
I
I
think
it's
important
if
we
don't
make
a
decision
now,
it's
going
to
block
the
the
sdk
spike
release
unless
we're
saying:
okay,
we're
going
to
mark
the
sdk
spec
as
stable,
with
the
exception
that
the
exemplar
part
will
be
marked
as
a
experimental.
So
it
will
be
a
mixed
state.
K
There
are
several
prs
I
won't
go
through
all
of
them,
but
just
quickly
mention
like
there's
one
pr
trying
to
rename
the
aggregation
type
from
non
to
job.
Just
for
clarity.
It
got
many
many
approvals,
so
I
think
it's
ready
to
be
merged
and.
K
I
have
another
pr
which
doesn't
change
the
real
content,
but
it's
trying
to
clarify
like
give
people
some
idea
about
how
they
can
implement
the
exporter
interface.
Clearly,
so
it's
not
adding
additional
requirements
just
trying
to
give
one
example
and-
and
I
need
more
approval-
currency
only
have
like
two
valid
approvals.
K
So
with
that,
I
I
have
a
pr
trying
to
list
the
requirements
that
I
I
found
during
the
prototype.
There's
some
interesting
things.
One
one
thing
I
want
to
get
feedback
from
this
group
is
so
far
most
of
the
people
when
they
talk
about
premises,
it's
possible
to
think
about
the
the
pool-based
exporter
only,
but
I
I
do
see
some
places
like
in
the
promises
official
web
page
they're
saying
if
you
have
a
short-lived
job
like
something
that
you
run
for
couple
seconds,
then
you
quit
then
pool
based
might
not
work.
K
So
I
have
a
proposal
here.
Just
want
to
get
feedback.
I
think
in
some
cases
people
may
want
a
push
mode
export
her
and
in
the
spec.
I
I
kind
of
try
to
allow
that.
But
the
question
is
in
this
case:
do
we
do
we
think
the
long
term
we
want
to?
We
want
to
encourage
people
saying
you
should
just
consider
using
the
otlp
push
mode
and
the
consequence
is
it
requires
you
to
have
the
open,
telemetry
collector
or
something
compatible.
So
if
you
have
a
permissive
gateway
existing
setup,
you
would
have
to
change
something.
K
And
then
there's
a
an
old
pr
about
how
do
we
handle
the
the
meter
name
and
the
library
version
in
the
premises
case?
So
so
basically,
otlp
will
allow
multiple
meters
with
this
different
name
to
coexist
in
premises.
We
don't
have
that
layer,
so
it's
very
similar
to
the
the
logger
name
or
something
like
tigran
mentioned,
so
in
premises
we
have
to.
K
We
have
to
convert
this
to
additional
dimension
and
the
suggestion
here
we
just
convert
the
thing
to
two
dimensions:
one
is
called
library,
another
one
is
called
version
or
something:
okay,
name
and
version.
So
I
I
do
this
and
I
have
a
big
concern
about
the
name
conflict.
The
the
only
complaint
I
have
is
those
names
are
are
too
common,
so
it
will
conflict
with
something
that
already
exists
in
the
user's
code.
My
suggestion
is
at
least
without
some
prefix
like
hotel
underscore
or
something.
E
I
I
think
we
should
stick
with
the
same
concept
that
we
have
in
yagar
and
zikin.
I
think
it's
all
tell
that
library
underscore
name
or
something
like
that.
You
can.
You
can
look
in
the
tracing
exporters
directory
there
is.
There
is
a
recommendation
for
these
fields
made
for
for
zipkin
and
jager,
and
I
think
we
should
stick
with
the
same
recommendation.
K
K
And
then
I
want
to
give
people
a
heads
up.
I
when
I
was
working
on
the
permissive
six
partner.
I
I
look
at
the
other
exporters.
I
think
all
the
other
exporters
are
ready
to
be
feature
freeze,
although
they
don't
mention
a
lot
of
things,
but
it's
pretty
straightforward.
So
I
was
in
the
pr
and
I
needed
help
to
review.
So
you
should
expect
a
pr
out
today
and
then
there's
another
pr
from.
I
I'd
advertise
that
briefly
for
him,
I
loved
his
otep.
It's
definitely
something
we
haven't
discussed
yet,
if
you're
familiar
with
the
prometheus
up
metric
and
you
think
we
should
do
something
similar
or
equivalent
in
open
telemetry.
This
is
the
discussion
that
you
should
join.
I
The
one
proposal
is
to
create
two
metrics
one
to
to
convey
up-ness
and
one
to
create
to
convey
how
long
you've
been
up,
and
actually
I've
got
a
proposal
I
want
others
to
think
about,
which
is
that
we
only
need
one
metric,
since
we
have
start
time
on
our
metrics
like
we
could
have
one
metric
that
conveys
up
and
start,
which
is
my
own
idea.
Please
join
that
discussion.
If
that
sounds
interesting
to
you,.
K
K
E
So
riley,
can
you
give
me
a
five
minute
summary
about
the
problem
between
push
and
pull
prometheus?
K
Go
ahead
riley,
so
the
the
push
model
allows
you
to
send
the
exact
same
tax
format
via
http,
post
and
and
you
don't
have
to
write
a
different
serializer.
It's
just
you
change
the
http
response
to
http
request
post
request.
All
the
content
should
remain
the
same
and
the
intention
is
to
allow
the
short-lived
batch
application.
This
is
what
permissive
has
I
don't.
I
know
I
know
the
intention.
I
know
the
intention,
so
the
protocol
is
the
same
based
tax.
E
Okay,
that's
good!
So
then,
then,
on
our
side.
What
do
we
need
to
change?
Do
we
not
have
enough
modules,
or
is
our
sdk
not
enough
modularized,
so
that
this
is
just
a
simple
configuration
change
of
a
component
instead
of
storing
cumulative
and
waiting
for
prometheus
to
storing
cumulative?
And
then
we
can
put
a
another
reader
of
this
component
that
does
temporary
pulling
of
these
and
push
things
or
something
like
that.
Whatever.
K
Okay,
so
it
is
a
fairly
simple
change
and-
and
you
don't
have
to
change
any
existing
api
or
public
interface.
Probably
you
can,
you
can
just
add
an
additional
feature
on
top
of
the
existing
export
or
you
can
even
decide
to
make
the
push
exporter
a
separate
thing,
and
you
can
even
see
I
I
didn't
even
put
a
shot.
K
I
was
saying:
may
support
push
mode.
I
think
each
language
has
their
flexibility
and
the
main
reason
is
I
look
at
the
problem.
Client,
it
doesn't
seem
all
the
languages
are
supporting
push
only
some
languages
and
also
to
answer
the
question
here.
The
pull
mode
think
about
the
javascript
running
inside
a
browser
or
some
environment
that
you
wouldn't
be
able
to
run
http
server
at
all.
The
only
viable
way
is
to
push
metric,
so
I
this
is
why
I
put
shoot
instead
of
a
mask.
B
The
set
of
the
settings
is
also
going
to
be
different
for
push
versus
tool
right
for
push.
You
also
need
the
destination
to
be
specified.
Maybe
also
do
you
do
compression?
Do
you
do
tls?
How
do
you
do
the
tls
portion
of
it
it's
different
from
when
you're
doing
a
pool,
which
is
exposing
a
port
you're
listening
locally,
which
has.
K
A
different
size
I
in
my
prototype-
I
actually
they
look
very
similar
like
for
the
for
the
pull
mode
I
even
see
like
in
premises.
It
allows
people
to
specify.
Do
you
enable
basic
authentication,
and
do
you
have
some
like
caching
algorithm?
So
if
another,
like
scripting,
happened
very
quickly,
then
you
just
report
the
previously
cached
value
and
also
the
tis,
so
just
think
about
all
of
them
are
http
whether
it's
a
request
or
response.
The
difference
is,
I.
B
B
I
Okay,
I
have
some
question
about
how
popular
this
is
in
the
prometheus
project.
I
I
wonder
if
we
asked
the
prometheus
developers
themselves
whether
they
would
endorse
this
because
it
doesn't
seem
like
it's
been
widely
adopted,
and
here
we
are
developing
our
own
push
protocol.
Do
we
really
need
to
push
protocols.
K
B
It's
not
about
short-lived
versus
long-lived,
it's
also
about
discoverability
and
ability
to
connect
to
to
that
particular
endpoint
to
pull
the
data.
I
had
an
exact
use
case
where
I
had
something
running
on
the
edge
behind
firewall,
to
which
you
could
not
connect,
which
needed
to
send
metrics
to
a
prometeus
backhand
running
somewhere
in
my
cloud.
I
had
that
like
a
couple
of
weeks
ago,
and
for
that
I
used,
I
used
prometheus
push,
it
worked
fine,
I
couldn't
use
prometheus
pool.
So
one
data
point
for
you
right.
I
have
this
exact
use
case.
B
I
I
I
used
collector
for
that
collector
has
a
remote
right
yeah,
so
I
didn't
need
that
to
be
done
from
the
sdk,
but
I
had
this
use
case.
I
don't
know
if
it
is
necessary
to
be
supported
in
the
sdk,
so
you
could
put
the
collector
there
as
an
engineer
and
do
that
using
the
collector
you
could
tool
using
prometheus
receiver
and
push
using
primitives
remote
right
exporter
in
the
collector.