►
From YouTube: 2022-01-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
D
E
B
Okay,
we
can
get
started
so
the
one,
so
I'm
slowly
getting
back
into
the
swing
of
things,
and
the
only
thing
that
I
have
on
the
agenda
that
I
wanted
to
bring
up
is
I
I
I
attended
the
specs
specs
meeting
like
the
middle
of
december.
B
I
was,
I
think,
december
15th,
and
there
was
a
long
discussion
about
events
and
logs
and
which
was
which
is
very,
you
know
relevant
to
us.
Obviously,
and
there
was,
I
think,
the
one
thing
that
was
brought
up
was
was
causality
and
you
know
the
maybe
the
one
idea
that
was
brought
up
was
well
what,
if
we,
instead
of
if
logs,
we
used
zero
duration
spans
for
for
client-side
events,
the
reasoning
being
that
that
would
automatic
automatically
give
us
causality.
B
So
we
could,
we
could
say,
like
this
event,
calls
to
this
other
event.
So
I
just
want
to
bring
it
up
to
this
group
and
see
what
you
guys
think.
So
I
think.
D
Yeah
there
was
actually
some
interesting,
so
I
can
never
remember
how
to
pronounce
his
name
but
sherman.
I
don't
know
how
to
pronounce
his
name,
I'm
terrible
with
eastern
european
names,
but
he
brought
up
a
really
interesting
idea
about
how
to
think
about
modeling
telemetry,
and
that
was
to
to
consider
the
relationship
of
a
given
atom
of
telemetry
to
the
other
telemetry.
D
D
Logs
do
not
have
any
of
that.
They
have
they're
just
a
point.
In
time
event,
you
can
attach
attributes
to
the
logs
that,
like
the
span
id
and
trace
id
that
have
an
implication
of
relationship
to
a
given
span
that
they
occurred
during
the
span.
D
The
the
signal
structure
that
exists
already,
and
if
it
fits
into
the
existing
signal
structure,
then
you
might
be
better
off
and
probably
be
better
off
using
that
existing
signal,
rather
than
trying
to
invent
a
new
one.
So,
for
example,
our
to
limit
our
events,
our
client-side
events,
which
I
think
might
also
might
or
might
not
apply
to
other
like
ebtf
events
and
things
like
that.
But
our
client-side
events
specifically
do
have
causality.
When
somebody
clicks
a
button,
it
can
result
directly
in
network
calls,
it
can
result
in
page
transitions.
D
It
can
result
in
these
things,
and
so
there
is
a
there
is
causality,
and
so
the
the
proposal
was
that
we
should
strongly
consider
using
the
span
model
because
it
has
the
built-in
causality
via
the
graph
structure
and
the
otlp
model.
The
open,
telemetry
data
model
already
does
support
zero
duration
spans
there's
no
requirement
that
they
have
a
non-zero
duration,
just
that
it's
not
negative,
and
so
this
was
kind
of
the
the
thought
that
this
that
the
it
was
a
very
small
group
and
with
kind
of
an
open
discussion
about
this.
A
I
think
we
want
to
understand
that
a
little
more
when
you
mention
that
this
fans
support
causality
is
that,
through
you
know,
like
multiple
spans
in
a
given.
C
Place
one
leader
together.
A
Sure
yeah,
I
I
think
I
understand
benefit
with
using
the
zero
division
spans.
It
can
give
us
a
facility
yeah.
I
think
the
at
the
same
time.
I
think
the
side
effects
are
that
they
do.
We
want
all
of
these
to
be
part
of
a
simple
trace.
A
There
is
a
binding
trace
corresponding
to
all
of
these
events.
Is
that
a
good
thing
or
a
bad
thing?
I'm
not
able
to
visualize
that.
D
I
guess
I
can't.
I
can't
imagine
why
it'd
be
a
bad
thing,
because,
because
it
connects
that
event
to
a
larger
context,
a
larger
sequence
of
other
events
and
other
spans
and
other
things
that
happen,
which
essentially
is
what
a
trace
is
right,
that
that's
a
trace.
It's
a
sequence
of
events
built
into
a
graph,
some
of
which
have
durations
on
which
don't
necessarily
have
to
have
duration.
F
What
john
described
essentially
is
from
one
rum
product
I
built
before
joining
splunk
was
indeed
reflecting
the
causality
that
was
triggered
by
a
user
interaction.
Typically,
click
on
a
button
or
something
with
all
the
subsequent
events
happen,
be
the
xml
http
requests
or
some
web
vital
events
or
dom
events
or
whatever
represented
as
a
trace.
So
there
was
a
causality
to
this
original
user
interaction
that
triggered
all
the
subsequent
events,
but
I
joined
few
minutes
late,
so
I
kind
of
trained
halfway
into
the
sentence
that
cuba
was
finishing
but
fitting
logs
into
this.
F
D
A
Logs,
so
even
in
rum
do
all
the
events
use
cases
fit
into
this
model,
or
are
there
any
situations
where
you
don't
need
causality.
D
That
doesn't,
I
think
this
is
an
excellent
ques,
excellent
question
and
one
at
least
in
the
kind
of
in
the
mobile
space
that
springs
to
mind.
I
guess
it
could
happen
in
the
web
space
too,
but
and
that's
the
network
change
like
if
you're
changing
from
a
mobile
network
to
a
wi-fi
network
or
you're
losing
your
network
altogether.
D
That's
certainly
an
event,
it's
a
point
in
time.
It
doesn't
have
a
duration,
at
least
as
far
as
I
can
tell,
there's
no
way
to
get
any
duration
out
of
it
and
it,
but
it
may
or
may
not
have
causal
effects.
D
I
suppose
it
I
mean
it
actually
can
have
causal
effects,
for
example,
at
least
in
android
you
can
the
user.
The
app
developer
can
react
to
a
change
in
the
network
and
do
things
to
it
and
like
make
network
like
if
the
network
becomes
available,
they
can
make
network
calls
at
that
time
to
do
whatever
synchronization
they
need
to
do
so.
I
think
even
those
cases
do
have
potential
causality,
even
if
they
don't
have
necessary
causality.
D
I
mean
it's
all
potential
value
right,
like
anyone
could
just
emit
an
event,
but
I
think
there
is
also
another
case
which
is
kind
of
this
business
event
idea,
which
is
like
the
there's
like.
If
they.
If
the
app
developer
wants
to
record,
then
a
checkout
is
finished
like
there's,
probably
nothing
causal
that
happens
after
that,
and
that
might
be
more
of
a
log
rather
than
as
iteration
span.
I'm
not
sure.
E
I
can
think
of
a
few
more
cases
where,
like
you
might
just
have,
let's
say
some
kind
of
a
method.
That's
running.
Let's
say
that's
updating!
You
know
a
time
on
your
page
or
something
like
that.
That
might
result
in
a
console
error
errors,
especially
like
in
browser
and
mobile,
tend
to
be
zero
duration.
Events
as
well,
especially
when,
like
the
because
the
causal
one
might
be-
and
I
don't
know
how
someone
can
figure
out
this
causality,
but
you
sent
out
some
http
event.
E
Oh,
so
you
sent
out
an
http
request,
you
got
a
null
response,
for
example,
which
also
resulted
in
an
app
error
that
could
be
the
causal
flow,
but
most
of
those
like
logging
of
errors
would
be
zero
event
spans.
In
that
case,.
D
D
D
B
D
Yeah-
and
my
guess
is
that
most
of
the
things
that
we
end
up
defining
will
end
up
being
zero
duration
spans
and
then
everything
else
will
just
be
logs.
Although
this
business
event
idea
is
one
that
I
haven't
haven't
fully
thought
through.
That
may
be
one
where
we
recommend
logs.
A
A
You
know
the
the
parent
child
relationship
in
terms
of
the
time
dimension,
you
know,
may
not
have
a
meaning.
D
But
I
think
in
open
telemetry
it
doesn't
anyway,
that's
already
that's
already
the
case.
There's
no
requirement
that
the
duration
of
a
parent
envelop,
the
duration
of
a
child,
that
there's,
certainly
that
is
not
definitely
not
a
requirement
in
many
cases,
especially
for
async,
already
isn't
the
case
for
normal
server-side
sync.
D
I
will
say
that
choosing
if
we
choose,
if
we
were
to
choose
zero
duration
spans
to
model
some,
some
subset
or
large
subset
of
the
events
that
we
want
to
admit
admit,
it
certainly
would
make
all
of
the
discussions
around
whether
we
need
a
name
on
the
log
like
the
log
data
model
like
the
log
entry
that
goes
away,
because
we
don't
care
about
it,
because
fans
have
names,
that's
kind
of
like
that's
one
big
advantage
of
it
was
we
don't
have
to
worry.
D
We
don't
have
to
have
that
argument
anymore,
because
fans
already
have
names,
so
we
can
just
use
them
and
the
thing-
and
maybe
this
is
actually
a
good
way
to
distinguish
between
what
we
would
think.
What
would
we
model
as
zero
duration
spans
versus
what
we
model
as
logs
and
then
it's
like?
Does
it
have
a
name
if
it
has
a
name
model?
It
is
a
zero
duration
span
that
might
be
a
here,
a
good
kind
of
heuristic
for
making
the
decision.
D
Well
in
that
case,
but
that
that
would
be
a
log,
though
not
an
event
right
like
if
you're,
if
it's
just
a
console
error,
that's
like
that's
just
a
log.
That's
not
really
something!
That's
that
we
model
as
an
event.
I
don't
think
like.
If
you'll
get
console
errors,
they
don't
have
names,
for
instance,.
B
B
F
Is
that
there
are
many
different
sources
for
the
errors
like
the
hand
you
might
have
unhandled
errors
or
or
errors
that
you
will
emit
as
as
con
by
a
con
directly
emitting
console
log
errors,
or
so.
D
B
Yeah,
I'm
still
not
I'd,
have
to
think
about
it.
I'm
still
not
fully
convinced,
because
I
think
the
like
the
counseling
out
an
error
is
like
the
effect
of
the
air
happening
like
if.
D
We
can
only
we
can
only
report,
one
of
those
things
right
like
we
don't
have
access.
We
only
have
access
to
one
of
those
things.
We
don't
have
like
any
kind
of
causal,
we're
not
going
to
be
reporting
both
the
fact
that
it
was
logged
and
the
thing
that
caused
the
thing
to
be
logged
right.
We
just
have
the
one
thing.
D
A
It
okay
is
also
confusing
to
think
how
one
would
start
a
trace
in
this.
In
this
you
know,
in
these
cases
let's
say
you
click
a
button
and
that
generates,
let's
say
an
error.
D
A
D
Wouldn't
that
just
happen
be
a
normal,
open,
telemetry
context,
internal
context,
propagation.
So
if
you
create
a
span,
you
you
put
it
in
the
current
context
and
then,
if
a
network
event
occurs
during
the
like,
when
that
span
is
active
or
when
that
span
is
in
the
context,
then
it
would
propagate
so,
but
there
is,
there
is
a
I
mean
I
think,
and
maybe
this
is
what
you're
getting
at
with
zero
duration.
D
You
have
to
make
sure
that
that
all
of
the
things
that
happen
as
a
result
have
that
context
available
so
that
it
can
propagate,
which
I
agree
is
something
I
haven't
100
thought
about,
but
I,
but
I
actually
built
this
into
the
android
instrumentation
for
splunk,
where,
even
though
the
dura,
even
though
the
span
of
zero
duration,
when
like,
for
example,
for
a
I'm
trying
to
think
of
a
good
example.
D
A
Even
the
semantics
of
how
a
trace
ends
is
easier
in
the
case
of
network
calls.
You
know
when
the
call
returns.
You
know,
that's
when
you
end
the
fans,
duration,
right
and
then
the
root
span
when
it's
it
gets.
The
final
call
back.
You
know
it
ends
itself
and
therefore
the
place
ends,
whereas
in
the
case
of
a
zero
duration,
it's
not
very
clear.
F
Which
gives
you
the
context
and
gives
you
the
possibility
to
say
when
the
trace,
whatever
the
trace,
means
in
the
browser?
It
doesn't
have
the
same
semantics
as
it
has
in
the
server
room
where
it's
clearly
nested
calls
with
non-zero
duration.
But
it
is
a
possibility
to
achieve
this
behavior
in
in
browser
world
at
least.
B
Yeah
it
may
be,
it
may
be
a
little
tricky
in
some
some
cases,
I'm
not
sure,
like
what
all
kind
of
different
events
we'll
we'll
be
capturing,
but
it's
like
for,
for,
like
the
network.
Call,
for
example,
like
it's
very
clear
that,
like
you
start
a
network
request
and
all
the
callbacks
you
know
associated
with
that
request
are
zoned
or
like
associated
together.
B
They
have
the
same
context
right,
but
if
you,
if
you
started
some
event,
that
has
zero
duration,
but
it
doesn't
have
any
callbacks
associated
as
an
api
like
which
which
con
like,
when
would
the
context
actually
be
associated
with
that
event,.
F
I
don't
know
I
don't
have
a
good
answer
again.
Can
I
just
say
that,
at
least
in
in
one
implementation,
I
have
implemented
it
via
building
the
zone,
setting
the
context
for
the
zone,
which
has
shares
the
same
trace
id
via
the
original
user
interaction.
Everything
that
followed
this
interaction
is
in
this
zone,
but
that's
definitely
one
only
one
way
to
think
of
it.
A
D
A
B
Okay,
we
have
one
more
topic:
pros
and
cons
between
attributes,
different
format,
attributes.
A
I
added
that
there,
I
think
in
one
of
the
tickets
jack
you
know,
suggested
that
we
use.
A
Slightly
more
qualified
attribute
names
for
the
run
events
rather
than
just
use
event
as
the
attribute
key
and
then
the
event
name.
As
the
attributes
value,
I
I
think
there
are
pros
and
cons
the
so
I
just
wanted
to
you
know,
get
some
thoughts.
I
think
the
I
I
mainly
wanted
a
way
to
I
mean
this
is
of
course
you
know
this
may
not
be
relevant
if
we
go
with
the
zero
duration
spans,
but
let's
discuss
anyways.
A
If
we
decide
to
use
log
records
for
events,
then
I
I
still
needed
a
mechanism
to
distinguish
between
logs
and
events,
and
one
way
would
be
to
look
for
an
attribute
called
event
and
and
then
that
you
know,
is
sufficient
to
put
them
into
a
different.
Let's
say
a
queue.
C
Or
back
in
question
like
an
event.
D
A
D
E
D
B
There's
I
don't
know
if
you've
seen
this
sometimes
but
there's
this
this
issue
that
has
a
long
discussion
around
this
topic,
I'm
going
to
put
it
in
the
in
the
chat,
yeah.
B
A
Name
required
right
in
in
log
requests.
D
B
Yeah
one
of
the
one
of
the
proposals
was
to
use
the
name
field
as,
like
the
the
type
of
the
you
know,
type
of
the
event
as
and
like.
If
it's
not
there,
then
it's
just
a
log,
but
I
think
I
think,
having
conventions
around
attributes
makes
more
sense
to
me.
D
I
mean
there's
the
conventions
around
attributes,
or
I
mean
the
other
option,
because
our
the
logging
data
model
was
so
flexible
is
we
could
use
a
structured
log
body
rather
than
using
attributes?
In
that
case,
like
that's,
we
could
define
a
specific
structure
for
the
log
body
for
events
that
could
be
could
be
used
as
an
alternative.
D
D
B
Sandwich
is
this
in
relation
to
the
old
app
you're
trying
to
write.
B
Okay,
so
I
think
we
can
resume
the
count.
The
discussion
about
the
zero
duration
spans
next
week.
I
think
that's
something
that
we
should
have
we
should
come.
You
know
we
should
have.
D
Do
we
have
a
way
to
record
causality
for
these
zero
duration
spans,
or
do
we
have
like
a
mechanism,
a
context-based
mechanism
that
we
could
use
to
record
that
causality?
Because
if
we
can't
even
record
the
causality,
then
it's
a
little
moved
like
there's,
no
reason
to
use
a
generation
span
if
we
can't
actually
have
causality
for
it.
B
Yeah
I
mean
that
this
might
be
maybe
good
good
to
like
put
together
some
prototype,
so
yeah
I
I
could
work
on.
I
could
put
something
together.
I
tried
to
put
something
together.
I
don't
know
if
I
can
do
it
within
a
week,
but
for
browser-
I
don't.
D
Actually
I
mean
I
don't
know
if
evo's
still
on
the
call,
but
you
know
this
would
be
a
really
good
thing
to
have.
Somebody
on
the
instrumentation
team
take
a
look
at
as
well
at
least
get
familiar
with
the
ideas
and
the
concepts.
D
I
think
we
still
have,
I
mean,
there's
still
the
big
open
issue
that
has
not
been
resolved,
not
necessarily
it
means
I
don't
know
how
much
of
it
is
in
our
court,
but
about
service
the
service
name
space
in
the
resource.
I
think
it's
going
to
take
some
quite
a
bit
of
time
to
get
that
resolved,
but
that's
still,
obviously
an
open
issue.
B
From
severine-
and
I
think
I've
we
talked
about
last
in
last
in
our
last
meeting-
talked
about
creating
a
separate
otep
for
the
app
attributes
which
is
on
my
to-do
list.
So
that's
on
my
that's
on
me
right
now,
cool.
B
Okay,
well
thanks
everyone
for
joining
happy
new
year
and
talk
to
you
next
week.
Thanks
folks,
see
ya.