►
From YouTube: 2021-09-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).
A
B
D
C
Yeah,
I
guess
we
can
get
started
so
welcome
everyone,
so
I
don't
actually
be
perfectly
honest.
I
don't
know
how
to
run
these
meetings.
I've
never
done
it
before.
So
maybe
we
can
just
get
started
by
introductions
and
maybe
just
saying
like
what
your
expectation
is
from
these
from
these
meetings.
C
So
I
can
get
started.
My
name
is
martin
cuba.
I
work
at
new
relic,
I'm
a
software
engineer
and
I
work
on
the
browser
monitoring
product
at
neuralic
and
we
we
would
like
to
so
we're
moving
everything
everything's
open
sourced.
We
would
like
to
move
our
browser
monitoring
to
hotel,
open
telemetry
as
well,
but
we
feel
like
there
is
there
is
we
need
to.
We
need
to
know
exactly
what
kind
of
signals
and
to
collect.
C
So
my
kind
of
hope
for
this,
for
these
meetings
is
to
standardize
the
way
we
collect
data
for
for
ram
scenarios,
use
cases.
E
I'm
looking
forward
to
get
the
open,
telemetry
data
models
and
semantic
conventions,
especially
not
so
much
about
sdk,
maybe
to
take
into
account
the
differences
that
we
encounter
in
the
in
the
client
side,
telemetry,
and
maybe
I'm
one
step
ahead
of
martin,
because
we
have
already
built
those
product
offerings
upon
open,
telemetry
and
have
already
touched
those
those
problems
with
our
own
fingers.
So
not
all
of
this
is
is
beautiful
at
the
moment
and
cannot
fully
upstream
everything
we
have
built
due
to
those
differences
and
cannot
fully
rely
on
semantic
conventions
for
those
purposes.
F
Okay,
next
hi,
my
name
is
morgan
maclean,
I'm
one
of
the
co-founders
of
the
open,
telemetry
community.
I
also
happen
to
work
at
splunk.
I
probably
won't
be
on
a
lot
of
these
calls
going
forward.
I
was
here
mostly
just
to
make
sure
the
first
one
gets
facilitated
well,
but
you
probably
won't
see
much
of
me
beyond
that
on
these
calls.
G
Let
me
go
next,
please!
My
name
is
stefan.
I
am
product
architect
at
steiner,
trees,
I'm
responsible
for
mobile
instrumentation
for
one
and
a
half
years
by
now
and
recently
took
over
also
the
javascript
part,
and
we
are
looking
to
integrate
open
telemetry.
So
the
ram
goes
into
our
product
as
first
class
citizen
and
I'm
hoping
to
get
forward
with
you.
H
I'll
go
next,
so
I'm
a
phone
so
coretti,
I'm
an
engineering
team
lead
at
datadog
currently
and
just
tuning
in
to
this
call
to
follow
the
developments
as
I
was
following.
Also
the
open
telemetry
project
and
the
rom
discussion
in
particular,
and
my
previous
turner
at
dynatrace,
with
stefan
hi.
Stefan.
H
D
Well,
I
guess
I
should
follow
in
suit,
I'm
also
a
datadog
with
stephanie
alfonso
I've
been
doing
a
roman
session
replay
previously
at
a
different
company,
and
now
I'm
at
datadog
and
big
fan
of
open
telemetry
I'd
love
to.
I
B
B
I
believe,
whatever
we're
talking
is
applicable
even
to
the
the
iot
devices
as
well.
J
K
I
I
think
everybody
said
something
so
hi.
This
is
severin,
I'm
with
santos
from
dynamics,
I'm
normally
with
the
javascript
group
for
open
telemetry.
So
there's
some
interest
from
my
set,
also
especially
on
the
browser
but
yeah
mobile.
Whatever
is
client-side
telemetry.
I'm
curious
about
that
and
that's
why
I'm
here
today.
C
C
Was
it
this
like
a
long
discussion
around
introducing
a
new
signal,
yeah
yeah,
so
I
guess
trying
to
figure
out
like
what
the
next
steps
would
be.
There's
something
there's
some
there's
some
arguments
for
adding
a
new
signal
kind
of
the
the
sense
that
I
got
from
some
of
the
feedback.
Most
of
the
feedback
was
that
it
was
going
to
be
difficult.
C
It
would
be
difficult
to
add
a
new
signal
and
then
most
people
would
prefer
to
use
the
existing
either
trades,
either
spans
in
traces
or
logs
and
introduce
like
semantic
conventions
on
top
of
that.
So
that
kind
of
the
general
consensus
or
kind
of
feeling
about
about
this.
F
I
I
would
generally
agree
like
from
my
experience.
Adding
a
new
signal
in
open
telemetry
is
challenging,
like
logs
is
obviously
started
at
a
later
time,
but
it's
still
very
early
on,
and
so
there's
there's
challenges
with
that.
But
beyond
that
I
would
actually
argue
for
I
would
question
what
new
signal
type
is
needed
to
express
rum
information
in
open
telemetry.
F
I
I,
like
I
said,
I'm
not
going
to
be
in
a
lot
of
these
calls,
but
just
my
opinion
is,
I
don't
know
of
any
scenarios
in
the
rum
space
that
can't
be
satisfied
with
traces
or
metrics
or
logs.
So
I
I
I'm
skeptical
that
we
need
a
new
type
of
signal.
But
then
again
perhaps
someone
experienced
here
knows
other
examples
like
when
I
think
of
like
in
like
a
year
or
two
from
now.
F
If
we're
adding
a
new
signal
to
open
telemetry,
probably
like
profiles
makes
sense
is
like
a
new
dedicated
thing,
but
I
don't
know
if
that's
something
that
we
would
necessarily
be
capturing
from
clients
immediately.
C
Yeah,
I
mean,
I
think,
some
of
the
the
arguments
like
for
adding
a
new
signal
was
to
around
more
like
a
streaming
streaming
environment
where
different
events,
as
they
happen,
they're
being
streamed
instances
they're
like
yeah,
because,
like
I
present,
it's
representing
certain
things
from
from
ram
as
spans
is
challenging
because,
because
you
know,
like
those
operations,
take
a
long
time
like
a
page
or
session
representing
those
as
spans
is
not
really
practical.
So
and
then
the
other
thing
is
things
like
user
interactions.
C
Events
like
clicks
or
things
like
that
should
they
be
represented,
as
you
know,
as
spans.
I
know
that
splunk
has
like
a
zero
span,
implementation
or
log
or
events
logs
kind
of
thing.
B
C
Yeah,
so
I'm
wondering
like
what
what
what
does
everyone
think
like?
We
should
be
the
next
steps
for
us
to
like
lead
this
discussion.
E
So
one
of
those
is
definitely
this
like
whether
we
need
a
new
signal
or
or
can
we
just
stick
with
changing
the
data
model
and
and
or
semantic
conventions
both
eventually
will
work,
it's
just
a
matter
of
preference
like
and
then
how
much
work
there
is
given
a
particular
path.
E
The
second
one
is
is:
what
kind
of
telemetry
do
we
aim
to
capture
in
a
sense
or
what
kind
of
product
offerings
this
should
should
take
into
account?
E
We
have
quite
a
few
people
here
who
work
with
real
user
monitoring
products,
and
there
was
at
least
one
session
replayer
interest
here,
but
I
wonder
if
this
goes
even
beyond
that,
like
different
kind
of
analytical
toolings,
like
user
journeys
stuff
like
this,
so
those
would
be
my
kind
of
questions
initially.
F
What
I
can
recommend
is
because
I
was
instrumental
in
the
creation
of
the
log
sig
and
was
running
that
for
a
while
of
tigran
would
be
if
you
want
to
follow
the
model
there.
We
looked
at
the
different
scenarios
that
we
wanted
to
tackle
initially
like
sort
of
classic
product
management
stuff
listed.
F
The
things
that
we
were
most
important
then
took
a
survey
of
existing
technologies
because
again,
open
telemetry
is
an
open
source
project
that
likes
to
play
well
with
other
ones,
and
so
we
looked
at
and
did
prototype
integrations
of
fluid
d
and
fluid
bid
and
explained
some
of
the
challenges
of
these
and
then
made
a
proposal
for
adding
a
new
signal,
type
and
new
components
to
open
telemetry.
So
not
just
the
signal
type
but
the
actual,
like
components
of
the
project.
F
Whereas
here
maybe
there
will
be
a
request
for
new
compound
new
signal
type,
but
they'll
definitely
be
a
request
for
new
components
and
and
listed
out
specific,
like
created
a
roadmap
for
what
we
wanted
to
do
and
along
alongside
this,
was
a
rationale
for
making
all
these
decisions,
and
so
I'd
probably
suggest
that,
for
this
group
would
be
just
like
creating
a
big
doc.
Basically,
that
lists
like
with
a
rum
sig
here
are
the
five.
F
You
know
two
to
ten
things
that
that
matter
to
us
the
most
prioritized
here's
a
prototype
of
us
trying
to
do
this
with
existing
open
telemetry
signals.
Here's
a
theoretical
prototype
of
us
trying
to
do
this
without
with
with
a
new
new
type
of
signal,
like
events
and
and
here
are
the
positives
and
the
negatives
of
each
and
and
so
no
matter
what
you're
definitely
gonna
be
proposing.
F
Used
in
theory,
I
mean
the
log
prototypes,
I
don't
think
were
really
used
in
production
by
anyone.
They
were
truly
prototypes
just
for
the
purposes
of
testing
things
in
the
case
of
logs.
A
lot
of
it
was
around
performance
and
packaging
for
including
fluentd,
which
is
written
in
ruby
with
the
collector.
F
In
this
case
there
may
be
other
reasons,
but
but
I
don't
think
anyone
ever
took
a
dependency
on
those
prototypes
because
they
were
prototypes
they're,
pretty
flaky.
They
achieved
their
purpose
for
a
design,
exercise
that
led
us
to
say
hey.
We
should
create
the
new
log
format
that
was
kind
of
expected
and
also
we'd
like
to
create
our
own
logging
agent
for
certain
scenarios,
but
also
play
well
with
existing
ones
and
and
so
in
addition
to
everything
I
described,
probably
worthwhile
doing
a
survey
if
there
are
any
open
source
rum
collection
packages.
F
I
don't
know,
take
a
look
at
those,
but-
and
that's
just
my
advice-
I
mean
it's.
K
I
mean
there
are
already
a
few
things
you
you
can
use,
so
I
mean
there's
an
implementation
in
javascript
for
the
browser
based
on
traces.
So
that's
definitely
something
to
look
at
one
prototype
I
built
because
of
that
is
a
browser
extension.
I'm
not
sure
if
everybody
is
aware
of
that,
so
it
is
a
browser
extension
that
you
can
then
put
open
telemetry
in
every
website
and
play
around
with
that
and
say
like
hey.
Let
me
do
a
journey
here
and
see
like
what's
working.
F
That's
a
good
point
where
I
don't
know
the
focus
on
this
call,
but
we
should
make
sure
that
the
people
who
work
on
opentelemetry.js
and
openslumptreeswift
are
involved,
because
I
I
mean,
I
presume
that's
going
to
be
where
a
lot
of
the
things
this
group
comes
comes
up
with
end
up
being
implemented
and
live
yeah,
and
so
I
know
some
of
the
js
contributors.
I
don't
know
the
swift
contributors
as
well.
I
believe
a
number
of
them
are
from
datadog.
C
Okay,
yeah
it'd,
be.
I
know
that
the
chairs
sig
is
happening
at
the
same
time
at
nine
nine
o'clock,
so
I'm
hoping
to
move
this
meeting
to
to
8
30.
So
we
can.
F
Yes
and
I
have
the
action
to
get
the
additional
zoom
accounts,
I
will
be
following
up
on
that
on
friday.
Okay,.
C
Yeah
great,
thank
you
so
as
far
as
building
prototypes
like
where
like
when
with
where
should
that
code
live.
F
For
logging,
I
believe
the
prototypes
were
just
people's
personal
repositories,
I'm
trying
to
remember
it
was
about
a
year
and
a
half
ago
I
think
they're
in
people's
personal
repos
for
the
most
part,
because
again
it
was
code
that
that
was
going
to
be
developed
and
then
thrown
away.
F
I
mean
you
could
put
it
in
a
folder
somewhere
in
one
of
them.
I
don't
think
really
matters
that
much
honestly,
okay,
okay,
got
it.
K
Step
would
be
to
say,
like
hey
use.
Cases
we
want
to
cover,
is,
I
don't
know,
browser
monitoring,
recession,
swiss
pages
mobile
monitoring,
xy
and
set?
I
mean
we
already
had
some
discussions
like
hey.
Also,
how
can
we
unify
those
things,
because
I
mean
there's,
maybe
a
few
concepts
like
a
session
that
is
yeah
reusable
all
over
them.
F
Will
the
doc
that
we
wrote
for
logging?
It
might
be
instructive,
there's
spread
across
three
and
I'll
put
them
in
the
agenda.
For
for
this
call.
C
C
F
Yeah
yeah,
so
so
there
aren't
really
any
docks
owned
by
otel,
so
to
speak,
all
the
docs
eventually
are
like.
Even
if
you
look
at
the
agenda,
I
think
it's
created
by
my
google
account.
We
don't
have
like
a
gotcha.
I
didn't
know
yeah
yeah.
Just
basically,
if
you
need
a
dog,
create
one
on
your
own,
make
sure
to
share
it
to
be
at
least
commentable
by
others.
Sure
and
then
add
the
people
need
to
be
there
as
editors
we've
yeah
other
than
that
yeah.
C
F
C
Yeah,
so
maybe
the
next
steps
are
we
can.
We
can
start
such
attack
and
is
everyone
in
the
slack
channel
the
client-side
slide
channel,
and
I
can
I
can
show
that
share
it.
There.
C
The
other
thing
that
I
was
wondering
is
since,
since
the
splunk
implementation
is
probably
the
furthest
along,
like
would
someone
from
splunk
be
willing
to
maybe
demo
it
or
like
talk
about
the
decision
decisions
that
went
behind
that
implementation.
E
E
The
ios
and
android
ones
are
are
relatively
early
in
their
in
their
in
their
development
site,
but
maybe
they're
conceptually
very
similar,
utilizing
tracing
spans
and
spans
to
represent
telemetry.
So
I
guess,
if
just
one
demo
would
be,
will
be
kind
of
enough.
I
For
browser
we
mostly
use
what
open
telemetry
gives
us,
which
is
there's
like
a
web
tracer
there's
some
document
load
plugin
and
some
things
about
causality
like
zone.js
and
stuff
like
that
and
for
events.
We
just
use
zero
duration
spans,
there's
nothing
about
the
error
collection
in
open,
telemetry,
probably
waiting
for
logs.
So
we
just
have
it
did
that
ourselves,
but
yeah.
We
mostly
use
open
telemetry
stuff.
I
So
I
would
just
suggest
everyone
takes
a
look
at
how
far
open
telemetry
is
and
imagine
that
you
have
logs
and
metrics
and
think
of
your
use
cases
like.
Can
you
already
do
that
with
the
open,
telemetry
stuff.
C
Yeah
I
mean
I
would
be
interested
like
in
why,
like
certain
data,
data
types
were
represented,
are
being
represented
as
like
zero
duration
spans,
as
opposed
to
logs,
like
what
was
this?
The
reason.
I
B
It
was
tracers
was
the
first
signal
that
was
officially
taken
up
right.
At
that
point,
I
think
the
metrics
and
logs
were
like
at
least
a
year
or
two
beyond
right.
What
was
the
thinking
about
vendors,
taking
up
implementations
on
those?
What
was
the
thought
process.
B
F
That's
a
good
question,
so
gen
and
I
don't
know
if
it's
necessarily
a
model.
We
want
to
follow
what
was
done
originally,
but
but
no
open
telemetry
only
started
being
really
used
in
in
services
by
vendors,
I'd
say
maybe
a
year
after
the
project's
creation,
because
I
mean
initially
when
we
announced
openslumptree
kubecon
there
was
there
was.
I
mean
it
was
just
an
announcement
that
open
tracing
and
open
census
are
one,
but
there
were
no
artifacts.
F
There
was
no
code,
there
was
no
nothing
for
people
to
go
use,
and
so
that
took
time
and
in
particular
early
on
there
was
the
development
of
the
specification
right.
So
even
once
we
had
a
specification
say
for
tracing
that
was
not
final,
but
mostly
complete.
That
still
didn't
mean
there
was
any
libraries.
You
could
link
that
to
your
app
that
would
actually
work,
and
so
it
took
some
time
now
I
will
say
with
rum.
By
contrast,
there
are
parts
of
open
telemetry
that
do
rummy
things
already
right.
We
talked
about.
F
Jay
opens
home
to
js
for
browsers
it
works.
It
does
some
capture
some
amount
of
data.
F
There's
a
swift
sdk
that
I
think
mostly
has
come
from
datadog
that
again
works,
and
I
imagine,
does
a
lot
of
great
things,
and
so
with
with
this
sig,
unlike
perhaps
some
of
the
others
that
were
all
focused
on
new
signal
types,
you
can
start
with
artifacts
that
work
from
well
from
day
one
really,
so
you
don't
necessarily
need
to
follow
the
same
path
as
as
the
original
signal
types
in
open
telemetry.
F
That
being
said,
if
you
want
to
propose
an
event
signal
type
and
then
rely
on
it
natively,
then
you
need
to
go,
define
the
event
signal
type
and
build
it
into
sdks,
and
that
takes
a
lot
of
time.
So
I
mean
my
my
suggestion.
F
Naively
again,
I
probably
won't
be
on
too
many
of
the
future
calls,
but
would
be
probably
start
with
what
you
have
right
like
there's,
there's,
there's
javascript
and
swift,
and
probably
other
sdks,
that
already
work
work
to
extend
those
using
the
existing
metaphors
and
in
parallel
work
on
like
the
a
document
like
we
did
for
logs
that
if
you
find
that
there
are
scenarios
that
are
not
fulfilled
with
the
existing
signal,
types
propose
an
event
signal
type.
Let's
get
it
in,
but
just
know
that
that
that'll
take
time.
F
And
so,
if
you
want
to
see
within
the
next
nine
months,
things
that
are
really
production
usable
across
all
languages.
Then
then
start
with
what
you
have
right
now
and
just
extend
it.
B
I
think
what
it
doesn't
answer
is
basically,
let's
say
from
a
project's
goal
perspective.
If
you
were
to
look
back
five
years
from
now,
you
know
what
would
it?
What
would
you
feel
like?
Would
we
have
we
used
the
right
data
types
for
representation?
Have
you
made
mistakes?
No,
how
does.
F
If
you
ask
me
again,
I
don't
want
to
influence
this
too
much,
but
if
you
ask
me
like
what
is
our
trajectory
for
rum,
probably
going
to
look
like
I'd,
say
just
continued
development
of
the
existing
javascript,
sdk
and
and
and
swift
sdk,
and
probably
extending
the
java
sdk
for
android
and
with
the
existing
signal
types
they
have
and
just
basically
extend
them,
make
them
even
better
and
then
at
some
point
you
know
change
the
model
to
rely
more
on
events,
if
you
feel
like
you're
being
really
held
back
by
the
existing
data
types
have
a
effectively
breaking
change
at
some
point
like
a
year
from
now
or
two
years
from
now,
where
you
say
you
know
what
we're
going
to
switch
this
to
events.
F
B
One
last
point:
I
I
want
to
highlight
that,
especially
with
respect
to
the
mobile
apps
mobile
agents,
it's
going
to
be
extremely
hard
for
making
the
end
users
upgrade
their
apps
right.
So
once
we
deploy
one
version
of
the
app
and
then
tomorrow,
when
we
change
things,
you
know
it's
going
to
be
a
long
cycle
to
get
all
your
end.
Users,
you
know
upgrade
their
apps
on
their
phones,
so
you
know
we
should
keep
in
mind.
B
Whenever
we
plan
a
change,
it
may
not
be
easy
to
roll
it
out.
F
I
have
to
jump
onto
a
different
call.
Apologies.
I
left
links
in
the
agenda
to
the
the
two
docs
and
the
specification
changes
that
we
made
for
the
log
sig
so
martin
and
others
if
you'd
like
to
use
that
as
a
model
feel
free
to
take
a
look,
they're
fairly,
thorough,
I
think
and
and
yeah
I
don't
wanna
influence
it
too
much,
but
my
recommendation
would
be
like
definitely
start
with
to
create
something
akin
to
like
a
product
requirements.
Doc
saying
were
the
rum
sig.
F
These
are
the
things
that
we
want
to
achieve.
This
is
why
and
then
then
come
up
with
a
plan
if
you
want
prototypes
use
those
for
you
know
the
next
sort
of
two
years.
How
do
you
think
you'll
achieve
that,
and
with
that
I
will
go.
F
C
Yeah,
so
that
sounds
good.
I
I
will
show
my
for
my
for
my
list.
It's
gonna
be
creating
the
the
doc
I'm
gonna
share
it
with
everyone
in
the
slide
channel.
I'm
also
put
a
link
in
in
here.
C
D
I'm
no
open
tell
expert,
but
I
get
the
impression
that
we
don't
have
a
new
signal
that
needs
to
be
added,
but
it
does
feel
like
a
lot
needs
to
be
standardized
as
far
as
rom
goes.
Does
that
still
make
sense
for
a
group
to
come
together
just
for
the
purpose
of
standardizing
rum
based
definitions
and
not
have
another
signal.
B
There
is
some
confusion.
I
need
to
read
up
more
on
the
logs,
but
if,
let's
say
events
were
to
be
available
as
a
high
level
signal
today,
it's
only
under
a
span
a
span
can
have
so
if
events
could
be
available
as
a
high
level
signal,
then
that
would
make
it
easier
to
represent
a
lot
of
scenarios.
B
So
today
I
agree
that
traces
can
traces
is,
is
typically
relevant.
Only
for
you
know
representing
any
web
requests.
Network
requests
made
right,
but
any
standalone
events
that
happen
outside
of
making
a
web
request.
It's
not
clear
how
you
represent
them
using
the
existing
signals.
Logs
comes
close
and,
as
somebody
mentioned
you
know,
logs
was
not
part
of
the
standard
until
recently,
so
it
it
could
be
either
logs
or
if
events
it
can
be
bubbled
up
as
a
first
class
entity.
B
You
know
that
that
would
be
ideal
too,
but
I
think
there
is
going
to
be
a
lot
of
confusion
with
respect
to
logs
versus
events.
So
more.
D
B
B
In
fact,
I
would
say
logs
might
be
a
closer
fit
than
a
zero
duration
span,
because
a
span
is
a
container
right.
You
know
it.
It
has
a
beginning
at
an
end
and
anything
that
happens
in
between
you.
You
want
to
include
in
the
in
the
span
as
attributes
so
for
a
standalone
event.
I
I
think
logs
is
is
more
appropriate
than
a
theoretical
spam.
So.
I
I
don't
think
I
don't
think
we
will
add
a
new
signal,
but
the
logs
will
be
the
one
to
do
it
and
I
would
suggest
everyone
will
should
go
and
read
the
logs
back
to
see
if
it
matches
what
we
want
from
it.
I
haven't:
read
it
like
thoroughly
yet,
but
taking
a
look
at
the
law
expect
makes
sense,
I
think
yeah.
I
agree.
A
At
the
logs
data
model,
as
part
of
looking
at
the
the
spec
is
important
too
I,
this
is
probably
an
oversimplification,
but
this
is.
This
is
kind
of
my
read
and
looking
at
the
log
data
model
is
that
logs
might
be
a
good
fit
because
it's
got
less
structure
than
like
the
trace
and
the
metric
data
model.
A
I
really
think
of
like
open
telemetry
logs
is
almost
just
kind
of
like
some
sort
of
a
name
attribute
or
not
even
an
attribute,
just
like
a
name
identifier
like
what
type
of
log
this
is
and
then
a
bag
of
of
attributes.
Along
with
that
right
now,
the
data
model
does
contain
like
some
stuff
that
is
kind
of
like
laggy.
You
know
like
like
message
and
severity
and
so
on,
which
may
not
be
applicable
to
to
the
rum
world,
but
there's
not
a
lot.
A
There's
not
a
lot
of
that,
like
log
specific
stuff
there.
So
so
I
think
that
there
may
be
a
compelling
story
to
just
use
logs
as
kind
of
a
time
stamp
type
and
bag
of
attributes,
because
it's
all
it's
all
there
from
kind
of
what
I'm
I'm
my
read.
But
I'm
super
curious
to
like
explore
the
use
cases
right
to
see
where
that
might
not
fit
for
whatever
reason.
A
None
that
I'm
aware
of,
but
I
won't
claim
definitively,
though
maybe
other
folks
know.
C
And
the
the
other,
the
other
thing
that
that
I
can
think
of
for
logs
is
if,
if
different
thing,
if
different
things
are
from
like
the
the
ram
session,
if
if
some
things
are
captured
as
logs
and
some
things
are
captured
as
traces,
then
you
know
like
how
is
that
gonna
look
like
with
ingest
because,
like
you,
you
will
have
like.
I
mean
I'm
guessing
like
that.
C
You
have
two
different,
like
you
know
in
just
in
just
like
services
that
handle
collecting
spans
and
logs,
so
you're
gonna
have
to
like
join
them
at
some
point,
for
example
like
if
you
wanted
to
replay
a
session
right.
A
Yeah
I'll
be
super
curious
to
see
how
like
different
vendors
approach
that
because,
on
the
one
hand,
I
kind
of
see
the
one
argument
being
like,
maybe
maybe
that's
a
vendor
concern.
You
know
like
if
vendors
already
can
ingest
otlp
log
data.
You
know
to
like,
I
think,
morgan's
point
earlier,
like
some
vendors
already
do
so,
there's
already
some
like
built
up
infrastructure
like
within
the
community,
both
by
the
community
and
by
vendors
themselves
in
support
of
of
the
efforts.
A
There's
there's
some
momentum
there
that
might
push
it
to
like
individual
vendors
to
solve,
but
I
also
like
I
can
see.
Maybe
it
makes
sense
for
us
to
consider
that
and
think
about
how
maybe
that
problem
domain
resides
somewhat
in
the
space
of
like
the
the
open,
telemetry
community.
I
I
There's
also
like
you
can
have
a
page
like
a
logical
piece,
but
what
currently
hotel
does
for
web
is.
I
Like
what
should
be
a
page
load,
when
does
it
end,
like
you
start
loading
a
page
and
like
when?
Do
you
stop
adding
spans
or
events
to
the
same
like
trace
currently
for
hotel?
I
F
C
Because
yeah,
like
you
said
like
there's
like
currently
in
the
hotel.js
repo
like
the
the
page
load,
is,
is
represented
as
a
span,
but
then
like
the
whole
page
duration
is
not
right.
I
Yeah,
because
what
is
the
whole
base
duration?
When
does
it
then
yeah
every
single
page
up?
Does
it
ever
end?
You
can't
really
start
well.
You
can
hook
into
history
api
and
start
like
making
decisions,
but
every
vendor
kind
of.
Does
it
differently.
I
guess
so.
You
can't
really
put
it
into
spec
or
you
could.
I
guess,
but.
C
Yeah
yeah
I
mean
so
like
yeah,
okay.
I
know
I
know
that
severing.
I
think
he
just
left,
but
one
of
the
comments
like
he
was
he
had
on
that
proposal,
that
a
new
signal
proposal
was
that
he
kind
of
thinks
of
the
whole
page
duration
as
like
a
single
span
so
and
the
session
could
be
represented
as
a
span,
which
I
I'm
not
sure.
If
that
makes
sense
or
not.
B
I
think
we
need
to
define
what
is
a
session
right.
I
think
sessions
are
unlike
a
trace.
You
know
they,
don't
they
don't
have
a
definite
boundary
right.
You
know
if,
let's
say
you're
using
a
a
mobile
app
and
you
could
define
sessions
in
different
ways.
You
know
if,
let's
say
one
definition
could
be
like
while
the
app
is
in
the
foreground
or
it
could
be.
You
know
you
know.
If
the
gap
between
two
sessions
is
beyond
five
minutes,
then
you
create
a
new
session.
So
I
think
the
session
is
slightly
fluid.
I
Good
to
yeah
yeah
for
mobile
and
web,
it
might
be
entirely
different
yeah
because
for
web
I
think
many
people
use
what
google
analytics
does
something
like
four-hour
duration
and
then
it
expires
or
you
can
do
it
by
inactivity
or
there
are
like
bunch
of
ways
you
can
do
it
in
browser,
but
for
mobile
yeah,
it's
different.
I
know
any
idea
about
mobile.
G
And
we
define
quite
similar
so
also
in
activity
also
by
maximum
session
duration.
G
B
So
from
our
perspective,
I
think
it
is
sufficient
as
long
as
we
agree
on
the
events
logs
versus
you
know,
using
the
span
for
describing
the
event,
but
the
sessions
can
be
left
out
to
the
to
the
vendor,
because
it's
it's
not
going
to
be
easy
to
define
that
with
clarity.
B
And
I
initially
thought
that
trace
is
a
container
containing
spans
right.
So
similarly,
you
need
something
on
on
the
other
dimension,
where
the
session
could
be
the
master
container.
You
know
and
then
it
could
have
events,
but
then
I
realized
that
metrics
already
are
independent
right,
metrics
don't
have
an
enclosing
container.
You
can.
B
Emit
a
metrics
anytime
themselves
without
an
enclosing
object.
So
similarly
you
know
events
or
logs,
you
know
could
be
modeled
similarly
and
and
then
that
should
be
sufficient
and
session
could
be
one
of
the
attributes,
and
that
could
be
vendor
specific.
C
So
johnny
you
asked
about
like:
does
it
make
sense
to
like
continue
this
this
sig?
I
thought
that
yes,
I
think
there
was
enough
to
discuss
this
for
some
time.
I
mean
it's
very
possible
that
we
will
come
to
the
agreement
very
fast
and
then
there
will
be
no
need
for
this
sick
anymore.
So
I
think
until
then
I
would
say,
let's,
let's,
let's
work
on
this
together
and
see
where
we
get.