►
From YouTube: 2021-12-08 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
C
C
Yeah,
it's
weird,
be
it
weird.
We.
B
C
C
A
All
right,
let's
start
so,
a
quick
update
on
the
logger
name,
so
we
we
looked
into
the
possibility
of
implementing
it
as
an
instrumentation
library
name.
It
is
possible.
There
may
be
some
probably
small
performance
impact,
but
it
was
doable.
I
guess
verified
it
for
java
and
python.
A
However,
the
second
step
that
we
wanted
to
do
was
to
try
to
rename
the
concept
of
instrumentation
library
to
instrumentation
scope,
which
failed,
because
it's
not
possible
to
do
in
a
way
that
is
not
a
breaking
change.
It
breaks
our
stability
guarantees.
I
think
if
so
that
means
that
we
keep
the
name.
We
keep
the
the
thing
called
instrumentation
library,
and
I
think
because
of
that
I
would
like
to
reassess
the
decision.
A
A
D
Yeah,
there's
no
material
difference
between
those
approaches
for
for
for
new
relic
is
like
a
back
end.
So
you
know
you
have
the
same
ability
to
filter
on
logs,
regardless
of
whether
it's
an
instrumentation
name
or
in
logger
name.
D
And
so
you
know,
if
there's
only
one
thing
to
group
under
because
there's
only
one
appender,
then
that's
much
cheaper
than
if
there's
hundreds
of
things.
A
A
E
Maybe
I
guess
go
ahead.
Sorry.
I
just
want
to
include
the
idea
of
component
that
we
that
we
had
discussed
right
like
in
this
conversation
at
least
right.
E
E
Do
we
think
that
the
other
signals
are
now
going
to
want
that
original
purpose
in
some
way
as
well?
Right
like?
Are
they
going
to
add
a
component
field
to
their
data
models
now
or
do
we
think
that
that's
a
possibility?
Because
if
so,
we
may
want
to
consider
adding
this
field
as
like
component
to
our
data
model,
and
then,
if
they
add
that
elsewhere,
we're
all
aligned,
we
don't
have
to
have
a
component
and
a
logger
name
in
our
data
model.
A
I
don't
know
if
there
is
any
appetite
for
introducing
the
component
as
a
concept.
I
didn't
see
a
lot
of
enthusiasm
from
in
the
room
when,
when
the
discussion
was
happening
and
and
introducing
that
certainly
does
require
some
energy
there,
it's
going
to
be
something
that
that
affects
a
lot
of
things
there
for
traces,
metrics
lots
of
existing
things.
A
I
don't
know,
maybe
yeah,
that's
a,
but
that's
a
good
point
anyway.
Maybe
I
can
try
to
open
an
issue
there
and
see
if
there
is
any
there
is
anyone
who
actually
wants
to
take
that
and
own
that,
because
it's
going
to
be
quite
complicated
and
I'm
not
sure
I
want
to
be
that
person
to
be
honest.
A
But
if
there
is
someone
who
wants
to
then
we
could
maybe
wait
a
bit
and
see
where
that
goes,
and
I
agree
with
you
if
that
actually
happens.
If
that
that
happens,
to
be
added
to
traces
and
metrics,
then
that
would
be
a
good
place
to
much
more
natural
place
to
put
the
logger
name
to
right,
because
that's
how
we
would
define
the
component,
the
the
the
site
that
meets
the
telemetry,
which
is,
which
is
what
the
logger
name
is
right.
A
E
Are
there
languages
where
logger
names
not
really
the
right
term
anyway,
right
where
like
like,
ultimately,
the
way
that
language
library
would
be
thinking
about
it
is
more.
Generic
like
just
component,
would
be
a
good
term
for
it,
because
if
so,
that
might
also
sort
of
support
this.
This
idea
any
case
I'm.
I
don't
really
feel
strongly
about
this.
A
E
A
A
Yeah,
but
it
depends
on
how
how
exactly
you
define
the
component,
how
far
you
want
to
go
with
that
right.
Do
you
I
don't
know:
does
that,
does
it
become
a
simple
field
in
traces
and
metrics
as
well,
or
that's
something
more
complicated
there
like
instrumentation
library
name,
is
not
a
regular
field
right,
it's
it's
something
that
introduced
a
hierarchy
of
data
could
component
also
result
in
something
like
that.
A
E
A
Yeah
then
I
mean:
if
we
open
that
discussion,
then
it
potentially
can
affect
the
logger
name
in
a
way.
That
is
not
just
the
name
of
the
field.
That's
that's
all
I'm
saying
so
we
do
that.
If
we
open
that
discussion,
I
don't
think
we
can
just
just
move
move
ahead
and
just
just
merge
logo
name
and
say
we're
done
with
that
and
whatever
is
the
component
name.
We
don't
care
about
that
right.
We
have
to
care
the
moment.
We
do
that.
F
It
seems
like
maybe
if,
if
we're
going
to
open
this
can
of
worms,
we
should
figure
out
a
couple
examples.
First
like
go
out
and
figure
out
something
that
does
this
and
kind
of
see.
If
it
see
if
we
would
need
something
new.
F
I
know
like
ruby
on
rails.
I
think
it's
ruby
on
rails.
One
of
the
frameworks
has
kind
of
like
a
front-end
back-end,
but
I
know
that
generally
they
they
reuse
logger
anyway.
E
Yeah,
I
I
my
only
you
well.
My
use
case
was
coming
from
the
fact
that
this
was
brought
up
in
the
first
place
in
the
context
of
traces
and
metrics,
and
I
I
don't
know
what
their
use
cases
were
exactly
so,
that's
primarily
where
I
was
coming
from
here
and
then
to
me,
and
then
there
was
the
other
side
of
it,
which
was
just
the
open
question.
And
I
don't
I
don't
know
the
answer,
but
are
there
languages
where
logger
naming
would
be
like
a
confusing
or
difficult
term
to
fit?
A
Question
so
I
think
there
are
logging
libraries
where
there
is
no
concept
of
logger
name
right.
I
think
zap
logger
is
like
that.
It's
no
longer
name,
you
can
add
a
field
and
call
it
a
logger
name,
but
it's
not
nothing
special
right,
it's
just
another
field,
so
I
guess
the
answer
is
yes,
but
in
that
case,
what
what
do
you
do?
You
just
put
that
as
a
oh,
you
don't
have
a
longer
name
right
that
that
remains
empty,
so
empty
value
is,
is
valid
value
for
that
field,
which
is
fine.
I
think.
E
It
doesn't
sound
like
there's
a
lot
of
enthusiasm
for
this.
I
don't
want
to
push
it.
I
don't
feel
strongly
about
it.
I
just
wanted
to
put
it
out
there,
so
I
don't
want
to
block
anything
here.
I'm
I'm
perfectly
happy
with
it
just
using
logger
name.
If
that's,
if
that's
what
the
consensus
is
here.
A
A
A
A
A
A
A
Okay,
so
maybe,
if
we're
good
with
this,
I
guess
one
other
small
thing
is
that
the
name
field
issue
is
now
resolved.
Thanks
check
for
submitting
that
clarification,
pr
we're
done
with
that.
The
issue
is
now
close
and
I
think
we're
now
down
to
two
issues.
One
is
the
logger
name
and
the
other
is
what
was
the
other
issue
that
is
remaining
yeah,
the
timestamps
right,
so
there
are
two
I
opened
two
pr's
one
one
is
to
clarify
the
existing
timestamp
and
the
other
is
to
add
the
observed
timestamp
both
are
approved.
A
A
A
A
A
Yes,
that
one
is
closed,
trace
flags
are
also,
if
I
remember
correctly.
Yes,
that's
closed
as
well,
so
the
only
one
from
the
last
one
last
time
is
the
cloud
logging.
Google
cloud
logging
prs,
but
that's
that's
so
that's,
okay!
I
I
will
whooping
google
folks
one
more
time.
This
is
not
blocking
us
in
any
way.
That's
more
like
a
clarification
in
the
examples.
C
C
One
topic
that
came
up
was
schema,
and
so
we
kind
of
felt
that
we
should
take
another
shot
at
that,
and
specifically
since
then,
some
folks
who
have
a
good
connection,
including
jonah
here
you
know
to
the
folks
at
elastic
that
are
in
charge
of
elastic
common
schema.
We've
had
them
on
here.
You
know
a
year
ago,
or
so
you
know
so
reached
out
and
want
to
kind
of
bring
that
discussion
back
and
see.
C
If,
in
an
ideal
world
we
can
maybe
get
elastic
to
you
know,
donate,
I
guess
elastic
common
schema
to
the
cncf,
so
governance
is
is
clear
and
then
see
at
the
same
time
also
see
whether
there's
consensus
here
that
that
that
would
be
a
possible
way
forward
for
us
to
kind
of
have
basically
a
standard
schema
right.
C
So
for
next
week
we
have,
I
think,
confirmation
from
elastic
folks,
they're
gonna
join
the
call,
there's
a
bunch
of
additional
folks
that
kind
of
got
added
on
that
email
thread,
including
morgan,
who
you
know,
and
a
bunch
of
folks
that
I
you
know
jonah
can
probably
highlight
that.
I
don't
actually
know
that.
Well,
you
know
abuelita
was
part
of
the
discussion
as
well.
I
think
all
of
you
know
her
like
leading
off
stability
at
aws,
so
in
short,
we
we
have.
C
We
can
have
that
conversation
both
in
terms
of
a
stereo
path
for
for
ecs
to
come
to
cncf
as
well
as
you
know,
more
generally,
what
are
people
thinking
outside
of
that
group
that
met
last
week
right?
You
know,
sort
of
almost
by
accident,
so
like
maybe
by
chance.
I
should
say
whether
there
is
whether
their
sport
consensus,
that
we
want
a
schema
right
and
then
that
obviously
also
opens
up.
You
know
paths
to
say:
hey
you
know
hey.
C
You
know
I
feel
my
schema
is
better
than
the
acs
one
you
know
or
somebody
else,
and
then
that's
also
fair
game
right.
I
personally
feel
ecs
is
a
very
good
starting
point
that
I
was
somewhat
you
know.
I
did.
The
whole
scheme,
I
think,
is
something
that
I've
lived
through
a
bunch
of
times
and
but
I
was
actually
really
really
happy.
C
You
know
when
I,
when
I
ultimately
saw
what
they
presented
last
last
year
and
that's
kind
of
frankly
been
admired
in
the
back
of
my
head
to
see
whether
we
can
construct
something
we
found.
There's
a
couple,
people
that
had
that
stuck
in
their
backs
in
the
back
of
their
heads
as
well,
so
trying
to
construct
that.
B
B
No,
I
just
wanted
to
add
a
little.
A
little
thing
is
that
a
little
piece
of
it
is
that
with
tracing
and
matrix
we
obviously
can
define
the
schema
the
protocol,
because
we're
doing
all
the
instrumentation
with
logging
the
challenges
that
we
have
so
much
history
of
log
data
and
in
order
for
us
to
do
the
correlation
and
make
sense
of
the
data,
we
really
need
a
common
schema
and
that's
one
of
the
biggest
challenges
with
logging.
B
So,
even
though
we're
focused
on
logging
from
the
code-
that's
great,
but
there's
lots
of
other
log
data
that
we
have
to
deal
with
and
correlate
to,
and
that's
really
where
the
schema
is-
is
an
important
piece
that
I
think
is
missing
for
motel
and
it
would.
It
would
be
a
mistake
to
not
have
some
type
of
schema
in
hotel.
That's
all.
B
A
A
So
they
have,
let's
say
this
concept
of
host
right:
they
define
how
you
record
the
host
name.
Sure
now,
if,
let's
say
hypothetically,
we
adopt
that
for
the
logs.
Now
you
have
two
different
ways
to
record
the
the
hostname
right
for
logs.
You
use
one
approach
and
for
traces
you
use
another,
which
I
don't
think
would
be
right
to
do.
A
C
C
C
I
think
the
most
the
most
obvious
initial
attach
point
is
with
this
group,
but
I,
but
I
all
the
points
you're
making
tigran
are
very
valid.
I
I
still
feel
that
you
know.
If
we
go
straight
to
speculate,
we
might
might
just
aim
too
high
that
they
might
just
them,
which
might
be
just
very
tricky,
to
were
like
four
levels.
Deep
in
the
chest
was
just
moved
three
at
that
point,.
A
C
For
logs
sorry,
I'm
off
with
probably
not
entirely
clear,
I
didn't
mean
to
say
that
we
shouldn't
consider
doing
that.
I
just
wouldn't
start
there.
I
would
probably
first
you
know
like
this
is
ultimately
meant
for
logging.
You
know
this
is
the
group
of
people
who
have
probably
you
know
the
most.
You
know
interesting
background
and
looking
you.
D
C
We
I
would
start
here
and
and
see
what
like,
what
the
sense
is
right
outside
of
whether
or
not
it
can
be.
You
know
which
one
is
the
right
one
and
you
know
what's
the
governance
and
all
of
that
right.
It
does
remind
me
a
lot
of
you
know
lots
of
recent
discussions
that
we've
had
like
around.
Like
you
all
remember
this
right
well,
but
I
have
a
structured
thing:
how
the
was
supposed
to
sort
of
represent
this
right
and
and
and
we
didn't
really
have
a
ton
of
good
answers
there
other
than
well.
C
That
would
be
great
now
to
your
point
about
conceptual
overlap.
I
do
remember
that
that
was
brought
up
last
time.
Also,
it
is
intuitive
to
me
that
there
might
have
to
be
some
harmonization
between
concepts
that
are
already
expressed
to
semantic
conventions
which,
with
my
you
know,
still
somewhat
limited
view
I
feel
are
more
about,
like
especially
about
resources
and
where
the
time
where
the
hell
is
the
law
coming
from
right.
C
Time
to
evolve
all
the
way
there
as
a
as
a
thing
right
and-
and
I
do
think
there
is
value
in
it.
Maybe
you
know
in
trying
to
accelerate
that
and
then
there
will
be
work
to
harmonize
you
know
if
we
get
past
that
initial
hurdle,
you
know
on
both
sides.
I
feel
right.
I
cannot.
I
cannot
really
intelligently
speak
to
your
concern
about
what
does
it
mean
for
all
of
open,
telemetry
and
because
I
just
don't
understand,
metrics
and-
and
you
know
you
know,
tracing.
B
Schemas
they
do
have
a
tracing
schema,
but
there's
no
metric
schema
in
ecs,
so
I
mean
we
would
obviously
have
to
say
we
would
keep
the
hotel
tracing
schema
because
that's
already
ga
there's
no
there's
no
reason
to
replace
it
per
se.
But
I
think
that
this
provides
a
lot
more
depth
than
you
know.
What
we
have
today.
A
So
are
we
are
we
thinking
about
using
ecs
as
a
source
of
inspiration
and
borrowing
ideas,
or
is
it
more
about
adopting
it
exactly,
as
is
because
this?
These
are
different
approaches
right
when
you
adopt
it
exactly,
then
you
can
claim
some
sort
of
compatibility
on
data
level
and
if
not,
then
it's
just
an
inspiration
source
right.
That's
very
good!
I
mean.
B
I
would
like
elastic
to
agree
to
to
donate
this
to
the
to
the
open,
telemetry
group
and
then
essentially
they
would
contribute
upstream
to
modifications
to
it.
But
the
idea
is
to
have
a
common
schema
that
everyone's
using
not
have
a
fork
of
a
schema
yeah
that
becomes
like
another
fragmented
thing
and
so.
A
B
To
be
exactly,
I
mean
we
would
obviously
change
a
few
things
in
it,
I
think,
but
we
would
have
to
discuss
especially
around
tracing.
I
think
that's
where
some
of
the
conflict
is,
and
also
some
of
the
new
things
that
we've
been
talking
about
around
real
user
monitoring.
B
I
know
that
the
aws
team
was
looking
at
building
a
schema
for
real
user
monitoring
and
the
result
of
that
discussion
tigram
that
you
probably
remember
that
was
happening
which
one
sorry
well
alolita
and
the
aws
team
was
in
trying
to
introduce
a
real
user
monitoring,
schema
yeah
yeah.
If
you
recall
that,
and
that
a
lot
of
that
is
actually
covered
in
the
ecs
already
okay,
so,
okay,
it
solves
a
lot
of
things
that
are
going
to
keep
coming
up
because
someone's
going
to
come
here
and
say
we
have
network
data.
B
Oh
look,
there's
no
schema
for
network
data.
What
are
we
going
to
do?
How
do
we
describe
a
network?
Oh
that's
an
ecs
already,
so
it
solves
a
lot
of
things
like
before.
We
otherwise
there's
going
to
be
a
hundred
discussions
about
different
data
sets
that
are
going
to
start
to
be
part
of
hotel
and
for
those
that
are
interested
in
the
chat.
I
just
pasted
the
field
reference
and
you
can
move
around
the
documentation,
but
ecs
is
already
apache
too.
B
B
Or
I
would
like
to
propose
exactly
what
I
said:
if
that
makes
sense,
is
that
we
have
to
get
consensus,
but
do
we
want
to
have
elastic
donate
this
to
open
telemetry,
and
everyone
contributes
to
a
common
schema
that
becomes
the
open,
telemetry
common
schema,
and
that
becomes
the
foundation
for
a
lot
of
the
different
data
that
we're
dealing
with
it's
more
applicable
to
logging.
But
obviously
I
think
it
you
know
it
applies
to
tracing
somewhat
too
metrics.
B
A
A
B
C
So
the
sequencing
here
is
tricky
right.
I
think
we
need
to
there's
basically
a
bunch
of
hypotheticals,
a
bunch
of
technical
hypotheticals
and
there's
a
bunch
of
business
hypotheticals
right
and
it's
not
clear
which
one
you
want.
Ideally,
you
would
try
to
sort
of
jump
into
both
at
the
same
time
right
because
it's
not
really
clear
with
otherwise
we
can
talk
all
day
about
how
we
would
do
it,
and
then
we
just
find
out
that
there's
absolutely
no
way
they
would
even
agree
to.
C
Right
and-
and
so,
but
I
do
feel
that
I
I
personally
would
like
to
suggest
and
also
you
know,
sign
up
to
spend.
You
know
time
as
needed
myself
that
if
we
go
try
to
like
play
with
both
of
those
and
see
whether
we
can
land
somewhere,
because
I
think
the
lift
would
be
pretty
pretty
dramatically
sort
of
it
would
be
automatically
if
they
will
benefit
us
all.
And
so
one
last
thing
I
want
to
say
ecs
seems
to
be
the
closest
thing
to
something
that
we
might
be
almost
wholesale
import.
D
C
Right,
your
ecs
is
already
open
source,
it
seems
pretty
reasonable
seems
like
a
potentially
chromatic
pragmatic
solution.
I
have
no
particular
preference
for
any
vendor
per
se.
I
don't
think
that
this
you
know
which
one
is
coming
from
as
well
either
right.
You
know,
I
know
splunk
has
prior
art
in
this.
You
know,
I'm
sure
you
know
new
relic
has
prior
to
it.
I
know
we
have
prior
to
it
over
here
at
sumo.
C
C
Folks
would
feel
free
in
this
part
in
this,
in
this
discussion
to
also
sort
of
raise
your
hand
and
say
well,
you
know
I
got
something
you
know
why
don't
we
look
at
this
too?
So
this
is
not
necessarily
an
attempt
to
just
force
fit
elastic
because
right,
it
just
seems
like
it's
a
really.
I
think
joan,
and
I
agree
this
at
least
for
what
it's
worth.
That
is
a
good
starting
point.
That's
starting
point.
We
can
think
of
right
now.
C
A
Yeah
just
to
be
clear,
I
I
completely
understand
the
value,
I'm
absolutely
not
against
using
ecs
in
any
way.
I
just
see
technical
difficulties
here
because
of
the
existence
of
open,
telemetry
semantic
conventions.
If
they
didn't
exist,
this
would
be
probably
much
much
easier
to
do
if
we
can
find
how
to
solve
this.
This,
this
technical
difficulties
like
that
this
much
then
I
don't.
A
C
Yeah-
and
it
seems
like
like
overdue
time,
was
also,
I
think,
like
saying.
Okay,
why
don't
we
like
punt
it
to
like
you
know,
2024
is
is
probably
also
it's.
You
know.
The
logging
thing
is
still
not
quite
there
yet
in
terms
of
it's
it's
like
ga,
etc,
blah
blah
blah.
So
if
we
can
actually
somehow
figure
out
how
to
do
this
reasonably
swiftly
and
get
it
in
there
before
the
or
like
official
big
reveal
right,
then
that
would
be
really
cool.
C
A
Okay,
so
I
guess
let's:
let's
have
that
discussion
next
week-
is
there
going
to
be
a
presentation
from
elastic
faults?
Are
they
just
coming
to
have
a
discussion?
What's
not
just
what
do
we
expect
to
happen.
A
B
Yeah
in
the
room
right
yeah
and
the
vp
that
owns
that
at
elastic
who
I
talked
to,
she
isn't
going
to
make
it,
but
two
of
her
pms
will
be
on
the
call
and
I'm
also
including
the
pm
one
of
the
pms
at
aws
open
search,
and
they
want
the
same
thing.
So
the
idea
is,
there
are
more
people
that
want
a
common
schema
to
be
in
the
open,
telemetry
world
and
not
different
vendors
implementing
different
schemas,
which
is
the
way
we
do
logging.
B
Today
I
can
tell
you
we
have
like
three
different
schemas
in
our
product.
Ecs
is
one
of
them,
and
probably
anyone
that's
doing
logs
has
different
schemas
and
different
things
that
they
do,
and
you
know
I
think
it
makes
sense
for
us
to
try
to
standardize.